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
<lists-ca...@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 <claus.ib...@gmail.com> [20150116 07:14]:
>> On Thu, Jan 15, 2015 at 4:15 PM, Joan Picanyol i Puig
>> <lists-ca...@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 <claus.ib...@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 <claus.ib...@gmail.com>
>> >> wrote:
>> >> > What version of Camel do you use?
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Jan 14, 2015 at 1:41 PM, V4Vaithi <alagappan.i...@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: cib...@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: cib...@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: cib...@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: cib...@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/
