Announcement

Collapse

Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

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

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

RabbitMQ for queue incomming messages

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

  • RabbitMQ for queue incomming messages

    Hi all

    Just wondering if Mirth Corp. has thought about implementing queues using RabbitMQ. I've found this

    http://www.mirthcorp.com/community/issues/browse/MIRTH-2236

    but it seems quite abandoned idea.

    I'm asking that because I have a LLP Listener receiving thousands of messages and delivering them to another channel which has a DBWritter. As you can imagine, the messages are queueing in the LLP channel and when the queue grows up to some thousands, it starts to stop delivering to the DBWritter channel. In fact, the queue directory is linked to the DBWritter channel. If I stop mirth and mv the directory to a new name, then restart mirth will create the directory again (and empty), everything works again.

    Thanks in advance
    Regards

    -----------------
    Mirth version is 2.2.2
    Java 1.7.0_25

  • #2
    That issue is talking about creating a new source and destination connector for interfacing with AMQP-enabled servers.

    You're talking about something different, using RabbitMQ as the internal messaging queue for Mirth Connect. In fact, we have already rewritten the entire messaging engine (and queuing system) from the ground up for version 3.x. It no longer uses Mule, and no longer stores queued messages in the filesystem. The queued messages are stored in the database like everything else.

    There are also several recovery points in the message process, so that if for whatever reason the server suddenly goes down in the middle of processing a message, it will automatically recover the message when the server starts back up. The message will simply resume where it left off.

    So basically, just upgrade to the latest version. Test it out on your dev server first, try upgrading to 3.0.3, then 3.1.1, 3.2.2, 3.3.2, 3.4.2. At each point in between make sure your channels still work and make sure to resolve any deprecation warnings you see.
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


    - How do I foo?
    - You just bar.

    Comment


    • #3
      I don't think the question was really answered. The link in the original question was talking about AMQP protocol and it also mentions RabbitMQ as the product running the AMQP protocol. I also have need for a AMQP driver for Mirth. It's nice that Mirth is saving it's messages in a database to allow error recovery and such. That does not replace the need for a message queue for messages being processed by other services. I guess I get to write one myself, or do I call the PilotFish guys? They have a driver for AMQP.

      Comment


      • #4
        To be honest, it's just something with seemingly not much demand in the market for... but if it's picking up then it could certainly be added. There's a JIRA issue for it, feel free to comment: MIRTH-2236

        However, note that it's completely possible and actually not too hard to do right now with the current version of Mirth Connect. As with most things, there's an open source library for that. RabbitMQ has a Java client, and there's also SwiftMQ which is more of a generic AMQP client. The code you'd write in a JavaScript Writer or whatever is rather simple:

        Code:
        var connection;
        var session;
        var producer;
        
        try {
        	var context = new com.swiftmq.amqp.AMQPContext(com.swiftmq.amqp.AMQPContext.CLIENT);
        	connection = new com.swiftmq.amqp.v100.client.Connection(context, 'localhost', 5672, true);
        	connection.connect();
        	session = connection.createSession(100, 100);
        	producer = session.createProducer('testqueue', com.swiftmq.amqp.v100.client.QoS.EXACTLY_ONCE);
        	
        	var msg = new com.swiftmq.amqp.v100.messaging.AMQPMessage();
        	msg.setAmqpValue(new com.swiftmq.amqp.v100.generated.messaging.message_format.AmqpValue(new com.swiftmq.amqp.v100.types.AMQPString(connectorMessage.getEncodedData())));
        	producer.send(msg);
        } finally {
        	try { producer.close(); } catch (e) {}
        	try { session.close(); } catch (e) {}
        	try { connection.close(); } catch (e) {}
        }
        Trust me, the open source community here definitely has a significant influence on our product roadmap. We're always looking to see which wheels are the squeakiest when it comes to where to put the oil. If you want, come join our public Slack group and chat... there are a lot of smart people in there.
        Last edited by narupley; 04-06-2017, 07:34 PM.
        Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

        Nicholas Rupley
        Work: 949-237-6069
        Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


        - How do I foo?
        - You just bar.

        Comment

        Working...
        X