MQSeries.net :: View topic - Timeout Control and Notification Query

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Timeout Control and Notification Query

Goto page Previous 1, 2

Timeout Control and Notification Query

« View previous topic :: View next topic »

Author

Message

lancelotlinc

Posted: Tue Oct 09, 2012 9:09 am Post subject:

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Going forward, the XML Boolean datatype should be the outcome of the serialization.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER

rekarm01

Posted: Tue Oct 09, 2012 2:05 pm Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 1415

The elements and format of a timeout request message are fairly simple -- no namespaces or xml schema datatype conversion needed. When generating the message, just assign character strings to the elements; why make it more complicated than that?

lancelotlinc wrote:

Going forward, the XML Boolean datatype should be the outcome of the serialization.

What does that mean?

The XML Schema specification defines a boolean datatype, but XML itself does not. The IBM-supplied schema for the timeout request messages does not use the xsd:boolean datatype; the IgnoreMissed and AllowOverwrite elements are enumerated strings, not booleans:

Code:

<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="TRUE"/>
<xsd:enumeration value="FALSE"/>
</xsd:restriction>
</xsd:simpleType>

lancelotlinc

Posted: Wed Oct 10, 2012 4:58 am Post subject:

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

rekarm01 wrote:

lancelotlinc wrote:

Going forward, the XML Boolean datatype should be the outcome of the serialization.

Code:

<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="TRUE"/>
<xsd:enumeration value="FALSE"/>
</xsd:restriction>
</xsd:simpleType>

It means that it is considered poor coding practice by some people to use strings, enumerated or not, to represent Boolean values. My suggestion is that the support pak should be updated to reference true booleans (no pun intended).
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER

rekarm01

Posted: Thu Oct 11, 2012 2:09 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 1415

Is this a good time to point out that the StartDate and StartTime elements are also just strings?

lancelotlinc wrote:

XML is not a programming language. It's a markup language, for character data. It doesn't define a boolean data type. XML Schema is a separate specification, which does define a boolean datatype ... as a set of enumerated strings. But XML parsers (such as XML, XMLNS, and MRM) don't have to implement it, and applications shouldn't have to use it. Applications may use something other than XML Schema (such as DTD, RELAX NG, Schematron) which may define booleans differently (if at all), or applications may prefer to manage datatype conversion directly.

The broker introduced the Timeout nodes in WMBv6, before its XMLNSC parser fully supported the XML Schema specification. Timeout nodes are not currently constrained to use the XMLNSC parser, or XML schemas. Any future change ought to be backwards compatible, to accommodate existing usage. Be sure to address these issues when opening an RFE, to increase the likelihood that it will be accepted.

sarat

Posted: Thu Feb 06, 2014 11:56 pm Post subject:

Centurion

Joined: 29 Jun 2005
Posts: 136
Location: India

Hello All,

I have gone through all the conversation in this thread.
Now, I have same issue from production. Customer recently moved some interfaces from one BROKER to another. Since then, one interface which uses TimerNode never worked as expected.
Though, WMB sets AllowOverwrite = TRUE it is failing to overwrite the existing request in the SYSTEM queue. Below is the trace snippet.

Quote:

2014-02-05 14:34:40.267216 8749 UserTrace BIP2537I: Node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Generate Request': Executing statement ''SET OutputLocalEnvironment.TimeoutRequest.AllowOverwrite = TRUE;'' at ('Input.ESB_SUB_TIMER_CONTROLLED_INPUT_GenerateRequest.Main', '101.6').
2014-02-05 14:34:40.267232 8749 UserTrace BIP2566I: Node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Generate Request': Assigning value ''TRUE'' to field / variable ''OutputLocalEnvironment.TimeoutRequest.AllowOverwrite''.
2014-02-05 14:34:40.267252 8749 UserTrace BIP2537I: Node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Generate Request': Executing statement ''SET maintRC = TRUE;'' at ('Input.ESB_SUB_TIMER_CONTROLLED_INPUT_GenerateRequest.Main', '104.8').
2014-02-05 14:34:40.267272 8749 UserTrace BIP2537I: Node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Generate Request': Executing statement ''RETURN maintRC;'' at ('Input.ESB_SUB_TIMER_CONTROLLED_INPUT_GenerateRequest.Main', '109.3').
2014-02-05 14:34:40.267284 8749 UserTrace BIP2539I: Node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Generate Request': Evaluating expression ''maintRC'' at ('Input.ESB_SUB_TIMER_CONTROLLED_INPUT_GenerateRequest.Main', '109.10'). This resolved to ''maintRC''. The result was ''TRUE''.
2014-02-05 14:34:40.267332 8749 UserTrace BIP4015I: Message propagated to the 'out' terminal of node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Generate Request' with the following message trees: 'OutputLocalEnvironment, OutputRoot, InputExceptionList'.
2014-02-05 14:34:40.268240 8749 UserTrace BIP2231E: Error detected whilst processing a message in node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Start_Controlling'.
The message broker detected an error whilst processing a message in node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.Start_Controlling'. The message has been augmented with an exception list and has been propagated to the node's failure terminal for further processing.
See the following messages for details of the error.
2014-02-05 14:34:40.268264 8749 RecoverableException BIP2230E: Error detected whilst processing a message in node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.TimeoutControl'.
The message broker detected an error whilst processing a message in node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.TimeoutControl'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2014-02-05 14:34:40.268272 8749 RecoverableException BIP4610E: The Timeout Control Node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.TimeoutControl' received a timeout request that contained an identifier which clashes with an existing timeout request for this node.
The Timeout Control Node 'ESB_CUSTOMER_CRMT_UpdateLCS_FF.ESB_CUSTOMER_CRMT_UPDATELCS.EVENT.IN.TimeoutControl' received a timeout request that contained an identifier which is already in use for a previous timeout request to this node. The supplied identifier is ''TimeReq''.
Supply a unique timeout Identifier element. Note also that this error can be avoided by setting AllowOverwrite in future timeout requests to TRUE. .

_________________
With Regards,
Sarat.

dogorsy

Posted: Fri Feb 07, 2014 12:26 am Post subject:

Knight

Joined: 13 Mar 2013
Posts: 553
Location: Home Office

sarat wrote:

Quote:

1- why resurrect an old thread ?! You should open a new one, and if needed , refer to the old one.
2- Please specify broker version.
3- did the flow ever work ?

sarat

Posted: Fri Feb 07, 2014 1:20 am Post subject:

Centurion

Joined: 29 Jun 2005
Posts: 136
Location: India

Hi dogorsy,

I thought to continue in the same thread as the issue also same.
2- Please specify broker version. V8.0.0.1
3- did the flow ever work ? - Yes. Working since 4 years. It was before V6.1 and now since Feb 2013 on V8.0.0.1

Please let me know, If you need any more details.

I have requested the dump of BROKER queue 'SYSTEM.BROKER.TIMEOUT.QUEUE' which is yet to receive.

But, nevertheless when the 'AllowOverwrite' is set to TURE ideally it should replace the existing request I hope.
_________________
With Regards,
Sarat.

dogorsy

Posted: Fri Feb 07, 2014 1:27 am Post subject:

Knight

Joined: 13 Mar 2013
Posts: 553
Location: Home Office

sarat wrote:

I thought to continue in the same thread as the issue also same.

yes, open a new thread and refer to the old one.

Display posts from previous:

Goto page Previous 1, 2

Page 2 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Timeout Control and Notification Query

Jump to:

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

Protected by Anti-Spam ACP