You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Bjørn Ellingsen <bj...@osloclearing.no> on 2014/12/10 16:59:46 UTC
Starting and stopping routes leak threads
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.
Re: Starting and stopping routes leak threads
Posted by Bjørn Ellingsen <bj...@osloclearing.no>.
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
> <bj...@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
>>> <bj...@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.
>>>>
>>>
>
>
Re: Starting and stopping routes leak threads
Posted by Claus Ibsen <cl...@gmail.com>.
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
<bj...@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
>> <bj...@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: cibsen@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/
Re: Starting and stopping routes leak threads
Posted by Bjørn Ellingsen <bj...@osloclearing.no>.
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
> <bj...@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.
>>
>
>
Re: Starting and stopping routes leak threads
Posted by Claus Ibsen <cl...@gmail.com>.
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
<bj...@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: cibsen@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/