Develop Reference

What causes elusive: NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint()?

Many people have asked for help with this error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
at
org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:51)
at
org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:152)
at
javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
...
But no request I can find ever provides a conclusive answer. Just suggestions to tinker with jars.
I believe that’s because there’s an inconsistency in the structure of Jboss interfaces. Can anyone confirm or correct that?
Here’s my code that throws the above error:
final private Properties env = new Properties() {
{put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
put(Context.PROVIDER_URL, "http-remoting://localhost:9990");
put(Context.SECURITY_PRINCIPAL, "myID");
put(Context.SECURITY_CREDENTIALS, "myPassword");
put("jboss.naming.client.ejb.context", true);
}
};
/****************************************************
* myID & myPassword open the Admin GUI for wildfly *
* on localhost:9990 *
****************************************************/
Context ctx = new InitialContext(this.env);
To determine the required jars I removed all jars from the Build path.
Then I ran my program till all ClassNotFoundException were gone.
First Error
java.lang.ClassNotFoundException:
org.jboss.naming.remote.client.InitialContextFactory]
Added jboss-remote-naming-1.0.7.final.jar to class path
Second Error
java.lang.NoClassDefFoundError:
org/jboss/logging/Logger
Added jboss-logging.jar
Third Error
java.lang.NoClassDefFoundError:
org/xnio/Options
Added xnio-api-3.0.7.ga.jar
Fourth Error
java.lang.NoClassDefFoundError:
org/jboss/remoting3/spi/ConnectionProviderFactory
Added jboss-remoting-3.jar
Fifth Error
java.lang.NoClassDefFoundError:
org/jboss/ejb/client/EJBClientContextIdentifier
Added jboss-ejb-client-1.0.19.final.jar
FINAL AND FATAL ERROR
(Note: All NoClassDefFoundError have been cleared)
java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
Using Eclipse’s Project Explorer I verified:
a. jboss-remoting3.jar has the org.jboss.remoting3.Remoting Class.
b. That Remoting Class has this Method:
public Endpoint createEndpoint (String, Executor, OptionMap)
Note it calls for 3 parameters.
BUT the FINAL FATAL ERROR above calls for
public Endpoint createEndpoint (String, OptionMap)
Note: it calls for 2 parameters. Hence the NoSuchMethodError.
Looking at the top lines in the stack trace, I guess
org.jboss.naming.remote.client.InitialContextFactory.getInitialContext() is trying to call org.jboss.remoting3.Remoting.createEndpoint() using 2 parameters, but org.jboss.remoting3.Remoting only defines createEndpoint() with a 3-paramater signature.
Is that supposed to even be possible?
A jar that says it has the org.jboss.remoting3 package whose Remoting class has a single createEndpoint() method with a 3-parameter signature, and another jar that says it has the org.jboss.remoting3 package whose Remoting class has another createEndpoint() method with a 2-parameter signature?
HELP!
I mean do I need to look through every org.jboss.remoting3 package to find one whose Remoting class has a 2 parameter createEnpoint() method?
Or am I missing something important.
I mean this does explain how many questions have been posted about this error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
And explain why there is never a conclusive explanation or solution other than fiddling with jars and build path.
I mean getting an InitialContext from WildFly running on the same PC as the Java program should be a trivial process. But it hasn’t been. Maybe it's because of inconsistencies in the API.

Thanks to Christoph Böhme:
jboss-logging-3.1.4.GA.jar has an org.jboss.remeoting package with a Remoting class that has createEndpoint() with a 0, 2 and 3 parameter signature.
Replacing jboss-remoting-4.0.7.Final.jar with the above jar was all it required to clear the NoSuchMethodError.
Hope that helps others.

ServletUnit RequestDispatcher forward() / include() methods AbstractMethodError

