I get the following exception in the Weblogic server,from the logs, it is definitely something internal to the weblogic, but, not sure which part of the application the weblogic is trying to archive, do you know why it is happening?
<Nov 4, 2015 10:32:07 AM CST> <Info> <EJB> <BEA-010213> <Message-Driven EJB: WLIArchiverSchedulerMDB's transaction was rolledback. The transaction details are: Xid=BEA1-0482AE5EBACD7EBCD75C(5835637),Status=Rolled back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=60,XAServerResourceInfo[JMS_cgJMSStore]=(ServerResourceInfo[JMS_cgJMSStore]=(state=rolledback,assigned=msolvint101-prd01-z),xar=JMS_cgJMSStore,re-Registered = false),XAServerResourceInfo[cgPool]=(ServerResourceInfo[cgPool]=(state=rolledback,assigned=msolvint101-prd01-z),xar=cgPool,re-Registered = false),SCInfo[m6intdomain+msolvint101-prd01-z]=(state=rolledback),properties=({ISOLATION LEVEL=2}),local properties=({weblogic.jdbc.jta.cgPool=weblogic.jdbc.wrapper.TxInfo#1ff65e5}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=msolvint101-prd01-z+msolvint101-prd01-z.tds.local:7001+m6intdomain+t3+, XAResources={JMS_FileStore, JMS_pluginStore, cgPool, NetExpert Pool, MSLVPool, JMS_cgJMSStore, MSLVwliPool, bpmArchPool},NonXAResources={})],CoordinatorURL=msolvint101-prd01-z+msolvint101-prd01-z.tds.local:7001+m6intdomain+t3+).>
<Nov 4, 2015 10:32:07 AM CST> <Warning> <EJB> <BEA-010065> <MessageDrivenBean threw an Exception in onMessage(). The exception was:
java.lang.IllegalStateException: [EJB:010158]Illegal attempt to call EJBContext.setRollbackOnly() from an EJB that was not participating in a transaction..
java.lang.IllegalStateException: [EJB:010158]Illegal attempt to call EJBContext.setRollbackOnly() from an EJB that was not participating in a transaction.
at weblogic.ejb20.internal.BaseEJBContext.setRollbackOnly(BaseEJBContext.java:348)
at weblogic.ejb20.internal.MessageDrivenEJBContextImpl.setRollbackOnly(MessageDrivenEJBContextImpl.java:56)
at com.bea.wli.management.archiving.WLIArchiverSchedulerMDB.onMessage(WLIArchiverSchedulerMDB.java:164)
at com.bea.wli.management.archiving.WLIArchiverSchedulerMDB.onMessage(WLIArchiverSchedulerMDB.java:75)
at weblogic.ejb20.internal.MDListener.execute(MDListener.java:400)
at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:333)
at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:298)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2686)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
Make sure your MDB transaction attribute is set to Required and not to NotSupported
Related
I've one application in which I'm trying to process a file which contains 500k transactions, the processing of file completes in 3 minutes and the timeout is set to 15 minutes, still getting timeout exception during commit.
Getting Below Exception in Websphere System Logs while committing the transaction from my code in spring, due to which all the transactions are rolledback;
XATransaction E J2CA0027E: An exception occurred while invoking end on an XA Resource Adapter from DataSource JMS$FundtechQConFactory$JMSManagedConnection#75, within transaction ID {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54),
data(0000017bdaabecde0000000b6a6fc584d5dba62aea917f1902693232b82dd8a4ff309f370000017bdaabecde0000000b6a6fc584d5dba62aea917f1902693232b82dd8a4ff309f37000000010000000000000000000000000097)} : javax.transaction.xa.XAException: The method 'xa_end' has failed with errorCode '106'.
at com.ibm.mq.jmqi.JmqiXAResource.end(JmqiXAResource.java:559)
at com.ibm.ejs.jms.JMSManagedSession$JMSXAResource.end(JMSManagedSession.java:1410)
at com.ibm.ejs.j2c.XATransactionWrapper.end(XATransactionWrapper.java:623)
at com.ibm.ws.Transaction.JTA.JTAResourceBase.end(JTAResourceBase.java:254)
at com.ibm.tx.jta.impl.RegisteredResources.sendEnd(RegisteredResources.java:1154)
at com.ibm.tx.jta.impl.RegisteredResources.distributeEnd(RegisteredResources.java:1130)
at com.ibm.tx.jta.impl.TransactionImpl.distributeEnd(TransactionImpl.java:1748)
at com.ibm.tx.jta.impl.TransactionImpl.prepareResources(TransactionImpl.java:1478)
at com.ibm.ws.tx.jta.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:630)
at com.ibm.tx.jta.impl.TransactionImpl.processCommit(TransactionImpl.java:1040)
at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:974)
at com.ibm.ws.tx.jta.TranManagerImpl.commit(TranManagerImpl.java:439)
at com.ibm.tx.jta.impl.TranManagerSet.commit(TranManagerSet.java:191)
at com.ibm.ws.tx.jta.UserTransactionImpl.commit(UserTransactionImpl.java:307)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1035)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:743)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:711)
XATransaction E J2CA0027E: An exception occurred while invoking rollback on an XA Resource Adapter from DataSource JMS$FundtechQConFactory$JMSManagedConnection#206, within transaction ID {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54),
data(0000017bdaabecde0000000b6a6fc584d5dba62aea917f1902693232b82dd8a4ff309f370000017bdaabecde0000000b6a6fc584d5dba62aea917f1902693232b82dd8a4ff309f37000000010000000000000000000000000003)} : javax.transaction.xa.XAException: The method 'xa_rollback' has failed with errorCode '-4'.
at com.ibm.mq.jmqi.JmqiXAResource.rollback(JmqiXAResource.java:874)
at com.ibm.ejs.jms.JMSManagedSession$JMSXAResource.rollback(JMSManagedSession.java:1201)
at com.ibm.ejs.j2c.XATransactionWrapper.rollback(XATransactionWrapper.java:1328)
at com.ibm.tx.jta.impl.JTAXAResourceImpl.rollback(JTAXAResourceImpl.java:381)
at com.ibm.tx.jta.impl.RegisteredResources.deliverOutcome(RegisteredResources.java:1718)
at com.ibm.tx.jta.impl.RegisteredResources.distributeOutcome(RegisteredResources.java:2004)
at com.ibm.tx.jta.impl.RegisteredResources.distributeRollback(RegisteredResources.java:2657)
at com.ibm.tx.jta.impl.TransactionImpl.internalRollback(TransactionImpl.java:1973)
at com.ibm.tx.jta.impl.TransactionImpl.internalRollback(TransactionImpl.java:1936)
at com.ibm.tx.jta.impl.TransactionImpl.coreStage2CommitProcessing(TransactionImpl.java:1156)
at com.ibm.tx.jta.impl.TransactionImpl.stage2CommitProcessing(TransactionImpl.java:1183)
at com.ibm.tx.jta.impl.TransactionImpl.processCommit(TransactionImpl.java:1044)
at com.ibm.tx.jta.impl.TransactionImpl.commit(TransactionImpl.java:974)
at com.ibm.ws.tx.jta.TranManagerImpl.commit(TranManagerImpl.java:439)
at com.ibm.tx.jta.impl.TranManagerSet.commit(TranManagerSet.java:191)
at com.ibm.ws.tx.jta.UserTransactionImpl.commit(UserTransactionImpl.java:307)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1035)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:743)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:711)
Error code 106 that you get on xa.end is XA_RBTIMEOUT.
This means that the resource manager has rolled back the transaction due to exceeding a timeout.
Error code -4 that you get on xa.commit is XAER_NOTA.
This means that the transaction xid isn't valid anymore, which makes sense given the previous error - because transaction branch was already rolled back due to the timeout.
It is important to be aware that transaction timeouts can be set at various levels. WebSphere Application Server has a global transaction lifetime timeout. Various resource providers will often have their own timeout settings (I'd recommend checking if MQ does) which can cause them to time out their transaction branches prior to the overall transaction. Applications can specify a transaction timeout on UserTransaction, although it appears in this case you are going through Spring, which might be specifying that value, so also look into Springs settings for transaction timeout.
I'm trying to use Oracle Advanced Queuing instead of a running JMS implementation in weblogic.
In theory I have everything configured as it should (as per documentation) in Weblogic but, when trying to send a message I get the following error:
####<Sep 18, 2019 10:27:12,290 AM CEST> <Info> <EJB> <svc-1> <svc_srv_1> <[ACTIVE] ExecuteThread: '4'
for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <5e679652-75c8-44bc-948a-cec4ee2af708-00000437>
<1568795232290> <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-010213>
<Message-Driven EJB: OutQueueMDBReader's transaction was rolled back, because javax.jms.JMSRuntimeException:
[JMSPool:169829]JMS 2.0 method "createContext(int sessionMode)", called on the interface
"javax.jms.ConnectionFactory", is not implemented by this JMS Provider.:
java.lang.AbstractMethodError: oracle.jms.AQjmsXAQueueConnectionFactory.createXAContext()Ljavax/jms/XAJMSContext;
at weblogic.deployment.jms.JMSExceptions.getJMSRuntimeException(JMSExceptions.java:47)
at weblogic.deployment.jms.PooledConnectionFactory.createContext(PooledConnectionFactory.java:298)
at weblogic.jms.integration.injection.AbstractJMSContextManager.createContext(AbstractJMSContextManager.java:68)
at weblogic.jms.integration.injection.AbstractJMSContextManager.getContext(AbstractJMSContextManager.java:49)
at weblogic.jms.integration.injection.TransactedJMSContextManager$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
at weblogic.jms.integration.injection.InjectableJMSContext.delegate(InjectableJMSContext.java:144)
at weblogic.jms.integration.injection.ForwardingJMSContext.createBytesMessage(ForwardingJMSContext.java:105)
Truncated. see log file for complete stacktrace
java.lang.AbstractMethodError: oracle.jms.AQjmsXAQueueConnectionFactory.createXAContext()Ljavax/jms/XAJMSContext;
at weblogic.deployment.jms.PsuedoXAJMSContext.<init>(PsuedoXAJMSContext.java:87)
at weblogic.deployment.jms.PrimaryContextHelper.openConnection(PrimaryContextHelper.java:355)
at weblogic.deployment.jms.PrimaryContextHelper.<init>(PrimaryContextHelper.java:180)
at weblogic.deployment.jms.PrimaryContextHelper$PrimaryContextHelperServiceGeneratorImpl.createPrimaryContextHelperService(PrimaryContextHelper.java:1205)
at weblogic.deployment.jms.PooledConnectionFactory.createNonPooledPrimaryContext(PooledConnectionFactory.java:562)
at weblogic.deployment.jms.PooledConnectionFactory.createContextInternal(PooledConnectionFactory.java:488)
at weblogic.deployment.jms.PooledConnectionFactory.createContext(PooledConnectionFactory.java:296)
at weblogic.jms.integration.injection.AbstractJMSContextManager.createContext(AbstractJMSContextManager.java:68)
at weblogic.jms.integration.injection.AbstractJMSContextManager.getContext(AbstractJMSContextManager.java:49)
at weblogic.jms.integration.injection.TransactedJMSContextManager$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
Truncated. see log file for complete stacktrace
The last place where my code runs is just:
#Inject
#JMSConnectionFactory("MyConnectionFactory")
private JMSContext context;
BytesMessage bytesMessage = getContext().createBytesMessage();
I've already checked this JMS 2.0 documentation and it seems everything should be working.
May I be importing interfaces from different versions or something like this?
Based on this message in your log:
JMS 2.0 method "createContext(int sessionMode)", called on the interface "javax.jms.ConnectionFactory", is not implemented by this JMS Provider.:
java.lang.AbstractMethodError: oracle.jms.AQjmsXAQueueConnectionFactory.createXAContext()Ljavax/jms/XAJMSContext;
The documentation you cited is just an article about what's new in the JMS 2.0 specification. It makes no statement about what support OAQ provides for these new features. The fact that you're receiving the error message as well as the fact that when you remove OAQ it works indicates to me that OAQ simply doesn't support JMS 2.0. I recommend you modify your application to use the JMS 1.1 API.
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
Why doesn't Spring 3.0.4 HibernateTemplate method load() throw DataAccessException or more specifically, ObjectRetrievalFailureException, in the event that Hibernate 3.3.2GA throws ObjectNotFoundException?
2010-12-15 13:16:03,939 133247782 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO org.hibernate.event.def.DefaultLoadEventListener - Error performing load command
org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.db.spgit.abstrack.model.ConsUsCustomMark#78445AAD8]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:375) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:145) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:179) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103) ~[hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878) [hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:795) [hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:788) [hibernate-3.2.1.ga.jar:3.2.1.ga]
at org.springframework.orm.hibernate3.HibernateTemplate$3.doInHibernate(HibernateTemplate.java:558) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:406) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.load(HibernateTemplate.java:551) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
at org.springframework.orm.hibernate3.HibernateTemplate.load(HibernateTemplate.java:545) [spring-orm-3.0.4.RELEASE.jar:3.0.4.RELEASE]
The exception is being logged, not necessarily thrown. What you see there is a log to info level of the exception stack trace, done by hibernate. If you look at the source code of DefaultLoadEventListener(line 134 in my version of the source) you will notice that it logs the exception and then rethrows.
All we're seeing here is a log of the exception stack trace - there is no evidence here that spring is not transforming the exception.
The org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException() method does check to see if the exception is net.sf.hibernate.ObjectNotFoundException. This means that it should be throwing an UncategorizedDataAccessException.
I do not know if this is a design decision or an oversite (i.e. a bug in spring).
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.