>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]
