[esb-issues] [JBoss JIRA] Commented: (JBESB-1873) JBoss messaging threads can still be created as non-daemon

Kevin Conner (JIRA) jira-events at lists.jboss.org
Thu Jul 17 06:26:52 EDT 2008


    [ https://jira.jboss.org/jira/browse/JBESB-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12421646#action_12421646 ] 

Kevin Conner commented on JBESB-1873:
-------------------------------------

The following explanation is taken from a conversation with magesh on IRC.

JBM creates background threads to handle their processing but do not mark them as daemon processes
The existence of these threads prevents the VM from shutting down
We put a workaround into SOA CP2 to force the threads to inherit the daemon flag of a parent
specifically, we force all JMS session creation to occur within a background thread that we control and this is a daemon
My testing just now (on our trunk release) showed another route through this

Now this may be specific to the version of JBM we are running, that has still to be determined
But JBM appears to 'restart' the executor within the client thread
Because this is restarted in a non-daemon thread it creates non-daemon executor threads
I need to investigate further to determine the scope.

> JBoss messaging threads can still be created as non-daemon
> ----------------------------------------------------------
>
>                 Key: JBESB-1873
>                 URL: https://jira.jboss.org/jira/browse/JBESB-1873
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transports
>    Affects Versions: 4.3, 4.2.1 CP3
>            Reporter: Kevin Conner
>            Assignee: Kevin Conner
>             Fix For: 4.2.1 CP4, 4.4
>
>
> There is scenario in which the workaround for JBESB-1799 does not catch the JBoss Messaging thread creation.
> An example thread is as follows.
> Thread [main] (Suspended (breakpoint at line 290 in java.lang.Thread))	
> 	java.lang.Thread.init(java.lang.ThreadGroup, java.lang.Runnable, java.lang.String, long) line: 290	
> 	java.lang.Thread.<init>(java.lang.Runnable) line: 371	
> 	EDU.oswego.cs.dl.util.concurrent.ThreadFactoryUser$DefaultThreadFactory.newThread(java.lang.Runnable) line: 30	
> 	org.jboss.messaging.util.JBMExecutor(EDU.oswego.cs.dl.util.concurrent.QueuedExecutor).restart() line: 141	
> 	org.jboss.messaging.util.JBMExecutor(EDU.oswego.cs.dl.util.concurrent.QueuedExecutor).execute(java.lang.Runnable) line: 157	
> 	org.jboss.messaging.util.JBMExecutor.execute(java.lang.Runnable) line: 89	
> 	org.jboss.jms.client.container.ClientConsumer.waitForOnMessageToComplete() line: 699	
> 	org.jboss.jms.client.container.ClientConsumer.close(long) line: 363	
> 	org.jboss.jms.client.container.ConsumerAspect.handleClosing(org.jboss.aop.joinpoint.Invocation) line: 147	
> 	org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect53.invoke(org.jboss.aop.joinpoint.Invocation) line: not available	
> 	org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_2473194355759371067.invokeNext() line: not available	
> 	org.jboss.jms.client.container.FailoverValveInterceptor.invoke(org.jboss.aop.joinpoint.Invocation) line: 92	
> 	org.jboss.aop.advice.PerInstanceInterceptor.invoke(org.jboss.aop.joinpoint.Invocation) line: 105	
> 	org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_2473194355759371067.invokeNext() line: not available	
> 	org.jboss.jms.client.container.ClosedInterceptor.invoke(org.jboss.aop.joinpoint.Invocation) line: 170	
> 	org.jboss.aop.advice.PerInstanceInterceptor.invoke(org.jboss.aop.joinpoint.Invocation) line: 105	
> 	org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_2473194355759371067.invokeNext() line: not available	
> 	org.jboss.jms.client.delegate.ClientConsumerDelegate.closing(long) line: not available	
> 	org.jboss.jms.client.JBossMessageConsumer.close() line: 96	
> 	org.jboss.internal.soa.esb.couriers.JmsCourier.cleanup() line: 114	
> 	org.jboss.soa.esb.couriers.CourierUtil.cleanCourier(org.jboss.internal.soa.esb.couriers.PickUpOnlyCourier) line: 244	
> 	org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.cleanup() line: 249	
> 	org.jboss.soa.esb.couriers.CourierUtil.cleanCourier(org.jboss.soa.esb.couriers.TwoWayCourier) line: 276	
> 	org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(org.jboss.soa.esb.message.Message, org.jboss.soa.esb.addressing.EPR) line: 574	
> 	org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker, org.jboss.soa.esb.message.Message, org.jboss.soa.esb.addressing.EPR) line: 452	
> 	org.jboss.soa.esb.client.ServiceInvoker.post(org.jboss.soa.esb.message.Message, org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker) line: 318	
> 	org.jboss.soa.esb.client.ServiceInvoker.deliverSync(org.jboss.soa.esb.message.Message, long) line: 198	
> 	org.jboss.soa.esb.samples.quickstart.timeout.test.SendEsbMessage.main(java.lang.String[]) line: 56	

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the esb-issues mailing list