[Kolab-devel] [issue1335] pfbcache.db locking problems

Pieter Vanmeerbeek kolab-issues at intevation.de
Mon Jul 31 12:23:06 CEST 2006


New submission from Pieter Vanmeerbeek <pieter.vanmeerbeek at able.be>:

For every incoming mail in postfix 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. Doing this for 15 simultaneous mails 
(ie.e one appointment with 15 reousrces) causes a db lockup resulting in lost
meeting request. 
So I created an ugly hack to more or less solve this (please find it attached):
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 daemon (including queueing 
mechanisme) in php (see code below). However as this is an TCP based socket 
you need to create the proper syntax for an smtp  connection in 
this daemon to correctly receive the mail from postfix. 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 (although it will not solve the locking problem, but just
boost performance) 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 


server script  :
-------------
<?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);

----------
files: patch
messages: 8056
nosy: pieter.vanmeerbeek
status: unread
title: pfbcache.db locking problems
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue1335>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 4277 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060731/4da0c8f5/attachment.obj>


More information about the devel mailing list