A little bit more detail on this:

The problem was added in this commit:
https://sourceforge.net/p/hl7api/code/926/#diff-5
It was to fix this bug report: https://sourceforge.net/p/hl7api/bugs/206/

The question is, when a socket times out, do you expect to be able to
recover from that error?  The previously reported behaviour, in which a
partial message was processed was obviously incorrect.  The solution
implemented was to throw away the first half of the message, which seems
ok, but then the decoder tries to recover by going back and looking for the
next message.  The socket is now in an unknown state (the decoder assumes
it is in between messages while the sender knows it is in the middle of the
message).  I guess at best, the decoder can treat the rest of the message
as garbage and get back in sync next time it comes across a
start-of-message byte.

What I question, though, is whether trying to recover from a socket timeout
is ever a good idea.  I think the solution to the problem in bug 206 should
have been to stop setting a socket timeout at all.  Doing that, the slow
message would not have been lost.  Anyone who sets an explicit socket
timeout probably wants something useful to happen when that timeout is hit.

I think the most reasonable thing is to treat it as fatal and close the
connection.  For example, if you don't want ill-behaving clients to cause
you to leave sockets open for ever.

Jeremy Huiskamp | karoshealth
Software Engineer
7 Father David Bauer Drive, Suite 201
Waterloo, ON, N2L 0A2, Canada
www.karoshealth.com

On 15 March 2016 at 10:19, Jeremy Huiskamp <jeremy.huisk...@karoshealth.com>
wrote:

> Hi Martin,
>
>  Thanks for your response.  This is a server socket, but we're already
> installing our own socket factory and setting the socket timeout.  The
> problem is that MllpDecoder catches the SocketTimeoutException and ignores
> it, going back to listening on the socket again.
>
>  Have you verified that something actually happens when you hit your
> timeout?  Maybe I'm missing something...
>
> Jeremy Huiskamp | karoshealth
> Software Engineer
> 7 Father David Bauer Drive, Suite 201
> Waterloo, ON, N2L 0A2, Canada
> www.karoshealth.com
>
> On 15 March 2016 at 04:00, Martin Schlapfer <martin.schlap...@gmail.com>
> wrote:
>
>> Hi Jeremy,
>>
>> Is this a server side socket, or client side?  For server side we
>> subclass the HAPI socket factory, so we can set the socket timeout, then
>> set it in the HapiContext:
>>
>>     public class MySocketFactory extends
>> ca.uhn.hl7v2.util.StandardSocketFactory {
>>         @Override
>>         public void configureNewAcceptedSocket(Socket theSocket) throws
>> SocketException {
>>             if (socketTimeout>0)
>>             {
>>                 log.info("Setting socket timeout on accepted socket from
>> HAPI to '{}'.", socketTimeout);
>>                 theSocket.setSoTimeout(socketTimeout);
>>             }
>>         }
>>     }
>>
>> ....
>>     ctx = new DefaultHapiContext();
>>
>>     ctx.setSocketFactory(new MySocketFactory());
>>
>> Does this help you?
>>
>> Cheers,
>> Martin.
>>
>>
>> On 3/14/2016 7:11 AM, Jeremy Huiskamp wrote:
>>
>> Anyone have any thoughts on the below question?
>>
>> Thanks,
>>
>> Jeremy Huiskamp | karoshealth
>> Software Engineer
>> 7 Father David Bauer Drive, Suite 201
>> Waterloo, ON, N2L 0A2, Canada
>> <http://www.karoshealth.com/>www.karoshealth.com
>>
>> On 14 September 2015 at 23:32, Jeremy Huiskamp <
>> jeremy.huisk...@karoshealth.com> wrote:
>>
>>> Hi all,
>>>
>>>  We're in the process of upgrading from hapi 1.2 to 2.2.  With 1.2, we
>>> used to be able to call Socket.setSOTimeout() and when that timeout
>>> tripped, the connection using the socket would nicely shut down.  2.2 seems
>>> to catch the exception, ignore it and keep on going.
>>>
>>>  Is there some other mechanism we can use to automatically shut down a
>>> connection after a certain period of inactivity?  We need this
>>> functionality to prevent leaks in our hl7 servers in environments where
>>> clients crash or firewalls silently drop connections.
>>>
>>>  I'd be happy to submit a patch but would want some feedback first.
>>> Would it be acceptable to close the connection when a
>>> SocketTimeoutException happens?  Are there legitimate use cases for
>>> triggering and then recovering from a timeout?
>>>
>>> Jeremy Huiskamp | karoshealth
>>> Software Engineer
>>> 7 Father David Bauer Drive, Suite 201
>>> Waterloo, ON, N2L 0A2, Canada
>>> <http://www.karoshealth.com/>www.karoshealth.com
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn 
>> more.http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>>
>>
>>
>> _______________________________________________
>> Hl7api-devel mailing 
>> listHl7api-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>
>>
>>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel

Reply via email to