You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by sjlee7373 <sj...@gmail.com> on 2016/03/08 02:15:00 UTC

Camel jetty Dead Lock and Threadfull based ServiceMix 5.3.0

Hi, 

I have a problem with camel in ServiceMix.

I made webservice throught camel-jetty, camel-recipentlist in servicemix.
This package is good performance but resource lock and thread full ocurred
it. This system process 40 Call per second.

The problem is that pool threads aren't released properly sometimes. After 
a few hours following the start of an application I can see using jstack 
tool that some threads are stuck in a WAITING state: 

configuration is as follows: 
- servicemix 5.3.0
- camel 2.13.2
- using component (camel-jetty , camel-recipentlist  based Spring DSL)

-------------- SOURCE
----------------------------------------------------------------------
<route customId="true" >
    <from uri="direct:giop_addr_async">
        <recipentList>
             
<simple>jetty://http://api.host.lm?x=${header.x}&amp;y=${header.y}</simple>
        </recipentList>
        <bean ref="soapDecode" method="userDecode"/>
        <to uri="direct:sendEndPoint">
</route>

<route customId="true>
        <from uri="direct:sendEndPoint">
        <to uri="jetty://http://resultMap?httpClient.soTimeout=80000"/>
</route>

-------------- LOG
---------------------------------------------------------------------------
ps -eLf  | wc -l --> 32500

"CamelJettyClient(0x3d0b240d)-26916" damen prio=10 tid=0x000000000ff69800
nid =0x10ef wating on condition [0x00002b4b3ba3f0000]
   java.lang.Thread.State: TIMED_WAITNG(parking)
     at sun.misc.Unsafe.park(Native Method)
 - parging to wati for <0x000000006f13f19b0> (a
java.util.concurrent.locks.AbstractQueuedsynchronizer$ConditionObject)
 at java.util.concurrent.locks.LocsSupport.parkNanos(LockSupport,java:226)
 at
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:342)
 at
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoss(QueuedThreadPool.java:526)
 at
org.eclipse.jetty.tuil.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
 atjava.lnag.thread.run(Thread.java:745)

Above log more than 30000line...... 

Can you suggest what else can be checked? Am I missing something? Or may be 
this is a bug in Camel? 




--
View this message in context: http://camel.465427.n5.nabble.com/Camel-jetty-Dead-Lock-and-Threadfull-based-ServiceMix-5-3-0-tp5778717.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel jetty Dead Lock and Threadfull based ServiceMix 5.3.0

Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 8, 2016 at 2:15 AM, sjlee7373 <sj...@gmail.com> wrote:
> Hi,
>
> I have a problem with camel in ServiceMix.
>
> I made webservice throught camel-jetty, camel-recipentlist in servicemix.
> This package is good performance but resource lock and thread full ocurred
> it. This system process 40 Call per second.
>
> The problem is that pool threads aren't released properly sometimes. After
> a few hours following the start of an application I can see using jstack
> tool that some threads are stuck in a WAITING state:
>
> configuration is as follows:
> - servicemix 5.3.0
> - camel 2.13.2
> - using component (camel-jetty , camel-recipentlist  based Spring DSL)
>
> -------------- SOURCE
> ----------------------------------------------------------------------
> <route customId="true" >
>     <from uri="direct:giop_addr_async">
>         <recipentList>
>
> <simple>jetty://http://api.host.lm?x=${header.x}&amp;y=${header.y}</simple>
>         </recipentList>

Dont use a recipient list when you send the message to the *same*
host. Instead set a header with the Exchange.HTTP_QUERY and send the
message to a regular <to>. Then only 1 endpoint is in use and that
reduces the memory/thread and whatnot.




>         <bean ref="soapDecode" method="userDecode"/>
>         <to uri="direct:sendEndPoint">
> </route>
>
> <route customId="true>
>         <from uri="direct:sendEndPoint">
>         <to uri="jetty://http://resultMap?httpClient.soTimeout=80000"/>
> </route>
>
> -------------- LOG
> ---------------------------------------------------------------------------
> ps -eLf  | wc -l --> 32500
>
> "CamelJettyClient(0x3d0b240d)-26916" damen prio=10 tid=0x000000000ff69800
> nid =0x10ef wating on condition [0x00002b4b3ba3f0000]
>    java.lang.Thread.State: TIMED_WAITNG(parking)
>      at sun.misc.Unsafe.park(Native Method)
>  - parging to wati for <0x000000006f13f19b0> (a
> java.util.concurrent.locks.AbstractQueuedsynchronizer$ConditionObject)
>  at java.util.concurrent.locks.LocsSupport.parkNanos(LockSupport,java:226)
>  at
> org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:342)
>  at
> org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoss(QueuedThreadPool.java:526)
>  at
> org.eclipse.jetty.tuil.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>  atjava.lnag.thread.run(Thread.java:745)
>
> Above log more than 30000line......
>
> Can you suggest what else can be checked? Am I missing something? Or may be
> this is a bug in Camel?
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-jetty-Dead-Lock-and-Threadfull-based-ServiceMix-5-3-0-tp5778717.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2