Configuration is not difficult. Try something like <sm:container flowNames="seda,jca?jmsURL=tcp://localhost:61616"
Depending on the requested QoS for the exchange, one of the flow will be choosen. You can change the default implementation by setting the defaultFlowChooser property on the Broker -- i have just seen that i forgot to add getter / setter :( Anyway, if you use a sendSync on jca flow, an exception should be thrown. If you have multiple flows (including a seda / st flow), sendSync calls should use the seda flow. If your problem is the http binding, you could try using the servicemix-http component which uses send and not sendSync. Cheers, Guillaume Nodet On 5/17/06, William Blackburn <[EMAIL PROTECTED]> wrote:
Success! Got the JCA flow up and running - thank you very much. I did run into that problem with sendSync though. I use an httpBinding component to introduce some messages. It uses sendSync internally, and now I get sporadic io errors when I attempt to use it. I may simply choose to use a jmsbinding for this message insertion, but you mentioned that multiple flows can be configured - does this mean that the httpBinding could use seda or jms, while everything else uses jca? I haven't seen an example of this - if its not too much trouble, could you elaborate? Thanks again for all your help so far. B.J. On May 16, 2006, at 2:02 PM, Guillaume Nodet wrote: > On 5/16/06, William Blackburn <[EMAIL PROTECTED]> wrote: >> Guillaume, >> >> Thank you for your quick reply. Sorry to be so dense, but I just want >> to confirm my understanding of what you've said: >> >> If I configure jms flow only with activemq journaled db persistence, >> I would get recovery of message-exchanges that were 'in-flight' at >> the time of a server crash, but I would NOT get exchanges that had >> already hit a particular component, correct? > > Exactly. > >> >> If I configure jca flow, I will, in addition to above, be able to get >> exchanges that were in the middle being processed by a component at >> the time of the crash, yes? Is this automatic, or must my components >> commit or rollback the transaction? Given that I am using extensions >> of servicemix' ComponentSupport, how would I get access to the >> transaction to do so? > > The JCA flow uses jca ;) > So each time a jms message is received, a transaction is started and > the message consumption is part of the xa transaction. The > transaction will be automatically commited, unless the setRollbackOnly > has been called on the transaction. > You can do that by using the > ((TransactionManager) > ComponentContext.getTransactionManager).getTransaction() > or > (Transaction) exchange.getProperty > (MessageExchange.JTA_TRANSACTION_PROPERTY_NAME) > > Remarks: > * the jca flow does not handle sendSync because the message has to > be enlisted in a transaction so you may experience problems with > components using sendSync (note that you can also configure multiple > flows) > * you can set the autoEnlistInTransaction attribute on the jbi > container to true so that all jbi exchanges will automatically be part > of a transaction > * you should also set the persistent attribute on the jbi container > to true else jms messages will be sent using jms > DeliveryMode.NON_PERSISTENT > > Cheers, > Guillaume Nodet > >> >> Thanks again for all your help. >> >> BJ >> >> On May 16, 2006, at 11:47 AM, Guillaume Nodet wrote: >> >> > On 5/16/06, William Blackburn <[EMAIL PROTECTED]> wrote: >> >> I will be moving from a single deployment, SEDA flow to a cluster >> >> using the JMSflow. I've run the cluster example and studied up on >> >> ActiveMQ, My goal is as much fault tolerance as load handling, >> >> Configuring ActiveMQ's journaled db persistence will get me >> most of >> >> the way (I think), but I still have two remaining questions. >> >> >> >> First, in the MQ sense, when is an message-exchange considered >> >> 'delivered' ? For example, if I have a bunch of servicemix >> components >> >> running on a node configured as above, and I yank the power >> while a >> >> component is in the middle of an 'onMessageExchange()' what >> happens >> >> to that message? Will ActiveMQ redeliver it when the node comes >> back >> >> up? Can components influence what ActiveMQ considers >> 'delivered' in >> >> any way. >> > >> > To be able to use redelivery, the flow should be able to use >> > acknowledgements, jms transactions or xa transactions. Currenly >> there >> > is no callback to be able to use client acks or jms transaction, so >> > you will have to use xa transactions. Note that there is no real >> > overhead if the jms resource is the only one enlisted in the xa >> > transactions. The JCA flow provides high performance concurrent >> > delivery using. The configuration is the same than for the jms >> flow. >> > >> >> >> >> My second question is probably more an ActiveMQ one, but I hope >> you >> >> can comment anyway. We will be using a redundant database- >> server as >> >> well. Should the ActiveMQ brokers be configured to use the same >> >> database? Or should each have its own database? >> > >> > You should either use master / slave, or have a shared database >> if you >> > want high availability, else messages kept by a broker are not >> > available to other brokers, so if this one fails, the message >> will be >> > lost. >> > >> > Cheers, >> > Guillaume Nodet >> >> >> >> Thanks very much in advance for any help. >> >> >> >> B.J. >> >> >> > >> > >> > -- >> > Cheers, >> > Guillaume Nodet >> >> > > > -- > Cheers, > Guillaume Nodet
-- Cheers, Guillaume Nodet
