Hello,
Ok, I'm working on changing everything to #defines for status
value, and as the local college doesn't offer "Stupid C coders 101,"
can anyone tell me why this (from db_update_pop(), and don't think
correctness of the query, I'm just trying to get snprintf to work):
snprintf (query,DEF_QUERYSIZE,
"UPDATE messages set status=%d WHERE message_idnr=%llu AND status<%d",
((struct message *)tmpelement->data)->virtual_messagestatus,
((struct message *)tmpelement->data)->realmessageid,
STATUS_DELETE
);
Creates the following query:
[UPDATE messages set status=1 WHERE message_idnr=398383986507776 AND status<0]
Whild this, in the exact same place, for the exact same
user/message# in pop3:
snprintf (query,DEF_QUERYSIZE,
"UPDATE messages set status=%d WHERE message_idnr=%llu AND status>%d",
STATUS_DELETE,
((struct message *)tmpelement->data)->realmessageid,
((struct message *)tmpelement->data)->virtual_messagestatus
);
Creates this query:
[UPDATE messages set status=2 WHERE message_idnr=92756 AND status>1]
In the second query, all format args are read correctly - in the
first query, virtual_messagestatus is (ie. it is 1), but realmessageid
is wrong and the last arg is alway read as a 0, no matter what it is
(hard coded number, variable, or #define). This is in dbmysql.c, on
a debian stable box.
Thanks,
Jesse
---- Original Message ----
From: Aaron Stone <dbmail-dev@dbmail.org>
To: dbmail-dev@dbmail.org
Subject: RE: [Dbmail-dev] message status 4
Sent: Wed, 18 Jun 2003 12:27:45 -0700 (PDT)
Actually, if you take a look at my lmtp/sorting patch, I split off a
couple of these shared functions into smaller files, including
create_unique_id(). I hope that Roel can review and comment on that patch
soon (hint hint ;-) because I think it sets the code in the right
direction for enhancing the delivery pipeline.
You do seem to be correct that the status field isn't being used
consistently, and what's worse, there are "magic numbers" scattered
throughout the code. These should all be changed to defined values,
such as...
#define STATUS_ACTIVE 0
#define STATUS_INSERT 5
#define STATUS_DELETE 2
#define STATUS_EXPUNGE 3
Aaron
On Wed, 18 Jun 2003, Jesse Norell wrote:
>
> Hello,
>
> Back to work, after a few days recovering from a
> little trencher incident...
>
> As for the idea presented here, using a status id for
> "not yet complete" messages - the pop3 server does this
> already, using status 5, but imap does not - it instead
> uses an empty unique_id (ie. '') to handle the same thing,
> from what I've seen. I don't see any problems (eg. pop3
> session disreguards messages with unique_id=''), but it
> would be a bit more efficient and less confusing to be
> consistent in what a partially inserted message looks like.
>
> I plan on making a small util.c with a create_unique_id
> function, as it needs to be included in more than just
> dbmail-smtp. Seems overkill to have a dedicated file, and
> there's no such "misc. utility functions" file yet, so...
>
>
>
> ---- Original Message ----
> From: Jesse Norell <dbmail-dev@dbmail.org>
> To: dbmail-dev@dbmail.org
> Subject: [Dbmail-dev] message status 4
> Sent: Tue, 10 Jun 2003 09:07:06 -0600 (MDT)
>
> >
> > Hello,
> >
> > In implimenting a unique_id fix, in several issues in the past, and
> > in message insertion in general, it seems appropriate to have a
> > message status that basically just means 'not yet processed/complete,'
> > for which I propose using message status = 4 (which isn't used
> > anywhere, right?). I believe all the existing code should handle
> > that without change (ie. if status is 4, it won't show in any
> > mailboxes, get cleaned by maintenance, etc.), so there should be no
> > migration problems unless someone uses status 4 locally (which a
> > trivial db update can fix).
> >
> > This would make things like the "message inserted, but not yet
> > filtered" race condition Aaron was going to have to address a while
> > back easy - just insert all messages with status = 4, do whatever
> > processing, and update to 2 when the message is fully processed.
> > It would fix a race condition in the current insertion code where a
> > message actually changes unique_id and another where the messages
> > table entry exists, but messageblk entries do not yet (ie. if
> > messages entry was inserted, then a user checks POP3 before
> > messageblk is inserted, it'll hang OE waiting for data, till a
> > timeout period, then error).
> >
> > Sound good / any objections (particularly from IC&S)?
> >
> > Jesse
> >
> >
> > --
> > Jesse Norell
> > jesse (at) kci.net
> >
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
> -- End Original Message --
>
>
> --
> Jesse Norell
> jesse (at) kci.net
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
-- End Original Message --
--
Jesse Norell
jesse (at) kci.net
Ok, I'm working on changing everything to #defines for status
value, and as the local college doesn't offer "Stupid C coders 101,"
can anyone tell me why this (from db_update_pop(), and don't think
correctness of the query, I'm just trying to get snprintf to work):
snprintf (query,DEF_QUERYSIZE,
"UPDATE messages set status=%d WHERE message_idnr=%llu AND status<%d",
((struct message *)tmpelement->data)->virtual_messagestatus,
((struct message *)tmpelement->data)->realmessageid,
STATUS_DELETE
);
Creates the following query:
[UPDATE messages set status=1 WHERE message_idnr=398383986507776 AND status<0]
Whild this, in the exact same place, for the exact same
user/message# in pop3:
snprintf (query,DEF_QUERYSIZE,
"UPDATE messages set status=%d WHERE message_idnr=%llu AND status>%d",
STATUS_DELETE,
((struct message *)tmpelement->data)->realmessageid,
((struct message *)tmpelement->data)->virtual_messagestatus
);
Creates this query:
[UPDATE messages set status=2 WHERE message_idnr=92756 AND status>1]
In the second query, all format args are read correctly - in the
first query, virtual_messagestatus is (ie. it is 1), but realmessageid
is wrong and the last arg is alway read as a 0, no matter what it is
(hard coded number, variable, or #define). This is in dbmysql.c, on
a debian stable box.
Thanks,
Jesse
---- Original Message ----
From: Aaron Stone <dbmail-dev@dbmail.org>
To: dbmail-dev@dbmail.org
Subject: RE: [Dbmail-dev] message status 4
Sent: Wed, 18 Jun 2003 12:27:45 -0700 (PDT)
Actually, if you take a look at my lmtp/sorting patch, I split off a
couple of these shared functions into smaller files, including
create_unique_id(). I hope that Roel can review and comment on that patch
soon (hint hint ;-) because I think it sets the code in the right
direction for enhancing the delivery pipeline.
You do seem to be correct that the status field isn't being used
consistently, and what's worse, there are "magic numbers" scattered
throughout the code. These should all be changed to defined values,
such as...
#define STATUS_ACTIVE 0
#define STATUS_INSERT 5
#define STATUS_DELETE 2
#define STATUS_EXPUNGE 3
Aaron
On Wed, 18 Jun 2003, Jesse Norell wrote:
>
> Hello,
>
> Back to work, after a few days recovering from a
> little trencher incident...
>
> As for the idea presented here, using a status id for
> "not yet complete" messages - the pop3 server does this
> already, using status 5, but imap does not - it instead
> uses an empty unique_id (ie. '') to handle the same thing,
> from what I've seen. I don't see any problems (eg. pop3
> session disreguards messages with unique_id=''), but it
> would be a bit more efficient and less confusing to be
> consistent in what a partially inserted message looks like.
>
> I plan on making a small util.c with a create_unique_id
> function, as it needs to be included in more than just
> dbmail-smtp. Seems overkill to have a dedicated file, and
> there's no such "misc. utility functions" file yet, so...
>
>
>
> ---- Original Message ----
> From: Jesse Norell <dbmail-dev@dbmail.org>
> To: dbmail-dev@dbmail.org
> Subject: [Dbmail-dev] message status 4
> Sent: Tue, 10 Jun 2003 09:07:06 -0600 (MDT)
>
> >
> > Hello,
> >
> > In implimenting a unique_id fix, in several issues in the past, and
> > in message insertion in general, it seems appropriate to have a
> > message status that basically just means 'not yet processed/complete,'
> > for which I propose using message status = 4 (which isn't used
> > anywhere, right?). I believe all the existing code should handle
> > that without change (ie. if status is 4, it won't show in any
> > mailboxes, get cleaned by maintenance, etc.), so there should be no
> > migration problems unless someone uses status 4 locally (which a
> > trivial db update can fix).
> >
> > This would make things like the "message inserted, but not yet
> > filtered" race condition Aaron was going to have to address a while
> > back easy - just insert all messages with status = 4, do whatever
> > processing, and update to 2 when the message is fully processed.
> > It would fix a race condition in the current insertion code where a
> > message actually changes unique_id and another where the messages
> > table entry exists, but messageblk entries do not yet (ie. if
> > messages entry was inserted, then a user checks POP3 before
> > messageblk is inserted, it'll hang OE waiting for data, till a
> > timeout period, then error).
> >
> > Sound good / any objections (particularly from IC&S)?
> >
> > Jesse
> >
> >
> > --
> > Jesse Norell
> > jesse (at) kci.net
> >
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
> -- End Original Message --
>
>
> --
> Jesse Norell
> jesse (at) kci.net
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
-- End Original Message --
--
Jesse Norell
jesse (at) kci.net