I think I've isolated the problem. Someone better-versed in Camel guts please advise?
I tested with a standalone program using the JavaMail library, and found that if you close a POP3 folder and open it again the DELETED flag doesn't work. I think this is because messages are identified by relative sequence numbers in the POP3 folder, so when the folder is re-opened it gets a whole new message index and forgets about any extraneous message objects. Therefore, even though the message object points to the folder, the folder no longer recognizes the message object. In the JavaMail code, messages are deleted when a folder is about to be closed. The code cycles through the folder's messages and any with the DELETED flag are deleted. So since the folder no longer sees the obsolete message object it doesn't see the message's DELETED flag. The Camel MailConsumer opens a folder, gets all the messages, cycles through the messages processing them one at a time as exchanges, and then closes the folder. I'm guessing -- someone please verify? -- that if a message goes from one route to another -- say, a SEDA queue -- it's considered "processed" as far as MailConsumer is concerned, since addOnCompletion has been called and the SEDA route is just as capable of calling the Synchronization as the MailConsumer. Arkadi was right...the messages cease to be handled right when they hit a SEDA queue, or probably any other secondary route. But they're handled properly as long as they stay in the original email-consuming route. There's a possible workaround. POP3 has a UID mechanism, though messages can't be referenced by the UID directly. If the UID is fetched when the message is first read, then when it comes time to set flags on the message its UID could be compared to the UIDs in the current incarnation of the folder, and the flags set on the folder message. I think IMAP has something similar. So this would be something to add to MailMessage() and MailConsumer.processCommit(). Alternately, or perhaps along with, should there be an option to simply delete the messages when read? Risky, but some users may think it's acceptable. On Thu, May 5, 2011 at 10:10 AM, Donald Whytock <dwhyt...@gmail.com> wrote: > I will, yes, but correcting that in my copy didn't seem to fix the > problem. I'll do a little more research and testing, try to get it > working and submit a patch. > > On Thu, May 5, 2011 at 9:20 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> Hi >> >> >> >> http://javamail.kenai.com/nonav/javadocs/com/sun/mail/pop3/package-summary.html >> >> Seems like we should only set the reset when we do NOT want to delete >> the mails with POP3. >> eg so if delete=true, we do not set this option. >> >> >> I think the reset is a bug. Do you mind creating a ticket? >> >> >> >> On Wed, May 4, 2011 at 5:29 PM, Donald Whytock <dwhyt...@gmail.com> wrote: >>> A design question regarding the mail component... >>> >>> When I tried using the mail component with POP3, I had a problem with >>> deleting messages. Depending on the server I was talking to, I had >>> either inconsistent and sporadic success, or consistent lack of >>> success. >>> >>> I think I see what might be the problem. JavaMail recognizes a >>> property called mail.pop3.rsetbeforequit, which, if true, sends a RSET >>> command to the POP3 server just before disconnecting. The RSET >>> command is effectively a global undelete for the session. >>> >>> By default, this is set to true in MailConfiguration in the mail >>> component. I'm inclined to make this dependent on the delete field; >>> this would mean setting the delete field in the URI would result in >>> any and all message deletes done during the session being >>> automatically resolved. >>> >>> My experience with POP3 and Camel mail handling is limited. Is there >>> a reason not to do this? >>> >>> Don >>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: cib...@fusesource.com >> Web: http://fusesource.com >> CamelOne 2011: http://fusesource.com/camelone2011/ >> Twitter: davsclaus >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> >