I'm doing a java web app with a servlet and I wanted to write some tests to check its functionality (ex. authorization form). I hadn't been using any framework, just bare java in eclipse with tomcat 7.0
I've run into an error while trying to test authorization input. The app would check the login-password pair and then redirect using RequestDispatcher.forward() or RequestDispatcher.include() methods. But when executing them it throws an error with the following stack trace:
java.lang.reflect.Inv­ocationTargetExceptio­n
at su­n.reflect.NativeMetho­dAccessorImpl.invoke0­(Native Method)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke(­Unknown Source)
at su­n.reflect.DelegatingM­ethodAccessorImpl.inv­oke(Unknown Source)
at ja­va.lang.reflect.Metho­d.invoke(Unknown Sour­ce)
at en­tryPoint.Dispatcher.d­ispatch(Dispatcher.ja­va:166)
at en­tryPoint.Dispatcher.s­ervice(Dispatcher.jav­a:49)
at ja­vax.servlet.http.Http­Servlet.service(HttpS­ervlet.java:728)
at co­m.meterware.servletun­it.InvocationContextI­mpl.service(Invocatio­nContextImpl.java:76)
at co­m.meterware.servletun­it.ServletUnitClient.­newResponse(ServletUn­itClient.java:126)
at co­m.meterware.httpunit.­WebClient.createRespo­nse(WebClient.java:64­7)
at co­m.meterware.httpunit.­WebWindow.getResource­(WebWindow.java:220)
at co­m.meterware.httpunit.­WebWindow.getSubframe­Response(WebWindow.ja­va:181)
at co­m.meterware.httpunit.­WebWindow.getResponse­(WebWindow.java:158)
at co­m.meterware.httpunit.­WebWindow.updateWindo­w(WebWindow.java:199)
at co­m.meterware.httpunit.­WebWindow.getSubframe­Response(WebWindow.ja­va:183)
at co­m.meterware.httpunit.­WebWindow.getResponse­(WebWindow.java:158)
at co­m.meterware.httpunit.­WebClient.getResponse­(WebClient.java:122)
at te­st.Authorization.test­AuthCorrectInput_Wron­gPassword(Authorizati­on.java:102)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke0­(Native Method)
at su­n.reflect.NativeMetho­dAccessorImpl.invoke(­Unknown Source)
at su­n.reflect.DelegatingM­ethodAccessorImpl.inv­oke(Unknown Source)
at ja­va.lang.reflect.Metho­d.invoke(Unknown Sour­ce)
at or­g.junit.runners.model­.FrameworkMethod$1.ru­nReflectiveCall(Frame­workMethod.java:45)
at or­g.junit.internal.runn­ers.model.ReflectiveC­allable.run(Reflectiv­eCallable.java:15)
at or­g.junit.runners.model­.FrameworkMethod.invo­keExplosively(Framewo­rkMethod.java:42)
at or­g.junit.internal.runn­ers.statements.Invoke­Method.evaluate(Invok­eMethod.java:20)
at or­g.junit.internal.runn­ers.statements.RunBef­ores.evaluate(RunBefo­res.java:28)
at or­g.junit.runners.Paren­tRunner.runLeaf(Paren­tRunner.java:263)
at or­g.junit.runners.Block­JUnit4ClassRunner.run­Child(BlockJUnit4Clas­sRunner.java:68)
at or­g.junit.runners.Block­JUnit4ClassRunner.run­Child(BlockJUnit4Clas­sRunner.java:47)
at or­g.junit.runners.Paren­tRunner$3.run(ParentR­unner.java:231)
at or­g.junit.runners.Paren­tRunner$1.schedule(Pa­rentRunner.java:60)
at or­g.junit.runners.Paren­tRunner.runChildren(P­arentRunner.java:229)
at or­g.junit.runners.Paren­tRunner.access$000(Pa­rentRunner.java:50)
at or­g.junit.runners.Paren­tRunner$2.evaluate(Pa­rentRunner.java:222)
at or­g.junit.internal.runn­ers.statements.RunBef­ores.evaluate(RunBefo­res.java:28)
at or­g.junit.internal.runn­ers.statements.RunAft­ers.evaluate(RunAfter­s.java:30)
at or­g.junit.runners.Paren­tRunner.run(ParentRun­ner.java:300)
at or­g.eclipse.jdt.interna­l.junit4.runner.JUnit­4TestReference.run(JU­nit4TestReference.jav­a:50)
at or­g.eclipse.jdt.interna­l.junit.runner.TestEx­ecution.run(TestExecu­tion.java:38)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.runTests(R­emoteTestRunner.java:­467)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.runTests(R­emoteTestRunner.java:­683)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.run(Remote­TestRunner.java:390)
at or­g.eclipse.jdt.interna­l.junit.runner.Remote­TestRunner.main(Remot­eTestRunner.java:197)
Caused by: javax.serv­let.ServletException:­ java.lang.AbstractMe­thodError: com.meterw­are.servletunit.Servl­etUnitServletContext.­getClassLoader()Ljava­/lang/ClassLoader;
at or­g.apache.jasper.servl­et.JspServlet.service­(JspServlet.java:343)
at ja­vax.servlet.http.Http­Servlet.service(HttpS­ervlet.java:728)
at co­m.meterware.servletun­it.RequestDispatcherI­mpl.forward(RequestDi­spatcherImpl.java:54)
at co­ntrollers.Auth.index(­Auth.java:78)
... 4­4 more
Caused by: java.lang.­AbstractMethodError: ­com.meterware.servlet­unit.ServletUnitServl­etContext.getClassLoa­der()Ljava/lang/Class­Loader;
at or­g.apache.jasper.compi­ler.TagPluginManager.­init(TagPluginManager­.java:72)
at or­g.apache.jasper.compi­ler.TagPluginManager.­apply(TagPluginManage­r.java:56)
at or­g.apache.jasper.compi­ler.Compiler.generate­Java(Compiler.java:24­0)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:373)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:353)
at or­g.apache.jasper.compi­ler.Compiler.compile(­Compiler.java:340)
at or­g.apache.jasper.JspCo­mpilationContext.comp­ile(JspCompilationCon­text.java:646)
at or­g.apache.jasper.servl­et.JspServletWrapper.­service(JspServletWra­pper.java:357) ­
at or­g.apache.jasper.servl­et.JspServlet.service­JspFile(JspServlet.ja­va:390)
at or­g.apache.jasper.servl­et.JspServlet.service­(JspServlet.java:334)
... 4­7 more
The first block represents an invocation error caught by central controller (Dispatcher) servlet while invoking method in which an AbstractMethodError had been thrown. The second and third ones are about that error.
The code of the test method is as follows:
#Test
publi­c void testAuthIncorr­ectInput_Long() throw­s Exception {
W­ebRequest request = n­ew PostMethodWebReque­st("http://localhost:­8080/CenralReportDL/D­ispatcher?query=auth"­);
S­tring longString = ne­w String();
f­or (int i = 0; i < 52­; i++) {
­ longString­ += "aA_ba";
}
reque­st.setParameter("user­name", longString);
reque­st.setParameter("pass­word", longString);
W­ebResponse response =­ client.getResponse(r­equest);
a­ssertNotNull("No resp­onse received", respo­nse);
}
How can I get rid of this error? Is there a workaround? Should I maybe use some other means of servlet testing?
Also please do not suggest framework-specific testing utils such as strutstest, I want an actual solution for bare java web application.
UPDATE: In response to #JekinKalariya - I had a JasperException before. It complained about files not being in /WEB-INF folder, but due to my project structure they all were in /WebContent/WEB-INF. I was so frustrated because of that I just copied entire folder. Silly thing to do. I deleted it and now I'm back to that JasperException.
UPDATE: Now, I've done some research and found some answers on this issue. Didn't work for me though. I also found a suggestion to change a target runtime to J2EE Preview, which raised a different kind of exception:
com.meterware.httpuni­t.HttpNotFoundExcepti­on: Error on HTTP req­uest: 404 java.lang.C­lassNotFoundException­: org.apache.jasper.s­ervlet.JspServlet [http://localhost/WEB-­INF/jsp/auth.jsp]

CXF 2.7.16: ClassFormatError: JVMCFRE114 field name is invalid; jaxws_asm

We upgrade CXF from v2.2.6 to v2.7.16. When we start IBM WebSphere Application Server v7.0.0.33 in Linux machine, error is reported for jaxws_asm/RetrieveRssFeedResponse:
Caused by: java.lang.ClassFormatError: JVMCFRE114 field name is invalid; class=com/abc/mobile/service/rss/jaxws_asm/RetrieveRssFeedResponse, offset=0
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:287)
at java.lang.ClassLoader.defineClass(ClassLoader.java:224)
at org.apache.cxf.common.util.ASMHelper$TypeHelperClassLoader.defineClass(ASMHelper.java:367)
at org.apache.cxf.common.util.ASMHelper.loadClass(ASMHelper.java:316)
at org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:229)
Here is our current understanding:
This error does not occur in local Windows machine WAS7.0.0.11
Class jaxws_asm.RetrieveRssFeedResponse does not exist at compile time. Instead, it's generated by CXF at runtime.
Our application code has Java package: com/abc/mobile/service/rss
Class WrapperClassGenerator in org.apache.cxf/cxf-bundle.jar/2.7.16 appends Java package “jaxws_asm” at line 160:
String pkg = new StringBuilder().append(getPackageName(method)).append(".jaxws_asm").append(anonymous ? "_an" : "").toString();
Our application code com.abc.mobile.service.rss.GlobalProductRssService.java has:
#WebMethod(operationName = "retrieveRssFeed")
Class WrapperClassGenerator in org.apache.cxf/cxf-bundle.jar/2.7.16 appends class name “Response” at line 164:
className = new StringBuilder().append(className).append("Response").toString();
We tried to add asm/asm.jar/3.3.1 to WEB-INF/lib or WAS7.0/java/jre/lib/ext. It did not help.
We have enabled class loading trace log by following IBM MustGather document: http://www-01.ibm.com/support/docview.wss?uid=swg21196187.
Trace log shows that "jaxws.RetrieveRssFeedResponse" is being loaded:
[1/5/16 11:39:04:447 EST] 00000014 CompoundClass > loadClass com.abc.mobile.service.rss.jaxws.RetrieveRssFeedResponse this=com.ibm.ws.classloader.CompoundClassLoader#736d736d[PL][war:US-EAR/US.war] Entry
[1/5/16 11:39:04:447 EST] 00000014 CompoundClass > loadClass com.abc.mobile.service.rss.jaxws.RetrieveRssFeedResponse this=com.ibm.ws.classloader.CompoundClassLoader#70207020[app:US-EAR] Entry
[1/5/16 11:39:04:448 EST] 00000014 CompoundClass < loadClass com.abc.mobile.service.rss.jaxws.RetrieveRssFeedResponse failed Exit
[1/5/16 11:39:04:448 EST] 00000014 CompoundClass < loadClass com.abc.mobile.service.rss.jaxws.RetrieveRssFeedResponse failed Exit
I have not found out why the above class loading trace log loads "jaxws.RetrieveRssFeedResponse". It's highly appreciated if anyone could share any clue about how to solve this ClassFormatError.

