Java Mail api, connection gets lost during message process

Question

In our java mail (using Java Mail API) application we first connect to the mail server, fetch messages, process headers and then afterwards process the message bodies and attachments using pop3 as usual.

Session session = Session.getInstance(props, null);
Store store = session.getStore(urln);
store.connect();
Folder f = store.getFolder("INBOX");
f.open(READ);
Messages m = f.getMessages(..);
for (Message m : messages) {
    if (!store.isConnected()) {
        //raise exception
    }
    processSubject();

    processFrom();

    processBodyAndAttachments();

    ..
}

The implementation works fine on most environments, but on some customer the storeconnection gets lost during the process in the for loop. We can see the raises exception in the logs. My questions:

• AFAIK, the mail server can sometimes reject new connections, but does it terminate current living connections (may be becasue of too much connections or disconnects old ones to give access to the new ones?)

• When the store is disconnected, does the folder gets closed too?

• Is it better to check the folder?

• The connection may be lost everywhere in the for loop and it does not seem to be a good practise to put isConnected check everywhere in the loop, it will make the code dirty and also cause performance issues, is it a good practise to put in a try catch block and check for IOExceptions? (Folder closed) Or other suggestions? Which exceptions should be handled? There may be some cases where the message is not parseable but connection is healthy.

• What about adding a disconnect listener?

Answer 1

• Network connections can be broken for a variety of reasons. Your program always has to be prepared for the connection to drop at any time.
• With POP3, there is only one connection, so if the connection is dropped the store should be disconnected and the folder should be closed.
• If the Folder is open, check the Folder. Otherwise check the Store.
• You need a strategy for handling failures. If you keep track of what messages have been successfully processed you may be able to restart the processing at the next message after a failure. A lot of the details depend on your environment and your application requirements.
• A disconnect listener won't make this easier.