- This topic has 4 replies, 3 voices, and was last updated 6 years ago by
.
-
Topic
-
Cloverleaf 6.2.2 – This process gets recycled via script every hour due to issues with large volumes of large messages of base64-encoded PDF data in HL7 messages. I have not seen these error messages before; we upgraded to 6.2.2 last week. Error occurred for a message in flight during a recycle (we use the Recovery DB). This was reported when the process came back up: process log: Unable to write message as connection no longer available — retries disabled
message state/text: 418 – Unable to deliver to specified server connection
Protocol Driver Control – {CONNID 18901} (is that a port number?)
The Destination Thread field is blank. Does that mean it failed in the inbound UPOC, before it got to the Route Detail? Our inbound proc is HL7raw_ack and trxid is HL7, nothing else.
Both destination threads seem fine – all threads are up now, but using the Error DB to resend returns the same error.
Is the message holding onto some ephemeral network connection identifier that no longer corresponds to a current connection, and therefore cannot be sent?
And by the way, all threads have retries set to -1.
Peter Heggie
-
Replies
-
-
OK false alarm – sort of – the message, I think, was the ACK, not the original message. And the ACK could not be delivered for some reason related to the process being recycled.
I’m not sure because I just went in, first thing in the morning, and used the Error DB function to resend the message, just checking that the source and target threads were in the same process, but not actually looking at the message. It probably was an ACK.
After resending, there was one message in the Error DB window, which lead me to believe it was the same message, but now I’m not sure. Maybe the original entry in the Error DB was the message, and after resending the ACK showed up there? Or was it first an ACK, and then after resending it was another ACK? The second message had a date stamp from this morning, not yesterday when the original error occurred. But the content of the latest message is the ACK from yesterday’s message (judging by the MSH timestamp).
If I had looked at the message content first I’d have a better sense of what happened. I still don’t know what the error message means. Why would it care about the network-level connection identification?
Peter Heggie
-
-
Just musing out loud here Peter but perhaps the delay in returning the ACK when doing the recycle is sufficient to exceed the sending system’s wait for a reply.
Some systems’ action when timing out waiting for a reply is to close the connection for a period of time then restart. So by the time you look at the connection it may have been restarted.
I also think the CONNID is the port number you have assigned to that thread – is that correct?
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
