After further investigation, I have two more questions. But first, my test flow
is as follows:
file:poller -> eip:Pipeline(transformer) = {eip:ASyncBridge ->
eip:StaticRecipientList -> [1a. smx-bean -> 1b eip:RecipientListAggr] [2.
eip:RecipientListAggr] -> smx-saxon -> eip:ASyncBridge} -> file:sender
In order to test the eip:RecipientListAggr timeout case, I set the timeout
value to a very small number.
1. In StaticRecipientList.java, I see a boolean reportErrors property. In the
async case if this property is true, I see a UnsupportedOperationException("Not
implemented") being thrown. If reportErrors=true was supported in this case,
would it be appropriate for the RecipientListAggr to return an
ExchangeStatus=ERROR if a timeout occurs. I am working with the Spagic folks to
merge some of their Synchronizer functionality into the ASyncBridge which you
recently committed. The Synchronizer's value add is it supports ASync
processing and it offers an "ASyncBridgeFaultListener" which looks for error or
fault messageExchanges that are generated "between" an ASyncBridge start and
finish. When the listener gets one of these error/fault exchanges, it sends a
new exchange back to the ASyncBridge for graceful handling. So, in this case,
if the RecipientListAggr returned an ExchangeStatus=ERROR, the
ASyncBridgeFaultListener would catch it and send an "error"
messageExchange back to the ASyncBridge for handling. Does this make sense?
2. In the AbstractAggregator.onTimeout thread, the ThreadLocal
JBIConstants.CORRELATION_ID property is being set to the RECIPIENT_LIST_CORRID
instead of using the JBIConstants.CORRELATION_ID present throughout the rest of
the flow. So, in the timeout case, the messageExchange
JBIConstants.CORRELATION_ID returned by smx-saxon to the ASyncBridge is the
RECIPIENT_LIST_CORRID which it can't find in its store. In the non-timeout
case, messageExchange JBIConstants.CORRELATION_ID returned is the original,
expected value. This seems like a bug to me. Do you agree? If you agree, I have
some ideas for a patch that I would like to run by you. Let me know.
- Ron
----- Original Message ----
From: Guillaume Nodet <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, May 8, 2008 10:48:41 AM
Subject: Re: EIP Aggregator timeouts
You can not send a new exchange with an ERROR status. I guess one way
would be to send an InOnly exchange to another endpoint specifically
when a timeout occurs, but it really depends on the kind of
aggregation used. Overriding the method is quite easy if you want to
do some custom processing too.
On Thu, May 8, 2008 at 10:40 AM, Ron Gavlin <[EMAIL PROTECTED]> wrote:
> When an EIP Aggregator times out, should the aggregate messageExchange
> created have an ERROR status or should the message be flagged in such a way
> to indicate this condition? In AbstractAggregator.sendAggregate, I was
> surprised to find that there is no special processing performed when timeout
> = true. Is this an oversight?
>
> - Ron
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
