Re: [mule-user] Handling Sync and Async requests together........
Paul Robinson
Hello,
I am trying to setup the scenario described in this thread. I am using mule
1.4.1
I have the following config file: http://pastie.caboo.se/77664
I send a soap request to UMO1 on http://localhost:8080/requests. Using
TCPMon, I can see that the following request is sent:
http://pastie.caboo.se/77666
I've set a breakpoint in the onCall method of each UMO, which allows me to
control the progression of the workflow. from this I can see that the
following response is sent back to the http client after UMO1 is called and
before UMO2 is called: http://pastie.caboo.se/77667
Nothing appears to happen after UMO3 has been called.
I'm guessing either I've misinterpreted the instructions in the previous
posts, or something has changed in this version of mule.
Any help would be greatly appreciated,
Thanks,
Paul Robinson.
Ross Mason-x wrote:
>
> The replyTo address on the outbound-router on UMO3 should be the
> endpoint specified in the response-router on UMO1 (in this case
> '???????').
>
> Just to clarify the response router behaves the same way as an inbound
> router (i.e. it receives events on an endpoint) except the
> response-router will block the current execution thread (which has been
> started because an event was received by the component).
>
> There seems to be a lot of confusion over this at the moment and it
> doesn't help that the WebApp async example doesn't work. I will fix
> this next week (hopefully as part of the Mule 1.1) release. However, I
> think we need some better examples and docs about how to configure
> ReplyTo's and response routers. Any suggestions are more than welcome.
>
> Cheers,
>
> Ross
>
> Suhas wrote:
>
>> Hi!!!!
>>
>> Shall I have the configuration as follows:
>>
>> *UMO 1:*
>>
>> <mule-descriptor
>> name="UMO1"
>> inboundEndpoint="EndPoint1"
>> implementation="......">
>>
>> <outbound-router>
>> <endpoint address="EndPoint2">
>> </outbound-router>
>>
>> <response-router>
>> <endpoint address="??????/>
>> <router className=".........."/>
>> </response-router>
>>
>> </mule-descriptor>
>>
>> *UMO 2:*
>>
>> <mule-descriptor
>> name="UMO2"
>> inboundEndpoint="EndPoint2"
>> implementation=".......">
>>
>> <outbound-router>
>> <endpoint address="EndPoint3">
>> </outbound-router>
>>
>> </mule-descriptor>
>>
>> *UMO 3:*
>>
>> <mule-descriptor
>> name="UMO3"
>> inboundEndpoint="EndPoint3"
>> implementation="core.TrapLogger"
>>
>> <outbound-router>
>> <router
>> className="org.mule.routing.outbound.StaticRecipientList">
>> <properties>
>> <property name="replyTo" value="EndPoint1"/>
>> </properties>
>> </router>
>> </outbound-router>
>>
>> </mule-descriptor>
>>
>> Thanks
>> -Suhas
>>
>> Suhas wrote:
>>
>>>Shall I have router configure as follows?
>>>
>>>UMO 1 (having response router configured on it)
>>>UMO 3 (having its replyTo property set to UMO 1)
>>>
>>>Sorry but I did not find the sample in docs, can u plz forward the link
for the same.
>>>
>>>Thanks
>>>-Suhas
>>>
>>>
>>> Andrew Perepelytsya wrote:
>>>
>>>>UMO1 should have it. Additionally, every async call _must_ have a
>>>>replyTo set to UMO1. Note this is different from just setting teh
>>>>replyTo without a response router. The response router doc has the
>>>>sample which might help.
>>>>
>>>>On 8/8/05, Suhas <su...@kenati.com> wrote:
>>>>
>>>>
>>>>> On which component should I put the response router?
>>>>>
>>>>>
>>>>> Andrew Perepelytsya wrote:
>>>>> replyTo should put you into the loop. I think response router is the
>>>>> way to
>>>>>go.
>>>>>
>>>>>On 8/8/05, Suhas <su...@kenati.com> wrote:
>>>>>
>>>>>
>>>>> Hi !!
>>>>>
>>>>> I am using mule in following scenario:
>>>>>
>>>>> 1) Browse ------- (should send sync request to) --------------> UMO 1
>>>>> 2) UMO 1 ------- (should send async request to) --------------> UMO 2
>>>>> 3) UMO 2 ------- (should send async request to) --------------> UMO 3
>>>>> 4) UMO 3 ------- (should send aggregated reply to) --------------> UMO
>>>>> 1
>>>>> 5) UMO 1 -------- (should send this reply browser as HTTP response)
>>>>>--------------> Browser
>>>>>
>>>>> I am able to accomplish this till step no. 3, but i am not able to
>>>>> receive
>>>>>the reply for all events from UMO 3 on UMO 1,
>>>>> then aggregate them and send a aggregated reply back as an HTTP
>>>>> response.
>>>>>I am not able to decide what to use
>>>>> response router OR outbound router with "replyTo" property.
>>>>>
>>>>> Please let me know how to accomplish this.
>>>>>
>>>>> Thanks
>>>>> -Suhas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>
> --
> Regards,
>
> Ross Mason
> SymphonySoft Ltd
>
> tel: 07005-978-001
> fax: 07005-978-003
> www.symphonysoft.com
>
>
>
>
--
View this message in context: http://www.nabble.com/-mule-user--Handling-Sync-and-Async-requests-together........-tf207681.html#a11522759
Sent from the Mule - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
Andrew Perepelytsya
Andrew
Paul Robinson
Hello,
Thanks, for the reply....
I'm trying to achieve the original scenario described in this thread. Sorry
if I didn't describe it fully; I think the following sums it up:
1) WS Client ------- (should send sync request to) --------------> UMO 1
2) UMO 1 ------- (should send async request to) --------------> UMO 2
3) UMO 2 ------- (should send async request to) --------------> UMO 3
4) UMO 3 ------- (should send async response to) --------------> UMO 1
5) UMO 1 -------- (should send this reply as HTTP response) -------------->
WS client
What i need to do is have only the http transport as synchronous and then
send a number of asynchronous messages around the system. eventually a
response will be produced and which will be delivered to the blocking http
transport.
the following diagram shows this:
http://www.nabble.com/file/p11537329/simple-async-umo2.png
also, my UMOCallable class looks like this: http://pastie.caboo.se/77974
Ultimately, I want to obtain the response from a synchronous Web service.
Again, the http transport that invokes the Web service will block, whilst
all internal calls within the system are asynchronous.
The following diagram shows this.
http://www.nabble.com/file/p11537329/simple-async-umo-full.png
Eventually, we will want to have the UMOs spanning, many ESBs, hence the
reason for making the internal system asynchronous.
I'm telling you this to help put things in context. Help with just the
original issue would be greatly appreciated!
Thanks a lot,
Paul Robinson.
--
View this message in context: http://www.nabble.com/-mule-user--Handling-Sync-and-Async-requests-together........-tf207681.html#a11537329
Paul Robinson
Also,
I forgot to say. If you (Andrew and the Mule guys) think it would be useful,
I could create a cookbook recipe for the scenario that I'm trying to
achieve; once I've managed to get it working. It seems to me like something
other people would want to do and I don't think it is currently covered in
the documentation.
Paul Robinson.
--
View this message in context: http://www.nabble.com/-mule-user--Handling-Sync-and-Async-requests-together........-tf207681.html#a11538050
Andrew Perepelytsya
Paul,
What i need to do is have only the http transport as synchronous and then
send a number of asynchronous messages around the system. eventually a
response will be produced and which will be delivered to the blocking http
transport.
I don't know why you think all others would be async. This is classic, your calls will simply be sync between UMOs and ultimate response just propagates back to the caller. There are variation, depending on the transport. E.g. if you absolutely must have async (which I don't see a need for yet), e.g. JMS sync could be emulated by sending async messages and layering a response aggregator on top listening on the final reply destination.
Eventually, we will want to have the UMOs spanning, many ESBs, hence the
reason for making the internal system asynchronous.
No, crossing JVM borders does not make you go async, could you explain the reason for that assumption of yours?
I'm telling you this to help put things in context. Help with just the
original issue would be greatly appreciated!
For the original issue you need to add the URI param on the serverUrl to make admin agent synchronous, smth like ?synchronous=true. Or, make the model synchronous by default (in mule-environment-properties) and override with async for endpoints that need it.
Andrew
Paul Robinson
Andrew,
Thanks for the response...
>I don't know why you think all others would be async.
I was under the impression that they would be if I set
<mule-environment-properties synchronous="false" />. I've now modified my
config xml and set "synchronous='false'" on the endpoints that I want to be
asynchronous. I've also added "<mule-environment-properties
synchronous="true" />" as you suggest. Here's my current config xml:
http://pastie.caboo.se/78313
>if you absolutely must have async (which I don't see a need for yet)
This example is a simplified version of what we need to achieve in the long
term. Eventually we would like to have a workflow spanning a number of ESB
processes. We don't want the ESBs to be tightly coupled so we will use
asynchronous message passing between ESBs. The following scenario describes
this:
1) WS-client ------- (should send sync ws-request to) -------------->
UMO1@ESB1
2) UMO1@ESB1 ------- (should send async ws-request to) -------------->
UMO2@ESB2
3) UMO2@ESB2 ------- (should send sync ws-request to) -------------->
WebService
4) UMO2@ESB2 ------- (should send async ws-response) -------------->
UMO3@ESB1
4) UMO3@ESB1 ------- (should send async ws-response) -------------->
UMO1@ESB1
5) UMO1@ESB1 -------- (should send ws-response as HTTP response)
--------------> ws-client
This will allow ESB1 to crash shortly after sending the ws-request to ESB2
and then receive ws-response when it recovers. Also, using asynchronous
messaging internally will allow us to assign a different sized thread pool
to each UMO (in order to support priorities).
> JMS sync could be emulated by sending async messages and layering a
> response aggregator on top listening on the final reply destination.
I think I have attempted to do this by specifying a "response-router" with
the "org.mule.routing.response.SingleResponseRouter" implementation on
"UMO1"
>No, crossing JVM borders does not make you go async, could you explain the
reason for that assumption of yours?
I don't think I explained myself properly here. I wasn't assuming that you
had to use asynchronous messaging over JVM borders, it was more that we want
to use asynchronous messaging. Our reasons for wanting this are described
above.
As stated above, I've changed my xml config to take into account your
comments ( http://pastie.caboo.se/78313 ). I am now experiencing some
different behaviour.
I have breakpoints on my UMO implementation and
"org.mule.routing.response.AbstractResponseAggregator.getResponse(UMOMessage
message)" (this class is extended by the SingleResponseRouter, used by my
"response-router").
1. I begin by sending the following soap request:
http://pastie.caboo.se/78323
2. TCPMon shows the request being delivered to my http endpoint on UMO1.
TCPMon currently shows no response.
3. UMO1 is invoked (breakpoint triggered)
4. UMO2 is invoked (breakpoint triggered)
5. UMO3 is invoked (breakpoint triggered)
6.
org.mule.routing.response.AbstractResponseAggregator.getResponse(UMOMessage
message) is invoked (breakpoint triggered)
7. By stepping through the "getResponse", I notice that a message is
received, but no latch has been registered for it. Therefore a new latch is
created and then the thread waits for the timeout to occur.
8 After 10seconds the timout triggers, an exception is thrown and the
following message is returned to the client: http://pastie.caboo.se/78326.
Notice that a "500 server error" is returned with the desired response
appended!
After all this, the console output is as follows:
http://pastie.caboo.se/78329
What confuses me is that, no latch is created just before the first
asynchronous call from UMO1 to UMO2. Hence, when the response-router obtains
the result, it thinks its a new message and not a result to a previous
message.
Another thing that confuses me is that when the timeout occurs, the message
that passed through each of the UMOs is returned to the client (rather than
just the request as it was received by UMO1). I'm sure this is the case (and
not just the initial request being sent back) as I have tried modifying the
message as it passes through the UMOs (the modified version is the one that
returns to the client).
I hope this all makes sense, any further help would again be greatly
appreciated.
Thanks again,
Paul Robinson.
--
View this message in context: http://www.nabble.com/-mule-user--Handling-Sync-and-Async-requests-together........-tf207681.html#a11562371