[Kolab-devel] pfbcache.db locking problems

[Pieter Vanmeerbeek]

Hi,

No I didn't since nobody replied on this and I lost track of it .

I created a temporary fix in my installation. The problem is the setup in
postfix : 

For every incoming mail a new pipe to an php environment is created (see
master.conf). However postfix can receive upto 100 simultaneous connections.
This means worst case scenario is 100 php envorinments all trying to read/
write to the pfbcache.db database. DSOing this for 15 simultaneous mails
(ie.e one appointment with 15 reousrces) already causes a db lockup
resulting in lost meeting request.

So I created an ugly hack to more or less solver this : retry a number of
times whenever a read/write to the database is done and a failure is
received.


A better solution would be to create a php server daemon which is always
running. You can very easily create a socket daomeon (including queueing
mechanisme) in php (see code below). However as this is an TCP based socket
you probably need to create the proper syntax for an smtp  connection in
this daemon to correctly receive the mail from postfix. Perhaps this is not
needed with a unix socket type? Perhaps someone can  complete the daemon
script? Code needs to be added to receive the full message from postfix +
passing it to the already existing kolabmailboxfilter.php script.


This way only  one meeting request will  be handled at a time . Code below
supports a queue for 10 other requests being delayed until the previous one
is finished.


Another optimalisation would be to only redirect messages with meeting
requests in it to the daemon. As I understand it a Content type of
text/calendar is always present in a meeting request. You could use the
postfix body or header check to match on this  and overrule the default
content_filter to the the new php serverdaemon. Or another option could be
to set the mailbox_transport to cyrus and use mailbox_transport_maps to
overrule this for all users/resources with automatic meeting requesting.


I think this proposed solution will make kolab  more performing + will solve
the db locking issues





<?php
set_time_limit(0);

$addr = "127.0.01";
$port = 5000;

$sock = socket_create(AF_INET, SOCK_STREAM, 0);
if($sock < 0)
   die(socket_strerror(socket_last_error));

if(($ret = socket_set_option($sock, SOL_SOCKET, SO_REUSEADDR< 1))<0)
   print strerror($ret);

if(($ret =socket_bind($sock, $addr, $port)) < 0)
   die(socket_strerror(socket_last_error));

if(($ret = socket_listen($sock, 10)) < 0)
   die(socket_strerror(socket_last_error));

while (($csock = accept_connect($sock)) >= 0){
   // .. manipulate $csock here.

	socket_close($csock);
}

close ($sock);

?>



-----Original Message-----
From: Martin Konold [mailto:martin.konold at erfrakon.de] 
Sent: zondag 30 juli 2006 17:38
To: kolab-devel at kolab.org
Cc: Pieter Vanmeerbeek; kolab-users at kolab.org
Subject: Re: [Kolab-devel] pfbcache.db locking problems

Am Dienstag, 23. Mai 2006 17:19 schrieb Pieter Vanmeerbeek:

Hi Pieter,

> file. If you create an appointment with > 14 resources, all set with
> declines if conflicts, you can simulate it easily.

Did you file an issue in our bugtracker?

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker


--
---------------------------------------------------
Able: 1996-2006: already 10 safe years in YOUR company!

aXs GUARD has completed security and anti-virus checks on this e-mail (http://www.axsguard.com)
---------------------------------------------------
Able NV: ond.nr 0457.938.087
RPR Mechelen