Asankha & Paul,
Rather than leaving the send out of try there is another solution, I think
we can change the configuration of the try mediator a bit and resolve this
issue.
The modified try mediator will be as follows.
<try onError="$ref_to_sequence_def" finally="$ref_to_sequence_def">
mediator+
</try>
Then we can set the onError and finally sequence references as corelate
properties to the in message context so that the references will be
availabel in the out message context.
Check the out message context for Faults and execute the relevant sequence.
Even though this is not the expected way of mediating the try, this will
simulate the try mediator.
I think the problem was that we can't keep track of a reference to the
onError mediator list, so if we can make it a sequence def, we have a
reference to that, which is the basic idea of the above solution.
Thanks,
Ruwan.
On 2/7/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Asankha
I think its reasonable to leave the send out of the try, but maybe we
need to add a failure handler to the send:
<send>
<endpoint ...>
<onError>
<log>...
</onError>
</send>
Paul
On 2/7/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
> I have come across a situation (with the synapse sample #4) where the
> try mediator will not work with non-blocking transports anymore. I think
> it seems to the user that it would be able to block and detect any
> errors during a send operation and then execute the onError and finally
> sequences if something goes wrong - but in reality the connection and
> transmission of a message takes place on one or more different threads.
>
> <try>
> <send>
> <endpoint ref="bogus"/>
> </send>
> <onError>
> mediator+
> </onError>
> <finally>
> mediator+
> </finally>
> </try>
>
> So the possibilities for this issue as I think is to state that the try
> mediator does not support send, though it will work for transforms and
> other such same-thread mediators.. a possible way to detect a connection
> refused, timeout or IO error during send would be to keep a copy of the
> outgoing message and the current sequences' error handler sequence in a
> callback that gets notified by the transport on errors - so that such an
> error 'sequence' could be executed once an exception is detected...
>
> your thoughts and suggestions are welcome
>
> asankha
>
> dscdscs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
