Announcement

Collapse
No announcement yet.

LLP to File Exception

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

  • LLP to File Exception

    ERROR org.mule.impl.DefaultExceptionStrategy: Caught exception in Exception Strategy: No group 9
    java.lang.IndexOutOfBoundsException: No group 9
    at java.util.regex.Matcher.group(Matcher.java:463)
    at java.util.regex.Matcher.appendReplacement(Matcher. java:730)
    at java.util.regex.Matcher.replaceAll(Matcher.java:80 6)
    at java.lang.String.replaceAll(String.java:2000)
    at org.mule.providers.file.FileMessageDispatcher.repl aceValues(FileMessageDispatcher.java:122)
    at org.mule.providers.file.FileMessageDispatcher.doDi spatch(FileMessageDispatcher.java:88)
    at org.mule.providers.AbstractMessageDispatcher$Worke r.run(AbstractMessageDispatcher.java:257)
    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(Thread.java:595)


    The file names are created just fine but the files are zero length.

    JDK 1.5.0_08
    Linux
    Mirth 1.1.0

    HL7 destination template

    file name template is: {UUID}-{SYSDATE}.hl7

    also had a 2nd destination for XML

    both same result

    thanks

    Mark

  • #2
    Re: LLP to File Exception

    What is your file-template?
    Chris Lang

    Comment


    • #3
      Re: LLP to File Exception

      I did a channel export of the problematic channel. I blanked the LLP IP address, though internal, for good measure. I noticed that a copy of the exception also was stored with the channel export XML file. Was this intentional?

      Thanks for your help!

      <com.webreach.mirth.model.Channel>
      <id>1</id>
      <name>GROUPCAST REALTIME ADT</name>
      <description>Groupcast Realtime ADT from Integrate EMR Rebroadcaster</description>
      <enabled>true</enabled>
      <version>1.1.0</version>
      <revision>0</revision>
      <direction>INBOUND</direction>
      <mode>ROUTER</mode>
      <sourceConnector>
      <name>sourceConnector</name>
      <properties>
      <property name="tcpProtocolClassName" value="org.mule.providers.tcp.protocols.LlpProtoco l"/>
      <property name="messageEnd" value="0x1C"/>
      <property name="sendACK" value="1"/>
      <property name="keepSendSocketOpen" value="1"/>
      <property name="bufferSize" value="65536"/>
      <property name="port" value="55702"/>
      <property name="messageStart" value="0x0B"/>
      <property name="charEncoding" value="hex"/>
      <property name="DataType" value="LLP Listener"/>
      <property name="recordSeparator" value="0x0D"/>
      <property name="receiveTimeout" value="5000"/>
      <property name="host" value="www.xxx.yyy.zzzI "/>
      </properties>
      <transformer>
      <steps/>
      </transformer>
      <filter>
      ERROR org.mule.impl.DefaultExceptionStrategy: Caught exception in Exception Strategy: No group 9
      java.lang.IndexOutOfBoundsException: No group 9
      at java.util.regex.Matcher.group(Matcher.java:463)
      at java.util.regex.Matcher.appendReplacement(Matcher. java:730)
      at java.util.regex.Matcher.replaceAll(Matcher.java:80 6)
      at java.lang.String.replaceAll(String.java:2000)
      at org.mule.providers.file.FileMessageDispatcher.repl aceValues(FileMessageDispatcher.java:122)
      at org.mule.providers.file.FileMessageDispatcher.doDi spatch(FileMessageDispatcher.java:88)
      at org.mule.providers.AbstractMessageDispatcher$Worke r.run(AbstractMessageDispatcher.java:257)
      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(Thread.java:595)
      <rules/>
      </filter>
      <transportName>LLP Listener</transportName>
      </sourceConnector>
      <destinationConnectors>
      <com.webreach.mirth.model.Connector>
      <name>Destination 1</name>
      <properties>
      <property name="outputAppend" value="0"/>
      <property name="DataType" value="File Writer"/>
      <property name="outputPattern" value="${UUID}-${SYSTIME}.hl7"/>
      <property name="template" value="${HL7 ER7}&#x0D;"/>
      <property name="host" value="/us1/idxadt"/>
      </properties>
      <transformer>
      <steps/>
      </transformer>
      <filter>
      <rules/>
      </filter>
      <transportName>File Writer</transportName>
      </com.webreach.mirth.model.Connector>
      <com.webreach.mirth.model.Connector>
      <name>Destination 2</name>
      <properties>
      <property name="outputAppend" value="0"/>
      <property name="DataType" value="File Writer"/>
      <property name="outputPattern" value="${UUID}-${SYSTIME}.xml"/>
      <property name="template" value="${HL7 XML}"/>
      <property name="host" value="/us1/idxadt"/>
      </properties>
      <transformer>
      <steps/>
      </transformer>
      <filter>
      <rules/>
      </filter>
      <transportName>File Writer</transportName>
      </com.webreach.mirth.model.Connector>
      </destinationConnectors>
      <properties>
      <property name="initialState" value="started"/>
      <property name="recv_xml_encoded" value="false"/>
      </properties>
      </com.webreach.mirth.model.Channel>

      Comment


      • #4
        Re: LLP to File Exception

        Also, here is a section of the &#039;ls -l&#039; of what was being written to the destination directory:

        -rw-r--r-- 1 root root 0 Sep 29 16:49 09927f27-4ffc-11db-b5c9-e546f5a46a93-1159562
        984851.hl7
        -rw-r--r-- 1 root root 0 Sep 29 16:49 0992f458-4ffc-11db-b5c9-e546f5a46a93-1159562
        984855.xml
        -rw-r--r-- 1 root root 0 Sep 29 16:49 0aa3a01a-4ffc-11db-b5c9-e546f5a46a93-1159562
        986641.hl7
        -rw-r--r-- 1 root root 0 Sep 29 16:49 0aa9456b-4ffc-11db-b5c9-e546f5a46a93-1159562
        986678.xml
        -rw-r--r-- 1 root root 0 Sep 29 16:49 0ab7281d-4ffc-11db-b5c9-e546f5a46a93-1159562
        986770.hl7
        -rw-r--r-- 1 root root 0 Sep 29 16:49 0adb7900-4ffc-11db-b5c9-e546f5a46a93-1159562
        987007.hl7
        -rw-r--r-- 1 root root 0 Sep 29 16:49 0b11a436-4ffc-11db-b5c9-e546f5a46a93-1159562
        987362.xml

        File names seem to be generating correctly.

        Thanks

        Mark

        Comment


        • #5
          Re: LLP to File Exception

          One more thing, too. The inbound side of this channel receives the data just fine and I can View Messages on the channel and see all messages and their payloads (in raw, XML and HL7 views). So, the data is successfully getting into Mirth. It is only on the outbound that the exception occurs.

          mark

          Comment


          • #6
            Re: LLP to File Exception

            That is really strange - the exception should not be in the filter. Try re-creating the channel, or editing the filter and adding a new blank step.

            -Chris
            Chris Lang

            Comment


            • #7
              Re: LLP to File Exception

              Hi Chris,

              OK, I imported &#039;LLP to File Writer.xml&#039; and created a brand new channel (just changing the inbound IP address to 192.168.5.34 and TCP 55702 (what the client wanted me to use). The outbound was unchanged except that the directory path was set for /tmp.

              Same problem.

              Again, running generic install of JDK 1.5.0_08 (J2SE) on Redhat EL3. Mirth is 1.1.0 from a .zip file with nothing deviated.

              When you refer to "adding a new blank step" to the original channel, what exactly do you mean?

              Also, all messages inbound were accepted by Mirth no problem. The only real differences channel setup wise are the inbound listening on the 192. instead of the "example" 127. and the TCP port.

              Could also be something about the JDK install but it was all generic from the Sun .bin/.rpm and then the path set for Mirth.sh (in the $PATH ordering). $JAVA_HOME was set also for good measure.

              Anyways, below are the nuts and bolts.


              Files created:

              -rw-r--r-- 1 root root 0 Oct 3 08:12 results60afa9e5-52d8-11db-89c4-82f21e06cfa7.txt
              -rw-r--r-- 1 root root 0 Oct 3 08:12 results60c099da-52d8-11db-89c4-82f21e06cfa7.txt
              -rw-r--r-- 1 root root 0 Oct 3 08:12 results60d2260f-52d8-11db-89c4-82f21e06cfa7.txt
              -rw-r--r-- 1 root root 0 Oct 3 08:12 results60edeb77-52d8-11db-89c4-82f21e06cfa7.txt
              -rw-r--r-- 1 root root 0 Oct 3 08:12 results60ff9ebb-52d8-11db-89c4-82f21e06cfa7.txt

              Exception:

              ERROR org.mule.impl.DefaultComponentExceptionStrategy: Caught exception in Exception Strategy for: 6: org.mule.impl.FailedToQueueEventException: Interrupted while queue event for "6". Connector that caused exception is: 6. Message payload is of type: [B
              org.mule.impl.FailedToQueueEventException: Interrupted while queue event for "6". Connector that caused exception is: 6. Message payload is of type: [B
              at org.mule.impl.model.seda.SedaComponent.doDispatch( SedaComponent.java:184)
              at org.mule.impl.model.AbstractComponent.dispatchEven t(AbstractComponent.java:253)
              at org.mule.impl.MuleSession.dispatchEvent(MuleSessio n.java:160)
              at org.mule.routing.inbound.InboundMessageRouter.disp atch(InboundMessageRouter.java:146)
              at org.mule.routing.inbound.InboundMessageRouter.rout e(InboundMessageRouter.java:126)
              at org.mule.providers.AbstractMessageReceiver$Default InternalMessageListener.onMessage(AbstractMessageR eceiver.java:486)
              at org.mule.providers.AbstractMessageReceiver.routeMe ssage(AbstractMessageReceiver.java:277)
              at org.mule.providers.AbstractMessageReceiver.routeMe ssage(AbstractMessageReceiver.java:246)
              at org.mule.providers.tcp.TcpMessageReceiver$TcpWorke r.processData(TcpMessageReceiver.java:274)
              at org.mule.providers.tcp.TcpMessageReceiver$TcpWorke r.run(TcpMessageReceiver.java:250)
              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(Thread.java:595)
              Caused by: java.lang.InterruptedException
              at org.mule.util.queue.TransactionalQueueManager$Queu eInfo.offer(TransactionalQueueManager.java:285)
              at org.mule.util.queue.TransactionalQueueManager$Queu eSessionImpl$QueueImpl.offer(TransactionalQueueMan ager.java:464)
              at org.mule.util.queue.TransactionalQueueManager$Queu eSessionImpl$QueueImpl.put(TransactionalQueueManag er.java:453)
              at org.mule.impl.model.seda.SedaComponent.enqueue(Sed aComponent.java:322)
              at org.mule.impl.model.seda.SedaComponent.doDispatch( SedaComponent.java:179)
              ... 13 more

              Export of the new (modified) channel:

              =======================================

              <com.webreach.mirth.model.Channel>
              <id>6</id>
              <name>LLP to File Writer (GROUPCAST2)</name>
              <description></description>
              <enabled>true</enabled>
              <version>1.1.0</version>
              <revision>0</revision>
              <direction>INBOUND</direction>
              <mode>ROUTER</mode>
              <sourceConnector>
              <name>sourceConnector</name>
              <properties>
              <property name="tcpProtocolClassName" value="org.mule.providers.tcp.protocols.LlpProtoco l"/>
              <property name="messageEnd" value="0x1C"/>
              <property name="sendACK" value="1"/>
              <property name="keepSendSocketOpen" value="0"/>
              <property name="bufferSize" value="65536"/>
              <property name="port" value="55702"/>
              <property name="messageStart" value="0x0B"/>
              <property name="charEncoding" value="hex"/>
              <property name="DataType" value="LLP Listener"/>
              <property name="recordSeparator" value="0x0D"/>
              <property name="receiveTimeout" value="5000"/>
              <property name="host" value="192.168.5.34"/>
              </properties>
              <transformer>
              <steps/>
              </transformer>
              <filter>
              <rules/>
              </filter>
              <transportName>LLP Listener</transportName>
              </sourceConnector>
              <destinationConnectors>
              <com.webreach.mirth.model.Connector>
              <name>Destination 1</name>
              <properties>
              <property name="outputAppend" value="0"/>
              <property name="outputPattern" value="results${UUID}.txt"/>
              <property name="DataType" value="File Writer"/>
              <property name="template" value="${HL7 ER7}"/>
              <property name="host" value="/tmp"/>
              </properties>
              <transformer>
              <steps/>
              </transformer>
              <filter>
              <rules/>
              </filter>
              <transportName>File Writer</transportName>
              </com.webreach.mirth.model.Connector>
              </destinationConnectors>
              <properties>
              <property name="initialState" value="stopped"/>
              <property name="recv_xml_encoded" value="false"/>
              </properties>
              </com.webreach.mirth.model.Channel>


              =======================================

              Comment


              • #8
                Re: LLP to File Exception

                UPDATE:

                Chris,

                One record did output. I cannot post it here, but, it was a test record with a number of fields blanked.

                What is notable is that lines are ONLY terminated with ^M (CR) and there are no ^J (NL) anywhere!

                When I view this message in the Mirth database, it appears just fine. As I understand it, there is a complete disconnect from an inbound message and its outbound route/generation, correct?

                so, something in the outbound does not appear correctly formatting.

                maybe this is a clue?

                thanks

                mark

                Comment


                • #9
                  Re: LLP to File Exception

                  Chris,

                  Let me add this thought. On a more normal, "fully packed" message in transit, if the entire output is actually getting dumped in a large "blob", could it be crashing into the upper boundary of the output/string buffer data structure and overruning it?

                  Mark

                  Comment


                  • #10
                    Re: LLP to File Exception

                    I&#039;ll have more info for you soon, but to answer your Newline vs CR question - the standard HL7 end-of-segment character is just the CR, no NLs. You could perform a translation on this in the transformer, but any receiving HL7 compliant system will want to see CRs.

                    -Chris
                    Chris Lang

                    Comment


                    • #11
                      Re: LLP to File Exception


                      I&#039;m getting a similar error when I try to export HL7 ER7 or HL7 XML to a file.

                      In the template I&#039;m only putting: ${HL7 ER7} or ${HL7 XML}

                      JDK 1.5.0_06
                      Windows XP Pro SP2
                      Mirth 1.1.0

                      Here is the Error:
                      ERROR org.mule.impl.DefaultExceptionStrategy: Caught exception in Exception Strategy: Illegal group reference
                      java.lang.IllegalArgumentException: Illegal group reference
                      at java.util.regex.Matcher.appendReplacement(Unknown Source)
                      at java.util.regex.Matcher.replaceAll(Unknown Source)
                      at java.lang.String.replaceAll(Unknown Source)
                      at org.mule.providers.file.FileMessageDispatcher.repl aceValues(FileMessageDispatcher.java:122)
                      at org.mule.providers.file.FileMessageDispatcher.doDi spatch(FileMessageDispatcher.java:88)
                      at org.mule.providers.AbstractMessageDispatcher$Worke r.run(AbstractMessageDispatcher.java:257)
                      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)

                      Comment


                      • #12
                        Re: LLP to File Exception

                        Hi Chris,

                        Have you guys come up with anything? I see that mp3pete was having a similar problem but different platform.

                        Thanks,

                        Mark

                        Comment


                        • #13
                          Re: LLP to File Exception

                          This will be fixed in 1.2 (Oct. 25th)

                          -Chris
                          Chris Lang

                          Comment


                          • #14
                            Re: LLP to File Exception

                            Just as a note, we&#039;ve completely re-written the template system (with much more powerful functionality) and the internal message storage object has been completely re-written.
                            Chris Lang

                            Comment


                            • #15
                              Re: LLP to File Exception

                              Good deal! What is the current projected release date for 1.2?

                              Comment

                              Working...
                              X