You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Oki DZ <ok...@pindad.com> on 2001/08/21 05:02:36 UTC

RemoteDelivery and db repositories

Hi,

I took the following from the RemoteDelivery mailet.

public void run():
while (!Thread.currentThread().interrupted()) {
            try {
                String key = outgoing.accept(delayTime);
                log(Thread.currentThread().getName() + " will process mail
" + key);
                MailImpl mail = outgoing.retrieve(key);
                if (deliver(mail, session)) {
                    //Message was successfully delivered/fully failed...
delete it
                    outgoing.remove(key);
                } else {
                    //Something happened that will delay delivery.  Store
any updates
                    outgoing.store(mail);
                }

I was wondering what actions should be taken if the db connection was not
available during the retrieve(), deliver(), remove() or store() method
invocation. I think the exception handled by the run() method should be
more than just Exception, but something more precise like SQLException or
"no more db connection from the connection pool" exception.

I think the db connections should be regarded as limited resources, where
you couldn't expect that they would be available all the time. Problems
may arise in a situation where you have successfully send a message out,
but when you are going to remove the message from the spool, the
connection is gone. What are you going to do with the message? The message
could get resent, or if you didn't remove the lock, the message would stay
in the database. If it is in the database (in outgoing spool) and James
gets restarted, the message will be resent also.

It would be nice if James has a "supervisor" thread that watches the
availability of the resources. The thread may suspend or stop some of the
remote delivery threads when the number of db connection has reached a
maximum amount. It could also suspend all James threads when the db
connection is completely not available (say, somebody pull out the UTP
connectors) or simply when the db server is shutdown (currently, I have
to manually to shutdown James when doing some maintenance on the db
server; because I don't know what's going to happen if James didn't get
shutdown when no db connection available).

Oki
 




---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org