[BUG] MirthConnect not using RabbitMQ Plugin

[Daudimania]

Describe the bug When using Mirth Connect 4.3.0 in a docker container and using RabbitMQ 3.11.15 also in a docker container, the Mirth JMS Queue does not send messages to RabbitMQ.

To Reproduce Setup steps (if required). Example:

1. Setup Mirth with a PostgresSQL container.
2. Setup RabbitMQ container with ports 5672, 15672, and 25672 open.
3. Import the .jar files RabbitMQ JMS 3.1.0 and RabbitMQ Java Client 5.17.0 into the custom-lib folder for Mirth. You may also need the Jakarta Messaging API 3.0.0

Steps to reproduce the behavior:

1. Create a channel with a JMS Destination, and attempt to send message to rabbitmq. (Note: you might have to change the hostname in the connection settings to the container name/ip of RabbitMQ)
2. Check RabbitMQ for message sent
3. Note no connection was attempted from Mirth and that MIrth has no log of attempting to send the message.
4. Port 5672 has no record of traffic going across it.

Expected behavior A log of an attempt to send the message to RabbitMQ is found in Mirth A connection is recorded between Mirth and RabbitMQ

Actual behavior No obvious attempt to send the message to RabbitMQ from Mirth is found, and the message stays in the queue

Environment:

• Host: Ubuntu 20.04
• RabbitMQ Container: RabbitMQ 3.11.15
• Mirth Container: Mirth Connect 4.3.0
• Postgres Container: Postgres 15.3
• Java Distribution/Version: OpenJDK 17

Workaround(s) With the exact same setup from above, everything works on Mirth 3.12.0

Additional context

• Mirth can successfully send to an exterior Postgres database and can also write to the Postgres container for it's internal Mirth database.
• RabbitMQ reports a connection made when using the curl command from the Mirth container on ports 5672, 15672, and 25672

[pacmano1]

I suspect you will need to provider more instructions on this. e.g. channels, docker compose files, etc. I doubt NG will look at this... maybe someone in the community will. (I don't work for Nextgen)

Also, did you validate it does work in a non container set up?

[Daudimania]

Thanks for the quick response.

This post is the basic guide to follow for the channels. It closely follows our setup, we just have more channels/a different template for the messages. Also note that the guide does not have mirth in a container, but I provided further setup instructions for the containerized version.

This bug was found when my org was attempting to containerize all of our applications from having them installed directly on the host. We have the same issues running on the host with the most recent versions of both applications. It was just listed as the containerized version to reflect the workaround state.

[pacmano1]

I don't think that article ever worked (I think someone else posted that on the forums at some point).

[Daudimania]

Odd. It ended up working for us. The main difference is we use the updated plugins, and our connection settings only has the host name provided instead. We were able to get the full system working on 3.12.0, but using anything 4.x and up caused failure with no logs reported.

[pacmano1]

LOL, then I take that back, my bad.

[pacmano1]

So containerized or not, it does now work now, got it.