This is exactly what I'm looking for! I just had a look at
JdbcAuditor and the ExchangeListener interface - I'm pretty sure
writing the code will be straightforward, but I'm pretty new to
servicemix - its clear how to install extensions of componentsupport
using ActivationSpec in servicemix.xml -- but how would I install
such a listener, once I wrote it?
You've been a huge help, I really appreciate it.
On Apr 12, 2006, at 3:16 PM, Guillaume Nodet wrote:
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
