[mule-user] SMTPSendFailedException (retry config not working in 2.0.x?)
richrem
I've been messing around (unsuccessfully) with setting up a
SimpleRetryConnectionStrategy for an SMTP connector. I've included an
example config that reads a message from STDIN, and attempts to send the
message via the SMTP connector. This config does not require any extra
classes - other than a straight mule installation. I've also included the
log (at debug level) for this example.
Environment:
- Mac OSX
- mule 2.0.3-SNAPSHOT (I read that this fixed something with default
exception strategies)
- Java 1.5.x
Included files:
- smtp-retry-config.xml --
http://www.nabble.com/file/p19374347/smtp-retry-config.xml
smtp-retry-config.xml
- smtp-retry-log.txt --
http://www.nabble.com/file/p19374347/smtp-retry-log.txt smtp-retry-log.txt
The first email is sent successfully. Then I wait (at least) 5 minutes,
enter a new message to try again, and get the following result:
=======
ERROR 2008-09-08 08:24:35,744 [SmtpConnector.dispatcher.2]
org.mule.DefaultExceptionStrategy: Caught exception in Exception Strategy:
[EOF]
com.sun.mail.smtp.SMTPSendFailedException: [EOF]
at
com.sun.mail.smtp.SMTPTransport.issueSendCommand(SMTPTransport.java:1388)
at com.sun.mail.smtp.SMTPTransport.mailFrom(SMTPTransport.java:959)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:583)
at
org.mule.transport.email.SmtpMessageDispatcher.sendMailMessage(SmtpMessageDispatcher.java:124)
at
org.mule.transport.email.SmtpMessageDispatcher.doDispatch(SmtpMessageDispatcher.java:95)
at
org.mule.transport.AbstractMessageDispatcher$Worker.run(AbstractMessageDispatcher.java:262)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:613)
=======
It "appears" that the SimpleRetryConnectionStrategy gets assigned to the
connector, but it does not work as it did in the 1.4.x mule where I could
set a createConnector property to "ALWAYS_CREATE". I'm not convinced the
retry strategy is being called -- or, it could be that a
DefaultExceptionStrategy is being set to override this.
Please let me know if this is related (or not) to the issue with setting
default connector and/or exception strategies or if I've not completely
configured the SimpleRetryConnectionStrategy correctly.
And, I'll create a JIRA if warranted and is not a duplicate of something
else.
Also, not the focus here, but when I ctrl-C to stop the mule instance, I get
the following, which indicates (to me) an improper shutdown of the SMTP
connector:
=====
DEBUG 2008-09-08 08:24:40,478 [WrapperListener_stop_runner]
org.mule.transport.email.SmtpMessageDispatcher: Disconnecting:
SmtpMessageDispatcher{this=3f704e, endpoint=smtp://:@192.168.9.16:25,
disposed=false}
WARN 2008-09-08 08:24:40,479 [WrapperListener_stop_runner]
org.mule.transport.email.SmtpMessageDispatcher: Can't send command to SMTP
host
javax.mail.MessagingException: Can't send command to SMTP host;
nested exception is:
java.net.SocketException: Broken pipe
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1420)
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1408)
at com.sun.mail.smtp.SMTPTransport.close(SMTPTransport.java:643)
at
org.mule.transport.email.SmtpMessageDispatcher.doDisconnect(SmtpMessageDispatcher.java:73)
at
org.mule.transport.AbstractConnectable.disconnect(AbstractConnectable.java:238)
at
org.mule.transport.AbstractConnectable.dispose(AbstractConnectable.java:141)
at
org.mule.transport.AbstractMessageDispatcherFactory.destroy(AbstractMessageDispatcherFactory.java:56)
...
=====
Thanks,
Rich
--
View this message in context: http://www.nabble.com/SMTPSendFailedException-%28retry-config-not-working-in-2.0.x-%29-tp19374347p19374347.html
Sent from the Mule - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Mike Cantrell
I'm troublshooting the exact same issue. Are you using Microsoft's SMTP by
chance? If so, the SMTP server is set to timeout inactive clients after 10
minutes (default setting). After the timeout period, you should see a
response sent to the client (using a packet capture):
SMTP Response: 451 Timeout waiting for client input
After this even occurs, any subsequent attempts to send mail will result in
the error you referenced. It appears that there is an attempt to account for
this in SmtpMessageDispatcher:
/*
* Double check that the transport is still connected as some SMTP
servers may
* disconnect idle connections.
*/
if (!transport.isConnected())
{
EndpointURI uri = endpoint.getEndpointURI();
if (logger.isInfoEnabled())
{
logger.info("Connection closed by remote server.
Reconnecting.");
}
transport.connect(uri.getHost(), uri.getPort(), uri.getUser(),
uri.getPassword());
}
Debugging this code shows that the transport still thinks that it is
connected. I'm not sure if there is a way to configure the connector to
force a disconnect after an idle period but that would be a decent fix. I'm
still not quite sure why the transport doesn't detect the disconnection.
--
View this message in context: http://www.nabble.com/SMTPSendFailedException-%28retry-config-not-working-in-2.0.x-%29-tp19374347p19380938.html
richrem
I will check on the brand of server, but it is likely Microsoft. The timeout
issue hits at 5 minutes for us. I can try another server brand (Linux) to
see if the same thing occurs. With your research, it may be there are
multiple issues at play: 1) the retry stuff won't stick, and 2) what you
point out below -- the transport thinks it's still connected when it isn't.
Mike Cantrell wrote:
>
> I'm troubleshooting the exact same issue. Are you using Microsoft's SMTP
> by chance?
> ...
>
> Debugging this code shows that the transport still thinks that it is
> connected. I'm not sure if there is a way to configure the connector to
> force a disconnect after an idle period but that would be a decent fix.
> I'm still not quite sure why the transport doesn't detect the
> disconnection.
>
--
View this message in context: http://www.nabble.com/SMTPSendFailedException-%28retry-config-not-working-in-2.0.x-%29-tp19374347p19381360.html
Mike Cantrell
I'm having a difficult time believing what I am seeing. If you look at
com.sun.mail.smtp.SMTPTransport.java (607), you'll see the following code:
// NOOP should return 250 on success, however, SIMS 3.2 returns
// 200, so we work around it.
//
// Hotmail doesn't implement the NOOP command at all so assume
// any kind of response means we're still connected.
// That is, any response except 421, which means the server
// is shutting down the connection.
//
if (resp >= 0 && resp != 421) {
return true;
} else {
try {
closeConnection();
} catch (MessagingException mex) { } // ignore it
return false;
}
I put a breakpoint in here and I see that the server response was 451 (same
as the timeout error I noticed in the packet capture). This is why the
transport is staying open in my case. I'm a bit baffled about how to fix it.
MS really should be returning back 421 but I have no idea why you'd want to
ignore the 451 code.
http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html
--
View this message in context: http://www.nabble.com/SMTPSendFailedException-%28retry-config-not-working-in-2.0.x-%29-tp19374347p19382179.html
richrem
Just for the curious:
The failing server is indeed Microsoft Exchange, version 2007. Using a
Linux based SMTP server, I was able to send a message after 5, 20, and 30
minutes of idle time. So, this does appear to be Microsoft server related.
richrem wrote:
>
> I will check on the brand of server, but it is likely Microsoft. The
> timeout issue hits at 5 minutes for us. I can try another server brand
> (Linux) to see if the same thing occurs.
> ...
>
--
View this message in context: http://www.nabble.com/SMTPSendFailedException-%28retry-config-not-working-in-2.0.x-%29-tp19374347p19382734.html
Mike Cantrell
http://blog.devnull.org/2008/09/11/javamail-and-exchange-woes/
Andrew Perepelytsya
Andrew