Poll once on start feature - Failure to log and even start channel when initial poll fails

[fhirybutpeaceful]

When poll once on start is set for a timed queue I would expect that failures on the initial poll would result in a clean startup - with an attempt logged in the channel logs showing any error for the first poll. However, here is what I am finding. When channel type is set to ftp and the poll fails the entire channel does not start. I am attaching the sample to try. This was tested with 4.0.0 on Windows.

This is the channel setup - note the bad url:

The results of which is a start up failure with the following callstack:

	at com.mirth.connect.donkey.server.channel.Channel.start(Channel.java:790)

	at com.mirth.connect.server.controllers.DonkeyEngineController$DeployTask.doDeploy(DonkeyEngineController.java:1981)

	at com.mirth.connect.server.controllers.DonkeyEngineController$DeployTask.execute(DonkeyEngineController.java:1817)

	at com.mirth.connect.server.channel.ChannelTask.call(ChannelTask.java:67)

	at com.mirth.connect.server.channel.ChannelTask.call(ChannelTask.java:16)

	at java.util.concurrent.FutureTask.run(Unknown Source)

	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

	at java.lang.Thread.run(Unknown Source)
Caused by: com.mirth.connect.donkey.server.ConnectorTaskException: connect timed out

	at com.mirth.connect.connectors.file.FileReceiver.onStart(FileReceiver.java:158)

	at com.mirth.connect.donkey.server.channel.SourceConnector.start(SourceConnector.java:105)

	at com.mirth.connect.donkey.server.channel.PollConnector.start(PollConnector.java:31)

	at com.mirth.connect.donkey.server.channel.Channel.start(Channel.java:766)

	... 8 more
Caused by: java.net.SocketTimeoutException: connect timed out

	at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)

	at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)

	at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)

	at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)

	at java.net.AbstractPlainSocketImpl.connect(Unknown Source)

	at java.net.PlainSocketImpl.connect(Unknown Source)

	at java.net.SocksSocketImpl.connect(Unknown Source)

	at java.net.Socket.connect(Unknown Source)

	at org.apache.commons.net.SocketClient.connect(SocketClient.java:182)

	at org.apache.commons.net.SocketClient.connect(SocketClient.java:203)

	at org.apache.commons.net.SocketClient.connect(SocketClient.java:296)

	at com.mirth.connect.connectors.file.filesystems.FtpConnection.<init>(FtpConnection.java:113)

	at com.mirth.connect.connectors.file.filesystems.FtpConnection.<init>(FtpConnection.java:98)

	at com.mirth.connect.connectors.file.filesystems.FileSystemConnectionFactory.makeObject(FileSystemConnectionFactory.java:174)

	at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:861)

	at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:435)

	at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)

	at com.mirth.connect.connectors.file.FileConnector.getConnection(FileConnector.java:186)

	at com.mirth.connect.connectors.file.FileReceiver.onStart(FileReceiver.java:153)

	... 11 more

Also, the channel logs don't contain anything about the failure - which I would expect if it failed to start.

I also tested this with a javascript channel - I had the channel throw an error (i.e. throw new Error()). The result there was different - the channel ended up starting, however, there was nothing logged. It seems that that is an issue as well. It should log the result of the error.

If you need the channel xml let me know.

[pacmano1]

Mirth has always worked that way. Sort of is what it is I think, not sure if it a bug.

[fhirybutpeaceful]

Thank you for the quick response. However, logically, it doesn't seem right that a poll failure on startup results in a channel deploy failure. I am pointing out that the behavior is not even consistent across channel types. I haven't always seen the option to poll once on deploy - it seems like a more recent addition but I may be wrong on that. We just had a server restarted because of maintenance and the channel failed to deploy because of a ftp timeout in the startup one-time poll.

[pacmano1]

I have seen what you have seen in your last sentence. In my case so many were polling at once on startup to the same endpoint the other end declined a connection. I think you are right though - I seem to remember the channel deploying but ending up on the stopped state rather than not deploying at all.

Overall, I agree though - it should behave better! Just dealt with it by not polling on start which happended to be OK in my use case.

[fhirybutpeaceful]

Got it - I will work around it. Just wanted to point this out. Thanks.

[pacmano1]

I would not close it, it's a good report.