Noel J. Bergman wrote:
If we set this to null, then the timeouts are infinite, which I don't think we want... I think if we try to deliver to a server that's too slow (doesn't respond to IO for 20 minutes), we want to disconnect and let that thread try to deliver someplace else.Seems to me that it makes sense to have defaults (NULL to not set the value) for each property, and configuration entries to override.
This might also explain why I see the # of active delivery threads go down over time... some socket gets corrupt and Java doesn't get a solid timeout/close, and that thread is stuck. I think you ALWAYS should have some timeout for a server app if you're tying resources to it.
I think this changes behavior, and the implication is not really tested. In theory this is a great improvement I'd like us to make, but for the 2.1.1 pending, I wouldn't include this. Most of our test structures can't really check this, so I think we'd need to release this into alpha use for a while and get feedback before committing to it in a release.With respect to "mail.smtp.sendpartial", I think that it is important to use it. See the API docs: "If set to true, and a message has some valid and some invalid addresses, send the message anyway, reporting the partial failure with a SendFailedException. If set to false (the default), the message is not sent to any of the recipients if there is an invalid recipient address." RemoteDelivery already has the code for handling the SendFamiledException, and processing the getValidSentAddresses list. But, again, this can be a configuration setting. I just think that it should probably be true in most cases.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
