Well, throwing an Error instead of an Exception will do exactly what you
wan't - it will make HAPI's receiving thread to terminate and nothing will
be shipped over the wire. Try it yourself, it should be fairly easy to test
2012/12/3 LDH <l...@360fresh.com>
> We are on 1.2, with plans to move to 2.0 in the next few months.
>
> - We really want to simply fail and return nothing back to the sender,
> i.e., reset the connection in effect. The sending system will retry, and
> we'll refail again until we regain a db connection. etc...
> - I am not sure about your comment regarding DOS attacks, plus we are
> within a secured intranet only in a datacenter, so i do not believe this to
> be a risk.
> - I am not sure either what you mean by "being brought up to code". We are
> listening on a port and processing messages. It is possible that a
> catastrophic failure occurs which causes us to be unable to process the
> message: we cannot guarantee (nobody could) 100% success. Our problem is
> that the HL7 gateway (Cloverleaf in this case) has been configured on
> premise to always assume success whether ACKs or NACKs were received, thus
> eating out messages that we may not have properly processed. We cannot make
> changes to that configuration unfortunately. The only option, and what the
> hospital system we work with has standardized upon, is for the consuming
> system to simply return nothing and close the connection. Being a large
> hospital system, i figured this was a fairly standard and accepted
> process... :) Silly me! :)
>
>
>
> Thank you,
> ------------------------------
> *Laurent Hasson*
> Co-Founder, 360Fresh.com
> Cellphone: 646-283-2186
> This email and any attachments thereto may contain private, confidential,
> and privileged material for the sole use of the intended recipient. Any
> review, copying, or distribution of this email (or any attachments thereto)
> by others is strictly prohibited. If you are not the intended recipient,
> please contact the sender immediately and permanently delete the original
> and any copies of this email and any attachments thereto.
>
> On 12/3/2012 06:02, Christian Ohr wrote:
>
> Laurent,
>
> What version of HAPI are you using? Internals of the whole app
> framework changed quite a bit in 2.0.
> If I understood you correctly, you need to close the socket on an
> erroneous message and you are well aware of the fact that you expose
> yourself to DOS attacks by doing so - anyway.
>
> In general, HAPI application objects don't know about the connection
> from where the message came from. In general the socket can of course
> be shared by more than one client. If your system environment allows
> for closing a dedicated connection anyway, you can do this:
>
> 1. Let your Application class implement
> ca.uhn.hl7v2.app.ConnectionListener and remember the connection
> received in the connectionReceived() if it was initiated by your
> client.
> 2. In the Application's process method, call call the close() method
> on the connection you remembered. This will immediately close the
> underlying socket and nothing gets returned either.
>
> Even so, I wouldn't recommend this in production systems and rather
> that client should be brought up to code!
>
> Christian
>
>
> 2012/12/3 Jens Kristian Villadsen <j...@c3a.dk> <j...@c3a.dk>:
>
> from within the Application.processMessage() method, that is
>
>
> 2012/12/3 Jens Kristian Villadsen <j...@c3a.dk> <j...@c3a.dk>
>
> throw an Error instead of an Exception - that makes the HAPI thread choke
> and nothing will be returned and the entire framework still lives on. That
> sounds like its a proper solution for you.
>
>
> 2012/12/2 LDH <l...@360fresh.com> <l...@360fresh.com>
>
>
> I have performed some stress testing this weekend. One test is to kill
> our database, which causes our HAPI code that ingests messages to fail. Our
> strategy so far was simply to return a NACK, but we discovered that the
> system that is sending us messages is taking ANY response as a success
> indicator, thus swallowing the message and causing message loss. The sending
> system expects the socket connection to simply be terminated. We have tried
> a number of strategies such as:
> - throwing an exception from the Application.processMessage() method
> - returning NULL from the method
> - implementing our own PipeParser and overriding the encode() method
> to return "" when the message source was null
> - etc....
>
> All those strategies have failed because at the end of the day, the
> sending system still receives something. Unfortunately, we are not able to
> modify the sending system, and so, we have to fix this on our end and we are
> not sure how to make HAPI simply drop the connection and not send ANYTHING
> back.
>
> Any advice?
>
>
> Thank you,
> ________________________________
> Laurent Hasson
> Co-Founder, 360Fresh.com
> Cellphone: 646-283-2186
> This email and any attachments thereto may contain private, confidential,
> and privileged material for the sole use of the intended recipient. Any
> review, copying, or distribution of this email (or any attachments thereto)
> by others is strictly prohibited. If you are not the intended recipient,
> please contact the sender immediately and permanently delete the original
> and any copies of this email and any attachments thereto.
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> DESIGN Expert tips on starting your parallel project
> right.http://goparallel.sourceforge.net/
> _______________________________________________
> Hl7api-devel mailing
> listHl7api-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>
> --
> Med venlig hilsen / Kind regards
>
> Jens Kristian Villadsen
> cand.polyt
> Systemudvikler / System developer
> IM (Skype): j.kidd.o
> Cetrea A/S, Denmark
>
> phone : +45 38 40 05 81
> address: Brendstrupgårdsvej 21F, DK-8200 Aarhus N.
> e-mail : j...@cetrea.com
> w^3 : http://www.cetrea.com/
>
>
>
> --
> Med venlig hilsen / Kind regards
>
> Jens Kristian Villadsen
> cand.polyt
> Systemudvikler / System developer
> IM (Skype): j.kidd.o
> Cetrea A/S, Denmark
>
> phone : +45 38 40 05 81
> address: Brendstrupgårdsvej 21F, DK-8200 Aarhus N.
> e-mail : j...@cetrea.com
> w^3 : http://www.cetrea.com/
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.http://goparallel.sourceforge.net
> _______________________________________________
> Hl7api-devel mailing
> listHl7api-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.http://goparallel.sourceforge.net
> _______________________________________________
> Hl7api-devel mailing
> listHl7api-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
--
Med venlig hilsen / Kind regards
Jens Kristian Villadsen
cand.polyt
Systemudvikler / System developer
IM (Skype): j.kidd.o
Cetrea A/S, Denmark
phone : +45 38 40 05 81
address: Brendstrupgårdsvej 21F, DK-8200 Aarhus N.
e-mail : j...@cetrea.com
w^3 : http://www.cetrea.com/
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel