Bug 1033206

Summary: Integration with application server thread-pool
Product: [JBoss] JBoss Fuse Service Works 6 Reporter: Jochen Cordes <jcordes>
Component: SwitchYardAssignee: Aileen <aileenc>
Status: MODIFIED --- QA Contact: Matej Melko <mmelko>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0.0CC: atangrin, kejohnso, rcernich, serviceworks, soa-p-jira, tschan+redhat
Target Milestone: DR3   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Enhancement
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jochen Cordes 2013-11-21 17:17:16 UTC 
Description of problem:

Below you can find an example of a SwitchYard Camel Gateway (i.e. Binding) thread  which seem not be integrated with the JBoss EAP thead-pool:

"Camel (camel-1) thread #1 - file:///home/jcordes/workspace/switchyard-camel-aggregate-split/inbox" daemon prio=10 tid=0x842bc800 nid=0x419e waiting on condition [0x88cad000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0xeff786b8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:196)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2025)
        at java.util.concurrent.DelayQueue.take(DelayQueue.java:164)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:609)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:602)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:957)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:917)
        at java.lang.Thread.run(Thread.java:662)

Usually a container should take care of managing threads, so that you have a central point of control.

Version-Release number of selected component (if applicable):

6.0.0 Beta

How reproducible:

Always

Steps to Reproduce:
1. Create a Gateway with Camel binding
2. Do a threaddumo
3.

Actual results:

Thread is managed not managed by JBoss EAP

Expected results:

Thread is managed not managed by JBoss EAP

Additional info:
Comment 3 Rob Cernich 2014-10-21 14:52:55 UTC 
I believe this has been fixed.  However, there are a few Camel endpoints that create their own threads but don't use the thread factory associated with the Camel context (e.g. quartz).