| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQTT Publication exception |
« View previous topic :: View next topic » |
| Author |
Message
|
| p.cradwick |
 Posted: Wed Jan 10, 2007 1:30 am Post subject: MQTT Publication exception |
 |
|
Acolyte
Joined: 16 May 2001
Posts: 56
|
My environment is WBIMB v6 on Windows XP
I have an MQTT system and have a intermittent error which seems to be associated with the publication node. The flow in question has a flow node which first sends the message to a Publication node for MQTT Qos=2 transmission. Mostly this works ok but on a few occasions we get an exception that appears from the trace to come from the publication node. Trace included below:
-----------------------------------------------------------------------------------
UserTrace BIP4160I: Message propagated to match terminal by check node 'TankerAcknowledgement.TankerAcknowledgement.FlowOrder1'.
The check node 'TankerAcknowledgement.TankerAcknowledgement.FlowOrder1' has matched a received message against the criteria and is propagating it to any nodes connected to its match terminal.
No user action required.
UserTrace BIP7083I: Node 'TankerAcknowledgement.TankerAcknowledgement.Publication.ComIbmPSService': The Publication Node with Subscription Point '''' has received an error code 3008.
The Publication Node with Subscription Point '''' has received an error with code 3008. A response message has been sent to the originator's reply queue.
No user action required.
UserTrace BIP7085I: Node 'TankerAcknowledgement.TankerAcknowledgement.Publication.ComIbmPSService': The Publication Node has propagated a message to its output terminal for subscription point ''''.
The Publication Node has propagated the current message to its output terminal.
No user action required.
UserTrace BIP2638I: The MQ output node 'TankerAcknowledgement.TankerAcknowledgement.Publication.Response' attempted to write a message to queue ''LQ.FMST.PUBLICATION_RESPONSE'' connected to queue manager ''FMSTQM''. The MQCC was '0' and the MQRC was '0'.
UserTrace BIP2622I: Message successfully output by output node 'TankerAcknowledgement.TankerAcknowledgement.Publication.Response' to queue ''LQ.FMST.PUBLICATION_RESPONSE'' on queue manager ''FMSTQM''.
UserTrace BIP2231E: Error detected whilst processing a message 'TankerAcknowledgement.TankerAcknowledgement.FMS.FONTERRA.TANKER_ACK.IN'.
The message broker detected an error whilst processing a message in node 'TankerAcknowledgement.TankerAcknowledgement.FMS.FONTERRA.TANKER_ACK.IN'. 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.
RecoverableException BIP2230E: Error detected whilst processing a message in node 'TankerAcknowledgement.TankerAcknowledgement.Publication.ComIbmPSService'.
The message broker detected an error whilst processing a message in node 'TankerAcknowledgement.TankerAcknowledgement.Publication.ComIbmPSService'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
ImbPubSubEngineNode::evaluate , 'caught exception'
RecoverableException BIP2328E: A value of SQL datatype ''CHARACTER'' encountered when datatype ''INTEGER'' expected.
The value of SQL datatype 'CHARACTER' was encountered, but a value of SQL datatype 'INTEGER' was expected.
This message will be accompanied with others which will give the higher level context for this error. Look at these other messages to determine the root source of the problem.
-----------------------------------------------------------------------------------
Note that the flow sends a Publication response and this is 'ok'.
FMS.FONTERRA.TANKER_ACK.IN is the MQInput node. What is the 3008 error reported by the publication node? It appears to me that the later BIP2328E error is occurring in the publication node.....???
The second path from the flow node is a Compute node and this is never reached - control goes to the exception handler via the MQInput node catch.
Anyone seen this before and have any answers?
I was lucky to capture this on a trace, but are now waiting for the problem to reappear reliably so I can do a service trace.
Peter |
|
| Back to top |
|
 |
| p.cradwick |
| Posted: Tue Jan 30, 2007 3:09 pm Post subject: MQTT publication Exception |
|
|
Acolyte
Joined: 16 May 2001
Posts: 56
|
There appeared to be some interest in this post, but no response so I will respond to my own post with what I eventually found.
After a lot of trial and error was able to generate the exception with about 90% certainty and was able to get a service trace. In studying this around the exception it appeared that the RFH header was being parsed twice and the second time all values were char values so the Broker threw an exception when it found the 'NameValueCCSID' was a char instead of an integer!
On adding a trace node it appeared that the 'second' RFH header had been inserted in the NameValuePair tag:
(0x01000000):MQRFH2 = (
(0x03000000):Version = 2
(0x03000000):Format = ' '
(0x03000000):Encoding = 546
(0x03000000):CodedCharSetId = 437
(0x03000000):Flags = 0
(0x03000000):NameValueCCSID = 1208
(0x01000000):Version = (
(0x02000000): = '2'
)
(0x01000000):Format = (
(0x02000000): = ' '
)
(0x01000000):Encoding = (
(0x02000000): = '546'
)
(0x01000000):CodedCharSetId = (
(0x02000000): = '437'
)
(0x01000000):Flags = (
(0x02000000): = '0'
)
(0x01000000):NameValueCCSID = (
(0x02000000): = '1208'
)
(0x01000000):psc = (
In this area of processing, the broker could be in one of two states. It might be sending 'wake up' calls to the sender or it may not. If it receives a message from the sender, then it needs to turn the 'wake up' off before sending the received message through, so the receiver flow copied the entire message to OutputRoot and parked it in the Environment as:
SET InputLocalEnvironment.InputMsg.*[] = OutputRoot.*[];
It then propagated a 'stop wake up' to output1 then retrived the output message to send to output0 as:
SET OutputRoot.*[] = InputLocalEnvironment.InputMsg.*[];
Clearly the message did not come back as it went in! The various Tree nodes need to be written with their appropriate parsers e.g.
Store:
CREATE FIELD InputLocalEnvironment.tempStore;
CREATE LASTCHILD OF InputLocalEnvironment.tempStore DOMAIN('Properties') PARSE(ASBITSTREAM(OutputRoot.Properties));
CREATE LASTCHILD OF InputLocalEnvironment.tempStore DOMAIN('MQMD') PARSE(ASBITSTREAM(OutputRoot.MQMD));
CREATE LASTCHILD OF InputLocalEnvironment.tempStore DOMAIN('MQRFH2') PARSE(ASBITSTREAM(OutputRoot.MQRFH2));
CREATE LASTCHILD OF InputLocalEnvironment.tempStore DOMAIN('BLOB') PARSE(ASBITSTREAM(OutputRoot.BLOB.BLOB));
Retrieve:
SET OutputRoot.Properties = InputLocalEnvironment.tempStore.Properties;
SET OutputRoot.MQMD = InputLocalEnvironment.tempStore.MQMD;
SET OutputRoot.MQRFH2 = InputLocalEnvironment.tempStore.MQRFH2;
SET OutputRoot.BLOB.BLOB = InputLocalEnvironment.tempStore.BLOB.BLOB;
So
Error1: Should have put in trace node at the first sign of trouble. The problem was apparent there without requiring a Service trace.
Error2: Use parsers when writing a complete message to the Environment.
The 10% when no error occurred?
This was when the wakeup processing was not running so the message was not parked and retrieved from the Environment store, it was just passed straight through.
Live and Learn!
Peter |
|
| 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
|
|
|
|
