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
