> The remote delivery could use more smarts by grouping messages into the
> different hostname buckets, so it knows the 3 messages going to
> yahoo.com accounts, and work through those buckets one by one, rather
> than the current message-based (so host-agnostic) ordering. That's more
> work and requires some refactoring to that spool implementation.
From what I can see sendmail caches open connections to hosts, keeping them open for a
short time so that any subsequent messages to the same host can be delivered on the
existing open connection.
From what I can see this would require us to cache "Transport"s in RemoteDelivery,
test with Transport.isConnected() and only connect if the answer is no. Unless
JavaMail is already only creating single Transports for each URLName, in which case
the conditional connect/close would help.
I can see that it would also help if we could get messages by hostname, when we would
then be able to guarentee useing a single session for all mail to a single host, but
this would require, as you say, overhaul of the spool interface.
On the other hand if we could somehow make Mail a ConnectionListener on the relevant
Transport then we could use an event driven remote delivery which would work, perhaps,
by adding mail to the transport as a listener, we'd then open the transport when we
know mail is waiting for that host, at which point all the mail which was listening
would know, and send itself. We could listen to the transport for the results of the
send and take action based upon the transport events raised this way. Just a thought.
d.
