camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CAMEL-11731) Servlet Component isn't really async
Date Thu, 01 Feb 2018 10:01:00 GMT


ASF GitHub Bot commented on CAMEL-11731:

onderson commented on issue #2188: CAMEL-11731 - add asynccallback and sync camel and servlet
async APIs
   AFAIK, async servlet API handles requests by writing to HttpServletResponse and setting
context.complete(). Currently (before what i have done) what is done in CamelServlet is to
do this and process camel's exchange with  `consumer.getProcessor().process`. What i have
added is to call `consumer.getAsyncProcessor().process(exchange, asyncCallback)` with a proper
asyncCallBack in which callkback.done(false) is called after completing to write to HttpServletResponse,
which will trigger context.complete(). 
   If you can describe what your thinking around the subject of the complexity, i'd like to
try to implement..
   Thanks for the review.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> Servlet Component isn't really async
> ------------------------------------
>                 Key: CAMEL-11731
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-servlet
>    Affects Versions: 2.18.4, 2.19.2
>         Environment: All
>            Reporter: Nick Houghton
>            Assignee: ├ľnder Sezgin
>            Priority: Major
>             Fix For: Future
> So my assumption reading the servlet component doco is that with 2.18+ and a Servlet
3+ container, the component supports async, which it kind of does with the async=true init
config, and there is even a method in CamelServlet called "doServiceAsync" but from what i
can tell it doesn't really do it in a asynchronous manner, where there are no blocked threads
while a request is awaiting an async operation (like an AHC call for example).
> Looking at:
> While processing a request, we check if we are in async mode and call doServiceAsync..
> {code:java}
>  @Override
>     protected final void service(HttpServletRequest req, HttpServletResponse resp) throws
ServletException, IOException {
>         if (isAsync()) {
>             final AsyncContext context = req.startAsync();
>             //run async
>             context.start(() -> doServiceAsync(context));
>         } else {
>             doService(req, resp);
>         }
>     }
> {code}
> then in doServiceAsync() we call doService().. and then we call getProcessor().process(exchange),
not process(exchange, asyncCallback) which is the proper async method..
> {code:java}
> try {
>             if (log.isTraceEnabled()) {
>                 log.trace("Processing request for exchangeId: {}", exchange.getExchangeId());
>             }
>             // process the exchange
>             consumer.getProcessor().process(exchange);
>         } catch (Exception e) {
>             exchange.setException(e);
>         }
> {code}
> So the actual behaviour is an inbound request in async mode that ends up just blocking
waiting for the request to complete, in a totally sync manner. I presume this is not the desired
> It seems the fix would be to move the doService() logic to doServiceAsync() and have
doService() call it and use the AsyncProcessorConverterHelper. Or the other alternative would
be to update the documentation to explicitly note that it is actually not async at all.
> I can probably PR it in, just wanted to get thoughts on the actual intention.

This message was sent by Atlassian JIRA

View raw message