Thanks, new issue created: CAMEL-8146. I set 2.14.1 as fix version, but since I don't know the exact release plan (other than Q4) I guess 2.14.2 might be just as good a choice.

Bjørn E.

On 11. des. 2014 07:34, Claus Ibsen wrote:
Hi

Thanks for reporting. You are welcome to log a JIRA ticket about this bug.

On Wed, Dec 10, 2014 at 4:59 PM, Bjørn Ellingsen
<bjorn.elling...@osloclearing.no> wrote:
Using Camel 2.14.0, I'm experiencing the exact same situation as described
in this old Jira issue: https://issues.apache.org/jira/browse/CAMEL-5677
only difference is that my routes are file (or SFTP) based, not SEDA.

Trying something like:

for (int i = 0; i < 50; i++) {
     camelContext.startRoute(routeId);
     camelContext.stopRoute(routeId);
}

results in 50 orphan threads of this type:

"Camel (camel) thread #231 - sftp://user@host/path"; #10170 daemon prio=5
os_prio=0 tid=0x00007fa4b46a5800 nid=0x10fc waiting on condition
[0x00007fa452934000]
    java.lang.Thread.State: TIMED_WAITING (parking)
       at sun.misc.Unsafe.park(Native Method)
       - parking to wait for  <0x00000000b83dc900> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
       at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
       at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
       at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
       at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
       at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
       at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
       at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
       at java.lang.Thread.run(Thread.java:745)

Switching to suspend/resume solves the problem, however I guess the
start/stop issue should be addressed.

--
Bjørn E.




Reply via email to