[JBoss Messaging] - Threads Hanging Indefinitely in ClosedInterceptor
by zackurey
Hi,
I've been running into some intermittent issues where threads publishing messages are waiting forever in ClosedInterceptor.checkCloseAlreadyDone.
Environment:
Client Server: JBoss 4.2.2GA using the JMSRA
Broker Server: JBoss 4.2.2GA, JBoss Messaging 1.4.0.SP3
The only current work around I have right now is to bounce my application as the thread is never let free. The only thing I can think of is that somehow inUseCount never gets down to 0.
The broker isn't under heavy load with messages only being published every 4 hours by the threads that are getting stuck, and one other thread that is pinging for availability every 30 seconds. Again this is very random, I've seen it run for a week with no issues, and other times it happens nearly immediately.
Doing a thread-dump I see:
"QuartzScheduler_Worker-8" prio=1 tid=0x198c6640 nid=0x259e in Object.wait() [0x19279000..0x19279e20]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at org.jboss.jms.client.container.ClosedInterceptor.checkCloseAlreadyDone(ClosedInterceptor.java:245)
- locked <0x37d7fd18> (a org.jboss.jms.client.container.ClosedInterceptor)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:142)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$close_N4742752445160157748.invokeNext(ClientConnectionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.close(ClientConnectionDelegate.java)
at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:203)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:124)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:637)
at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:370)
at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:238)
at org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.commit(JcaXAResourceWrapper.java:53)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:636)
at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2619)
at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1779)
- locked <0x37d7d108> (a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:842)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:662)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
Are there any previous issues resolved that could be related to this that have a work around or patch that anyone knows of?
Thanks in advance.
Zach
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163750#4163750
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163750
17 years, 10 months
[Remoting] - Re: java.net.SocketException: Can not obtain client socket c
by kapil.singhal
Hello Ron,
I have modified the jboss-service.xml located at anonymous wrote : C:\Lang\JBoss\jboss-4.2.2.GA\server\default\deploy\ejb3.deployer\META-INF as follows:
<mbean code="org.jboss.remoting.transport.Connector"
| name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
| <depends>jboss.aop:service=AspectDeployer</depends>
| <attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/?maxPoolSize=200</attribute>
| <attribute name="Configuration">
| <handlers>
| <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
| </handlers>
| </attribute>
| </mbean>
But the problem still persists...
I have tried with both the versions of jboss-remoting.jar - 2.2.2 & 2.4.0
In case of 2.2.2 it is throwing exception after 50 connections and in case of 2.4.0 it is behaving same as I last mentioned - after 50 it slowed down.
I have changed in the default\deploy\ejb3.deployer and all\deploy\ejb3.deployer folder after it was not working in the default folder. My ejb3 is deployed in the default folder.
Please suggest if some more changes are required, as this change is not working.
Regards,
Kapil
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163747#4163747
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163747
17 years, 10 months
[EJB 3.0] - Can you Inject Local EJB from separate ear file?
by jfrankman
I have two session beans each deployed in a different ear's on the same JBoss server. Can i successfully inject Session bean A into Session bean B if each one is deployed in a different ear? I keep getting this error and everything looks ok so I assume that they must both be within the same ear for @EJB injection to work. Can anyone tell me this is correct?
here is the error I get upon deployment:
" Reason: java.lang.RuntimeException: could not resolve global JNDI name for @EJB for container KeyBankCheckImagesMessageHandler: reference class: com.idfbins.nexusevents.services.NexusEventsService ejbLink: not used by any EJBs"
Here is my how I inject it:
public class KeyBankCheckImagesMessageHandler implements MessageListener{
|
| @PersistenceContext(unitName = "KeyBankChecksDB")
| private EntityManager em;
|
| @In(create=true) KeyBankServices keybankServices;
|
| @EJB(name="NexusEvents/NexusEventsServiceImpl/local")
| NexusEventsService nexusEventsService;
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163742#4163742
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163742
17 years, 10 months