Javamail sometimes blocks during send, sendMessage or connect

[Mike Taylor]

Help!

I've got a javamail application which is delivering many messages to a
number of mailboxes - these are currently hosted on a Domino mailserver.

This mailserver is accepting connections on smtp (port 25), but
is not sending the SMTP protocol exchanges. Because of this, javamail just
blocks. I've tried the send(), sendMessage() and the Transport.connect()
methods, and they are all the same.

Most of the time, it works fine. The thing sends many thousands of
messages a day, but every now and then, the Domino mail server gets
stressed out, and whilst it listens on port 25, it doesn't send or respond
to SMTP protocol messages.

I can emulate this by writing a simple application which listens on port
25, accepts incoming connections, but does nothing else. If I get javamail
to connect to this emulator, it blocks - just as it would when connecting
to a heavily-loaded Domino server.

Any idea how I can abort the connection, or define a timeout, so the
connection is closed? Domino mailservers have a limited number of
connections, so leaving "dead" connections open is causing real problems.

Thanks in advance!

Mike Taylor.

 

[Gary M]

Any idea how I can abort the connection, or define a timeout, so the
connection is closed? Domino mailservers have a limited number of
connections, so leaving "dead" connections open is causing real
problems.

Mike you can implement the TransportListener interface and trap events
created during the message tranport process. Upon connection, spawn a
timeout thread and if the next event has not been received by the end of
the timeout, you can issue a SMTPTransport.close(). Note, I think this
requires you to instantiate the SMTPTransport class to get the close()
method.

 

[Mike Taylor]

Mike you can implement the TransportListener interface and trap events
created during the message tranport process. Upon connection, spawn a
timeout thread and if the next event has not been received by the end of
the timeout, you can issue a SMTPTransport.close(). Note, I think this
requires you to instantiate the SMTPTransport class to get the close()
method.

Gary, thanks for that - I had already implemented something similar where
another monitor thread was attempting to do the close() call, but it had
no effect on the underlying connection.

I've found the solution - and this is it:

props.put("mail.smtp.timeout","30000"); // 30 seconds protocol timeout

No doubt it would break on some very slow SMTP servers, but it works for
me!

Regards,

Mike.

 

[GaryM]

No doubt it would break on some very slow SMTP servers, but it
works for me!

Cool. I took a look at the source and the close connection does try to
issue a QUIT command to the server, before doing the socket close. Of
course with the timeouts at infinite and the server not responding it
never gets to the socket close. Now you have set that time out your
monitor thread will work. Irrelevant, I know .

Gary

 

[HLong]

On Tue, 07 Oct 2003 20:46:08 +0000, Gary M wrote:

>
> Mike you can implement the TransportListener interface and trap events
> created during the message tranport process. Upon connection, spawn a
> timeout thread and if the next event has not been received by the end of
> the timeout, you can issue a SMTPTransport.close(). Note, I think this
> requires you to instantiate the SMTPTransport class to get the close()
> method.

Gary, thanks for that - I had already implemented something similar where
another monitor thread was attempting to do the close() call, but it had
no effect on the underlying connection.

I've found the solution - and this is it:

props.put("mail.smtp.timeout","30000"); // 30 seconds protocol timeout

No doubt it would break on some very slow SMTP servers, but it works for
me!

Regards,

Mike.

Thanks, maybe I solved my problem