Massive loss of events in enterprise35 client

[Bernhard Reiter]

On Donnerstag, 15. Januar 2009, ITSEF Admin wrote:
> On Wednesday 14 January 2009 18:32:48 Bernhard Reiter wrote:
> > On Mittwoch, 14. Januar 2009, ITSEF Admin wrote:
> > > - $HOME is on NFS
> >
> > Your analysis should try to exclude this as a cause.
> > Put the cache on a local disc if you can for this.
>
> Would migrating to NFSv4 suffice? 

No, as far as I can say. I suggest you put a few people on a local store 
for this analytic step to be completed. Also you could check your NFS 
performance and logs for general problems.

> BTW: The local cache did *not* help with proko2 - despite having the cache
> on the local hard drive (which causes all sorts of adminstrative
> headaches), we've seen spontaneous and large scale data losses in all DIMAP
> accounts (groupware and mail) every now and then.

I only have one clearly reported case of this with proko2 (over several years 
of usage). I do not quite remember, did you use the Debian packages build 
from KK? 

Note that with the fix of kolab/issue3196 (large number of appointments can 
lead to corrupt index and loss of events) we found a potential source of this
problem in all Kontact Kolab clients (proko2, enterprise35 and enterprise4).
We are very appy to frame any other issue that might remain, but again
with our experience proko2 has been very stable from that respect.
Enterprise35 is also running very nice since about 9 month.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20090116/c8cf43c2/attachment.sig>