[Dbmail-dev] (no subject)
Aaron Stone writes: An interesting front end is SQL Relay, http://firstworks.com/ My thinking on the database redundancy issue is a compromise with the full-failover and the write-master+read-slaves ideas; There's a main server with read/write (the master) and a slave with read only. Geesh why everyone want to stop one of the servers from operating in normal mode to a read-only mode. I personally cant accept the fact however, i`m working further on this issue, for now i have a simple algorithm which solves the issue with the unique ids, negotiates the backend grouping and makes it more generic in its structure, since obviously this can't be done on the db layer thanks to the primitive[1] replication in mysql which doesnt do any merging(not any of i`m aware of) and is quite scared when it meets few ids with the same values that it makes it stop the whole replication process, which IMHO is absolutely unacceptable. The problems in PgSQL are a bit different since it doesnt have native replication ready for productional use, but it`s in development, and it`s doing quite well according to my research. Now we have an issue which is obviously called 'data sharing' since there is _a_ difference between clustering db servers and having a backup in any way or redundancy (that was the idea from the begining). If we`re doing clustering the issue is not only one but it will create more sub-issues on its layer. The term redundacy is quite different, the simplest one is 'if server1 is down server2 will take over and continue the operations without a downtime', and personally that`s quite enuf for me, since there wont be any downtime. But if we add more servers we need more sofisticated and complex approach than the first one, we need consistency, the consistency itself is so vast in terms of communication and data share[2], since we`re aware of what might and might not happen, but assuming that something is, is not the right way of creating something generic and therefor portable, because simply the false postivives on the network are growing, more members, more participants..etc. What i want to say, is something that`ve already said - It`s a dbmail's problem, because we cannot force the db devels to get to the place where we want, and since that wont be in the nearest months or whatever bit of time, i prefer solving the problem on dbmail layer. The primary and secondary MX idea is a very good one, and when the primary goes down, the secondary will receive the mail but not be allowed to insert it. Incoming messages will queue up between postfix and dbmail (must be tuned not to attempt immediate retries, though) and once the master is alive, will be delivered. In the mean time, everyone can still read their mail from the slave (but no flagging, deleting or moving). That was my idea in the begining but i want both of my databases to be able to share and therefor modify the data whenever they want in way that wont cause any collisions. However we are in power to minimize the possibility of any collisions and i suppose that`s the first thing we should do before everything failes. Somehow I personally dont accept downtime vs wrongly inserted message[2]. I`m happy with Jose`s example about the whole stuff, but he`s taking it too far in the future, because that is the first step we take on this road, and that`s not the last, since it will evolve in something more sofisticated in aspect of consistency, redundancy and in general distributed systems, grids, blahblah. [1] primitive in terms of no grouping. no failover. no decent multimaster replication nor any advanced data merging abilities. [2] client1 gets client2 message, obviously there is a workaround since we can control how the message is inserted and where is inserted.. that`s not an issue in my design though, nor the random subscribers we might get in Jose`s example. I`ll continue to work on it, if anyone in any way is interested, ask. cheers, -lou On Thu, 27 Mar 2003, Roel Rozendaal - IC&S wrote: Hi lou, The problem here is that the database consistency is not guaranteed - the databases are not synchronized so behaviour seems pretty undefined when for example the imap daemon connects to another database in the mid of a session. The unique-id's and message_idnr's are no longer unique nor will the message_idnr guarantee the correct order of delivery; some messages/folders will suddenly be no longer available when a system fails and some others again will no longer be available as the first system is up again. We are still looking for some good replication funcionality but it seems that the logics for such failover system should be a database issue and not a dbmail one - the ultimate system would allow dbmail to connect to some front-end (preferrably local so network failure is shielded from dbmail) SQL interface which would implement all the failover functionality we desire: different groups of re
[Dbmail-dev] (no subject)
Hi, Here's an update to the LMTP server and sorting framework. There's a pretty significant rewrite of the delivery chain included in here. Not all of it works, but there's enough good material that I want this to be out there and just let everyone know I'm still working on it :-) The sorting routines themselves are not included, btw... just enough framework that adding them should be quite simple and will not require deep hacks into the database layer or anything else besides writing one function to the spec laid out in sorting.c and uncommenting one line. I'm 99% tracking CVS; hopefully this will patch cleanly, but let me know if otherwise! Test it out and enjoy! Aaron dbmail-lmtpd-sorting-alpha2.patch.gz Description: This patch adds an LMTP server and the framework for sorting facilities.
[Dbmail-dev] (no subject)
Current svn build problems... minor fixes.. Without sieve enabled there is
a missing ifdef and the Return-Path argument is of the wrong type...
diff -urN dbmail-svn-2.1.3-1987.orig/lmtp.c dbmail-svn-2.1.3-1987/lmtp.c
--- dbmail-svn-2.1.3-1987.orig/lmtp.c 2006-02-17 17:23:43.0 -0500
+++ dbmail-svn-2.1.3-1987/lmtp.c2006-02-17 17:44:23.244784376 -0500
@@ -616,7 +616,7 @@
return 1;
}
- dbmail_message_set_header(msg,
"Return-Path", from->data);
+ dbmail_message_set_header(msg,
"Return-Path", (char *)(dm_list_getstart(&from)->data));
if (insert_messages(msg,
&headerfields, &rcpt) == -1) {
ci_write((FILE *) stream,
"503 Message not
received\r\n");
} else {
diff -urN dbmail-svn-2.1.3-1987.orig/sort.c dbmail-svn-2.1.3-1987/sort.c
--- dbmail-svn-2.1.3-1987.orig/sort.c 2006-02-17 17:41:10.323157000 -0500
+++ dbmail-svn-2.1.3-1987/sort.c2006-02-17 17:41:45.705486863 -0500
@@ -42,6 +42,7 @@
}
}
+#ifdef SIEVE
/* Sieve. */
config_get_value("SIEVE", "DELIVERY", val);
if (strcasecmp(val, "yes") == 0) {
@@ -52,6 +53,7 @@
sort_free_result(sort_result);
}
}
+#endif
/* Sieve actions:
* (m = must implement, s = should implement, e = extension)
Thanks,
Leif
p.s. Aaron & Paul I am excited to see all the great changes going into
svn! Thanks for all your time and efforts!
[Dbmail-dev] (no subject)
>From d10673a9dcfd66414e20bfc678b45408c926034a Mon Sep 17 00:00:00 2001 In-Reply-To: <<[EMAIL PROTECTED]>> References: <<[EMAIL PROTECTED]>> From: Paul J Stevens <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 09:20:19 +0200 Subject: bail out after too many uncaught socket errors --- dbmail-imapsession.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dbmail-imapsession.c b/dbmail-imapsession.c index 3d818a5..ee650df 100644 --- a/dbmail-imapsession.c +++ b/dbmail-imapsession.c @@ -1308,6 +1308,7 @@ int dbmail_imap_session_printf(struct ImapSession * self, char * message, ...) int maxlen=100; int result = 0; gchar *ln; + static int errcount = 0; assert(message); @@ -1341,8 +1342,11 @@ int dbmail_imap_session_printf(struct ImapSession * self, char * message, ...) g_free(re); g_free(ln); TRACE(TRACE_ERROR, "write to client socket failed"); + if (errcount++ > 1) + TRACE(TRACE_FATAL,"uncaught error on socket, exiting"); return -2; } + errcount = 0; if (result < maxlen) TRACE(TRACE_DEBUG,"RESPONSE: [%s]", re); -- 1.5.1.1 ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
[Dbmail-dev] (no subject)
>From d10673a9dcfd66414e20bfc678b45408c926034a Mon Sep 17 00:00:00 2001 In-Reply-To: <<[EMAIL PROTECTED]>> References: <<[EMAIL PROTECTED]>> From: Paul J Stevens <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 09:20:19 +0200 Subject: bail out after too many uncaught socket errors --- dbmail-imapsession.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dbmail-imapsession.c b/dbmail-imapsession.c index 3d818a5..ee650df 100644 --- a/dbmail-imapsession.c +++ b/dbmail-imapsession.c @@ -1308,6 +1308,7 @@ int dbmail_imap_session_printf(struct ImapSession * self, char * message, ...) int maxlen=100; int result = 0; gchar *ln; + static int errcount = 0; assert(message); @@ -1341,8 +1342,11 @@ int dbmail_imap_session_printf(struct ImapSession * self, char * message, ...) g_free(re); g_free(ln); TRACE(TRACE_ERROR, "write to client socket failed"); + if (errcount++ > 1) + TRACE(TRACE_FATAL,"uncaught error on socket, exiting"); return -2; } + errcount = 0; if (result < maxlen) TRACE(TRACE_DEBUG,"RESPONSE: [%s]", re); -- 1.5.1.1 ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] (no subject)
I think the errcount should be kept in struct ImapSesssion, and a clean shutdown of the sockets and freeing of the session should follow. FATAL is pretty darn severe... I'm doing a cleanup of the timeout code right now, because it turns out that lmtp, pop3 and sieved all segfault on timeouts. Bug #517. Aaron On Fri, Apr 27, 2007, Paul J Stevens <[EMAIL PROTECTED]> said: >>From d10673a9dcfd66414e20bfc678b45408c926034a Mon Sep 17 00:00:00 2001 > In-Reply-To: <<[EMAIL PROTECTED]>> > References: <<[EMAIL PROTECTED]>> > From: Paul J Stevens <[EMAIL PROTECTED]> > Date: Fri, 27 Apr 2007 09:20:19 +0200 > Subject: bail out after too many uncaught socket errors > > --- > dbmail-imapsession.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/dbmail-imapsession.c b/dbmail-imapsession.c > index 3d818a5..ee650df 100644 > --- a/dbmail-imapsession.c > +++ b/dbmail-imapsession.c > @@ -1308,6 +1308,7 @@ int dbmail_imap_session_printf(struct ImapSession * > self, char * message, ...) > int maxlen=100; > int result = 0; > gchar *ln; > + static int errcount = 0; > > assert(message); > > @@ -1341,8 +1342,11 @@ int dbmail_imap_session_printf(struct ImapSession * > self, char * message, ...) > g_free(re); > g_free(ln); > TRACE(TRACE_ERROR, "write to client socket failed"); > + if (errcount++ > 1) > + TRACE(TRACE_FATAL,"uncaught error on socket, exiting"); > return -2; > } > + errcount = 0; > > if (result < maxlen) > TRACE(TRACE_DEBUG,"RESPONSE: [%s]", re); > -- > 1.5.1.1 > > ___ > 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
Sorry Subject Current svn build problems, minor patch Re: [Dbmail-dev] (no subject)
On Fri, February 17, 2006 5:35 pm, Leif Jackson wrote:
> Current svn build problems... minor fixes.. Without sieve enabled there
> is a missing ifdef and the Return-Path argument is of the wrong type...
>
> diff -urN dbmail-svn-2.1.3-1987.orig/lmtp.c dbmail-svn-2.1.3-1987/lmtp.c
> --- dbmail-svn-2.1.3-1987.orig/lmtp.c 2006-02-17 17:23:43.0
> -0500
> +++ dbmail-svn-2.1.3-1987/lmtp.c2006-02-17 17:44:23.244784376
> -0500
> @@ -616,7 +616,7 @@
> return 1; }
>
>
> - dbmail_message_set_header(msg,
> "Return-Path", from->data);
> + dbmail_message_set_header(msg,
> "Return-Path", (char *)(dm_list_getstart(&from)->data));
> if (insert_messages(msg, &headerfields, &rcpt) == -1) {
> ci_write((FILE *) stream, "503 Message not
> received\r\n"); } else {
> diff -urN dbmail-svn-2.1.3-1987.orig/sort.c dbmail-svn-2.1.3-1987/sort.c
> --- dbmail-svn-2.1.3-1987.orig/sort.c 2006-02-17 17:41:10.323157000
> -0500
> +++ dbmail-svn-2.1.3-1987/sort.c2006-02-17 17:41:45.705486863
> -0500
> @@ -42,6 +42,7 @@
> }
> }
>
>
> +#ifdef SIEVE
> /* Sieve. */
> config_get_value("SIEVE", "DELIVERY", val); if (strcasecmp(val, "yes") ==
> 0) {
> @@ -52,6 +53,7 @@
> sort_free_result(sort_result); }
> }
> +#endif
>
>
> /* Sieve actions:
> * (m = must implement, s = should implement, e = extension)
>
>
>
> Thanks,
> Leif
>
>
> p.s. Aaron & Paul I am excited to see all the great changes going into
> svn! Thanks for all your time and efforts!
>
> ___
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>
