[Kolab-devel] event triggered freebusy data generation
Matt Moldvan
matt at moldvan.com
Fri Feb 28 19:26:04 CET 2014
It is definitely rough, not only against the mailbox servers but also
against the LDAP environment, as each has to authenticate that way first.
One other issue I had was the fact that the ifb files are stored on each
individual application server. Because we have 5 RoundCube servers, it's
tough to run 5 instances of that freebusy cron job, each hitting the
mailbox servers. At some point, I guess, we'll have to dedicate a server
or multiple behind a load balancer for free/busy generation. Having one
server run the cron job and rsync over just seems too easy to break...
Maybe through the use of a default sieve script or something like inotify
watching the directories might work... a little hackish of course until
someone comes up with a proper solution, but it could work.
On Fri, Feb 28, 2014 at 4:21 AM, hede <kolab983 at der-he.de> wrote:
> Am Thu, 27 Feb 2014 08:52:50 -0500 schrieb Matt Moldvan <matt at moldvan.com
> >:
>
> > We've had nothing but trouble with free/busy to the point we had to
> disable
> > it (we are still running Kolab 2.3 ish). 65,000+ users now and it kills
> > the load all of our mailbox servers when it was running through a cron
> > job...
>
> That's hardly surprising, AFAIK freebusyd has to read every single
> calendaring event of every single user on every single run. So reading
> 65000*x files every few minutes from imap store...
>
> I can see there's some work done for an event triggered system. But AFAICS
> this will be implemented by using some web service in parallel to the imap
> service. The client has to manually set the free/busy-entries? I think this
> goes into the wrong direction. It's clearly foreseeable to result in
> inconsistencies between imap- and free/busy-Datastores if both use
> different ways to the storage pool.
>
> I would prefer a solution where the imap daemon itself triggers an event
> with every new upload to a folder with type "calendar". This solution would
> be independent from any client-support. Even deleting events with some pure
> email-only-client would be fine.
>
> Does cyrus support triggering some executable (e.g. a script) when pushing
> a message to an imap folder?
>
> regards
> hede
> _______________________________________________
> devel mailing list
> devel at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/devel
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20140228/e4deb3d0/attachment.html>
More information about the devel
mailing list