Bug 1033206
| Summary: | Integration with application server thread-pool | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Fuse Service Works 6 | Reporter: | Jochen Cordes <jcordes> |
| Component: | SwitchYard | Assignee: | Aileen <aileenc> |
| Status: | CLOSED UPSTREAM | QA Contact: | Matej Melko <mmelko> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.0.0 | CC: | 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: | 2025-02-10 03:34:27 UTC | Type: | Enhancement |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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). This product has been discontinued or is no longer tracked in Red Hat Bugzilla. |
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: