-
1. Re: Implementing ServiceMix retry logic?
bsnyder May 15, 2008 2:31 PM (in response to roger)During this chain of events, it might happen that something goes wrong. In some of these cases, we want the message to queue up for periodic retries.
In this case I'd recommend using JMS semantics via the use of the servicemix-jms component because JMS provides retry capability already, so there's no reason to implement this in other components.
1. The ExchangeStatus concept somehow implements this, though I don't know whether that's what the functionality is intended for?
There is no retry logic in the ExchangeStatus object. That object is nothing more than a container for the status of a message exchange.
2. If I want a delay between the retries, would it be possible to configure the ESB to provide that?
Redelivery can already be controlled through both JMS as well as via the servicemix-camel component. Take a look at these two components.
Bruce
-
2. Re: Implementing ServiceMix retry logic?
roger May 21, 2008 9:19 AM (in response to bsnyder)Thanks a lot for the answers! With small steps I take myself forward in this jungle...
One further question though: If I activate JMS flow (I suppose I do that by adding the flowType attribute to the container tag in my servicemix.xml file?), would I then use the ActiveMQ settings to control redelivery? I've seen some settings there, but how would I control it per component?
Perhaps this is where Apache Camel comes into question?
Regards,
Roger
-
3. Re: Implementing ServiceMix retry logic?
bsnyder May 21, 2008 1:26 PM (in response to roger)One further question though: If I activate JMS flow (I suppose I do that by adding the flowType attribute to the container tag in my servicemix.xml file?), would I then use the ActiveMQ settings to control redelivery? I've seen some settings there, but how would I control it per component?
The JMS flow is already enabled by default in the servicemix.xml container configuration. Below is the default snippet from that file where the flows are enabled:
<sm:broker> <sm:securedBroker authorizationMap="#authorizationMap"> <sm:flows> <sm:sedaFlow></sm:sedaFlow> <sm:jmsFlow jmsURL="${activemq.url}"></sm:jmsFlow> <sm:jcaFlow connectionManager="#connectionManager" jmsURL="${activemq.url}"></sm:jcaFlow> </sm:flows> </sm:securedBroker> </sm:broker>
Notice that by default, the SEDA flow, the JMS flow and the JCA flow are enabled.
Perhaps this is where Apache Camel comes into question?
The flows in ServiceMix are used by the NMR to communicate with components via a delivery channel. This has absolutely nothing to do with Camel. Camel is only used in ServiceMix by the servicemix-camel component.
Bruce