Daniel Donnelly's response is pretty close on to what's happening, and I
have a workaround (very poor workaround, but one none the less) to assist
for the time being. Let me see if I can go farther:
>Without seeing exactly what POP3/IMAP4 commands you
>(or your 'looped query') are issuing, I cannot say exactly what
>you are doing and if that is 'correct'.
Briefly: running Cold Fusion middleware, standard CFLOOP with proper
transaction code, error catching, and query locking. If I trust the code -
having gone over it a LOT does not mean it's trustworthy :) - It should be
completing all actions on it's end, waiting for completion before running
the next iteration of the loop.
Running a third-party (non-Cold Fusion) java-mail code to replace CF's CFPOP
command (highly flaky and processor intensive).
>However, if one disconnects incorrectly (just aborting the connection)
>IMail will see that as a bad POP3 session and will _not_ perform the 'DELE
>1' operation,
This is what I assume happens, but with the following observation: the "will
_not_ perform" occurs after several interactions of the loop (which I've had
to break down to run 35 every five minutes to slow down the corruption) -
say iteration 8 through to 35 of the thirty-five. What this leads me to
believe that there is - for lack of knowing how to phrase this - something
slow in the DELE function on the Imail side - or something takes a long time
to close - and it allows the loop to issue a new RETR command, creating for
Imail and improper disconnect (or something similar).
Running one query a minute over the mail (I have the folder backed up and
have been running the queries against the EXACT SAME emails) - will cause
none of the "Missing Message #1" - problems to occur.
There just seems (and again, I can easily be wrong) to be something that
isn't moving quickly on the Imail side to keep the process in time to the
requests. Is there a timing issue of some sort that we are not aware of?
So, yup - I'm connecting with another POP3 session when the code I'm running
has completed the transaction, and gone back again for more! ("Please sir,
can I have some more?").
If I have to give Imail time to complete the process - exactly how much time
is that (milliseconds, seconds, etc.)? Does anyone know?
>So, I suspect you are not disconnecting correctly or
>connecting multiple times to the mailbox,
>with your 'looped query' and 'causing' the problem.
Connecting multiple times. But I loop because:
I'm pulling emails into a database. I want to make sure I grab each and
every email - so I go grab one at a time. I don't want a case where I delete
message ID #1, which shifts all other message ID's down one, so by deleting
Message ID #2 I'm actually deleting Message ID #3, and Message #2 has become
#1 - and has been missed.
>So the mailbox is not really corrupt,
Well, I called it corrupt because by deleting them main.uid file - the
system is forced to re-index and recognize the deletion. Now, with the scale
of the project - this becomes very cumbersome to code into the system.
Managing one email account works, but hundreds or thousands? Right now -
based on the information I get from GetAll, message one - if it's corrupt I
catch the error, delete the .uid and continue on in the loop. That does
correct the situation.
But cumbersome, messy, and - well - a performance issue that would be best
addressed at the Imail level, not through middleware.
>Also, if you used a 'DELE 2' command, instead of 'DELE 1', you probably
>would find that you never have problems with message 1.
Ha ha ha ha hah aha. ROTFL. I HAVE done that. And all I get is "no such
message" error created after a while for message 2. Indeed, I tried looping
that on error I would ignore all messages up to that error. So, slowly I
grew from no errors, to message 1, to message 1 &2, to, well, I went up to
message 1 though 4 before I pulled the plug.
Mr. Donnelly, thank you for your response - I think it's highly accurate as
to what and why things are happening - I just don't know of a good solution
(as in one I would trust under enterprise level abuse). I don't believe
catching the error and deleting the .uid to be a good solution. There has to
be a solution closer to the source, and that means something with the Imail
engine. (I think!).
Stephen R. Cassady
President, Ububik new media
[EMAIL PROTECTED]
http://www.ububik.com
403.271.0468
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
