Difference between pausing and disabling channels

[seamims]

Hello,

Can someone explain to me the difference between pausing and stopping a channel?

I have a "main" LLP listener which is using router.routeMessage to send messages to other Channel Reader "children" channels. When I pause one of these children using "channel pause" in Mirth Shell and send a few messages, code within the channel transformers doesn't execute as expected. Then I "resume" and the code does execute, also as expected.

The thing is, when I stop the channel using "channel stop" and then restart it with "channel start" apparently the same thing happens.

Could someone tell me the difference between "pause" and "stop"

Thanks!

[brendanh]

Reifference between pausing and disabling channels

I believe pausing still allows the channel to receive messages. It just doesn't start processing them until you resume it.

Stopping a channel will stop everything in that channel, and incoming messages will not be accepted.

[seamims]

Reifference between pausing and disabling channels

This is odd, because I tested sending several messages to the channel both when paused and when stopped. In both instances the recipient didn't do anything until I resumed or started the channel and then all of the messages would get processed.

Note that the channels I am talking about are ChannelReaders. I'm sending messages to them via router.routeMessage.

[jacob41]

Is this still good advice, more than 7 years later?

I believe pausing still allows the channel to receive messages. It just doesn't start processing them until you resume it.

Stopping a channel will stop everything in that channel, and incoming messages will not be accepted.

[narupley]

In the latest version, lots of things have changed. You can now stop individual connectors in addition to the overall channel.

Pausing a channel is the same thing as stopping the source connector. The receiver (e.g. TCP server socket, database poll timer, etc.) will stop, so no new messages will automatically flow into the channel. However the destination connectors will remain started, so if you have any queued destination messages, those will continue to process. In addition to that, while a channel is paused you can still manually send messages (or reprocess messages) through the Administrator.

Stopping a channel still stops everything, including all destination connectors. However any currently processing messages will finish before the channel is stopped (which is why you may see the Stopping status on the dashboard). That includes any messages on the main processing thread, and also any destination queued messages that are in the middle of a send attempt. The moment you stop a channel no new messages are allowed to flow into the channel, but it's only after those currently processing messages finish that the channel is truly completely stopped.

If for whatever reason your channel fails comply with a start/stop/pause/deploy/undeploy action, you'll see one of the gerund statuses on the dashboard (e.g. Stopping, Deploying, etc.). This can mean that the currently processing message is just legitimately taking a while to finish, or it can mean that it's stuck. Usually this is due to an infinite loop in your code or something similar.

As a last resort, when the channel is in one of these states you can choose to "Halt" it. What this means is that the channel (and all of its connectors) will attempt to immediately stop what they are doing and return. If your message is in the middle of a JavaScript script, it will attempt to immediately break out of the script after the current line.

Any intermediate data will not be committed to the database when you halt, so that message will essentially fall back to the last recovery point and become an "unfinished" message. If message storage is at Production or higher, then "message durability" is enabled, which means that unfinished messages will automatically recover themselves when the channel is next started. There are certain places throughout the message life-cycle where data is committed to the database, and those are the "recovery points". For example, when the message first flows into the channel, the source raw content (and source map) are committed before anything else. If you halt the channel in the source transformer, then anything that happened after the source raw content was committed is basically forgotten. When you start the channel again, that message will pick back up from that recovery point, and start going through the source filter/transformer again, etc. If the storage setting is at Raw or below, then that automatic recovery won't happen.

[jacob41]

Great - thanks. If I stop a destination, will the messages queue there? i.e., I want to continue to receive messages, but I don't want to process them right now.

[narupley]

Great - thanks. If I stop a destination, will the messages queue there? i.e., I want to continue to receive messages, but I don't want to process them right now.

Yes, messages will queue on the destination side without being sent anywhere. However, the messages will still have been run through the source and destination(s) filter/transformer scripts. In 3.2 you will have the ability to include the filter/transformer within the destination queue itself (MIRTH-3558), so you will be able to stop a destination and have messages queue without having the filter/transformer run, if you wanted.