Mule FTP polling dies silently

[Glenn Murray]

Hi,

I am using Mule 1.4.3 running in Tomcat 5.5 to poll several FTP
servers.  After some hours (12-30) of inactivity, Mule will stop
polling one or more of them, but not always the same ones.  For
example my log (catalina_2008-08-25.log) will have

26248:DEBUG 2008-08-25 15:50:42,485 [org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.6]
: >>> retrieving client for ftp://anonymous:mule@ftpServer1/
26249:DEBUG 2008-08-25 15:50:42,485 [org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.6]
: === get pool for ftp://anonymous:mule@ftpServer1/
26250:DEBUG 2008-08-25 15:50:42,485 [org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.5]
: >>> retrieving client for ftp://anonymous:mule@ftpServer2/
26251:DEBUG 2008-08-25 15:50:42,485 [org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.5]
: === get pool for ftp://anonymous:mule@ftpServer2/

and then ftpServer2 will disappear from the logs and files on that
server will not be polled, though the other servers continue to be
polled.  

Remark 1: It may be useful to know that "receiver.5" does not reappear
in catalina_2008-08-25.log, or catalina_2008-08-26.log, either.

Remark 2: I am able to manually put and get files to the unpolled machine.

My config has this:

  <mule-environment-properties>
    <connection-strategy
      className="org.mule.providers.SimpleRetryConnectionStrategy">
      <properties>
        <property name="retryCount" value="-1" /> <!-- Retry forever: -1. -->
        <property name="frequency" value="600000" />
        <property name="doThreading" value="true" />
      </properties>
    </connection-strategy>
  </mule-environment-properties>

and the endpoints look like

      <inbound-router>
        <endpoint address="ftp://anonymous:mule@ftpServer1/">
          <filter pattern="*.zip"
            className="org.mule.providers.file.filters.FilenameWildcardFilter"/>
          <properties>
            <property name="pollingFrequency" value="60000"/>
            <property name="passive" value="false"/>
            <property name="outputPattern" value="${ORIGINALNAME}"/>
          </properties>
        </endpoint>

        <endpoint address="ftp://anonymous:mule@ftpServer2/">
          <filter pattern="*.zip"
            className="org.mule.providers.file.filters.FilenameWildcardFilter"/>
          <properties>
            <property name="pollingFrequency" value="60000"/>
            <property name="passive" value="false"/>
            <property name="outputPattern" value="${ORIGINALNAME}"/>
          </properties>
        </endpoint>
        ...

Any help would be appreciated, thanks.

Glenn

[antoine.borg]

Hi,

Not sure if this will help but ...

If receiver.5 (or any other receiver) does not re-appear in the logs, I
would suspect a threading issue as this suggests that a thread is
lost/closed/disappears.  My first suggestion would be to change that
doThreading attribute. One reason for using it is to allow Mule to start
even if the connector hasn't which may not be a problem in your situation
(is it?).

Also, why do you set the polling frequency on both the connector and the
endpoint?

Regards


Antoine Borg, Senior Consultant | Tel: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: antoine.borg@... | blog: blog.ricston.com | web: ricston.com

-----Original Message-----
From: Glenn Murray [mailto:gmurray@...]
Sent: Tuesday, August 26, 2008 10:18 PM
To: user@...
Subject: [mule-user] Mule FTP polling dies silently


Hi,

I am using Mule 1.4.3 running in Tomcat 5.5 to poll several FTP servers.
After some hours (12-30) of inactivity, Mule will stop polling one or more
of them, but not always the same ones.  For example my log
(catalina_2008-08-25.log) will have

26248:DEBUG 2008-08-25 15:50:42,485
[org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.6]
: >>> retrieving client for ftp://anonymous:mule@ftpServer1/ 26249:DEBUG
2008-08-25 15:50:42,485
[org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.6]
: === get pool for ftp://anonymous:mule@ftpServer1/ 26250:DEBUG 2008-08-25
15:50:42,485
[org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.5]
: >>> retrieving client for ftp://anonymous:mule@ftpServer2/ 26251:DEBUG
2008-08-25 15:50:42,485
[org.mule.providers.ftp.FtpConnector.connector.ftp.0.receiver.5]
: === get pool for ftp://anonymous:mule@ftpServer2/

and then ftpServer2 will disappear from the logs and files on that server
will not be polled, though the other servers continue to be polled.  

Remark 1: It may be useful to know that "receiver.5" does not reappear in
catalina_2008-08-25.log, or catalina_2008-08-26.log, either.

Remark 2: I am able to manually put and get files to the unpolled machine.

My config has this:

  <mule-environment-properties>
    <connection-strategy
      className="org.mule.providers.SimpleRetryConnectionStrategy">
      <properties>
        <property name="retryCount" value="-1" /> <!-- Retry forever: -1.
-->
        <property name="frequency" value="600000" />
        <property name="doThreading" value="true" />
      </properties>
    </connection-strategy>
  </mule-environment-properties>

and the endpoints look like

      <inbound-router>
        <endpoint address="ftp://anonymous:mule@ftpServer1/">
          <filter pattern="*.zip"
           
className="org.mule.providers.file.filters.FilenameWildcardFilter"/>
          <properties>
            <property name="pollingFrequency" value="60000"/>
            <property name="passive" value="false"/>
            <property name="outputPattern" value="${ORIGINALNAME}"/>
          </properties>
        </endpoint>

        <endpoint address="ftp://anonymous:mule@ftpServer2/">
          <filter pattern="*.zip"
           
