I think you can see where I'm going here. On an undeploy we first stop the channel from the same thread (which leads to the reverse issue MIRTH-3316). The problem is that on a deploy we also start the channel from the same thread.
In fact I'm not sure I've ever seen an instance of a channel stuck at deploying/undeploying. I think in 99% of cases the channel gets stuck starting/stopping, not deploy/undeploying.
However as long as that channel is hanging at the start then it will still prevent all future deploy/undeploy requests. Note that if we leave deplo圜hannels synchronized and take it off from deplo圜hannel, one channel hanging will not block the rest of the channels from deploying/starting. We'll have to verify those use cases after any changes we make for this issue. You're right that this change wasn't made to support multiple servers. That said, it's still "better" restricting requests to one per server than allowing more. If the goal was to only allow one deploy request across multiple servers, it would require some sort of centralized or peer-to-peer locking system, like the clustering extension provides. Each server will only allow one deploy request, but multiple deploy requests can still be occurring simultaneously. Different servers are going to be running in completely different JVMs, so both servers are still going to be able to get into their respective deplo圜hannels methods at the same time. However I'm not sure that the synchronization itself has anything to do with multiple servers on the same database. I agree, obviously something like this (as with any issue) is going to require testing. This is similar to the changes made to ChannelStatusServlet for start/stop/etc. The changes here would call for the public method to submit multiple tasks to an executor, and those tasks would call the private method simultaneously for different channels. Currently the public deplo圜hannels method just iterates through each channel ID and calls the private method.
The public deploy channels method would remain synchronized, so that only a single request should happen at a time. The private deplo圜hannel method doesn't need to be synchronized, since it is only called from the public deplo圜hannels method.
0 kommentar(er)
