camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <>
Subject Re: Is the SEDA producer really async?
Date Sun, 23 Sep 2012 12:16:54 GMT
Am 23.09.12 13:53 schrieb "Babak Vahdat" unter

>Hi Raul,
>As the documentation states:
>  When we say a component is supported, that means the component is
>leveraging the asynchronous model.
>And yes the SedaProducer leverages the asynchronous model because it
>extends the *abstract* DefaultAsyncProducer base class (abstract because
>it actually does not provide any Impl for the AsyncProcessor interface but
>it's extensions do that, like SedaProducer)
>Now SedaProducer is indeed asynchronous because we will get the reply (if
>any) through an onCompletion block, which itself will be always invoked
>asynchronously (see the first blue box below):

Part of my reply was of course nonsense :-( in background, kids are still
yelling for swimming-pool

The link I provided above has to do with the onCompletion() block on the
DSL level (OnCompletionProcessor) which has nothing to do with the
Exchange.addOnCompletion() API. The first runs always asynchronously
however the latter always synchronusly


>And in case we don't have any reply to wait for, well then we just add a
>copy of the original exchange to the BlockingQueue being attached on the
>endpoint, *but* with handover being enabled so that it's the *copy* having
>all those "org.apache.camel.spi.Synchronization" callbacks being attached
>to it and not the *original* exchange anymore. So that also in this case
>we will have no synchronous overhead (by the original exchange) for the
>completion of the Synchronization callbacks if any (see UnitOfWorkHelper
>executing the callbacks synchronusly on the copy, for which we don't have
>to wait for at all by the original exchange, as we did the handover
>original => copy).
>Now in both cases above (with or without wait) the process()
>implementation of SedaProducer *itself* actually did his job
>synchronously! So why we should signal the callback we are done
>synchronously (The reason why "true" is being returned and not "false").

View raw message