Thanks Willem,
Based on your response, I'll be interested to know if there is a better
approach to handle my scenario. Obviously it is a simplified case, but I have
been using a similar approach to achieve high throughput http requests and has
been working fine so far. It is only since I have added the initial http
request through the same channel which has resulted in this issue.
The reason I am re-using the same endpoint is that the URIs are dynamic, so I
set a fixed endpoint URI but then fetch the required content using the
CamelHttpUri header.
Many thanks,
Elvio
-Original Message-
From: Willem Jiang [mailto:willem.ji...@gmail.com]
Sent: 02 February 2015 05:37
To: users@camel.apache.org; Elvio Caruana (ecaruana)
Subject: Re: camel-ahc issue
It’s not a good idea to send the multiple requests through a single channel, as
it could confuse the async handler when it receive the response.
--
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 31, 2015 at 7:12:34 AM, Elvio Caruana (ecaruana)
(ecaru...@cisco.com) wrote:
> Hi,
>
> I think I may have run into a potential issue with camel-ahc. I've
> narrowed it down to a very specific scenario - a combination of
> re-using the same ahc component in combination with using
> split().parallelProcessing() EIP. Tested with camel 2.14.1 and 2.14.0.
>
> I'll try and demonstrate in a simple route:
>
> List list = Arrays.asList("alice", "bob", "charles", "david",
> "edward");
>
> from("timer://foo?repeatCount=1")
> .setBody(constant("someMainRouteContent"))
> .to("direct:fetch") // [1]
> .setBody(constant(list))
> .split(body()).parallelProcessing() // [2] .log("processing ${body}")
> .to("direct:fetch") // [3]
> .end()
> .log("and back to main processing")
> .end();
>
> from("direct:fetch")
> .log("making http request for ${body}")
> .to("ahc:http://localhost:8765/rest/test";)
> .log("returned from http request for ${body}") .end();
>
> Note:
>
> 1. The routes share the same AHC component [1, 3] (i.e. common set of ahc
> worker threads).
>
> 2. The ahc worker thread will continue processing synchronously
> between [1] and [2],until the point the split() parallel thread pool
> takes over. On an http response, the ahc worker thread will continue
> processing synchronouslyas expected.
>
> 3. The above will result in a timeout exception for one of the split
> exchanges (irrespective of the size of the list), and the route never
> completes.
> java.util.concurrent.TimeoutException: Request timeout of 6 ms at
> com.ning.http.client.providers.netty.timeout.TimeoutTimerTask.expire(T
> imeoutTimerTask.java:43) at
> com.ning.http.client.providers.netty.timeout.RequestTimeoutTimerTask.r
> un(RequestTimeoutTimerTask.java:41)
> at
> org.jboss.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(Hashed
> WheelTimer.java:556) at
> org.jboss.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts
> (HashedWheelTimer.java:632) at
> org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java
> :369) at
> org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable
> .java:108) at java.lang.Thread.run(Thread.java:722)
>
> Trace of the above route is attached.
>
> Having two separate ahc endpoints (i.e. with separate thread pools),
> or without parallel processing in the split EIP, then the above works fine.
> Any thoughts?
>
>
> Kind Regards,
> Elvio
>
>