className="org.mule.providers.file.filters.FilenameWildcardFilter"/>
          <properties>
            <property name="pollingFrequency" value="60000"/>
            <property name="passive" value="false"/>
            <property name="outputPattern" value="${ORIGINALNAME}"/>
          </properties>
        </endpoint>
        ...

Any help would be appreciated, thanks.

Glenn


--
View this message in context:
http://www.nabble.com/Mule-FTP-polling-dies-silently-tp19169571p19169571.htm
l
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Glenn Murray]

Hi,

Thanks for the reply.  It is important that the application start and continue running even if some
of the FTP endpoints fail.  My understanding is that the connection-strategy I am using will
allow that---if I am incorrect, please let me know!  

It is also my understanding that I am not "polling twice", but that I am retrying failed connections
every 600000ms (10min) and polling every 60000ms (1min).  Again, please correct me if I am wrong.

Thanks again,
Glenn

antoine.borg wrote:

Hi,

Not sure if this will help but ...

If receiver.5 (or any other receiver) does not re-appear in the logs, I
would suspect a threading issue as this suggests that a thread is
lost/closed/disappears.  My first suggestion would be to change that
doThreading attribute. One reason for using it is to allow Mule to start
even if the connector hasn't which may not be a problem in your situation
(is it?).

Also, why do you set the polling frequency on both the connector and the
endpoint?

Regards


Antoine Borg, Senior Consultant | Tel: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: [e-mail] | blog: blog.ricston.com | web: ricston.com

[antoine.borg]

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: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: antoine.borg@... | blog: blog.ricston.com | web: ricston.com

-----Original Message-----
From: Glenn Murray [mailto:gmurray@...]
Sent: Friday, August 29, 2008 7:15 AM
To: user@...
Subject: RE: [mule-user] Mule FTP polling dies silently


Hi,

Thanks for the reply.  It is important that the application start and
continue running even if some of the FTP endpoints fail.  My understanding
is that the connection-strategy I am using will allow that---if I am
incorrect, please let me know!  

It is also my understanding that I am not "polling twice", but that I am
retrying failed connections every 600000ms (10min) and polling every 60000ms
(1min).  Again, please correct me if I am wrong.

Thanks again,
Glenn



antoine.borg wrote:

>
> Hi,
>
> Not sure if this will help but ...
>
> If receiver.5 (or any other receiver) does not re-appear in the logs,
> I would suspect a threading issue as this suggests that a thread is
> lost/closed/disappears.  My first suggestion would be to change that
> doThreading attribute. One reason for using it is to allow Mule to
> start even if the connector hasn't which may not be a problem in your
> situation (is it?).
>
> Also, why do you set the polling frequency on both the connector and
> the endpoint?
>
> Regards
>
>
> Antoine Borg, Senior Consultant | Tel: [phone] ricston Ltd., BP
> 2, 1180 Uccle, Brussels, BELGIUM
> email: antoine.borg@... | blog: blog.ricston.com | web:
> ricston.com
>
>
>

--
View this message in context:
http://www.nabble.com/Mule-FTP-polling-dies-silently-tp19169571p19213789.htm
l
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Glenn Murray]

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: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: [e-mail] | blog: blog.ricston.com | web: ricston.com

[antoine.borg]

Hi there,

Your original message mentioned Mule 1.4.3 - can you upgrade to 1.4.4 at the
least (changing to 2.x may require some config re-writing that you may not
want to do) and see if your problem is resolved.  I've seen similar posts on
the user list for other transports and the latest 2.1.1 release seems to
have solved a number of them but I'm not sure about FTP.

A


Antoine Borg, Senior Consultant | Tel: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: antoine.borg@... | blog: blog.ricston.com | web: ricston.com

-----Original Message-----
From: Glenn Murray [mailto:gmurray@...]
Sent: Tuesday, November 25, 2008 8:31 PM
To: user@...
Subject: RE: [mule-user] 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: [phone] ricston Ltd., BP 2,
1180 Uccle, Brussels, BELGIUM
email: antoine.borg@... | blog: blog.ricston.com | web: ricston.com



--
View this message in context:
http://www.nabble.com/Mule-FTP-polling-dies-silently-tp19169571p20688071.htm
l
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Glenn Murray]

Hi,

Actually I upgraded to 1.4.4 shortly after the first message, but there was
no change in behavior.  Without any error messages from Mule it's hard
to figure out.  I'm thinking it might be some subtle Vmware/Ubuntu6.06/Tomcat
issue.  I expect to move to a newer Ubuntu soon, perhaps I can rewrite my
config and move to Mule 2.x then. For now I think I'll have to get by with the
occasional restarting.

Thanks,
Glenn

antoine.borg wrote:

Hi there,

Your original message mentioned Mule 1.4.3 - can you upgrade to 1.4.4 at the
least (changing to 2.x may require some config re-writing that you may not
want to do) and see if your problem is resolved.  I've seen similar posts on
the user list for other transports and the latest 2.1.1 release seems to
have solved a number of them but I'm not sure about FTP.

A

Antoine Borg, Senior Consultant | Tel: [phone]
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: [e-mail] | blog: blog.ricston.com | web: ricston.com

[Ove Gram Nipen]

On Mon, 2008-12-01 at 14:22 -0800, Glenn Murray wrote:
> I expect to move to a newer Ubuntu soon, perhaps I can rewrite my
> config and move to Mule 2.x then. For now I think I'll have to get by with
> the occasional restarting.

There are serious issues with the FTP connector in Mule 2.x that haven't
been resolved yet. See http://mule.mulesource.org/jira/browse/MULE-3192

--
Best regards,
Ove Gram Nipen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email