Hi again,
What is the reasoning behind assigning a random number to new messages such
that the latter would come and disrupt the sequence (but not the ordering)
of existing emails?
It seems more intuitive to me to add new messages at the end of a list -
even though the POP3 protocol does not apparently require it.
I guess that Cyrus is adding new msgs at the end of the list thus explaining
our inability to reproduce the problem there then.
After looking at the UIDL listing for a James mailbox before and after
inserting new emails, I realized that the messages actually preserve their
_ordering_ across sessions but new messages will come and offset parts of
the existing list at different random points.
The UIDL responses below show how two new messages disrupted the _sequence_
but NOT the _ordering_.
_BEFORE_NEW_MESSAGES_ _AFTER_NEW_MESSAGES_
# UID # UID
(Prev #)
1 Mail1145932157811-2379 1 Mail1145987288808-2619 <<-- (NEW)
2 Mail1145932156155-2367 2 Mail1145932157811-2379 <<-- (1)
3 Mail1145932175686-2489 3 Mail1145932156155-2367 <<-- (2)
4 Mail1145932065343-2273 4 Mail1145932175686-2489 <<-- (3)
5 Mail1145932158077-2381 5 Mail1145932065343-2273 <<-- (4)
6 Mail1145932149920-2323 6 Mail1145932158077-2381 <<-- (5)
7 Mail1145932167420-2445 7 Mail1145932149920-2323 <<-- (6)
8 Mail1145932165405-2431 8 Mail1145987289230-2623 <<-- (NEW)
9 Mail1145932172389-2469 9 Mail1145932167420-2445 <<-- (7)
10 Mail1145932169483-2459 10 Mail1145932165405-2431 <<-- (8)
11 Mail1145932163514-2417 11 Mail1145932172389-2469 <<-- (9)
12 Mail1145932160795-2401 12 Mail1145932169483-2459 <<-- (10)
13 Mail1145932175530-2487 13 Mail1145932163514-2417 <<-- (11)
14 Mail1145932160795-2401 <<--
(12)
15 Mail1145932175530-2487 <<--
(13)
Any thoughts or clarifications?
I have some apprehensions due to James behaving in such an 'odd way' - which
I hope you can help to rationalize.
Cheers,
Al.
> -----Original Message-----
> From: Al Caponi [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 25, 2006 11:52 AM
> To: 'James Users List'
> Subject: RE: Wrong email deleted with concurrent delete and
> receive operations
>
> From today's test - Chilkat sent the DELE commands without
> any UIDL within a
> totally new session.
> So this is not accurate as there is no guarantee of the
> msg_num (the param
> passed to DELE) for a message to remain the same across
> different sessions.
> And this would be the reason for the deletion operations
> possibly going
> haywire, specially when new messages are coming in concurrently.
>
> Log command extracts for one of the messages downloaded by Chilkat -
> (UIDL,RETR) and (DELE) cmds are in different sessions:
> -----------------------------------------------------
> 25/04/06 10:29:43 DEBUG pop3sserver: [default Worker #19]
> Command received:
> USER chilkat
> 25/04/06 10:29:43 DEBUG pop3sserver: [default Worker #19]
> Command received:
> PASS <password omitted>
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #19]
> Command received:
> STAT
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #19]
> Command received:
> UIDL
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #19]
> Command received:
> RETR 27
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #19]
> Command received:
> QUIT
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #15]
> Command received:
> USER chilkat
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #15]
> Command received:
> PASS <password omitted>
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #15]
> Command received:
> STAT
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #15]
> Command received:
> DELE 27
> 25/04/06 10:29:44 DEBUG pop3sserver: [default Worker #15]
> Command received:
> QUIT
> -----------------------------------------------------
>
> Log command extracts from a JavaMail test client - all
> operations are done
> within the same session:
> -----------------------------------------------------
> 24/04/06 21:10:45 DEBUG pop3server: [default Worker #13]
> Command received:
> USER javaclient
> 24/04/06 21:10:45 DEBUG pop3server: [default Worker #13]
> Command received:
> PASS <password omitted>
> 24/04/06 21:10:45 DEBUG pop3server: [default Worker #13]
> Command received:
> STAT
> 24/04/06 21:10:45 DEBUG pop3server: [default Worker #13]
> Command received:
> NOOP
> 24/04/06 21:10:45 DEBUG pop3server: [default Worker #13]
> Command received:
> UIDL 1
> 24/04/06 21:10:45 DEBUG pop3server: [default Worker #13]
> Command received:
> TOP 1 0
> 24/04/06 21:10:45 DEBUG pop3server: [default Worker #13]
> Command received:
> RETR 1
> ...
> 24/04/06 21:10:51 DEBUG pop3server: [default Worker #13]
> Command received:
> DELE 1
> ...
> 24/04/06 21:10:51 DEBUG pop3server: [default Worker #13]
> Command received:
> QUIT
> -----------------------------------------------------
>
>
> Also, I omitted to reply about DELE9 without DELE2-7. You
> might have figured
> out that we were doing selective 'download and delete'. That
> would explain
> the non-consecutive msg nums.
>
> I'll leave the JIRA alone for the time being as it's not an issue with
> James.
>
> Thanks for the help.
> Cheers,
> Al.
>
> > -----Original Message-----
> > From: Al Caponi [mailto:[EMAIL PROTECTED]
> > Sent: Monday, April 24, 2006 8:34 PM
> > To: 'James Users List'
> > Subject: RE: Wrong email deleted with concurrent delete and
> > receive operations
> >
> >
> > > >
> > > > 2. "DELE 1" commands
> > > > As for the 'DELE 1' cmds being from different connections,
> > > I can't confirm
> > > > that as I didn't log the thread name.
> > > > I'll need some time to re-simulate that as the client code
> > > has changed.
> > >
> > > What about the DELE9 with no previous DELE2-7 ?
> > >
> > > Are the connections made concurrently?
> > >
> > > James does not lock the pop3 inbox, so multiple concurrent
> > > connections
> > > for the same user may ends to unknown behaviours.
> > >
> > > You said that you have 100 messages and you start reading them.
> > > Then you send to the same inbox more messages.
> > >
> > > If the client close and reopen connections then it will
> see the new
> > > messages too.
> > >
> >
> > > No one ensure that the messages in pop3 are shown in
> arrival order.
> > >
> >
> > Each 'download and delete' was made sequentially from a
> > single client. The
> > latter does the following:
> > 1. Start a session.
> > 2. Grab the list of messages in the inbox.
> > 3. For each message on that list,
> > i. Scan header for some proprietary meta-info to
> > determine if
> > download is required.
> > ii. Download the message and then issue the deleteByUIDL
> > command.
> >
> > We're processing all the messages in a single thread but we
> > don't know yet
> > whether Chilkat handles each download and/or delete with a
> > new session or
> > not.
> > We'll run the original code and add the thread name logging
> > in James. Until
> > the Chilkat folks get back to us, that'll be the only
> > guideline that we
> > have.
> > Will keep you updated.
> >
>
> Send instant messages to your online friends
> http://asia.messenger.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
Send instant messages to your online friends http://asia.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
