I've got an application that I wrote a while ago now that is starting to 
have some issues I need to look into.

Basically, this application contains a process that regularly polls for 
emails (every 5 minutes) and gathers any available, stripping off up to 
60 jpg attachements and processes them. (emails are from CCTV cameras)

The email server is on a network, and not connected via the 'net, 
although the connection does go through a megastream link, which is 
starting to become a little erratic, which I think is the cause of these 

Normally, the application works fine, collects emails, logs everything 
then sleeps until the next cycle and carries on 24/7

However, I think that occasionally, during the email collection routine, 
the megastream link goes down briefly causing the routine to fail. At 
this point, I log a fail, but then I cannot reconnect to the email 
server again until I restart the application.

So, all I can imagine is that I am not doing the right thing when an 
error occurs in the email retrieve routines.

In my "co_Pop3ClientRequestDone" routine, I have 2 error 
handling/logging parts. The first being:
if(Error) // Error is passed to ClientRequestDone event
        co_LogReport->Lines->Add(DateTimeToStr(Now( )) + "  Email check 
failed (" + IntToStr(RqType) + "/" + IntToStr(Error) + ")");
        at_EmailError = true;
        co_Pop3Client->Abort( );

The second being:

        default: // Handle unknown request and close
            co_LogReport->Lines->Add(DateTimeToStr(Now( )) + "  Email 
check failed (" + IntToStr(RqType) + "/" + IntToStr(Error) + ")");
            me_Exec(co_Pop3Client->Quit, "Quit");

Now, the first uses Abort and this may not be the right way to close the 
connection down, but I didn't want to create an infiniate loop where a 
Quit command called this routine with and error and then everything 
falls over.

What is the 'right' way to close the connection down in such a way that 
the next attempt will be a 'clean' one? I presume I haven't closed 
everything down properly which is causing be to fail on the next connection.

At the moment, unfortunately, this software is 'on-site' and not in a 
good position to test/debug so I would like to be confident that any 
changes will be in the right direction.


To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to