camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: POP3 mail deletion
Date Fri, 06 May 2011 01:53:02 GMT
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 <dwhytock@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.ibsen@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 <dwhytock@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: cibsen@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/
>>> 
>> 


Mime
View raw message