ACK leads to indefinite loop of sending messages
Brought to you by:
jackkane
Menu
▾
▴
#13 ACK leads to indefinite loop of sending messages
unread
5
2015-12-21
2015-12-21
No
if you have multiple Out-Sockets which deliver the very same HL7 message, after the first successfull ACK the self.messageCtrlId is going to be set to None. This leads to the problem that the next ACK can not be handled anymore as it compares to None instead to the actual message ID. This leads to an indefinite loop of sending the very same HL7 message over and over again.
To fix this, comment line 1249 of workerThreads.py out (#self._ _messageCtrlId = None)
Hi Linus,
thanks for your report!
After a few years off, I was trying to figure things out.
self.messageCtrlId is private to every instance of the HL7Transmitter
class. When creating new instances of it and adding them to the same
message queue, each of the class instances should hold, along with a
private queue of messages, its own state of which ACK have been seen.
Not resetting self.messageCtrlId after having seen the appropriate ACK
might cause the adapter to falsely dismiss other messages sent but not
ACKed yet - however, major havoc would be needed to create such a
condition. Anyway, I believe that just not cleaning up when done may
eventually cause problems later and is not a good strategy to employ in
software products.
So, I was trying to figure out what could have gone wrong initially. I
came up with several guesses but I would need more information from you
about your setup to confirm or dismiss them and then do a real fix.
a) Did you set up several HL7Transmitters on the same queue, so they
all get a copy of each message on their own? If so, did all
transmitters have their own unique combination of IP:PORT
(important)?
b) Did you set up one HL7Transmitter as a socket server and then have
multiple devices connect to it for receiving messages (unsupported,
please use distinct adapters for each device to feed messages to)?
Best regards,
-- Sebastian
--
PGP-Key Fingerprint:
A9DB 35EF D353 A79E 7CEA 3DC5 8474 8C67 84CF DA58
On 21.12.2015 16:42, Linus Betschart wrote:
Related
Bugs: #13