rbeckman-nextgen
commented
4 years ago I don't think this is necessary, because the side-effect it produces (channels blocking each other during deploy) will be fixed with a different issue (MIRTH-3334). We don't currently automatically disable channels based on other channels' properties, so the change as described might be inconsistent. Plus, the ability to deploy multiple channels on the same port is something that we're looking to add in the future anyway (MIRTH-1702, MIRTH-1624).
Imported Comment. Original Details: Author: narupley Created: 2014-07-08T09:16:17.000-0700
Feature Request
For MC version 3.x.
Notify the user that he can't deploy channels with duplicate listening ports and then disable the channels.
Details
Currently, if you deploy channels with the same listening ports, one of channels would deploy but the rest would be at starting and then they would stop and error out with something like
{noformat} [2014-07-08 08:16:20,585] ERROR (com.mirth.connect.server.controllers.DonkeyEngineController:190): Error deploying channel d91e5135-d61b-4732-8638-c8086d081aee. com.mirth.connect.donkey.server.StartException: com.mirth.connect.donkey.server.StartException: Failed to create server socket (TCP Listener "Source" on channel d91e5135-d61b-4732-8638-c8086d081aee). at com.mirth.connect.donkey.server.channel.Channel$StartTask.call(Channel.java:1957) at com.mirth.connect.donkey.server.channel.Channel$StartTask.call(Channel.java:1857) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:680)Caused by: com.mirth.connect.donkey.server.StartException: Failed to create server socket (TCP Listener "Source" on channel d91e5135-d61b-4732-8638-c8086d081aee). at com.mirth.connect.connectors.tcp.TcpReceiver.onStart(TcpReceiver.java:141) at com.mirth.connect.donkey.server.channel.SourceConnector.start(SourceConnector.java:88) at com.mirth.connect.donkey.server.channel.Channel$StartTask.call(Channel.java:1935) ... 6 moreCaused by: java.net.BindException: Address already in use at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) at java.net.ServerSocket.bind(ServerSocket.java:328) at java.net.ServerSocket.(ServerSocket.java:194)
at com.mirth.connect.connectors.tcp.StateAwareServerSocket.(StateAwareServerSocket.java:36)
at com.mirth.connect.connectors.tcp.TcpReceiver.createServerSocket(TcpReceiver.java:705)
at com.mirth.connect.connectors.tcp.TcpReceiver.onStart(TcpReceiver.java:139
{noformat}
+Example+:
Let's say there are two channels that are TCP Listeners that listen on Port 6661:
Channel A Channel B
1) Deploy both channels at the same time 2) Channel A deploys first. It starts and then becomes "Started". 3) Channel B deploys second. It's at "Starting" for a few seconds. Then it becomes "Stopped" and errors with the error above.
+Why this feature should be implemented+:
A channel could get stuck at "Starting" like at step 3 in the example above. This occurred in SUPPORT-1149. When a channel gets stuck at starting, it will prevent subsequent channels from deploying. This feature would prevent such channels from deploying and possibly getting stuck.
Imported Issue. Original Details: Reporter: beverlys Created: 2014-07-08T08:52:35.000-0700