RE: Mule FTP polling dies silently

My apologies for reawakening the thread so much later.  The problem persists:
After some hours, usually >12, some FTP server will stop being polled.  I am polling
a dozen, and which one seems to be random.  After a few more hours, another
one stops, and then another.  Restarting Mule (in Tomcat 5.5) will bring them all
back again.

Setting doThreading="false" has no effect.

There is no stack trace.  No error is indicated (I wish there were!).  The polled
machine just disappears from the logs.  The last log line for a particular server
looks like:

DEBUG 2008-11-24 16:36:13,574 [connector.ftp.0.receiver.1] org.mule.providers.ftp.FtpConnector:=== get pool for ftp://<user>:<pw>@<FTP server>/

and then no more.  I've noticed that "receiver.1" will disappear from the logs
for a while, then, too.  Servers that go off-line appear in the logs ("Connection
timed out") but they do not disappear.  My problem is that on-line servers
stop being polled.  My work-around is to restart Mule.  

Any help would be appreciated---Thanks,
Glenn



Hi,

In your case, the connection-strategy has nothing to do with your problem.
If the remote FTP server was unavailable for a few minutes, the
connection-strategy will force Mule to retry connections.  However, this is
not happening (according to your description), what is happening is that
some sort of internal thread (or threads) are being closed/terminated.
Since there is no reported fault in the communication with the FTP server,
the connection-strategy is not being used.

You are right in your understanding of the polling properties. I mistakenly
mis-read the config and thought that you set the property on the connector
and on the endpoints.

Can you post a full stack trace here? Perhaps there is some information that
will help your problem be diagnosed. What was the difference when you
changed the doThreading attribute?

Regards


Antoine Borg, Senior Consultant | Tel: +32 28 504 696
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: antoine.borg@ricston.com | blog: blog.ricston.com | web: ricston.com