Recent changes to bugs

edit or create a custom HL7 ACK for messages

Edgardo Prieto — Tue, 23 Apr 2024 15:23:59 -0000

Hi !! Is there a way to edit or create custom HL7 ACKs? Currently the instrument I working is not accepting the default ACK sent by the socket, thanks in advance!

Socket reader not running in Service

Francis Pelletier — Tue, 19 Feb 2019 15:55:13 -0000

The Socketreader works fine on the Command Prompt mode but does not seem to work in the Service mode. Although it installs and runs, it does not seem to pickup my socketreader.cfg file and looking at the README file, you say I MUST use the --configfile option but when I do it says it is not a recognized option. Can you help please ...

Bind socketReader to a single port?

Thomas Altfather Good — Wed, 04 May 2016 15:14:17 -0000

Is there a way to force socketReader to SEND from a specific port? At the moment it is sending from one port, waiting briefly for an MLLP ACK then resending the message from another port. The net result is that the remote server replies but I never get the ACK because it is replying to the original port. Ideally I would like it to transmit / listen on one specific port. Can this be done? Thanks.

Issue with 'nacksonly' and suggestion for dumped files

Francisco Saez — Thu, 28 Apr 2016 21:38:50 -0000

Hello, first of all I want to let you know I am very pleased with this tool.
I hope you find this feedback useful.

I have one issue and one suggestion.

Issue: According to the example configuration provided, one of the debug options for [outgoing_socket] is supposed to dump all files, no matter they are ACKs or NAKs.

I quote lines 176 – 178 from “example.cfg”

   'nacksonly'       :   Defaults to True
       If set to True, only negative ACKs will be dumped to file.
       If set to False, all ACKs will be dumped.

If you set this option to “True” only NAK files will be dumped. Which I believe is the correct behavior.
But if you set this option to False you won’t get all Files, actually you will get only ACK files.

I have reviewed the code and found a conditional that prevents the dump of NAK files. As you can see in “handleMessage” method in “Common/workerThreads.py” on line 1259.

if self.__debugopts and self.__debugopts.get('nacksonly'):
    # dump the NACK
    self.__debugHandleAck(self.message)

I think NAK files should always be dumped.

Summarizing the issue consist in having the “nacksonly” option working as a switch between ACK and NAK files, instead of just dumping NAK files when is set to True and all files when is set to False.

Suggestion: Currently you can define the prefix and the suffix for dumped files, but the middle is set with a timestamp “AAAAMMDDHHMMSS”. As you can see in “__debugHandleAck” method in “Common/workerThreads.py”.

fpath = os.path.normpath(self.__debugopts.get('ackmsgdir') + '/' + self.__debugopts.get('ackmsgprefix') + isoDate + '_' + str(fileCounter).zfill(counterLength) + self.__debugopts.get('ackmsgsuffix'))
while os.path.exists(fpath):
    fileCounter += 1
    fpath = os.path.normpath(self.__debugopts.get('ackmsgdir') + '/' + self.__debugopts.get('ackmsgprefix') + isoDate + '_' + str(fileCounter).zfill(counterLength) + self.__debugopts.get('ackmsgsuffix'))

I think it will very useful to have a config option to change the “isoDate” for the MSA-3 or MSH-9 because in my opinion they contain a better way to uniquely identify the dumped files.

Kind regards.

Francisco Saez.

Issue with 'nacksonly' and suggestion

Francisco Saez — Tue, 26 Apr 2016 22:34:50 -0000

Hello, first of all I want to let you know I am very pleased with this tool.
I hope you find this feedback useful.

I have one issue and one suggestion.

Issue: According to the example configuration provided, one of the debug options for [outgoing_socket] is supposed to dump all files, no matter they are ACKs or NAKs.

I quote lines 176 – 178 from “example.cfg”

       'nacksonly'       :   Defaults to True
           If set to True, only negative ACKs will be dumped to file.
           If set to False, all ACKs will be dumped.

I have reviewed the code and found a conditional that prevents the dump of NAK files. As you can see in “handleMessage” method in “Common/workerThreads.py” on line 1259.

                    if self.__debugopts and self.__debugopts.get('nacksonly'):
                        # dump the NACK
                        self.__debugHandleAck(self.message)

I think NAK files should always be dumped.

Suggestion: Currently you can define the prefix and the suffix for dumped files, but the middle is set with a timestamp “AAAAMMDDHHMMSS”. As you can see in “_debugHandleAck” method in “Common/workerThreads.py”.

            fpath = os.path.normpath(self.__debugopts.get('ackmsgdir') + '/' + self.__debugopts.get('ackmsgprefix') + isoDate + '_' + str(fileCounter).zfill(counterLength) + self.__debugopts.get('ackmsgsuffix'))
            while os.path.exists(fpath):
                fileCounter += 1
                fpath = os.path.normpath(self.__debugopts.get('ackmsgdir') + '/' + self.__debugopts.get('ackmsgprefix') + isoDate + '_' + str(fileCounter).zfill(counterLength) + self.__debugopts.get('ackmsgsuffix'))

Kind regards.

Francisco Saez.

ACK leads to indefinite loop of sending messages

Linus Betschart — Mon, 21 Dec 2015 15:42:31 -0000

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)

#11 socketReader should attempt to reconnect outgoing sockets

Fred — Mon, 22 Sep 2014 03:48:48 -0000

I set up a completely separate test environment. It looks like if the VPN goes down (100% packet loss) the sending process just keeps retrying every 10 seconds, each time it tries to send the message it goes into the outbound queue of messages (aka Send-Q). Once Send-Q is full, the operating system terminates the connection, which leads to the console message:

Hl7Transmitter_test_file_to_test_socket_Thread-7 will be stopped... Hl7Transmitter_test_file_to_test_socket_Thread-7: The socket has probably been closed already
Done. Queue length: 1

at DEBUG level (minute the sleeping 10 seconds message) the log has:

2014-09-21 20:57:01,939 - SocketOps                           - ERROR    - The socket we tried to receive from is currently down.
2014-09-21 20:57:01,939 - SocketOps                           - ERROR    - The socket we tried to receive from is currently down.
2014-09-21 20:57:01,955 - SocketOps                           - ERROR    - socketReader encountered an exception:
Traceback (most recent call last):
  File "/home/derf/src/socketreader/Common/socketWrapper.py", line 72, in shutdown
    retval = self.__sock.shutdown(socket.SHUT_RDWR)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected
2014-09-21 20:57:01,955 - SocketOps                           - ERROR    - socketReader encountered an exception:
Traceback (most recent call last):
  File "/home/derf/src/socketreader/Common/socketWrapper.py", line 72, in shutdown
    retval = self.__sock.shutdown(socket.SHUT_RDWR)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected
2014-09-21 20:57:01,955 - Hl7Transmitter_test_file_to_test_socket_Thread-7 - ERROR    - socketReader encountered a socket exception:
Traceback (most recent call last):
  File "/home/derf/src/socketreader/Common/workerThreads.py", line 1323, in threadStop
    self.__clientSocket.shutdown()
  File "/home/derf/src/socketreader/Common/socketWrapper.py", line 72, in shutdown
    retval = self.__sock.shutdown(socket.SHUT_RDWR)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected
2014-09-21 20:57:01,960 - Hl7Transmitter_test_file_to_test_socket_Thread-7 - PROD     - First message still left in the queue:
[hl7 message here]

At this point no attempt is made to restart the sending thread.

I think the main while running: loop can be modified to check for dead threads and restart them. Since the thread is removed from the threadList when it stops, if the main body keeps track of the configuration -> threads that should be running, it can make a new thread to replace the thread that has disappeared. In the event of a VPN outage, the new thread would attempt to connect until the VPN is fixed, at which point it can start sending messages again.

Exception during ACK when handling pre-2.3.1 messages (patch included)

Fred — Wed, 03 Sep 2014 17:32:29 -0000

Somewhere prior to HL7-2.3.1, MSH-9 only contained a message type and did not include the ^trigger event^message structure components. When receiving a message without MSH-9.2, an array index exception is triggered when it attempts to insert message[0][8][1] into the ACK.

This patch checks if message[0][8] has more than 1 component, and if so uses ACK^trigger event for the response. Otherwise, it uses ACK for the response.

socketReader should attempt to reconnect outgoing sockets

Fred — Wed, 03 Sep 2014 17:04:14 -0000

Whenever the outbound socket is lost, socketReader does not try to reconnect. Idle sockets could be closed due to VPN tunnel timeout, TCP timeout, etc. socketReader should attempt to restart the outgoing connection.

In the console:

Hl7Transmitter_test_orders_Thread-6 will be stopped... Hl7Transmitter_test_orders_Thread-6: The socket has probably been closed already

In the log file (configured to INFO level):

2014-09-03 11:13:14,835 - SocketOps - ERROR    - The socket we tried to send to is currently down.
2014-09-03 11:13:14,835 - SocketOps - ERROR    - The socket we tried to send to is currently down.
2014-09-03 11:13:22,679 - SocketOps - ERROR    - The socket we tried to receive from is currently down
2014-09-03 11:13:22,679 - SocketOps - ERROR    - The socket we tried to receive from is currently down
2014-09-03 11:13:22,679 - SocketOps - ERROR    - The socket we tried to receive from is currently down

this message is repeated a lot over ~ 5 minutes before ending with:

2014-09-03 11:13:22,693 - Hl7Transmitter_test_orders_Thread-6 - ERROR    - socketReader encountered a socket exception:
Traceback (most recent call last):
  File "/data/EDI/socketreader/Common/workerThreads.py", line 1322, in threadStop
    self.__clientSocket.fileno()    # Just to check if the socket still exists. Throws an exception if not.
  File "/data/EDI/socketreader/Common/socketWrapper.py", line 77, in shutdown
    retval = self.__sock.shutdown(socket.SHUT_RDWR)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected
2014-09-03 11:13:22,693 - Hl7Transmitter_test_orders_Thread-6 - PROD     - First message still left in the queue:
<hl7>
2014-09-03 11:13:22,693 - Hl7Transmitter_test_orders_Thread-6 - INFO     - Thread stopped. Queue length: 2

socketReader had to be restarted in order to send the queued messages.

#10 Can't configure File to socket mode

Sebastian Weigmann — Fri, 29 Aug 2014 13:14:23 -0000

labels: --> config
status: unread --> open-accepted
assigned_to: Sebastian Weigmann