To my knowledge the latter one will create a new exchange for each seda invoked route and copy over the data from the origin exchange while the primer one will just create threads within an executor service (no new exchange creation) and thus use the same exchange.
You might see a difference if you put stuff within your thread-logic onto the exchange. Seda provides a (somehow) thread-local usage of the exchange while threads maintains a more global usage of the exchange. In seda each thread should have its local state on the exchange without seeing/interfering the data from other threads while on using threads will probably replace exchange properties and similar stuff. Hope my understanding is correct though ... > Am 25.10.2017 um 01:35 schrieb Robson Vargas Farias > <robsonvargasfar...@gmail.com>: > > small correction on the bench code: > > > <from uri="direct:in"/> > <threads executorServiceRef="my20PoolSizeThreadPool"> > <to Uri="mock:out"/> > </threads> > > versus > > <route> > <from > uri="seda:in?concurrentConsumers=20"/> > <to Uri="mock:out"/> > </route> > > 2017-10-24 21:34 GMT-02:00 Robson Vargas Farias < > robsonvargasfar...@gmail.com>: > >> I'm trying to figure out the real world usage on both asynchronous >> options... even trying to fit a way where I could mix ... but not sure >> whether this makes sense... >> >> so, the question is, what's the basic difference using one or another, >> like: >> >> <from uri="direct:in"/> >> <threads executorServiceRef="my20PoolSizeThreadPool"> >> <to Uri="mock:out"/> >> </threads> >> >> versus >> >> <route> >> <from >> uri="seda:in=20"/> >> <to Uri="mock:out"/> >> </route> >> >> >>
