Hi Thanks
Camel 2.14.1 is currently being released (in vote) http://camel.465427.n5.nabble.com/VOTE-Release-Camel-2-14-1-td5760558.html So people can help give it a test. So this ticket is target for 2.14.2 On Thu, Dec 11, 2014 at 2:19 PM, Bjørn Ellingsen <bjorn.elling...@osloclearing.no> wrote: > 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. >>> >> >> > -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
