Mirth Connect
  1. Mirth Connect
  2. MIRTH-1818

Load test: inconsistent data error when you manually start & stop a Mirth jdbc channel.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.0
    • Fix Version/s: 3.0.0
    • Component/s: Server
    • Labels:
      None
    • Environment:
      Windows XP pro 32, First on Postgres 8.4, next on Oracle 10gR2
    • Operating System:
      Windows XP
    • Database:
      PostgreSQL

      Description

      Mirth channel performs replication messages between two tables in a local DBMS on the same server as Mirth, polling each 500 ms 100 new messages.
      Mirth 2.1 RC1 , 256 MB Java Heap size, on Windows XP pro 32 / 2 GB RAM using Oracle 10gR2 SGBD.
      (same error with the same test using Postgres 8.4 SGBD for Mirth 2.1 RC1 + inbound and outbound Postgres tables)
      The error occurred after a start and stop of the channel , Having previously received a significant number of messages - in full archive mode - (here after 100,000 msg , 0.7 KB/msg sized, for this test).

      For each message received (archived as received but not distributed): (not marked as Sent, nor errored or queued) the following error in Mirth log:

      [2011-04-21 17:11:21,542] ERROR (com.mirth.connect.connectors.jdbc.JdbcMessageReceiver:194): Error in channel: ZBR1_Y1_ADT_DEPUIS_CPAGE
      org.mule.umo.ComponentException: Cannot route event as component "f28d7ea9-8e4d-46db-9c38-6fca9e4838af" is stopped. Connector that caused exception is: f28d7ea9-8e4d-46db-9c38-6fca9e4838af. Message payload is of type: org.apache.commons.dbutils.BasicRowProcessor$CaseInsensitiveHashMap
      at org.mule.impl.model.AbstractComponent.sendEvent(AbstractComponent.java:258)
      at org.mule.impl.MuleSession.sendEvent(MuleSession.java:201)
      at org.mule.routing.inbound.InboundMessageRouter.send(InboundMessageRouter.java:176)
      at org.mule.routing.inbound.InboundMessageRouter.route(InboundMessageRouter.java:143)
      at org.mule.providers.AbstractMessageReceiver$DefaultInternalMessageListener.onMessage(AbstractMessageReceiver.java:487)
      at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:266)
      at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:229)
      at com.mirth.connect.connectors.jdbc.JdbcMessageReceiver.processMessage(JdbcMessageReceiver.java:179)
      at org.mule.providers.TransactedPollingMessageReceiver$1.doInTransaction(TransactedPollingMessageReceiver.java:98)
      at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:72)
      at org.mule.providers.TransactedPollingMessageReceiver.poll(TransactedPollingMessageReceiver.java:104)
      at org.mule.providers.PollingMessageReceiver.run(PollingMessageReceiver.java:97)
      at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
      at java.lang.Thread.run(Unknown Source)

      1. A_BENCH_START_STOP_LOG.txt
        8 kB
        Bruno MARTIN
      2. A_BENCH_START_STOP.xml
        5 kB
        Bruno MARTIN
      3. postgresql-2011-04-21_173706.log.txt
        1.0 kB
        Bruno MARTIN
      4. SRC_TABLES_ORACLE.txt
        10 kB
        Bruno MARTIN
      5. SRC_TABLES_POSTGRES.txt
        2 kB
        Bruno MARTIN
      6. ZBR1_ORA_TEST_CHAN.xml
        31 kB
        Bruno MARTIN
      7. ZBR1_PG_TEST_CHAN.xml
        32 kB
        Bruno MARTIN

        Issue Links

          Activity

          Hide
          Bruno MARTIN added a comment -

          context of the Mirth 2.1 load test

          Show
          Bruno MARTIN added a comment - context of the Mirth 2.1 load test
          Hide
          Bruno MARTIN added a comment -

          In some cases, (with the same channel) stopping or restarting the channel, the following error occurs:

          [2011-04-21 19:24:40,095] ERROR (org.mule.impl.model.seda.SedaModel:498): Error starting component [f28d7ea9-8e4d-46db-9c38-6fca9e4838af]
          org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@10f8ee4

          it is then necessary to kill the session of the administrative console and then stop and restart the Mirth server.
          (Without stopping Mirth server, it is not possible to restart the channel, even with another session of the Administrative Console)

          Show
          Bruno MARTIN added a comment - In some cases, (with the same channel) stopping or restarting the channel, the following error occurs: [2011-04-21 19:24:40,095] ERROR (org.mule.impl.model.seda.SedaModel:498): Error starting component [f28d7ea9-8e4d-46db-9c38-6fca9e4838af] org.mule.umo.provider.ConnectorException: There is already a listener registered on this connector on endpointUri: jdbc://query. Connector that caused exception is: com.mirth.connect.connectors.jdbc.JdbcConnector@10f8ee4 it is then necessary to kill the session of the administrative console and then stop and restart the Mirth server. (Without stopping Mirth server, it is not possible to restart the channel, even with another session of the Administrative Console)
          Hide
          Bruno MARTIN added a comment -

          Would it be possible to assign MIRTHA JRA-1818 to version 2.1.0.5389.b671 Mirth. (not only RC1 release)
          This bug, which challenges our way of Mirth Mirth 1.8 to 2.1 was found with this release, and a moderate amount of data archived, as well as Oracle 10g postgres 8.4 and 9.04, Windows 32, 64 and Suse Linux 64

          Thanking you in advance

          Best regards,

          Bruno MARTIN (CHU Dijon / France)

          Show
          Bruno MARTIN added a comment - Would it be possible to assign MIRTHA JRA-1818 to version 2.1.0.5389.b671 Mirth. (not only RC1 release) This bug, which challenges our way of Mirth Mirth 1.8 to 2.1 was found with this release, and a moderate amount of data archived, as well as Oracle 10g postgres 8.4 and 9.04, Windows 32, 64 and Suse Linux 64 Thanking you in advance Best regards, Bruno MARTIN (CHU Dijon / France)
          Hide
          Bruno MARTIN added a comment -

          Actually the problem also occurs with an outbound connector channel type writer or javascript (not only JDBC).
          When the channel is in state "Idle"it is possible to stop the channel without error.
          When the channel is in state "Reading" error occurs when processing outbound connector is not immediate.
          This seems the case when Mirth is slowed by the archiving of messages in a large database.

          When stopping for a channel, it is desirable that the connector is stopped before entering the outbound connector.
          (everything goes like it was the reverse)

          Show
          Bruno MARTIN added a comment - Actually the problem also occurs with an outbound connector channel type writer or javascript (not only JDBC). When the channel is in state "Idle"it is possible to stop the channel without error. When the channel is in state "Reading" error occurs when processing outbound connector is not immediate. This seems the case when Mirth is slowed by the archiving of messages in a large database. When stopping for a channel, it is desirable that the connector is stopped before entering the outbound connector. (everything goes like it was the reverse)
          Hide
          Bruno MARTIN added a comment -

          Illustration of error of this type (however slightly different) with a single javascript channel.

          Show
          Bruno MARTIN added a comment - Illustration of error of this type (however slightly different) with a single javascript channel.
          Hide
          Wayne Huang (Inactive) added a comment -

          This is probably fixed in Mirth Connect 3.x already because of the engine overhaul. In 3.x stopping a channel will allow currently processing message to flush out before the channel is stopped, instead of just interrupting the channel.

          Feel free to create another issue if you run into this in 3.x.

          Show
          Wayne Huang (Inactive) added a comment - This is probably fixed in Mirth Connect 3.x already because of the engine overhaul. In 3.x stopping a channel will allow currently processing message to flush out before the channel is stopped, instead of just interrupting the channel. Feel free to create another issue if you run into this in 3.x.

            People

            • Assignee:
              Wayne Huang (Inactive)
              Reporter:
              Bruno MARTIN
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development