Re: Starting and stopping routes leak threads

[Bjørn Ellingsen]

Oops, updated to 2.14.2 now :)

Bjørn E.

On 11. des. 2014 14:42, Claus Ibsen wrote:

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.