I'm currently working on a project using the MongoDB Java API. I have been working on this project for a while, but have recently come across an issue that I cannot resolve. I am trying to make a database system that is fault tolerant. To simulate a database crashing, I have my program connect to a Mongodb server that I have made, execute a simple read or write, and then shut down the database server. I had originally thought that this would cause certain methods that I am calling to throw a MongoException that I could catch and then recover from the database crash. However, I am getting a strange stack trace that says I am throwing an EOFException, among other things. Below is the stack trace itself.
Mar 04, 2013 8:06:15 PM com.mongodb.DBPortPool gotError
WARNING: emptying DBPortPool to polaris.cs.wcu.edu/152.30.5.5:12345 b/c of error
java.io.EOFException
at org.bson.io.Bits.readFully(Bits.java:48)
at org.bson.io.Bits.readFully(Bits.java:33)
at org.bson.io.Bits.readFully(Bits.java:28)
at com.mongodb.Response.<init>(Response.java:40)
at com.mongodb.DBPort.go(DBPort.java:124)
at com.mongodb.DBPort.call(DBPort.java:74)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:282)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:256)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:289)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:274)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
at edu.wcu.cs.capstone.view.AbstractViewEngine.getView(AbstractViewEngine.java:57)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.getView(ServerTransactionManager.java:52)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:183)
at java.lang.Thread.run(Thread.java:722)
Caught exception
Mar 04, 2013 8:06:15 PM com.mongodb.DBPortPool gotError
WARNING: emptying DBPortPool to polaris.cs.wcu.edu/152.30.5.5:12345 b/c of error
java.io.IOException: couldn't connect to [polaris.cs.wcu.edu/152.30.5.5:12345] bc:java.net.ConnectException: Connec
at com.mongodb.DBPort._open(DBPort.java:214)
at com.mongodb.DBPort.go(DBPort.java:107)
at com.mongodb.DBPort.call(DBPort.java:74)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:282)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:256)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:289)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:274)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
at edu.wcu.cs.capstone.view.AbstractViewEngine.getView(AbstractViewEngine.java:61)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.getView(ServerTransactionManager.java:52)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:183)
at java.lang.Thread.run(Thread.java:722)
DB is down.
Exception in thread "Thread-3" java.lang.NullPointerException
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:184)
at java.lang.Thread.run(Thread.java:722)
The Caught Exception and DB is down. are print statements I am using to verify I am catching certain exceptions. Here is the relevant code:
public View getView(Mongo mongo, Query query) throws MongoException,
EOFException {
String connected = "";
try {
connected = mongo.getConnectPoint();
} catch (Exception e) {
throw new MongoException("Error.");
}
System.out.println("Connected: " + connected);
DB db = mongo.getDB(query.getServer());
List<DBObject> viewList = new ArrayList<DBObject>();
DBCollection collection = db.getCollection(query.getCollection());
DBCursor cursor = collection.find(query.getQuery(), excludeID);
try {
cursor.hasNext();
} catch (Exception e) {
System.out.println("Caught exception");
}
while (cursor.hasNext()) {
viewList.add(cursor.next());
}
return new View(viewList);
}
As you can see, the error is occurring when I call cursor.hasNext(). I am also actually still catching the exception that is being thrown because of the Caught exception. However, I am still getting a stack trace as if it was not being caught. I am suspicious that this has something to do with the DBPortPoolgotError() method, but I have looked at the code for this method, and cannot determine what it is actually doing or even how it is being called. (GrepCode link)
As stated above, I thought the behavior for this type of code would have been to throw a MongoException when a call on that specific Mongo object failed because the database was no longer active. Any help that anyone could provide would be greatly appreciated!
this happens due to the driver loosing connection. Here is an issue on the mongo bug tracker referring to it https://jira.mongodb.org/browse/JAVA-481
I had the same issue. It was because I restarted mongod without restart my java server (tomcat in my case). Restarting tomcat solved this issue because the mongo driver was lost
Related
In Java API, No Exception is thrown, albeit erroneous transaction:
try {
…………………………………
logger.info("Delete Document " + uri);
docMgr.delete("rocky-mountains");
System.out.println("Deleted");
} catch (Exception e) {
logger.error("Exception : " + e.toString() );
}
Document rocky-mountains doesn’t exist, however, the API happily declares Deleted:
Jul 05, 2020 9:35:04 PM com.fc.allegro.DeleteDocument deleteDocument
INFO: Delete Document rocky-mountains
Jul 05, 2020 9:35:04 PM com.marklogic.client.impl.DocumentManagerImpl delete
INFO: Deleting rocky-mountains
Deleted
In Query Console, eval detects and throws error:
[1.0-ml] XDMP-DOCNOTFOUND: xdmp:document-delete("rocky-mountains") -- Document not found
As the lesser of two evils, DMSDK implies no document deleted but still doesn’t throw exception:
QueryBatcher batcher = dmManager.newQueryBatcher(new StructuredQueryBuilder().document("rocky-mountains"));
batcher.onUrisReady(new DeleteListener())
.onQueryFailure( exception -> exception.printStackTrace() );
Result:
Jul 05, 2020 9:52:07 PM com.marklogic.client.datamovement.impl.QueryBatcherImpl withForestConfig
INFO: (withForestConfig) Using forests on [localhost] hosts for "allegro"
Batch Deleted
INFO: Job complete, jobBatchNumber=1, jobResultsSoFar=0
I tried checked and unchecked exceptions, but to no avail.
Which MarkLogic Class and Method does enforce throwing exceptions and mitigate risk?
A query transaction via Java API:
Failure:
Success:
There is an important difference between running xdmp:document-delete and using Java API to delete a document. The Java API is a wrapper for the MarkLogic REST-API, which follows the rules for a RESTful API. One important rule of a RESTful API is that calls are expected to be idempotent. In short that means that you should be able to run the call twice and get same reply both times. That is why calls to insert, update, and delete don't throw errors if the document does or does not exist.
See also for instance: https://restfulapi.net/http-methods/#delete
I'd recommend using Data Services, or custom REST extensions if you want your app to be more strict.
HTH!
I use WorldWindGlCanvas in a netbeans TopComponent. When top component is opened WorldWInd try to connect to some url (for example worldwind20.arc.nasa.gov). If there is not internet connection UnknowHostException is occured and a dialog is shown to show this exception.
I want to catch this exception. Note that I know that worldwind could work offline and I can set it work offline but I want to set worldwind online so that it use online tiles when internet connection is provided and it uses cached tiles if there is no internet connection.
Is there any way to catch this exception?
Looking at the source code for World Wind, there doesn't appear to be a way to catch that exception.
Upon manually disconnecting my Internet connection, I received a stack trace of the following:
Jun 16, 2017 6:19:43 PM
gov.nasa.worldwind.util.SessionCacheRetrievalPostProcessor run
SEVERE: Retrieval failed for https://worldwind26.arc.nasa.gov/elev?EXCEPTIONS=application/vnd.ogc.se_xml&REQUEST=GetCapabilities&SERVICE=WMS&VERSION=1.3.0
Jun 16, 2017 6:19:43 PM gov.nasa.worldwind.util.SessionCacheUtils retrieveSessionData
SEVERE: Exception while retrieving resources for https://worldwind26.arc.nasa.gov/elev?EXCEPTIONS=application/vnd.ogc.se_xml&REQUEST=GetCapabilities&SERVICE=WMS&VERSION=1.3.0
java.net.UnknownHostException: worldwind26.arc.nasa.gov
...
at gov.nasa.worldwind.retrieve.HTTPRetriever.doRead(HTTPRetriever.java:48)
at gov.nasa.worldwind.retrieve.URLRetriever.read(URLRetriever.java:368)
at gov.nasa.worldwind.retrieve.URLRetriever.call(URLRetriever.java:244)
at gov.nasa.worldwind.retrieve.URLRetriever.call(URLRetriever.java:27)
at gov.nasa.worldwind.util.SessionCacheUtils.retrieveSessionData(SessionCacheUtils.java:80)
at gov.nasa.worldwind.util.SessionCacheUtils.getOrRetrieveSessionCapabilities(SessionCacheUtils.java:170)
at gov.nasa.worldwind.terrain.BasicElevationModel.retrieveResources(BasicElevationModel.java:2028)
at gov.nasa.worldwind.terrain.BasicElevationModel$3.run(BasicElevationModel.java:2118)
at java.lang.Thread.run(Thread.java:745)
Based on that stack trace, I investigated a few source files:
URLRetriever.java:
try {
...
} catch (Exception e) {
if (!(e instanceof java.net.SocketTimeoutException || e instanceof UnknownHostException
|| e instanceof SocketException)) {
Logging.logger().log(Level.SEVERE,
Logging.getMessage("URLRetriever.ErrorReadingFromConnection", this.url.toString()), e);
}
throw e;
}
SessionCacheUtils.java:
try {
retriever.call();
} catch (Exception e) {
String message = Logging.getMessage("layers.TiledImageLayer.ExceptionRetrievingResources", url.toString());
Logging.logger().log(java.util.logging.Level.SEVERE, message, e);
}
It appears to be handled internally, and thus you seem to be out of luck.
I have a program that makes several requests to a database, opening and closing connections to do what it needs to do. For each connection, it does a select that return 50 results and an update; it does this roughly 10 times per connection. After that, the connection is closed, and a new one is taken. But recently we have been having some random issues in which this SQL exception appears:
java.sql.SQLException: You can't operate on a closed Statement!!!
This error appears randomly. It first appeard mid-execution, and the only moment I managed to reproduce it, it happened at the initiation of the program (when I started it again after that, without making any change, it worked perfectly fine). I've looked around in the code but there's no chance that the connection closes before it can be used (the error occurs while inserting a parameter in a prepared statement). I'm already using c3p0 to manage the connection pool, so I don't know where else to look.
Someone has faced this error before? Any suggestions on where to look or how to reproduce it so I can test it properly?
Edit: Here is the problematic piece of code
try{
//send row to producer
producer.processItem(fields);
if (stmtLasProcessedTransaction == null) {
stmtLasProcessedTransaction = getDbConnection().prepareStatement("UPDATE JTICKET_SUBSCRIBER SET LAST_PROCESSED_ROW = ? WHERE NAME = ? ");
logger.trace("creating statement");
}
//update last processed transaction
logger.trace("Setting the primary key to the prepared statement");
stmtLasProcessedTransaction.setString(1, primaryKey);
logger.trace("Setting the name to the prepared statement");
stmtLasProcessedTransaction.setString(2, name);
logger.trace("Attempting to execute the update on JTICKET_SUBSCRIBER in consumer {}",this.name);
stmtLasProcessedTransaction.executeUpdate();
logger.trace("Commiting execution");
getDbConnection().commit();
logger.trace("Update on JTICKET_SUBSCRIBER in consumer {} executed successfully",this.name);
if (processedRows % 500 == 0) {
logger.trace("resetting prepared statement");
stmtLasProcessedTransaction.close();
logger.trace("statement closed");
stmtLasProcessedTransaction = null;
}
processedRows++;
}catch(SQLException sqlException){
logger.error("An SQL error ocurred while processing consumed item. Closing database connection and statement",sqlException);
try{
stmtLasProcessedTransaction.close();
logger.info("Previous prepared statement of db consumer {} closed",this.name);
}catch(Throwable throwable){
logger.info("Couldn't properly close the prepared statement of db consumer {}",this.name);
}finally{
stmtLasProcessedTransaction=null;
}
try{
databaseConnection.rollback();
logger.info("Rollback of db connection of consumer {} done successfully",this.name);
databaseConnection.close();
logger.info("Previous connection of db consumer {} closed",this.name);
}catch(Throwable throwable){
logger.info("Couldn't rollback and/or close the connection of db consumer {}",this.name);
}finally{
databaseConnection=null;
}
throw sqlException;
}catch(Exception exception){
logger.error("An error ocurred while processing consumed item.", exception);
throw exception;
}
The prepared statement is a local variable, not a function one, so it can be re-used with every loop (this piece is part of a function that is called once for every result in a query that is done with a prepared statement to the same db connection). The error occurs when I'm trying to work on the prepared statement.
And the latest stack:
18/06/15 15:54:34.841 [ecbcbcmt] TRACE DatabaseConsumer - creating statement 18/06/15 15:54:34.850 [ecbcbcmt] ERROR DatabaseConsumer - An
error ocurred while processing consumed item. java.sql.SQLException:
You can't operate on a closed Statement!!! at
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:118)
~[mchange-commons-java-0.2.9.jar:0.2.9] at
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:77)
~[mchange-commons-java-0.2.9.jar:0.2.9] at
com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.setString(NewProxyPreparedStatement.java:488)
~[c3p0-0.9.5.jar:0.9.5] at
us.inswitch.jticket.subscriber.consumer.database.DatabaseConsumer.processRow(DatabaseConsumer.java:152)
[bin/:na] at
us.inswitch.jticket.subscriber.consumer.database.DatabaseNumberConsumer.processRows(DatabaseNumberConsumer.java:73)
[bin/:na] at
us.inswitch.jticket.subscriber.consumer.database.DatabaseConsumer.start(DatabaseConsumer.java:65)
[bin/:na] at
us.inswitch.jticket.subscriber.consumer.Consumer.run(Consumer.java:35)
[bin/:na] at java.lang.Thread.run(Thread.java:662) [na:1.6.0_38-ea]
Caused by: java.lang.NullPointerException: null at
com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.setString(NewProxyPreparedStatement.java:482)
~[c3p0-0.9.5.jar:0.9.5] ... 5 common frames omitted 18/06/15
15:54:34.852 [ecbcbcmt] WARN DatabaseConsumer - An error ocurred
while consuming table data. DatabaseConsumer will be restarted.
java.sql.SQLException: You can't operate on a closed Statement!!! at
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:118)
~[mchange-commons-java-0.2.9.jar:0.2.9] at
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:77)
~[mchange-commons-java-0.2.9.jar:0.2.9] at
com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.setString(NewProxyPreparedStatement.java:488)
~[c3p0-0.9.5.jar:0.9.5] at
us.inswitch.jticket.subscriber.consumer.database.DatabaseConsumer.processRow(DatabaseConsumer.java:152)
~[bin/:na] at
us.inswitch.jticket.subscriber.consumer.database.DatabaseNumberConsumer.processRows(DatabaseNumberConsumer.java:73)
~[bin/:na] at
us.inswitch.jticket.subscriber.consumer.database.DatabaseConsumer.start(DatabaseConsumer.java:65)
~[bin/:na] at
us.inswitch.jticket.subscriber.consumer.Consumer.run(Consumer.java:35)
[bin/:na] at java.lang.Thread.run(Thread.java:662) [na:1.6.0_38-ea]
Caused by: java.lang.NullPointerException: null at
com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.setString(NewProxyPreparedStatement.java:482)
~[c3p0-0.9.5.jar:0.9.5] ... 5 common frames omitted
It's weird because it's completely random. We've had the program up and running for a while now, with all the connections working perfectly fine, and we get this kind of problem.
Use local variables, or otherwise use PreparedStatements carefully.
This avoids concurrent usage as in a web application.
try (PreparedStatement stmt = conn.prepareStatement(sql)) {
...
try (ResultSet rs = stmt.executeQuery()) {
...
} // rs close
} // Does stm.close()
The try-with-resources also closes when an exception is thrown.
The statement stmtLasProcessedTransaction.close(); is present at two places which is fishy!!
1. within try block in conditional if
2. within catch block
Better programming practice is to have only one close statement, that too in finally block
PS: You can have try-catch-finally within finally block as well
I am running two axis2 services which communicate with each other. On every service startup I get this error:
2014-02-24 13:02:31,258 [INFO ] HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:621)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:193)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:404)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:231)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:443)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:406)
at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:446)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Since this error is not important, I would like to catch it and to print some better error message instead of the whole stack trace. Where do I catch this error?
Looking at the stack trace, I don't think you can catch it. Catching it would require that you own code somewhere in the Thread where the exception is being thrown.
Looking at the lowest stack in the trace shows this:
at java.lang.Thread.run(Thread.java:724)
To me this says that the exception is occurring in a thread most likely started by Axis. Because of this you can't catch it and show an error message.
If this is expected behavior, the best you can do is to configure your logging framework not to show INFOs from Axis. Be aware that this may mean you'll also miss more useful error messages as well.
All in all, I would focus on how to solve the "Unable to sendViaPost" from happening rather than suppressing the logging statement.
To answer your comment question: As you can see from the stack trace, the exception is not caught by any client code but is bubbled up to Thread itself. This is the stopping point for an Exception and where it stops. If you were going to catch it you'd have to have code in its call stack (which you don't, since when the thread is created by Axis a new call stack is created for the new thread Axis starts).
Read more here. The only difference in your case is that since the exception is not thrown on the main thread the program doesn't exit, but the thread where the exception occurs is terminated.
To sum it up: You have no code in the call stack and therefore cannot catch the exception. The only other option is to turn of INFO statements for Axis.
If I am understanding the question properly you're attempting to catch something that is not the exception that is being thrown.
This:
HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
is what is being attempted. When it failed it's throwing a ConnectException.
Which you can simply catch with
try{
//Code that Makes the Connection
}
catch (ConnectException e)
{
e.printStackTrace();//Or What ever your message may be
}
Without seeing some code it's impossible to give a definitive answer. But this likely will solve the problem.
One Caveat, if you do catch a ConnectException to suppress it, you could suppress when there actually is a problem that would also throw a ConnectException.
If this is happening when you are starting up the server you might want to check why this is happening before trying to suppress it.
If it's refusing the connection that you are attempting you might want to ensure where it is connecting to has an available socket to connect to.
2014-02-24 13:02:31,258 [INFO] HTTPSender - Unable to
sendViaPost to
url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
Well, if you look closely, the message which you are trying to catch isn't an ERROR at all. It's an INFO log generated from HTTPSender. Only thing which you should catch in this entire stacktrace is java.net.ConnectException and check for message Connection refused.
You can make it easier for your clients though and provide a message, by wrapping the java.net.ConnectException with message Connection refused or throwing a custom exception with the original exception as the cause.
UPDATE
java.net.ConnectException is an elementary exception in network transactions. Generally standard libraries do not catch them unless there is something specific to be done.
In this case, if you are unable to catch hold of java.net.ConnectException, then you can look out to catch AxisFault thrown by org.apache.axis2.description.OutInAxisOperationClient.send.
Below snippet may be useful for you.
try {
...
} catch (RemoteException ex) {
if(ex instanceof AxisFault){
logger.error("Axis Fault error: " + ((AxisFault)ex).getFaultString());
throw new CustomExcpetion(" Custom Message ");
}
}
Also note that AxisFault is a subclass of java.rmi.RemoteException and this will not get caught when you use java.lang.Exception in a catch statement.
Shishir
We are facing an issue in our production env. We have searched the net high and low and we were not able to come up with any answers.
This error(stacktrace below) occurs when an ejb lookup is made from managed server 1 to manager server 2. Virtual ip is used for the lookup. It occurs intermittently and at random intervals. We are not able to identify any pattern and If the ejb call is attempted two or three times, it gets through successfully.
Env details :
server : weblogic 10.0 MP1 running on java 1.5
os : solaris
Pls revert if any other details are required.
Source used for lookup :
private TreControlRemote getController() throws Exception {
Context context = null;
Properties p = new Properties();
TreControlHome treHome = null;
TreControlRemote remote = null;
ConfigurationLoader lAppLoader = null;
try {
mLog.debug("Entering");
lAppLoader = PropertiesFileLoader.getInstance("context.properties");
p.put(Context.INITIAL_CONTEXT_FACTORY, lAppLoader.getValue("INITIAL_CONTEXT_FACTORY"));
p.put(Context.PROVIDER_URL, lAppLoader.getValue("PROVIDER_URL"));
context = new InitialContext(p);
mLog.debug("context : " + context.getEnvironment());
remote = null;
treHome = (TreControlHome) context.lookup("CONTROL");
mLog.debug("Object --->>>>" + treHome);
remote = (TreControlRemote) treHome.create();
mLog.debug("Leaving");
} catch (Exception ex) {
mLog.fatal("Exception while getting remote", ex);
ex.printStackTrace();
throw ex;
} finally {
lAppLoader = null;
}
return remote;
}
The url is a virtual ip pointing to managed server 2 and it contains a ejb with jndi "CONTROL". The problem is that it successful on certain occassions and fails randomly with the error:
stack trace of the error :
*javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.StreamCorruptedException]
at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslator.java:74)
at weblogic.jndi.internal.WLContextImpl.translateException(WLContextImpl.java:426)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:382)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:367)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
```````````````````````````````````````````````````````````````````
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.StreamCorruptedException
at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:221)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:338)
at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:252)
at weblogic.jndi.internal.ServerNamingNode_1001_WLStub.lookup(Unknown Source)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:379)
... 33 more
Caused by: java.io.StreamCorruptedException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1332)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:195)
at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:565)
at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:191)
at weblogic.jndi.internal.RootNamingNode_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:479)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:475)
at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:59)
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:1016)
... 2 more*
Obtained the below mentioned stacktrace from the weblogic log. Could this error be related to our problem mentioned above?
*####<Aug 25, 2009 2:11:04 AM BST> <Info> <RJVM> <pkssv049> <M1AP4> <ACTIVE ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <1251162664181> <BEA-000513> <Failure in heartbeat trigger for RJVM: 5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3
java.io.IOException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl#189ed0e - id: '5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3' connect time: 'Mon Aug 24 20:24:02 BST 2009'' has already been shut down.
java.io.IOException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl#189ed0e - id: '5433424963141690658S:169.93.73.0:10040,10040,-1,-1,-1,-1,-1:pkssv049.***.net:10240,pkssv049.***.net:10241,pkssv050.***.net:10240,pkssv050.***.net:10241:LIQP1_LMSDomain:M1AP3' connect time: 'Mon Aug 24 20:24:02 BST 2009'' has already been shut down
at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java:1686)
at weblogic.rjvm.ConnectionManager.createHeartbeatMsg(ConnectionManager.java:1629)
at weblogic.rjvm.ConnectionManager.sendHeartbeatMsg(ConnectionManager.java:607)
at weblogic.rjvm.RJVMImpl$HeartbeatChecker.timerExpired(RJVMImpl.java:1540)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)*
Any help would be greatly appreciated.
Here is some additional info..
Is the problem intermittent, or does reproduce every single time? If the problem is intermittent, do you know what conditions it occurs under?
It occurs intermittently and we are not able to observe any pattern.
Are there any other errors/warnings logged either on the local server or on the remote server?
We see a lot of connection refused errors in the weblogic log
Are both the managed servers in the same domain?
Yes
when you pass an instance of com.myclientcompany.server.eai.interactionspecimpl as argument to
your ejb. the weblogic needs to deserialize(unmarshal) the object under the ejb context, and its needs the required class for unmarshalling. so if you include the interactionspecimpl class in your ejb-jar file, then you do not need to include those classes in your servers classpath
This issue can occur if you have either a Duplicate entry for or due to a blank space in between.
You need to check all the configuration files including the JDBC , JMS and the config.xml file to find such and entry.
Check if you have left a blank space while entering the JNDI name from the console as well.
Removing the blank space or removing the duplicate entry resolves this issue.