Currently, the only way to have a redelivery behavior in ServiceMix would be to use a JCA flow that handles XA transactions (provided that your component rollback the transaction). I think the mechanism you describe could be implemented in a generic way using a listener configured on the ServiceMix container. Such a listener would be able to intercept exchanges with an ERROR status and put them in a redelivery queue. This would be a ServiceMix specific feature but completely transparent to the components themselves. The only drawback if that the exchange would not be the same (but a copy). Some of the code in the JdbcAuditor may be reused for that (it's quite easy to resend a JBI exchange).
Does this make sense ? Cheers, Guillaume Nodet On 4/12/06, William Blackburn <[EMAIL PROTECTED]> wrote: > Thank you - this makes sense, in fact I've seen this behavior in the > httpbinding component (initially I wasn't sending an answer and it > blocked). > > But does this mean that I should go ahead and implement my own > redelivery mechanism to address my other concern? I want to address > this scenario, but in an async way - I can code the behavior myself, > something like: > > * the provider might receive the exchange and determine that it can't > successfully complete it now, but that it may be able to in the future > * the provider sends the exchange (or a representation of it) to a > retry queue or similar > * a Quartz task or similar component periodically pulls from the > retry queue and resends the exchanges > > But I don't want to write all this if servicemix itself has this > behavior. > > BJ > > > > On Apr 12, 2006, at 1:51 PM, Guillaume Nodet wrote: > > > Let's take a simple example with an In-Only pattern. > > The consumer will create an exchange and send it synchronously: > > > > channel.sendSync(exchange) > > > > If the provider only receives the exchange without calling done or > > fail, > > the consumer will be blocked forever ... > > > > One of the reason why the consumer could send the message > > synchronously is when the JAXP source set as the content of the > > NormalizedMessage is a stream based source. > > (Imagine the case of a file poller which would only send an input > > stream opened on the file instead of reading the whole file in > > memory). In such a case, the consumer will want to close the stream > > when the provider as returned a status (DONE or ERROR). > > > > Hope this helps, > > Guillaume Nodet > > > > On 4/12/06, William Blackburn <[EMAIL PROTECTED]> wrote: > >> I'm trying to figure out the use of the 'status' property of > >> MessageExchange especially regarding servicemix Pojo components. Most > >> of the examples I've seen show using the convenience methods 'answer' > >> 'done' and 'fail' to set this status appropriately upon completion of > >> the work done by the component. > >> > >> Practically speaking, I cannot see differences in behavior regarding > >> this status. Indeed in my early testing I never set it at all, and > >> nothing seemed worse for wear. > >> > >> I was hoping to discover that failing to set this status to a > >> completed state would result in further attempts to deliver the > >> message, but this is not the case. > >> > >> My question is, what do these states signify, and which of > >> servicemix' internals is using the status? Secondly, is there a > >> configuration of servicemix that would allow a component to receive > >> repeated delivery attempts of an exchange that has not been set to a > >> completed state? > >> > >> Sorry to keep harping on this subject, but I'm desperate - thanks for > >> any help, > >> > >> BJ > >> > >
