You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by V4Vaithi <al...@gmail.com> on 2015/01/14 13:41:52 UTC
Camel-Netty ReadTimeout event not trigerred
ReadTimeout event is not triggered properly after adding custom
encoder/decoder to endpoint.
I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
My Route Confuiguration is as follows
<route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
<process ref="byteResponseMessage" /> <to
uri="bean:messageLogger?method=log" /> <to
uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&encoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
/> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
</route>
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel-Netty ReadTimeout event not trigerred
Posted by Willem Jiang <wi...@gmail.com>.
I guess you want to handle the ReadTimeout exception in your decoder.
As we just add the ReadTimeoutHandler after the customer decoder and encoder, your decoder may not get the exception as you want.
The issue could be fixed by applying the ReadTimeoutHandler at the first place.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On January 14, 2015 at 8:57:06 PM, V4Vaithi (alagappan.info@gmail.com) wrote:
> ReadTimeout event is not triggered properly after adding custom
> encoder/decoder to endpoint.
>
> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
>
> My Route Confuiguration is as follows
>
>
> > uri="bean:messageLogger?method=log" /> > uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&encoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
> />
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Camel-Netty ReadTimeout event not trigerred
Posted by V4Vaithi <al...@gmail.com>.
I am using camel 2.14.0
--
View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676p5761776.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel-Netty ReadTimeout event not trigerred
Posted by Joan Picanyol i Puig <li...@biaix.org>.
Ouch, just noticed that I confused sync with synchronous, sorry for the
confusion.
We still have the issue though, I'll try coming up with a simple route.
* Joan Picanyol i Puig <li...@biaix.org> [20150115 16:15]:
> Hi,
>
> We've been chasing pretty much the same issue for some days (on Camel 2.12.4),
> and just recently tried setting sync=true (set in your test, which fails with
> sync=false) but it has not fixed the issue for us.
>
> Our route is slightly more involved (we've been trying using recipientList() +
> parallelProcessing() to set the timeout), and even though all Netty threads are
> RUNNABLE and the ReadTimeout has been thrown, we end up getting application
> threads WAITING in:
>
> "http-bio-192.168.88.2-8080-exec-18" - Thread t@4227
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <682409b5> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.apache.camel.processor.MulticastProcessor.doProcessParallel(MulticastProcessor.java:328)
> at org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:214)
> at org.apache.camel.processor.RecipientList.sendToRecipientList(RecipientList.java:158)
> at org.apache.camel.processor.RecipientList.process(RecipientList.java:117)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:111)
> at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:82)
> at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
> at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:73)
> at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:378)
> at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:346)
> at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:242)
> at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:346)
> at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:201)
> at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:128)
> at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:132)
> at org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:277
>
> * Claus Ibsen <cl...@gmail.com> [20150115 09:42]:
> > Hi
> >
> > I added an unit test to camel-netty that works
> > https://github.com/apache/camel/commit/76c6a275e49960a6011c0c13102877c0ccf61366
> >
> > On Thu, Jan 15, 2015 at 9:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
> > > What version of Camel do you use?
> > >
> > >
> > >
> > > On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
> > >> ReadTimeout event is not triggered properly after adding custom
> > >> encoder/decoder to endpoint.
> > >>
> > >> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
> > >>
> > >> My Route Confuiguration is as follows
> > >>
> > >> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
> > >> <process ref="byteResponseMessage" /> <to
> > >> uri="bean:messageLogger?method=log" /> <to
> > >> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&e???ncoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
> > >> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
> > >> </route>
> > >>
> > >>
> > >>
> > >> --
> > >> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
> > >> Sent from the Camel - Users mailing list archive at Nabble.com.
> > >
> > >
> > >
> > > --
> > > 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/
> >
> >
> >
> > --
> > 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/
>
> --
> pica
--
pica
Re: Camel-Netty ReadTimeout event not trigerred
Posted by Joan Picanyol i Puig <li...@biaix.org>.
Hi Claus,
I'm attaching a handler which it seems like it fixes the issue for us.
I think the documentation should clarify that the requestTimeout
parameter in the netty component is not per request but a actually a
netty channel readTimeout.
regards
--
joan
* Claus Ibsen <cl...@gmail.com> [20150117 12:02]:
> Hi
>
> Sorry that is a bit complicated route to dive into, and Camel 2.12.x
> is not active supported. And help in the community is volunteer based.
>
> There is just too much else I want / should do in my humble spare time.
>
> If you can build a simple route that reproduce this on master branch,
> then let us know.
>
> Also you may consider avoiding having 2 x timeout in both
> requestTimeout and on the recipient list. And having doTry . .do Catch
> .. throw doesnt make so much sense either. In other words simplify
> your route, and rely on requestTimeout for a start. And try with a
> newer version of Camel to see if it works. Then that is easier to
> figure out what may fix it on 2.12.x branch.
>
> On Fri, Jan 16, 2015 at 4:24 PM, Joan Picanyol i Puig
> <li...@biaix.org> wrote:
> > Hi Claus,
> >
> > Unfortunately, can't upgrade 2.14 and haven't been able to come up with a
> > trivial test yet.
> >
> > We are sending via ProducerTemplate.requestBody() to a netty://tcp
> > endpoint and it seems that the requestTimeout is not really per message
> > but per TCP socket (or Netty Handler/Pipeline?). Currently our route looks like:
> >
> > .from(ENTRY_POINT)
> > .marshal()
> > .custom(DataFormat.REF)
> > .doTry()
> > .recipientList(
> > simple("netty:tcp://${properties.host}:${properties.port}"
> > + "?connectTimeout=" + "${properties.connection_timeout}" + "&requestTimeout="+ "${properties.request_timeout}" + "&"
> > + "synchronous=true&"
> > + "encoder=#" + BytesEncoder.REF + "&decoder=#" + ReplyDecoder.REF))
> >
> > //parallel processing to set timeout
> > .parallelProcessing().timeout(TIMEOUT)
> > //ensure that the recipientList is stopped when the timeout occurs
> > .stopOnException()
> > //aggregation strategy to (not) process the timeout
> > .aggregationStrategy(new ThrowReadTimeoutAggregationStrategy())
> > .end()
> > .doCatch(org.jboss.netty.handler.timeout.TimeoutException.class)
> > .throwException(new java.util.concurrent.TimeoutException("Timeout reading avett message"))
> > .end()
> >
> > ThrowReadTimeoutAggregationStrategy.timeout() just logs & throws a new
> > ReadTimeoutException. We already saw the issue before iontroducing
> > recipientList & friends (we just had a dynamicRouter()).
> >
> > Found http://stackoverflow.com/a/13120765 but have been unable to figure out if
> > there is some support for this in any Camel version or not. Should there be
> > something implemented, could you please point at it so that we can test whether
> > it works for us? Could https://github.com/apache/camel/pull/192 be related?
> >
> > tks
> > --
> > pica
> >
> > * Claus Ibsen <cl...@gmail.com> [20150116 07:14]:
> >> On Thu, Jan 15, 2015 at 4:15 PM, Joan Picanyol i Puig
> >> <li...@biaix.org> wrote:
> >> > Hi,
> >> >
> >> > We've been chasing pretty much the same issue for some days (on Camel 2.12.4),
> >> > and just recently tried setting sync=true (set in your test, which fails with
> >> > sync=false) but it has not fixed the issue for us.
> >> >
> >> > Our route is slightly more involved (we've been trying using recipientList() +
> >> > parallelProcessing() to set the timeout), and even though all Netty threads are
> >> > RUNNABLE and the ReadTimeout has been thrown, we end up getting application
> >> > threads WAITING in:
> >> >
> >>
> >> Can you try with Camel 2.14.1 ?
> >>
> >> And just to be sure, you are using recipient list + parallel = true to
> >> invoke a netty endpoint? And if the request timeout happens, then the
> >> threads get stuck in the latch below?
> >>
> >> If so I suspect its a bug in that Camel release that wont trigger a
> >> callback.done call that is needed to signal to the recipient list that
> >> it should continue.
> >>
> >>
> >>
> >>
> >>
> >> > "http-bio-192.168.88.2-8080-exec-18" - Thread t@4227
> >> > java.lang.Thread.State: WAITING
> >> > at sun.misc.Unsafe.park(Native Method)
> >> > - parking to wait for <682409b5> (a java.util.concurrent.CountDownLatch$Sync)
> >> > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> >> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> >> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> >> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> >> > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> >> > at org.apache.camel.processor.MulticastProcessor.doProcessParallel(MulticastProcessor.java:328)
> >> > at org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:214)
> >> > at org.apache.camel.processor.RecipientList.sendToRecipientList(RecipientList.java:158)
> >> > at org.apache.camel.processor.RecipientList.process(RecipientList.java:117)
> >> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> >> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> >> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> >> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> >> > at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:111)
> >> > at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:82)
> >> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> >> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> >> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> >> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> >> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> >> > at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> >> > at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
> >> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> >> > at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
> >> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> >> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> >> > at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> >> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> >> > at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:73)
> >> > at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:378)
> >> > at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:346)
> >> > at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:242)
> >> > at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:346)
> >> > at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:201)
> >> > at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:128)
> >> > at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:132)
> >> > at org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:277
> >> >
> >> > * Claus Ibsen <cl...@gmail.com> [20150115 09:42]:
> >> >> Hi
> >> >>
> >> >> I added an unit test to camel-netty that works
> >> >> https://github.com/apache/camel/commit/76c6a275e49960a6011c0c13102877c0ccf61366
> >> >>
> >> >> On Thu, Jan 15, 2015 at 9:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
> >> >> > What version of Camel do you use?
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
> >> >> >> ReadTimeout event is not triggered properly after adding custom
> >> >> >> encoder/decoder to endpoint.
> >> >> >>
> >> >> >> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
> >> >> >>
> >> >> >> My Route Confuiguration is as follows
> >> >> >>
> >> >> >> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
> >> >> >> <process ref="byteResponseMessage" /> <to
> >> >> >> uri="bean:messageLogger?method=log" /> <to
> >> >> >> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&e???ncoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
> >> >> >> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
> >> >> >> </route>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
> >> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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/
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> 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/
> >> >
> >> > --
> >> > pica
> >>
> >>
> >>
> >> --
> >> 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/
> >
> > --
> > pica
>
>
>
> --
> 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/
--
pica
Re: Camel-Netty ReadTimeout event not trigerred
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Sorry that is a bit complicated route to dive into, and Camel 2.12.x
is not active supported. And help in the community is volunteer based.
There is just too much else I want / should do in my humble spare time.
If you can build a simple route that reproduce this on master branch,
then let us know.
Also you may consider avoiding having 2 x timeout in both
requestTimeout and on the recipient list. And having doTry . .do Catch
.. throw doesnt make so much sense either. In other words simplify
your route, and rely on requestTimeout for a start. And try with a
newer version of Camel to see if it works. Then that is easier to
figure out what may fix it on 2.12.x branch.
On Fri, Jan 16, 2015 at 4:24 PM, Joan Picanyol i Puig
<li...@biaix.org> wrote:
> Hi Claus,
>
> Unfortunately, can't upgrade 2.14 and haven't been able to come up with a
> trivial test yet.
>
> We are sending via ProducerTemplate.requestBody() to a netty://tcp
> endpoint and it seems that the requestTimeout is not really per message
> but per TCP socket (or Netty Handler/Pipeline?). Currently our route looks like:
>
> .from(ENTRY_POINT)
> .marshal()
> .custom(DataFormat.REF)
> .doTry()
> .recipientList(
> simple("netty:tcp://${properties.host}:${properties.port}"
> + "?connectTimeout=" + "${properties.connection_timeout}" + "&requestTimeout="+ "${properties.request_timeout}" + "&"
> + "synchronous=true&"
> + "encoder=#" + BytesEncoder.REF + "&decoder=#" + ReplyDecoder.REF))
>
> //parallel processing to set timeout
> .parallelProcessing().timeout(TIMEOUT)
> //ensure that the recipientList is stopped when the timeout occurs
> .stopOnException()
> //aggregation strategy to (not) process the timeout
> .aggregationStrategy(new ThrowReadTimeoutAggregationStrategy())
> .end()
> .doCatch(org.jboss.netty.handler.timeout.TimeoutException.class)
> .throwException(new java.util.concurrent.TimeoutException("Timeout reading avett message"))
> .end()
>
> ThrowReadTimeoutAggregationStrategy.timeout() just logs & throws a new
> ReadTimeoutException. We already saw the issue before iontroducing
> recipientList & friends (we just had a dynamicRouter()).
>
> Found http://stackoverflow.com/a/13120765 but have been unable to figure out if
> there is some support for this in any Camel version or not. Should there be
> something implemented, could you please point at it so that we can test whether
> it works for us? Could https://github.com/apache/camel/pull/192 be related?
>
> tks
> --
> pica
>
> * Claus Ibsen <cl...@gmail.com> [20150116 07:14]:
>> On Thu, Jan 15, 2015 at 4:15 PM, Joan Picanyol i Puig
>> <li...@biaix.org> wrote:
>> > Hi,
>> >
>> > We've been chasing pretty much the same issue for some days (on Camel 2.12.4),
>> > and just recently tried setting sync=true (set in your test, which fails with
>> > sync=false) but it has not fixed the issue for us.
>> >
>> > Our route is slightly more involved (we've been trying using recipientList() +
>> > parallelProcessing() to set the timeout), and even though all Netty threads are
>> > RUNNABLE and the ReadTimeout has been thrown, we end up getting application
>> > threads WAITING in:
>> >
>>
>> Can you try with Camel 2.14.1 ?
>>
>> And just to be sure, you are using recipient list + parallel = true to
>> invoke a netty endpoint? And if the request timeout happens, then the
>> threads get stuck in the latch below?
>>
>> If so I suspect its a bug in that Camel release that wont trigger a
>> callback.done call that is needed to signal to the recipient list that
>> it should continue.
>>
>>
>>
>>
>>
>> > "http-bio-192.168.88.2-8080-exec-18" - Thread t@4227
>> > java.lang.Thread.State: WAITING
>> > at sun.misc.Unsafe.park(Native Method)
>> > - parking to wait for <682409b5> (a java.util.concurrent.CountDownLatch$Sync)
>> > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
>> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
>> > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
>> > at org.apache.camel.processor.MulticastProcessor.doProcessParallel(MulticastProcessor.java:328)
>> > at org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:214)
>> > at org.apache.camel.processor.RecipientList.sendToRecipientList(RecipientList.java:158)
>> > at org.apache.camel.processor.RecipientList.process(RecipientList.java:117)
>> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
>> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
>> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
>> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
>> > at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:111)
>> > at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:82)
>> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
>> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
>> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
>> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
>> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
>> > at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
>> > at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
>> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
>> > at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
>> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
>> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
>> > at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
>> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
>> > at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:73)
>> > at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:378)
>> > at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:346)
>> > at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:242)
>> > at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:346)
>> > at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:201)
>> > at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:128)
>> > at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:132)
>> > at org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:277
>> >
>> > * Claus Ibsen <cl...@gmail.com> [20150115 09:42]:
>> >> Hi
>> >>
>> >> I added an unit test to camel-netty that works
>> >> https://github.com/apache/camel/commit/76c6a275e49960a6011c0c13102877c0ccf61366
>> >>
>> >> On Thu, Jan 15, 2015 at 9:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> >> > What version of Camel do you use?
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
>> >> >> ReadTimeout event is not triggered properly after adding custom
>> >> >> encoder/decoder to endpoint.
>> >> >>
>> >> >> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
>> >> >>
>> >> >> My Route Confuiguration is as follows
>> >> >>
>> >> >> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
>> >> >> <process ref="byteResponseMessage" /> <to
>> >> >> uri="bean:messageLogger?method=log" /> <to
>> >> >> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&e???ncoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
>> >> >> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
>> >> >> </route>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
>> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > 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/
>> >>
>> >>
>> >>
>> >> --
>> >> 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/
>> >
>> > --
>> > pica
>>
>>
>>
>> --
>> 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/
>
> --
> pica
--
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: Camel-Netty ReadTimeout event not trigerred
Posted by Joan Picanyol i Puig <li...@biaix.org>.
Hi Claus,
Unfortunately, can't upgrade 2.14 and haven't been able to come up with a
trivial test yet.
We are sending via ProducerTemplate.requestBody() to a netty://tcp
endpoint and it seems that the requestTimeout is not really per message
but per TCP socket (or Netty Handler/Pipeline?). Currently our route looks like:
.from(ENTRY_POINT)
.marshal()
.custom(DataFormat.REF)
.doTry()
.recipientList(
simple("netty:tcp://${properties.host}:${properties.port}"
+ "?connectTimeout=" + "${properties.connection_timeout}" + "&requestTimeout="+ "${properties.request_timeout}" + "&"
+ "synchronous=true&"
+ "encoder=#" + BytesEncoder.REF + "&decoder=#" + ReplyDecoder.REF))
//parallel processing to set timeout
.parallelProcessing().timeout(TIMEOUT)
//ensure that the recipientList is stopped when the timeout occurs
.stopOnException()
//aggregation strategy to (not) process the timeout
.aggregationStrategy(new ThrowReadTimeoutAggregationStrategy())
.end()
.doCatch(org.jboss.netty.handler.timeout.TimeoutException.class)
.throwException(new java.util.concurrent.TimeoutException("Timeout reading avett message"))
.end()
ThrowReadTimeoutAggregationStrategy.timeout() just logs & throws a new
ReadTimeoutException. We already saw the issue before iontroducing
recipientList & friends (we just had a dynamicRouter()).
Found http://stackoverflow.com/a/13120765 but have been unable to figure out if
there is some support for this in any Camel version or not. Should there be
something implemented, could you please point at it so that we can test whether
it works for us? Could https://github.com/apache/camel/pull/192 be related?
tks
--
pica
* Claus Ibsen <cl...@gmail.com> [20150116 07:14]:
> On Thu, Jan 15, 2015 at 4:15 PM, Joan Picanyol i Puig
> <li...@biaix.org> wrote:
> > Hi,
> >
> > We've been chasing pretty much the same issue for some days (on Camel 2.12.4),
> > and just recently tried setting sync=true (set in your test, which fails with
> > sync=false) but it has not fixed the issue for us.
> >
> > Our route is slightly more involved (we've been trying using recipientList() +
> > parallelProcessing() to set the timeout), and even though all Netty threads are
> > RUNNABLE and the ReadTimeout has been thrown, we end up getting application
> > threads WAITING in:
> >
>
> Can you try with Camel 2.14.1 ?
>
> And just to be sure, you are using recipient list + parallel = true to
> invoke a netty endpoint? And if the request timeout happens, then the
> threads get stuck in the latch below?
>
> If so I suspect its a bug in that Camel release that wont trigger a
> callback.done call that is needed to signal to the recipient list that
> it should continue.
>
>
>
>
>
> > "http-bio-192.168.88.2-8080-exec-18" - Thread t@4227
> > java.lang.Thread.State: WAITING
> > at sun.misc.Unsafe.park(Native Method)
> > - parking to wait for <682409b5> (a java.util.concurrent.CountDownLatch$Sync)
> > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> > at org.apache.camel.processor.MulticastProcessor.doProcessParallel(MulticastProcessor.java:328)
> > at org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:214)
> > at org.apache.camel.processor.RecipientList.sendToRecipientList(RecipientList.java:158)
> > at org.apache.camel.processor.RecipientList.process(RecipientList.java:117)
> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> > at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:111)
> > at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:82)
> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> > at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> > at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> > at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
> > at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> > at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> > at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> > at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> > at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:73)
> > at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:378)
> > at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:346)
> > at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:242)
> > at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:346)
> > at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:201)
> > at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:128)
> > at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:132)
> > at org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:277
> >
> > * Claus Ibsen <cl...@gmail.com> [20150115 09:42]:
> >> Hi
> >>
> >> I added an unit test to camel-netty that works
> >> https://github.com/apache/camel/commit/76c6a275e49960a6011c0c13102877c0ccf61366
> >>
> >> On Thu, Jan 15, 2015 at 9:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
> >> > What version of Camel do you use?
> >> >
> >> >
> >> >
> >> > On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
> >> >> ReadTimeout event is not triggered properly after adding custom
> >> >> encoder/decoder to endpoint.
> >> >>
> >> >> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
> >> >>
> >> >> My Route Confuiguration is as follows
> >> >>
> >> >> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
> >> >> <process ref="byteResponseMessage" /> <to
> >> >> uri="bean:messageLogger?method=log" /> <to
> >> >> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&e???ncoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
> >> >> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
> >> >> </route>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
> >> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >
> >> >
> >> >
> >> > --
> >> > 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/
> >>
> >>
> >>
> >> --
> >> 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/
> >
> > --
> > pica
>
>
>
> --
> 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/
--
pica
Re: Camel-Netty ReadTimeout event not trigerred
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Jan 15, 2015 at 4:15 PM, Joan Picanyol i Puig
<li...@biaix.org> wrote:
> Hi,
>
> We've been chasing pretty much the same issue for some days (on Camel 2.12.4),
> and just recently tried setting sync=true (set in your test, which fails with
> sync=false) but it has not fixed the issue for us.
>
> Our route is slightly more involved (we've been trying using recipientList() +
> parallelProcessing() to set the timeout), and even though all Netty threads are
> RUNNABLE and the ReadTimeout has been thrown, we end up getting application
> threads WAITING in:
>
Can you try with Camel 2.14.1 ?
And just to be sure, you are using recipient list + parallel = true to
invoke a netty endpoint? And if the request timeout happens, then the
threads get stuck in the latch below?
If so I suspect its a bug in that Camel release that wont trigger a
callback.done call that is needed to signal to the recipient list that
it should continue.
> "http-bio-192.168.88.2-8080-exec-18" - Thread t@4227
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <682409b5> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.apache.camel.processor.MulticastProcessor.doProcessParallel(MulticastProcessor.java:328)
> at org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:214)
> at org.apache.camel.processor.RecipientList.sendToRecipientList(RecipientList.java:158)
> at org.apache.camel.processor.RecipientList.process(RecipientList.java:117)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:111)
> at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:82)
> at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
> at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
> at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
> at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
> at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:73)
> at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:378)
> at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:346)
> at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:242)
> at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:346)
> at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:201)
> at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:128)
> at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:132)
> at org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:277
>
> * Claus Ibsen <cl...@gmail.com> [20150115 09:42]:
>> Hi
>>
>> I added an unit test to camel-netty that works
>> https://github.com/apache/camel/commit/76c6a275e49960a6011c0c13102877c0ccf61366
>>
>> On Thu, Jan 15, 2015 at 9:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> > What version of Camel do you use?
>> >
>> >
>> >
>> > On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
>> >> ReadTimeout event is not triggered properly after adding custom
>> >> encoder/decoder to endpoint.
>> >>
>> >> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
>> >>
>> >> My Route Confuiguration is as follows
>> >>
>> >> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
>> >> <process ref="byteResponseMessage" /> <to
>> >> uri="bean:messageLogger?method=log" /> <to
>> >> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&e???ncoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
>> >> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
>> >> </route>
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>> >
>> >
>> >
>> > --
>> > 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/
>>
>>
>>
>> --
>> 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/
>
> --
> pica
--
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: Camel-Netty ReadTimeout event not trigerred
Posted by Joan Picanyol i Puig <li...@biaix.org>.
Hi,
We've been chasing pretty much the same issue for some days (on Camel 2.12.4),
and just recently tried setting sync=true (set in your test, which fails with
sync=false) but it has not fixed the issue for us.
Our route is slightly more involved (we've been trying using recipientList() +
parallelProcessing() to set the timeout), and even though all Netty threads are
RUNNABLE and the ReadTimeout has been thrown, we end up getting application
threads WAITING in:
"http-bio-192.168.88.2-8080-exec-18" - Thread t@4227
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <682409b5> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
at org.apache.camel.processor.MulticastProcessor.doProcessParallel(MulticastProcessor.java:328)
at org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:214)
at org.apache.camel.processor.RecipientList.sendToRecipientList(RecipientList.java:158)
at org.apache.camel.processor.RecipientList.process(RecipientList.java:117)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:111)
at org.apache.camel.processor.TryProcessor.process(TryProcessor.java:82)
at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:51)
at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:73)
at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:378)
at org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:346)
at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:242)
at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:346)
at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:201)
at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:128)
at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:132)
at org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:277
* Claus Ibsen <cl...@gmail.com> [20150115 09:42]:
> Hi
>
> I added an unit test to camel-netty that works
> https://github.com/apache/camel/commit/76c6a275e49960a6011c0c13102877c0ccf61366
>
> On Thu, Jan 15, 2015 at 9:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
> > What version of Camel do you use?
> >
> >
> >
> > On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
> >> ReadTimeout event is not triggered properly after adding custom
> >> encoder/decoder to endpoint.
> >>
> >> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
> >>
> >> My Route Confuiguration is as follows
> >>
> >> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
> >> <process ref="byteResponseMessage" /> <to
> >> uri="bean:messageLogger?method=log" /> <to
> >> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&e???ncoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
> >> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
> >> </route>
> >>
> >>
> >>
> >> --
> >> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >
> >
> >
> > --
> > 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/
>
>
>
> --
> 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/
--
pica
Re: Camel-Netty ReadTimeout event not trigerred
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I added an unit test to camel-netty that works
https://github.com/apache/camel/commit/76c6a275e49960a6011c0c13102877c0ccf61366
On Thu, Jan 15, 2015 at 9:24 AM, Claus Ibsen <cl...@gmail.com> wrote:
> What version of Camel do you use?
>
>
>
> On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
>> ReadTimeout event is not triggered properly after adding custom
>> encoder/decoder to endpoint.
>>
>> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
>>
>> My Route Confuiguration is as follows
>>
>> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
>> <process ref="byteResponseMessage" /> <to
>> uri="bean:messageLogger?method=log" /> <to
>> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&encoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
>> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
>> </route>
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> 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/
--
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: Camel-Netty ReadTimeout event not trigerred
Posted by Claus Ibsen <cl...@gmail.com>.
What version of Camel do you use?
On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <al...@gmail.com> wrote:
> ReadTimeout event is not triggered properly after adding custom
> encoder/decoder to endpoint.
>
> I am using DelimiterBasedFrameDecoder & StringEncoder as custom codecs.
>
> My Route Confuiguration is as follows
>
> <route id="route1"> <from uri="wmq:queue:queue1?disableReplyTo=true" />
> <process ref="byteResponseMessage" /> <to
> uri="bean:messageLogger?method=log" /> <to
> uri="netty:tcp://127.0.0.21:2626?decoders=#stxEtxDecoder,#byteToString&encoders=#stxEtxEncoder&sync=true&requestTimeout=5000"
> /> <to uri="bean:messageLogger?method=fromlog" /> <process ref="validate"/>
> </route>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Camel-Netty-ReadTimeout-event-not-trigerred-tp5761676.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
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/