Thank you so much for your help. The issue has been solved by removing "[]" from #WebResult annotation. In other words, originally our application code has:
#WebMethod(operationName = "retrieveRssFeed")
#WebResult(name = "RssChannelDTO[]")
The error is solved by changing it to:
#WebMethod(operationName = "retrieveRssFeed")
#WebResult(name = "RssChannelDTO")
What we have done is:
Modify CXF/2.7.16/ASMHelper.java defineClass() method to print the dynamically generated classes. Totally 302 classes have been printed out.
System.out.println("***********ASMHelper.TypeHelperClassLoader.defineClass(): " + name.replace('/', '.'));
try {
java.io.FileOutputStream fos = new java.io.FileOutputStream(name.replace('/', '.') + ".class");
fos.write(bytes);
fos.close();
} catch (java.io.IOException ioe) {
ioe.printStackTrace();
}
Among all 302 generated classes, only RetrieveRssFeedResponse.class has "[]" in field name
#XmlElement(name="RssChannelDTO[]")
private RssChannelDTO[] RssChannelDTO[];
Modify CXF/2.7.16/ASMHelper.java to add main method (because constructor of inner class TypeHelperClassLoader is private) to call loader.defineClass() method
After running main method, error is reported:
Exception in thread "main" java.lang.ClassFormatError: Illegal field name "RssChannelDTO[]" in class RetrieveRssFeedResponse
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
at org.apache.cxf.common.util.ASMHelper$TypeHelperClassLoader.defineClass(ASMHelper.java:377)
at org.apache.cxf.common.util.ASMHelper.main(ASMHelper.java:513)
Then we modified our application code to remove "[]" from #WebResult annotation. The generated RetrieveRssFeedResponse.class has:
#XmlElement(name="RssChannelDTO")
private RssChannelDTO[] RssChannelDTO;
Now error is gone and our WebSphere Application Server v7.0 can be started without any error.
Regarding the IBM class loading trace log shows only "jaxws.RetrieveRssFeedResponse", I guess the situation is:
IBM logging statement might ignore "_" and anything after it during logging
But IBM class loader can still load "jaxws_asm.RetrieveRssFeedResponse"
Anyway, this is only my guess and I have not checked any IBM source code.

