| Author |
Message
|
| smithamd |
 Posted: Wed Dec 19, 2018 7:06 am Post subject: Asynchronous behavior with GenericHl7Output Node |
 |
|
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 |
|
 |
| timber |
| Posted: Wed Dec 19, 2018 9:04 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
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'?
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 |
|
|
| smithamd |
| Posted: Wed Dec 19, 2018 10:27 am Post subject: |
|
|
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 |
|
|
| timber |
| Posted: Wed Dec 19, 2018 3:43 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
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 |
|
|
| rekarm01 |
| Posted: Wed Dec 19, 2018 6:21 pm Post subject: |
|
|
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 |
|
|
|
|
