Thanks for your accurate answers. I have seen messages groups but i have some messages which are out potential groups.
So i have to deal with unordered messages. (or i should find a way to have multiconsumer the main time and some time for some known messages i should "downgrade" to only one consumer and then restart all consumers but it will not work ^^). Regards Hervé On 1/31/12, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Tue, Jan 31, 2012 at 10:00 AM, Hervé BARRAULT > <herve.barra...@gmail.com> wrote: >> Thanks, >> So, i should publish sequentially and can consume concurrently. > > Yeah, or public concurrently also. If ordering does not matter. > > Only if you need ordering of messages, and process concurrently you > can use message groups > http://activemq.apache.org/how-do-i-preserve-order-of-messages.html > http://activemq.apache.org/how-do-message-groups-compare-to-selectors.html > http://activemq.apache.org/message-groups.html > > >> >> As there is only direct component which is a synchronous call, I guess >> a transaction can work across multiple route but in one camel context. >> > > Yes that would work. > >> Am i wrong ? > > No. > > >> >> >> On 1/30/12, Claus Ibsen <claus.ib...@gmail.com> wrote: >>> On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT >>> <herve.barra...@gmail.com> wrote: >>>> Hi, >>>> thanks for the quick answer. >>>> >>>>> It does not support batching, not async TX, etc. >>>> >>>> But does it supports TX and concurrentConsumers ? >>>> >>>> I have to multiply the number of consumers as they are slower than the >>>> producer. >>>> >>> >>> Yes. >>> >>> >>>> >>>> On 1/30/12, Claus Ibsen <claus.ib...@gmail.com> wrote: >>>>> On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT >>>>> <herve.barra...@gmail.com> wrote: >>>>>> Hi, thanks for confirmation. >>>>>> So for publication, i should use a transactions with sequential >>>>>> mechanism. >>>>>> >>>>>> I have seen also on activeMQ documentation : >>>>>> http://activemq.apache.org/should-i-use-transactions.html : >>>>>> Its also worth noting that if you are using persistent messaging, the >>>>>> fastest way of using JMS is to actually use transactions and use >>>>>> batching ... >>>>>> >>>>>> Is this mechanism working when using concurrentConsumer ? >>>>>> Or should i choose between transaction and batching ? >>>>>> >>>>> >>>>> The camel-jms component is baked on top of Spring JMS which is generic >>>>> and limited in some areas. >>>>> It does not support batching, not async TX, etc. >>>>> >>>>> Alot of people just use it as is, and its fast enough for their >>>>> use-cases. >>>>> I suggest to use that, and do some testing to see if its fast enough >>>>> for >>>>> you. >>>>> >>>>> >>>>> >>>>> >>>>>> Thanks for answers >>>>>> >>>>>> Regards >>>>>> >>>>>> Hervé >>>>>> >>>>>> >>>>>> On 1/28/12, Claus Ibsen <claus.ib...@gmail.com> wrote: >>>>>>> Spring Transaction does not support using multiple threads. The >>>>>>> transactional work should be done in the same thread, from spring TX >>>>>>> manager point of view. >>>>>>> >>>>>>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT >>>>>>> <herve.barra...@gmail.com> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I found in archive that parallel processing is not compatible with >>>>>>>> transaction. >>>>>>>> >>>>>>>> Is it still relevant or is there a workaround ? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Hervé >>>>>>>> >>>>>>>> On 1/27/12, Hervé BARRAULT <herve.barra...@gmail.com> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have two question about a route, JMS and transactions. >>>>>>>>> >>>>>>>>> The use is : one request response Web service put message on n >>>>>>>>> queues >>>>>>>>> (using transaction ensure the message really put in all queues or >>>>>>>>> no >>>>>>>>> one). >>>>>>>>> >>>>>>>>> Does this route make sense (only "pseudo" route not all the stuff >>>>>>>>> to >>>>>>>>> manage transaction i guess) ? >>>>>>>>> >>>>>>>>> from("cxf:bean:myEndpoint"). >>>>>>>>> .wireTap("direct:tap") >>>>>>>>> .process(myProcessor) >>>>>>>>> transacted("PROPAGATION_REQUIRES_NEW") >>>>>>>>> .multicast() >>>>>>>>> .parallelProcessing() >>>>>>>>> .recipientList(header("MY_HEADER")) >>>>>>>>> .end() >>>>>>>>> .process(myAnswerProcessor); >>>>>>>>> >>>>>>>>> from(direct:tap).process(myOptionalProcessor); >>>>>>>>> >>>>>>>>> If it could work, when is the transaction commit ? >>>>>>>>> >>>>>>>>> Thanks for answers. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Hervé >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Claus Ibsen >>>>>>> ----------------- >>>>>>> FuseSource >>>>>>> Email: cib...@fusesource.com >>>>>>> Web: http://fusesource.com >>>>>>> Twitter: davsclaus, fusenews >>>>>>> Blog: http://davsclaus.blogspot.com/ >>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Claus Ibsen >>>>> ----------------- >>>>> FuseSource >>>>> Email: cib...@fusesource.com >>>>> Web: http://fusesource.com >>>>> Twitter: davsclaus, fusenews >>>>> Blog: http://davsclaus.blogspot.com/ >>>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> FuseSource >>> Email: cib...@fusesource.com >>> Web: http://fusesource.com >>> Twitter: davsclaus, fusenews >>> Blog: http://davsclaus.blogspot.com/ >>> Author of Camel in Action: http://www.manning.com/ibsen/ >>> > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ >
