-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How can I recover from no ACK received (awaitingResponse = true)? #89
Comments
A very simple (but wasteful) solution would be, to open up a new connection every time you are sending something and closing the connection on receiving the ack. You could then further improve this aproach by tracking the |
this isn't currently built into the library, but the way I've handled this in the past is via a timeout. You keep track of when you are waiting for a response, if none is received in a certain period of time, you assume it failed and reset. |
@hitgeek |
@hitgeek speaking of awaitingResponse, isn't it possible to send and await multiple responses and match them to their message control id? Or is HL7 inherently 1 message at a time? |
(1 message at a time) is the way its implemented here in the tcp (mllp) server/client. that has worked well enough with the systems I've connected to. presumably it could be implemented differently, I don't know if the specification is explicit about this or not. There is also a batch protocol I believe in HL7, but i've never used it, or seen it used in the wild. |
I'm using the
TcpClient
to send HL7 messages to another server. The client functionality is wrapped with a simple Express API to trigger the sending of messages. Whenever the server doesn't return an ACK for whatever reason, the client is in theawaitingResponse
state and won't send another message. At the moment, the only way to recover from this state is to stop and restart the entire express app. Is there another way to recover from it?Here is a code snippet:
Any pointers would be greatly appreciated.
The text was updated successfully, but these errors were encountered: