Announcement

Collapse

Mirth Connect 4.3.0 Released!

Mirth Connect 4.3.0 is now available as an appliance update and on our GitHub page.

This is a major release containing new features like adding new functionality to the Mirth Connect Setup Wizard, adding the ability for resource and channel-specific classloaders to load child-first or parent-first, and added a default implementation of the getObjectsForSwaggerExamples() method in the ServicePlugin class. This release also contains enhancements for the Mirth Connect Administrator Launcher, the Mirth Connect Docker images, and several bug fixes and security improvements.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

Getting message regarding too many errors

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Getting message regarding too many errors

    My channel seems to stop sending data even though it is not shutting itself down. I'm seeing a message in Mirth that says I had too many errors. I can't tell if Mirth is coming up with this on it's own or if my destination system is refusing and shutting down.

    Here is the message
    ERROR-408: MLLP Connector error
    ERROR MESSAGE: Unable to send message. Too many retries
    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 java.net.Socket.connect(Unknown Source)
    at java.net.Socket.<init>(Unknown Source)
    at java.net.Socket.<init>(Unknown Source)
    at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageDispatcher.createSocket(MllpMessageDispatch er.java:190)
    at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageDispatcher.initSocket(MllpMessageDispatcher .java:107)
    at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageDispatcher.doDispatch(MllpMessageDispatcher .java:151)
    at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageDispatcher.doSend(MllpMessageDispatcher.jav a:219)
    at org.mule.providers.AbstractMessageDispatcher.send( AbstractMessageDispatcher.java:166)
    at org.mule.impl.MuleSession.sendEvent(MuleSession.ja va:191)
    at org.mule.impl.MuleSession.sendEvent(MuleSession.ja va:130)
    at org.mule.routing.outbound.AbstractOutboundRouter.s end(AbstractOutboundRouter.java:85)
    at org.mule.routing.outbound.FilteringMulticastingRou ter.route(FilteringMulticastingRouter.java:89)
    at org.mule.routing.outbound.OutboundMessageRouter$1. doInTransaction(OutboundMessageRouter.java:78)
    at org.mule.transaction.TransactionTemplate.execute(T ransactionTemplate.java:48)
    at org.mule.routing.outbound.OutboundMessageRouter.ro ute(OutboundMessageRouter.java:82)
    at org.mule.impl.model.DefaultMuleProxy.onCall(Defaul tMuleProxy.java:247)
    at org.mule.impl.model.seda.SedaComponent.doSend(Seda Component.java:209)
    at org.mule.impl.model.AbstractComponent.sendEvent(Ab stractComponent.java:277)
    at org.mule.impl.MuleSession.sendEvent(MuleSession.ja va:201)
    at org.mule.routing.inbound.InboundMessageRouter.send (InboundMessageRouter.java:161)
    at org.mule.routing.inbound.InboundMessageRouter.rout e(InboundMessageRouter.java:128)
    at org.mule.providers.AbstractMessageReceiver$Default InternalMessageListener.onMessage(AbstractMessageR eceiver.java:492)
    at org.mule.providers.AbstractMessageReceiver.routeMe ssage(AbstractMessageReceiver.java:271)
    at org.mule.providers.AbstractMessageReceiver.routeMe ssage(AbstractMessageReceiver.java:243)
    at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageReceiver$TcpWorker.processData(MllpMessageR eceiver.java:362)
    at com.webreach.mirth.server.mule.providers.mllp.Mllp MessageReceiver$TcpWorker.run(MllpMessageReceiver. java:284)
    at org.mule.impl.work.WorkerContext.run(WorkerContext .java:290)
    at edu.emory.mathcs.backport.java.util.concurrent.Thr eadPoolExecutor$Worker.runTask(ThreadPoolExecutor. java:650)
    at edu.emory.mathcs.backport.java.util.concurrent.Thr eadPoolExecutor$Worker.run(ThreadPoolExecutor.java :675)
    at java.lang.Thread.run(Unknown Source)



    Any help would be appreciated

  • #2
    Re:Getting message regarding too many errors

    I'm not sure about Mirth but I have come across similar error on a different HL7 host trying to send LLP message out. If the destination (client) is not up and running (listening), it throws this error for each message it tries to send out.

    If the Mirth channel is trying to send messages to an LLP destination, check if the client is up and running and ready to receive messages.

    Hope this helps!

    Comment


    • #3
      Re:Getting message regarding too many errors

      I'm fairly sure that the LLP client on the destination was up becuase it sent about 150 some messages then just stopped. When I looked at the errors the error I posted is what I ended up seing.

      To explain further I have a system sending messages to Mirth that sends more messages than is inteded to my destination. If my destination does not see a PV1 segment it responds with an AE.

      Now before using Mirth I was using another Interface tool and it was sending the messages even if the destination was unhappy.

      I'm trying to make sure that Mirth isn't seeing too many AE responses and assuming something else is wrong and therefore stopping the transmissions.

      Thanks for your quick response though.

      Kevin

      Comment


      • #4
        Re:Getting message regarding too many errors

        Following post has couple of suggestions for a similar LLP Channel problem:
        LLP Channel Stops Listening - Help!

        Turn on "Use strict LLP validation".
        To keep the connection open, set receive timeout to 0 (infinite).
        Hope it helps!

        Comment


        • #5
          Re:Getting message regarding too many errors

          After reading the other post you linked I know that I have the "keep connection open" set to on. I see that it might be bugged so I'll go modify that.

          What may also help me (if I can figure out how to do it) is to strip out any messages that do not have a PV1 segment. My destination only needs messages that have a PV1 segment in it and will error any that do not. This should reduce the number of AE's that are being sent back to Mirth and reduce the amount of messages being transmitted.

          So now I need to figure out how to create a good filter. Since I"m looking for PV1 Segments I probably need to write it to check if there is a PV1 segment and if there is transmitt it otherwise skip it.

          Comment


          • #6
            Re:Getting message regarding too many errors

            Sample filter code below is based on Scheduling message. I didn't get a chance to test it though.

            Code:
            if (msg['SIU_S12.PATIENT']['PV1'] != null) {
                var pivSegment = msg['SIU_S12.PATIENT']['PV1'].toString();
                 if (pivSegment.length > 0) {
                     return true;
                 }
                 else {
                    return false;
                 }            
            }
            Hope it helps!

            Comment


            • #7
              Re:Getting message regarding too many errors

              I wasn't sure what the 'SIU_S12.PATIENT' portion of your code represented and if I used the code directly as you put it it seemed to allow things to pass through. I removed just that portion and it seemed to work for me on my test box.

              Code:
              if (msg['PV1'] != null) {
                  var pivSegment = msg['PV1'].toString();
                   if (pivSegment.length > 0) {
                       return true;
                   }
                   else {
                      return false;
                   }            
              }
              I still need to go and try this on the live box but I think this is going to solve a lot of my problems since I'm filtering out 90% of the uncessary messages going to the destination.

              Comment


              • #8
                Re:Getting message regarding too many errors

                'SIU_S12.PATIENT' - It's an S12 message for patient appointment.

                In your case, you need to copy-and-paste a sample message in the Filter screen that your channel is processing. Drag-and-drop the PV1 part into the java script filter code. But if the sample code works with just PV1 alone, I guess that's okay.

                Comment

                Working...
                X