| Author |
Message
|
| sankritya |
 Posted: Thu Aug 19, 2010 7:46 am Post subject: Release of Thread and Memory for the flow using JCN |
 |
|
Centurion
Joined: 14 Feb 2008
Posts: 100
|
Hi All,
A flow is created with following nodes
SOAPInput ->SOAP Extract->JCN -> SOAP Reply
In the JCN a tuxedo service is called by connecting to Tuxedo Server using the Jolt API's. Number of Additional instances for the flow is set to 5 and request timeout is set to 60 seconds in SOAP Input. log4j is used for storing all the messages in a file in JCN. I want to know that in the case of exception scenario when the Tuxedo service does not provided the response in 60 seconds a timeout is triggered with exception written in the user log. As the request has timed out is the flow instance is released along with memory used?
Response message from the Tuxedo is getting written in the logs even in the case when an exception has occurred. Does it means the flow instance is still active?
I am using Broker 6.1.0.2 in AIX environment. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Aug 19, 2010 8:17 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
For what purpose do you use Tuxedo and WMB?
Why don't you use the built-in transactionality of WMB/MQ?
Using Tuxedo AND WMb is like Suzanne Somers getting bolt-ons. She doesn't need them because the originals do the job just fine.
Tuxedo's three main functions are: as middleware, to relay request and response communications between servers and clients; as a transaction processing (TP) monitor, to initiate, monitor, and terminate transactions; and, as a distributed TP monitor, to enable interaction between transaction participants on different machines and associated with different databases. All of these functions duplicate those residing in WMB.
What business case was used to justify the use of Tuxedo in WMB? What technical solution are you trying to solve?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| sankritya |
| Posted: Thu Aug 19, 2010 8:53 am Post subject: |
|
|
Centurion
Joined: 14 Feb 2008
Posts: 100
|
| This has been done for an existing Tuxedo implementation... different approach will be followed during change of implementation where backend will be changing too.... |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Aug 19, 2010 9:05 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Quote: |
As the request has timed out is the flow instance is released along with memory used?
|
No, the WMB thread instance still lives.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| sankritya |
| Posted: Thu Aug 19, 2010 6:30 pm Post subject: |
|
|
Centurion
Joined: 14 Feb 2008
Posts: 100
|
| What is the reason of thread instance being alive when already a SOAP Fault message has been sent back to requester in the form of a Time out message? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 20, 2010 5:49 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
sankritya wrote:
| Quote: |
What is the reason of thread instance being alive when already a SOAP Fault message has been sent back to requester in the form of a Time out message?
|
WMB thread instances don't go away once a message has been processed. They recycle to the beginning and become ready for the next message.
You are better to use the built in Transactionality of Message Broker rather than Tuxedo. A message received under Message Broker's built-in transaction control system becomes a rollable transaction within a unit of work.
Most of the built-in WebSphere Message Broker nodes have Failure terminals. When an exception is detected within a node, the message and the exception information are propagated to the node's Failure terminal. If the node does not have a Failure terminal, or it is not connected, the broker throws an exception and returns control to the input node.
You can connect other nodes or subflows to the failure terminal to perform unhappy path processing. When a message is propagated to the Failure or Catch terminal, the node creates and populates a new ExceptionList with an exception that represents the error that has occurred. The ExceptionList is propagated as part of the message tree.
If you connect the Catch terminal of the input node, you are indicating that the flow handles all of the exceptions that are generated anywhere in the out flow. The broker performs no rollback and takes no action unless there is an exception on the catch flow. If you want any rollback action after an exception has been raised and caught, you must provide this in the catch flow. You can rollback or rollforward transactions in your Catch processing.
The Error Handler sample project demonstrates how to use an error handling routine to trap information about errors and to store that information in a database. The error handling routine is a subflow that you can add, unchanged, to any message flow. The sample also demonstrates how to configure message flows to control transactionality; in particular, the use of globally coordinated transactions to ensure overall data integrity.
I would urge you to use WMB's built-in transactional processing rather than using Tuxedo. What would Suzanne Somers do with bigger knockers anyway? Bolting on a separate Transaction Monitor is not very useful because it cannot process the ExceptionList tree natively like Broker can.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Aug 20, 2010 6:26 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
I think you are a little confused. The timeout on the SOAPInput only applies to the SOAPInput node itself, not the flow as a whole, (so not the JCN). The instance (thread) that is waiting in the JCN stays waiting for the Tuxedo response even after the 60 seconds on the SOAPInput node has elapsed. Internally the SOAPInput node notices that the timeout has expired and the rest of the flow has not sent a reply, so it sends a timeout message back to the client. Then later on the JCN gets its reply back from Tuxedo, after the timout Fault has been sent. The only thing you can do to prevent this is to make the JCN call to Tuxedo timeout before the SOAPInput node does.
I hope this helps...
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 20, 2010 6:41 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Quote: |
| I think you are a little confused. |
Hey -- I . resemble . that remark.
My approach was more global and strategic. I would rather have a more pure implementation enveloping the complete function inside the ESB rather than a patchwork of legacy and new.
Whatever is being done in legacy can much more easily be done in the existing message flow.
You working late for a Friday, eh mgk? No rest for the weary.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Aug 20, 2010 7:10 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| No rest for the weary |
How true 
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 20, 2010 7:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| You working late for a Friday, eh mgk? |
He doesn't mention where he's working from....  |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 20, 2010 8:40 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
