| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How "transaction" is handled by WMB ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| ruimadaleno |
 Posted: Wed Oct 15, 2014 3:52 am Post subject: How "transaction" is handled by WMB ? |
 |
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi all,
one question about message broker internal behaviour that is raising some confusion here 
let's consider a message flow with the following struture:
Soap Input ---> A -> B -> C -> D ---> Soap Reply
where A , B, C and D are compute nodes that process the received message.
Soap Input http timeout is set to 60 seconds
So the scenario is:
message flow receives the message, soap input sends message to node A , node A starts processing, node A sends to node B to process message and so on until the soap reply outputs the resulting message.
Suppose that the work done by A, B , C and D takes longer than 60 seconds (no mather wich one of the nodes is taking longer to process). Than a timeout is "raised" ... what happens ?
1) when timeout is "raised", message processing is immediately interrupted, a rollback happens, flow is routed to soap input httptimeout node.
2) timeout is raised in another thread ( let's call it the "timeout thread") , the processing continues until the "processing thread" receives an acknowledge of the timeout, sent by the "timeout thread". A rollback happens, flow is routed to soap input httptimeout. There is the risk that something is processed while the "processing thread" is not informed by the "timeout thread".
3) another behaviour ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Oct 15, 2014 4:15 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If the processing takes longer than the timeout period you get an error thrown by the SOAP Reply node that says something like
-Message handle already used
This is from memory so I am sure that someone will be along shortly with the full responce inclusing BIP code.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Wed Oct 22, 2014 3:40 pm Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi SmDavies,
some additional info to my scenario. we are using "additional instances" =0, only one instance of the flow is created by execution group/ broker.
my millon dollar question is, how the broker handles the timetimeout. Each instance of the message flow is running under only one thread ? or by the other side, one single instance of the flow is supported by several threads?
What happens when max client wait time (defined in soap input) is reached ?
The only thread running the message flow instance is signaled , processing is immediately interrupted and message is sent to soap input http timeout terminal ?
or
The instance of the message flow is supported by several thread, for simplicity lets assume 2 threads, and call it thread A and threadB . One of the threads is watching the timeout (thread B) while thread A is handling the message flow processing. When thread B detects timeout, is signals thread A , wich is immediately interrupted and message is sent to soap input http timeout terminal ?
no luck searching KC or documentation on this subjects 
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 22, 2014 8:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Why do you assume that the main thread changes dramatically on time out?
The timeout thread sends the notification to the timeout terminal. If that terminal is connected and sends something back to the caller the token is consumed. When the main thread then tries to send the reply (post timeout) the reply node will throw the exception about not being able to use the handle as it has already been used /expired (by the timeout thread).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| akil |
| Posted: Tue Oct 28, 2014 10:48 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
My understanding ( from the trace ) like fjb_saper says is the following.
In the case when nothing is attached to the timeout terminal,
1. A reply is sent to the client
2. The initial flow will complete by itself , that means a , b ,c , d all these nodes will complete, and if any node says commit instead of automatic as it's transaction attribute, it will go ahead and commit as well, even if that happens after the timeout
3. rollback will be issued at the message flow level by the input node
4. A second reply will be attempted but an exception will come that says a reply identifier is invalid.
I have not tried a case where something is connected to the timeout terminal , though as per the documentation any nodes connected to the timeout terminal have a limited time to complete processing as a timeout reply is guaranteed to be sent ..
In either case, nothing stops the execution of the flow that timed out, it will complete its full cycle, obeying the transaction attributes on the nodes, eventually ending with a rollback..
_________________
Regards |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 28, 2014 10:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Are you sure the initiating HTTP client (that is sending the SOAP message) is not specifying a timeout of 30 seconds? |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Wed Oct 29, 2014 2:27 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Thank you all for your reply's
i have built a test case and consistently reproduce the timeout behaviour.
Lesson learned: message flow work is always done , even if a timeout occurs
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| akil |
| Posted: Wed Oct 29, 2014 9:23 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Fri Oct 31, 2014 4:05 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi akil,
very good work in your invesgation ! you should write a redpaper on the subject ! 
I have read you text and find some typos/improvements:
| Quote: |
| Takeaways, 6 - " ... like the main flow, the nodes attached to the time terminal also observe the ..." |
it should be ".. nodes attached to the TIMEOUT terminal also ..."
| Quote: |
| The timeout flow does not have a configurable timeout, the broker will time out by itself and return a SOAP fault if the timeout flow takes an unreasonable time, so make sure this flow is short. |
| Quote: |
| ...Well, the broker handles this case as well, it waits for some time (its not specified what time is this)... |
The timeout flow does have a timeout, it is not configurable, but the timeout value is defined by:
| Quote: |
If the Maximum client wait time expires, by default, the listener sends a SOAP fault message to the client, indicating that its timeout has expired. If you have connected the HTTP Timeout terminal, and you are using the HTTP transport, the SOAP Fault message is propagated through the HTTP Timeout terminal. You must include a SOAPReply node in the sequence of nodes connected to the HTTP Timeout terminal and this node must send a valid SOAP Fault message. The listener waits again for the interval defined by the Maximum client wait time (sec) property, or for 10 seconds, whichever is the shorter interval:
•If a response is received before this second interval expires, the listener propagates the response to the client.
•If a response is not received before this second interval expires, the listener sends a SOAP fault message to the client, indicating that its timeout has expired |
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| akil |
| Posted: Sat Nov 01, 2014 5:57 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Thank you for taking the time & the feedback, I've correct the notes.
And yes, that note on the timeout of the timeout flow was very useful, I had missed it in the documentation.
_________________
Regards |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Tue Nov 04, 2014 3:30 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
, here's a link to my sample and some notes...