| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Under what conditions, an activity instance gets stuck? |
« View previous topic :: View next topic » |
| Author |
Message
|
| ucbus1 |
 Posted: Tue Dec 02, 2003 12:58 pm Post subject: Under what conditions, an activity instance gets stuck? |
 |
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
I have upes stop in which, Workflow puts message in queue Q1.
The message will be retireved by a custom program that does some database updates and responds to workflow EXEXMLINPUTQ. The EXEXMLINPUTQ is defined as remote queue where the
custom program is running. The custom program browses the message,checks some falgs, if flags are OK then, reads the message.Once it is done with the processing it replies back to workflow.
Here is the problem.
This activity has been the bottleneck. The activity instace at this stop often gets stuck. I mean it shows with state "Running" but will be waiting at the stop. Since it is a UPES stop, we have to force restart to create a work item. Then we logon to Fat client and restart the work item The occurance of activity instace at this stop often gets stuck is often when there is high amount of messages that had to be processed by the "custom program". How how do I figure out wheter it is workflow that is misbehaving or the "custom program"?
Under what conditions, an activity instance gets stuck? and how to avoid it?
Please do let me know your input
Thanks |
|
| Back to top |
|
 |
| Andy |
| Posted: Tue Dec 02, 2003 1:37 pm Post subject: Re: Under what conditions, an activity instance gets stuck? |
|
|
Centurion
Joined: 14 May 2003
Posts: 122
|
| ucbus wrote: |
This activity has been the bottleneck. The activity instace at this stop often gets stuck. I mean it shows with state "Running" but will be waiting at the stop. Since it is a UPES stop, we have to force restart to create a work item. Then we logon to Fat client and restart the work item |
My understanding for UPES activity is- there would be no workitem. So we can not restart it using FAT client. If activity is synchronous type, activity instance would be in running state until response is received from custom program.
I have not worked on UPES, please correct my understanding.
Thanks
_________________
 Andy |
|
| Back to top |
|
|
| ucbus1 |
| Posted: Tue Dec 02, 2003 2:12 pm Post subject: |
|
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
You are right there is now workitem when it is in UPES. But when you force start the Activity Instance, a work item will be created. This work Item will be in ready state. This can be started either through webcleint or FAT client. But we were not having much luck with web client hence we use Fat client for this purpose
In our case the process is synchronous hence it is understandable that we are waiting for the response. But we are unable to prove that the "custom program" is not responding with the response message. Has anybody encounter such situation. If so , how did you solve it?
Thanks |
|
| Back to top |
|
|
| jmac |
| Posted: Thu Dec 04, 2003 4:16 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Is it possible that the Upes Queue is just temporarily backed up? I mean if you wait long enough do these instances eventually run? I would assume that MQWF puts the instance into the RUNNING state when it puts the message on the Queue, therefore, if that message sits on the queue because the queue monitor looking at this queue is busy, then it will appear to run longer than normal.
Give me a little more information, and maybe I can help.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| ucbus1 |
| Posted: Fri Dec 05, 2003 6:17 am Post subject: |
|
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
Thanks jmac
Here are the details.
In our model we have a couple of upes stops. We use vendor supplied "messageHandler" framework.One of the UPES stops is to contact another custom application say "xyz". To handle this we have defined in buldtime a UPES service called XYZUPES and defined the server to allow workflow to put REQUEST messages on to XYZQ. Now the custom app XYZ does some "HUGE" work. The way it does is, it browses the queue XYZQ, takes a message, checks some tables, if it finds relavant data then READS the message, processes RESPONSE and replies directly to Workflow's EXEXMLINPUTQ.
The process works fine on a GOOD day.
But one of the BAD days, we get some of the work instances stuck at the stop XYZ. Workflow indicates its waiting for response from XYZ showing with two GREEN arrrows and the AI state will be Running. But the response is never received from XYZ. So, what we have to do is to FORCE_RESTART the AI. This would create a work item in READY state. Then we would logon to Fat client and START the work item. This then processed by XYZ and everything then onwards OK.
Here are my questions:
1. When workflow shows two GREEN arrrows and the AI state in " Running", does itn't mean that workflow processed it and waiting for response. I think the process is defined as SYNCHRONOUS.Does workflow maintains this in any of the internal logs ( Of course in clear text format) that its waiting on XYZ? Is there any chance that its workflow doing the mischief by showing that it handed over the message to XYZQ, but not really? Or is it MQSeries definitions of the queue that is causing the problem. The queue XYZQ is defined with mostly default values except Max. depth and backout parameters.
2. The XYZ process is not in my scope, however I am working with them to log the message they have received, so that we could balance between Workflow and XYZ. If workflow says its waitng on XYZ, then we have to find it on the logs of XYZ (right?)
3. This is for Firefighing. Whenever a work instance shows its waiting on some response more than say 3 days, what we have to do is to FORCE_RESTART the AI. This would create a work item in READY state. Then logon to Fat client and START the work item. This then processed by XYZ and everything then onwards OK.I have tried to start the work_item from "webclient" but it does not work. Is it not weird?
If I have to do this programmatically, what should be my programming logic?
Thanks a Zillion |
|
| Back to top |
|
|
| ucbus1 |
| Posted: Mon Dec 08, 2003 11:04 pm Post subject: |
|
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
|
| Back to top |
|
|
| jmac |
| Posted: Tue Dec 09, 2003 9:24 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
| ucbus wrote: |
| Here are my questions: |
My Answers based on my understanding.
1.Not sure what you mean by two GREEN arrows, but if the ActivityInstance is in the running state, and this is a UPES activity, either the ActImplInvoke message is still on the UPES queue, or the UPES has not responded to EXEXMLINPUTQ. My guess is that this is the fault of your UPES.
2. Yes... if you have contacted XYZ and it logs, you should see an indication that it has received your input. Does your UPES (which contacts XYZ) show a log entry indicating that it has sent its message to XYZ? If not maybe you have a bug prior to contacting XYZ, if so then the problem most likely lies in XYZ.
3. Access AI, get a workitem, forceRestart workitem, start workitem.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| ucbus1 |
| Posted: Wed Dec 10, 2003 5:43 am Post subject: |
|
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
Thanks JMAC
| Quote: |
| if you have contacted XYZ and it logs, you should see an indication that it has received your input. Does your UPES (which contacts XYZ) show a log entry indicating that it has sent its message to XYZ |
.
Could you please tell me which log you are referring to?
If I understand correctly, Messagehandler framework does not log this as it is not set as service working under MessageHandler. the stop is defined as UPES service under build time and workflow recognizes it and sends to the destination as specified by UPES. Ami I missing something?
If it is one of the Workflow specific logs, could you please tell me which log might contain this info?
Thanks |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Dec 10, 2003 5:55 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Assuming that I am familiar with the MessageHandler you are refering to, you can most certainly cut a log record prior to invoking XYZ so that you can see if you are passing control correctly. There is no way I can know what logs XYZ cuts since I have no clue what it is. I am not talking about any MQWF logs, just the MHF log to see if XYZ is getting invoked, then any logs that XYZ might use.
_________________
John McDonald
RETIRED |
|
| 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
|
|
|
|
