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.