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
