camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Camel-Netty ReadTimeout event not trigerred
Date Sat, 17 Jan 2015 11:04:37 GMT
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-camel@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.ibsen@gmail.com> [20150116 07:14]:
>> On Thu, Jan 15, 2015 at 4:15 PM, Joan Picanyol i Puig
>> <lists-camel@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.ibsen@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.ibsen@gmail.com>
wrote:
>> >> > What version of Camel do you use?
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Jan 14, 2015 at 1:41 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
>> >> >>
>> >> >> <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&amp;e???ncoders=#stxEtxEncoder&amp;sync=true&amp;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/

Mime
View raw message