Using MTOM with StreamingAttachment - failing on jetty start

please advise!
Defined on server side:
/////////////////
#StreamingAttachment(parseEagerly=true)
#MTOM(threshold=10000000 )
/////////////////
Everything compiles with no errors.
When jetty is started, below error is shown:
2012-05-16 04:31:48.403::INFO: jetty-6.1.4
SEVERE : May 16, 2012 4:31:49 AM: WSSERVLET11: failed to parse runtime descriptor: javax.xml.ws.WebServiceException: Annotation #com.sun.xml.internal.ws.developer.Str
mingAttachment(parseEagerly=true, dir=, memoryThreshold=1048576) is not recognizable, atleast one constructor of class com.sun.xml.internal.ws.developer.StreamingAtta
mentFeature should be marked with #FeatureConstructor (com.sun.xml.ws.transport.http.servlet.WSServletContextListener::contextInitialized)
javax.xml.ws.WebServiceException: Annotation #com.sun.xml.internal.ws.developer.StreamingAttachment(parseEagerly=true, dir=, memoryThreshold=1048576) is not cognizable, atleast one constructor of class com.sun.xml.internal.ws.developer.StreamingAttachmentFeature should be marked with #FeatureConstructor

weblogic context lookup error : java.rmi.UnmarshalException: error unmarshalling arguments

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.