No way to catch an LLPException

[delfuego]

As far as I can tell, there's no way to catch an LLPException — is there anything that I'm missing, or some way I can help introduce a way to catch these?

The longer version is that I'm running an HL7Service to accept and consume HL7 messages sent from my institution's EMR, and have a very occasional situation where the message's framing itself has an issue and causes HAPI to throw an exception. An example is as such:

ca.uhn.hl7v2.llp.LLPException: MLLP protocol violation - Expected byte '11' in state START but was '115'
	at ca.uhn.hl7v2.llp.MllpDecoderState.read(MllpDecoderState.java:137) ~[hl7interface-prod.jar:na]
	at ca.uhn.hl7v2.llp.MllpDecoder.getMessage(MllpDecoder.java:63) ~[hl7interface-prod.jar:na]
	at ca.uhn.hl7v2.llp.Hl7DecoderReader.getMessage(Hl7DecoderReader.java:84) ~[hl7interface-prod.jar:na]
	at ca.uhn.hl7v2.llp.MinLLPReader.getMessage(MinLLPReader.java:33) ~[hl7interface-prod.jar:na]
	at ca.uhn.hl7v2.app.Receiver.handle(Receiver.java:63) ~[hl7interface-prod.jar:na]
	at ca.uhn.hl7v2.concurrent.Service.run(Service.java:205) [hl7interface-prod.jar:na]
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [na:1.8.0_121]
	at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.8.0_121]
	at java.lang.Thread.run(Unknown Source) [na:1.8.0_121]

So far as I can tell, there's no way for my application to catch these, though — they occur inside the Runnable thread process, and not within any class in which the exception handler that I define in my HL7Service (the handler class in HL7Service.setExceptionHandler(handler)). So instead, they just end up emitting info to my log file, and they cause the server to terminate the client connection.

Of course, I can catch the dropped client connection (using a ConnectionListener configured on the HL7Service), but that catches all closed client connections, which isn't the same as being able to catch the specific situation where the connection is terminated because of an invalidly-framed HL7 message.

Thoughts?

[delfuego]

Bumping this — I'm now encountering this again, and unable to really figure out a way to catch these instances of MLLP protocol violations. Anyone?

[alexanderankin]

Bumping this again - seeing 10 instead of 11, cant figure out how to fix

[sumeetchhetri]

Please ensure that the HL7 message does not contain any multi-byte encoded data like UTF-16/32, this is the primary reason for such errors. Refer to the MLLP spec for more information regarding the same https://www.hl7.org/documentcenter/public/wg/inm/mllp_transport_specification.PDF. Not an issue with the library. This should be closed.

[delfuego]

@sumeetchhetri This doesn't make sense — it's not in the control of the receiver what the sender does with its HL7. And this issue is noting that the receiver can't even CATCH the error you're describing, because it's happening in a process that I can't catch exceptions in.

[alexanderankin]

thats helpful to know what might be the issue, but that's also the responsibility of the library to catch this kind of error and rethrow with a meaningful message like, "thats probably an encoding issue". So there's another thing wrong with how this error is thrown.

The most jarring thing was of course the inability to catch it.

[sumeetchhetri]

Apologies for speaking too soon and without reading through all the details, For my implementation I directly extracted the MllpDecoderState class and used it in a custom Hl7Server, hence had full control of the exception handling. After reading through the documentation understood the problem and limitations in the library, as a penalty; here is a PR which provides a fix for the same :smiley:

https://github.com/hapifhir/hapi-hl7v2/pull/61