Not at all.
But do not blame yourself as this is not documented :(
When choosing a flow, several QoS requirements will be checked:
 * synchonous / asynchronous: if the exchange was sent using sendSync or
send
 * persistent: if the message need to be peristent
 * transactional: if the message is enlisted in an xa transaction
 * clustered: if the destination endpoint is clustered (activated on
another clustered jbi container)

The transactional attribute can be set by setting the transaction in the
needed property of the exchange (
MessageExchange.JTA_TRANSACTION_PROPERTY_NAME).  This can also be done
automatically by servicemix using autoEnlistInTransaction attribute on the
container (if an xa transaction is running, the property will be set).
Persistent feature may be set using the persistent attribute on the
container, on the activation spec or on the exchange itself (
org.apache.servicemix.JbiConstants.PERSISTENT_PROPERTY_NAME).

Each flow will check if it can fullfill the needed requirements, and the
first flow to answer yes will be used (this can be customized).
For example, the jms flow will reject any transactional exchange, whereas
the jca flow will reject any synchronous exchange and seda/st flow will
reject any persistent or clustered exchanges.
Note that you can force the NMR to choose a given flow by using the
JbiConstants.FLOW_PROPERTY_NAME property on the exchange.

The only combination that is not handled at all by servicemix is: clustered
+ transactional + synchronous.

However things should be improved regarding to clustering: the seda/st
should accept clustered exchanges if the target endpoint is also activated
locally.

Hope this helps,
Guillaume Nodet

On 5/17/06, William Blackburn <[EMAIL PROTECTED]> wrote:

Sorry, I swear this is my last post on this topic!

Requesting a particular Q0S - is this done when creating the
exchange? i.e. getExchangeFactory().createInOnlyExchange() would use
seda by default while getExchangeFactory().createRobustInOnlyExchange
() would use jca?

B.J.

On May 16, 2006, at 5:12 PM, Guillaume Nodet wrote:

> 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.





--
Cheers,
Guillaume Nodet

Reply via email to