ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Asynchronous behavior with GenericHl7Output Node

Post new topic  Reply to topic
 Asynchronous behavior with GenericHl7Output Node « View previous topic :: View next topic » 
Author Message
smithamd
PostPosted: Wed Dec 19, 2018 7:06 am    Post subject: Asynchronous behavior with GenericHl7Output Node Reply with quote

Newbie

Joined: 18 Aug 2015
Posts: 7

We are seeing a strange issue with our broker version 7 GenericHl7Output node. What we see when a wireshark is set is that engine sends a message , but before waiting for an ACK it sends another message. And the message and ACKs are out of sync. Also , since these messages are sent back to back , sometimes receiving application considers the next message received as error and we are sent an AE in the ACK.

My question is how does the ACK stack work. I see 2 ACKs at the same time and 2 messages sent at the same time in the wireshark logs. And the way I read it is engine sends a message and takes whatever the last ACK was received from a stack or something.

so pattern is like
ACK
ACK
Message sent
Message sent (this was sent since the 2nd ack above was parsed as the ACK for this)
ACK received
message sent
ACK
ACK
Message
Message
ACK
ACK

Receiving application says that multiple messages are receiving before they send an ACK. But on our side we are parsing the ACK's kind of like in a stack and get whatever is the last ACK and assumes we received an ACK and sends the next message.

Any thoughts?
Back to top
View user's profile Send private message
timber
PostPosted: Wed Dec 19, 2018 9:04 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

Obligatory: WMB v7 is now out of service You should upgrade as soon as possible from WMB v7 to a supported version of the product.
Quote:
What we see when a wireshark is set is that engine sends a message , but before waiting for an ACK it sends another message
Please define your terms. When you say 'engine' do you mean a WMB message flow?
Quote:
My question is how does the ACK stack work. I see 2 ACKs at the same time and 2 messages sent at the same time in the wireshark logs. And the way I read it is engine sends a message and takes whatever the last ACK was received from a stack or something.
You are calling it an 'ACK stack' but you openly admit that you don't know whether it's a stack!
Quote:
so pattern is like
ACK
ACK
Message sent
Message sent (this was sent since the 2nd ack above was parsed as the ACK for this)
ACK received
message sent
ACK
ACK
Message
Message
ACK
ACK
Why do some lines have 'Message sent' and others only have 'Message'?
Why do some lines have 'ACK received' and others only have 'ACK'?
Quote:
Any thoughts?
Are you running multiple copies of the message flow (additional instances >0)?
Or are you running multiple copies of the same message flow in different brokers or different execution groups?

I suspect that you will need to open a PMR and get IBM to answer this question - but that will require you to upgrade first.
Back to top
View user's profile Send private message
smithamd
PostPosted: Wed Dec 19, 2018 10:27 am    Post subject: Reply with quote

Newbie

Joined: 18 Aug 2015
Posts: 7

Thanks for the reply. We are looking at an upgrade but this is happening in production right now.

Engine - yes WMB
ACK stack - to me it looks like that the ACKs are being read in first come first serve basis or something. SO if we receive an ACK while sending the message , it keeps that ACK and parses it as an ACK for next message sent.

Message - means message sent
ACK - means ACK's received
ACK received
ACK received
Message sent
Message sent (this was sent since the 2nd ack above was parsed as the ACK for this)
ACK received
message sent
ACK received
ACK receieved
Message sent
Message sent
ACK recvd
ACK recvd


We are running only one copy of the message flow.
Back to top
View user's profile Send private message
timber
PostPosted: Wed Dec 19, 2018 3:43 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

I don't see any reason why it would act in the way that you are describing. The description of the node in the IIBv9 Knowledge Center ( https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0.0/com.ibm.healthcare.doc/ha00170.htm ) strongly implies that your assumptions are incorrect.

I recommend that you install IIBv10 or even ACEv11 in a test environment (with the compatible healthcare pack) and try out the same scenario. If you can reproduce the problem on a supported version then IBM will help. They are not obliged to provide any support for v7.
Back to top
View user's profile Send private message
rekarm01
PostPosted: Wed Dec 19, 2018 6:21 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 1415

smithamd wrote:
We are looking at an upgrade but this is happening in production right now.

A production issue for an unsupported version of the product is unfortunate. IBM doesn't even offer extended support for wmb7 anymore, does it? The description of the node in the wmb8 Knowledge Center is probably closer to the behavior for wmb7, though there doesn't seem to be much difference in the node between wmb8 and iib9.

smithamd wrote:
Message - means message sent
ACK - means ACK's received
ACK received
ACK received
Message sent
Message sent (this was sent since the 2nd ack above was parsed as the ACK for this)
...

How is the remote application able to acknowledge a message before the message flow can send it? The messages contain a (hopefully unique) message id, and the ACKs should reference that message id when acknowledging each message. It may help to correlate which ACKs go with which messages, and explain that in greater detail. A usertrace may also provide useful information.

smithamd wrote:
We are running only one copy of the message flow.

And how many copies of the remote application are running? Do any of these acknowledgements return an "AR code", which might cause the node to retry sending a message?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Asynchronous behavior with GenericHl7Output Node
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
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.