| Author |
Message
|
| TJW |
 Posted: Wed Mar 12, 2003 8:10 am Post subject: [SOLVED]Clustered UPES causes execution server to die |
 |
|
Novice
Joined: 11 Dec 2002
Posts: 16
Location: UK
|
Has anyone else experienced this 'problem' ...
A UPES is defined with a queue name but a blank queue manager name (this will be a clustered queue).
An activity in a process is defined as using this UPES.
If the queue refered to by the UPES does not exist then when an execution server reaches this activity it fails with error :
FmcAssertionException,.Condition=***.Pre-condition.failed.in.e:\v332\src\fmckstr.inl(323):
.!IsNull().&&.!rhs.IsNull()
Ouch! Surely an MQError 2085 (MQRC_UNKNOWN_OBJECT_NAME) would have been much friendlier. |
|
| Back to top |
|
 |
| DJGoodrich |
| Posted: Wed Mar 12, 2003 9:38 am Post subject: Clustered UPES causes execution server to die |
|
|
Apprentice
Joined: 12 Dec 2001
Posts: 30
Location: SW Florida
|
TJW,
While not(yet) a UPES expert, the problem could be more MQ specific.
Whether or not you are using clusters or distributed queuing, my understanding and experience has been you can only issue a GET from a locally defined queue. |
|
| Back to top |
|
|
| vennela |
| Posted: Wed Mar 12, 2003 10:00 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
DJG:
Workflow would PUT message to UPES and GET from EXEXMLINPUTQ.
TJW
My exec server is not failing.
Is it a synchronous activity or asynchronous. Where are you seeing this error.
-------
Venny |
|
| Back to top |
|
|
| TJW |
| Posted: Thu Mar 13, 2003 1:24 am Post subject: |
|
|
Novice
Joined: 11 Dec 2002
Posts: 16
Location: UK
|
I can replicate this error with both synchronous and asynchronous activities.
If I specify a queue manager for the (still) undefined queue then the UPES activity generates the expected MQerror 2085 rather than crashing the execution server. Unfortunqtely this isn't a work around that I can use as it defines the UPES queue as local instead of clustered.
By the way, this is MQWF 3.3.2 SP 2 on WindowsNT ... yes I know SP3,4 and v3.4 are available but it isn't possible to upgrade the system just yet.
Below is a sample fdl that I've used to test the problem - it requires a local queue SYNCH_QUEUE to be defined otherwise the activity that uses it will also cause the execution server to fail 
| Code: |
/*
*
* FDL definitions generated by MQSeries Workflow
*
*/
CODEPAGE 1252
FM_RELEASE V3R3 2
/*
* PROGRAMs
*/
PROGRAM 'Dummy'
DESCRIPTION "Dummy application taking any data structure"
STRUCTURES_FROM_ACTIVITY
UNATTENDED
WINNT EXE PATH_AND_FILENAME "c:\winnt\system32\cmd.exe"
INHERIT ENVIRONMENT
STYLE VISIBLE
START FOREGROUND
END 'Dummy'
/*
* SERVERs
*/
SERVER 'BADUPES'
DESCRIPTION "UPES using an undefined queue"
RELATED_GROUP 'FMCGRP'
RELATED_SYSTEM 'FMCSYS'
TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER
MQSYSTEM MQSERIES
MESSAGE_FORMAT XML
PHYSICAL_QUEUE_NAME "UNDEFINED_QUEUE"
VERSION 3
RELEASE 3
LEVEL 0
END 'BADUPES'
SERVER 'SYNCH'
DESCRIPTION "Dummy UPES used for synchronisation - QUEUE MUST EXIST"
RELATED_GROUP 'FMCGRP'
RELATED_SYSTEM 'FMCSYS'
TYPE USER_DEFINED_PROGRAM_EXECUTION_SERVER
MQSYSTEM MQSERIES
MESSAGE_FORMAT XML
PHYSICAL_QUEUE_NAME "SYNCH_QUEUE"
VERSION 3
RELEASE 3
LEVEL 0
END 'SYNCH'
/*
* PROCESSes
*/
/*
* PROCESS SERTEST
*/
PROCESS 'SERTEST' ( 'Default Data Structure', 'Default Data Structure' )
DESCRIPTION "Test serial processing when a queue does not exist"
DO NOT PROMPT_AT_PROCESS_START
WINDOW VIEW_REFERENCE_POINT XPOS 0 YPOS 378
WINDOW SHOW ALL CONNECTORS
WINDOW SHOW NO CONDITIONS
SOURCE 1 XPOS -600 YPOS 600
PROGRAM_ACTIVITY 'FINISH' ( 'Default Data Structure', 'Default Data Structure' )
DESCRIPTION "If we get here then the test activity has been processed"
START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS 600 YPOS 300
NAME_POSITION XPOS 600 YPOS 225
PRIORITY DEFINED_IN INPUT_CONTAINER
PROGRAM 'Dummy'
PROGRAM_EXECUTION_UNIT 'SYNCH.FMCSYS.FMCGRP'
SYNCHRONIZATION NESTED
END 'FINISH'
PROGRAM_ACTIVITY 'LAUNCH' ( 'Default Data Structure', 'Default Data Structure' )
DESCRIPTION "Activity to launch the UPES activity under test"
START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS -400 YPOS 300
NAME_POSITION XPOS -400 YPOS 225
PRIORITY DEFINED_IN INPUT_CONTAINER
PROGRAM 'Dummy'
PROGRAM_EXECUTION_UNIT 'SYNCH.FMCSYS.FMCGRP'
SYNCHRONIZATION NESTED
END 'LAUNCH'
PROGRAM_ACTIVITY 'TESTUPES' ( 'Default Data Structure', 'Default Data Structure' )
DESCRIPTION "If clustered UPES queue used by this acitivity is undefined then it leads to execution server failure"
START AUTOMATIC WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS 100 YPOS 600
NAME_POSITION XPOS 100 YPOS 525
PRIORITY DEFINED_IN INPUT_CONTAINER
PROGRAM 'Dummy'
PROGRAM_EXECUTION_UNIT 'BADUPES.FMCSYS.FMCGRP'
SYNCHRONIZATION NESTED
END 'TESTUPES'
CONTROL
FROM 'LAUNCH' TO 'TESTUPES'
CONTROL
FROM 'TESTUPES' TO 'FINISH'
DATA
FROM SOURCE 1 TO 'LAUNCH'
MAP '_STRUCT' TO '_STRUCT'
END 'SERTEST'
|
|
|
| Back to top |
|
|
| jmac |
| Posted: Thu Mar 13, 2003 6:00 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Is there some reason why the UPES queue is not defined?
It seems to me that the solution to this is to make sure the queue is defined. In the beginning there was an issue with the Execution server crashing when the queue was not defined, but we're talking V3.2 here.
I know that the ES no longer dies for a synchronous UPES, but I can't say for sure about asynchronous, when the queue is not defined.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| TJW |
| Posted: Thu Mar 13, 2003 6:57 am Post subject: |
|
|
Novice
Joined: 11 Dec 2002
Posts: 16
Location: UK
|
The UPES queue is undefined because of an 'administrative error' (someone deleted the wrong queue).
As mentioned previously the ES dies whether the activity is synchronous or asynchronous.
An MQ2085 error would have enabled us to track the problem down much faster beacause the state of the UPES activity would have been recorded as InError. When the ES dies the workflow backs out to the previous activity, so it is not immediately obvious that the problem is with queue definitions. |
|
| Back to top |
|
|
| jmac |
| Posted: Thu Mar 13, 2003 7:23 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
TJW:
I am running V332 sp3 and when I start an instance whose first activity uses a Queue which is not existant the ES does not die, the Workitem goes into an "In Error" state with the following Error reason:
Error reason is: FMC32008E The program Dummy could not be started.
The system call MQPUT to OVISIT@FMCQM returned rc=2 and an error code of 2085.
I see nothing in the Readme of SP3 to indicate that this was new with SP3.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| TJW |
| Posted: Thu Mar 13, 2003 7:28 am Post subject: |
|
|
Novice
Joined: 11 Dec 2002
Posts: 16
Location: UK
|
I have just procured a test machine to see if the problem occurs on later service packs.
With 3.3.2 SP4, for both synchronous and asynchronous UPES, the ES no longer dies and the expected 2085 error is generated.
Problem solved.
Hopefully we can move to SP4 before any more admin. errors |
|
| Back to top |
|
|
|
|
