The connection is NOT dropped after keepAliveTimeout

[wintergow]

Questions

We are facing the issue that our SMTP server drop the connection if the connection elapsed time more than 10 minute no matter the connection is idle or busy. I have checked keepAliveTimeout to be 300 sec by default. But it seems it cannot be killed after 300 sec sometime then it has been dropped by the SMTP server when sending the email.

Version

4.5.7

Context

To simulate the issue, I have set the config as below:
maxPoolSize = 1
keepAlive = true
keepAliveTimeout = 300
keepAliveTimeoutUnit = TimeUnit.SECONDS
poolCleanerPeriod = 1000
poolCleanerPeriodUnit = TimeUnit.MILLISECONDS
Change the log level to TRACE
Chang the maximum connection time to 30 minute in SMTP server.

09:39:37: 1st email send request is triggered. Then the connection is recycled with the log: "TRACE i.vertx.ext.mail.iml.SMTPConnection -recycle for next use"
09:40:38: 2nd email send request is triggered. Then the connection is recycled with the log: "TRACE i.vertx.ext.mail.iml.SMTPConnection -recycle for next use"
09:53:23: 3rd email send request is triggered. Then the connection is recycled with the log: "TRACE i.vertx.ext.mail.iml.SMTPConnection -recycle for next use"
09:55:06: 4th email send request is triggered. Then the connection is recycled with the log: "TRACE i.vertx.ext.mail.iml.SMTPConnection -recycle for next use"
10:00:07: The connection is dropped with the log: "DEBUG i.vertx.ext.mail.impl.SMTPConnection - QUIT"

You can see the connection is not dropped between 09:40:38 and 09:53:23. But the connection is dropped 5 min after 4th email request sent.

It seems the keepAliveTimeout is NOT always working.

Do you have a reproducer?

No

[gaol]

@wintergow From the logs I see:

• The connection got dropped after 5 minutes after the 4th mail, so it is expected behavior.
• The connection did not get dropped after 2nd mail, before 3rd mail, which is the suspicions here, one possibility is that the sending of the 2nd email takes long time somehow(big email body, high network latency, etc). During the data transmit, the connection is out of the pool and is active, so we don't close it.