Hi Donald, Looks like this requires some work in the mail component. I created an issue for this: https://issues.apache.org/jira/browse/CAMEL-3948
I tentatively scheduled it for 2.8.0. There is a good number of issues fixed in 2.8.0 though and I suspect we're gonna start closing down for a release soon. Cheers, Hadrian On May 5, 2011, at 8:48 PM, Donald Whytock wrote: > 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/ >>> >>
