|
#1
|
|||
|
|||
|
We've got a general alert setup on our Mirth server to email out 'Any' error code (the error matching field is just 'ERROR'). This seems to work fine for most channels and we regularly see emails about ACK timeouts and other various issues.
But I've got one channel that does not appear to be sending alerts. It is queued up trying to send (LLP sender) to a client since the client is not accepting connections right now. If I go into the dashboard for this channel and click on the 'error' tab of the first queued message, I see this error: ERROR-408: MLLP Connector error ERROR MESSAGE: Socket write exception java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at com.mirth.connect.connectors.mllp.MllpMessageDispa tcher.createSocket(MllpMessageDispatcher.java:212) at com.mirth.connect.connectors.mllp.MllpMessageDispa tcher.initSocket(MllpMessageDispatcher.java:90) at com.mirth.connect.connectors.mllp.MllpMessageDispa tcher.reconnect(MllpMessageDispatcher.java:533) at com.mirth.connect.connectors.mllp.MllpMessageDispa tcher.sendPayload(MllpMessageDispatcher.java:279) at org.mule.providers.QueueEnabledConnector$QueueWork er.run(QueueEnabledConnector.java:218) at java.lang.Thread.run(Unknown Source) I have confirmed that the channel is selected in our alert setup. I've even tried removing and re-adding it. As I mentioned, we have no problem getting error emails for other channels/errors but I searched through those other emails and can't find any for this same type of error (Socket write exception). I'm stumped at this point. Not sure if the problem is with my channel or with that type of error. Anyone seen this before? Thanks |
|
#2
|
|||
|
|||
|
Update on some of the things I've tried with this:
1) I rebuilt the channel from scratch to see if it was somehow an issue with the channel build. It's a very simple channel with no scripting, just a channel receiver that LLP sends to an outside port. This new version of the channel behaves the same way - I can see the 'socket write exception' error on the queued message but I don't get an error alert email for it 2) I forced it to drop an error with some intentionally bad transformer code - I did get an error alert email for that. 3) I've tried setting up the alerts to match on the word 'Socket' rather than 'ERROR' - still no email is sent. So I'm thinking that the issue is that for some reason the alerting code isn't even trying to process that 'Socket write exception' error. Not sure why we wouldn't want to see that - it's pretty critical to know when I'm not capable of establishing a connection. Thanks |
|
#3
|
|||
|
|||
|
It looks like this is due to how queued messages currently work in Mirth. In a normal LLP message flow, the doDispatch is called on the MllpMessageDispatcher object, which sends an alert to the alert controller in the case of any exceptions. However, the general QueueEnabledConnector instead goes right to the sendPayload method, which makes sense because each more specific connector does some special things, like the LLP Sender's max retry stuff. However, this also means that this bypasses any calls to the alert controller.
It's a bit of a thornbush to me so I hesitate to make any fully confident suggestions, but it looks like the sendPayload methods for the MLLP and TCP dispatchers just need to add a line in their catch blocks to send out an alert to the controller. Interestingly, it looks like the HTTP and Web Service dispatchers already do this... |
![]() |
| Thread Tools | |
| Display Modes | |
|
|