serious problemes with duplicated messages

Hi all,

I'm the Sysadmin of a small group of people. To create
eventes in the
Kolab server, which concern everybody, we created a shared
folder, on
which everybody has read and write access.

Recently we had the problem that there were suddenly a lot
of messages
duplicated. The messages have been duplicated so many times
that we
were unable to use the calendar!

They (the summary entry in the kolab.xml attachment) were
called "Copy
of: <summary>". I couldn't figure out completely
where this came from,
but I guess it's a problem with synchronizing with some
clients.

However I manually grepped for these msgs on the server and
removed
them. Now what I would like to know is why and how can this
happen and
what can I do that it doesn't happen again in the future.
Clients are
all now running Kubuntu Edgy, but before we also had clients
with
Dapper and older versions of Kubuntu.


Nils

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Hi Nils,

On Friday 17 November 2006 15:48, Nils wrote:
> I'm the Sysadmin of a small group of people. To create
eventes in the
> Kolab server, which concern everybody, we created a
shared folder, on
> which everybody has read and write access.
>
> Recently we had the problem that there were suddenly a
lot of messages
> duplicated. The messages have been duplicated so many
times that we
> were unable to use the calendar!
>
> They (the summary entry in the kolab.xml attachment)
were called "Copy
> of: <summary>". I couldn't figure out
completely where this came from,
> but I guess it's a problem with synchronizing with some
clients.
>
> However I manually grepped for these msgs on the server
and removed
> them. Now what I would like to know is why and how can
this happen and
> what can I do that it doesn't happen again in the
future. 

We have fixed a few issues which could lead to such a bad
situation
in the KDE Kolab Client, which is Kontact from the Proko2
branch.
Check the release notes of 2.1.5.
There is one potential corner case left:
kolab/issue1473 (conflict after moving day appointment)
Deadlock should not happen with 2.1.5 anymore.

> Clients are 
> all now running Kubuntu Edgy, but before we also had
clients with
> Dapper and older versions of Kubuntu.

The Proko2 branch is the conservative choice for production
systems.
We are forwardporting all fixes to KDE 3.5 
and are interested in bug reports for this as well,
so it is reasonable to use, but of course we do have less
control
there and what the distributions package. 

Best,
Bernhard
-- 
Managing Director - Owner, www.intevation.net       (Free
Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for
Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution,
Professional Service)
_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Thursday 23 November 2006 11:59, Bernhard Reiter wrote:
[...]
> We have fixed a few issues which could lead to such a
bad situation
> in the KDE Kolab Client, which is Kontact from the
Proko2 branch.
> Check the release notes of 2.1.5.
> There is one potential corner case left:
> kolab/issue1473 (conflict after moving day appointment)
> Deadlock should not happen with 2.1.5 anymore.

On the other hand, I ran into issue1498 and issue1505 with
2.1.5, both of 
which weren't reported to me by our users (nor had I seen
them myself) 
before. Unfortunately, both are quite difficult to
reproduce. :-(

> The Proko2 branch is the conservative choice for
production systems.
> We are forwardporting all fixes to KDE 3.5

But not all features, right? I tested a KDE 3.5.5 setup and
noticed that its 
Kontact does not seem to have the local subscription
feature, which allows to 
split accounts into DIMAP/IMAP, thus gaining a significant
performance 
advantage.

Cheerio,

Thomas

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Hi Bernhard, hi all,

Am Donnerstag, 23. November 2006 11:59 schrieb Bernhard
Reiter:
>> [Duplicate message bug]
>
> We have fixed a few issues which could lead to such a
bad situation
> in the KDE Kolab Client, which is Kontact from the
Proko2 branch.
> Check the release notes of 2.1.5.
> There is one potential corner case left:
> kolab/issue1473 (conflict after moving day appointment)
> Deadlock should not happen with 2.1.5 anymore.
>
> > Clients are
> > all now running Kubuntu Edgy, but before we also
had clients with
> > Dapper and older versions of Kubuntu.
>
> The Proko2 branch is the conservative choice for
production systems.
> We are forwardporting all fixes to KDE 3.5
> and are interested in bug reports for this as well,
> so it is reasonable to use, but of course we do have
less control
> there and what the distributions package.

We are using Fedora Core 6 here on client systems and the
KDE 3.5.5 that comes 
with Fedora. We also have issues with multiplying
appointments, so I would 
like to try the proko2 client. Is there a recommended easy
procedure for 
getting proko2 on FC6 without recompiling KDE?

regards,
Andreas Micklei

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Thursday 23 November 2006 14:32, Andreas Micklei wrote:
>  Is there a recommended easy procedure for
> getting proko2 on FC6 without recompiling KDE?

No, you probably need to compile an earlier KDE version (3.3
or 3.4).

-- 
Managing Director - Owner, www.intevation.net       (Free
Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for
Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution,
Professional Service)
_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Thursday 23 November 2006 12:19, ITSEF Admin wrote:
> > The Proko2 branch is the conservative choice for
production systems.
> > We are forwardporting all fixes to KDE 3.5
>
> But not all features, right? 

We do port all features as well, except the ones that KDE
developer
do not want in their because of architecture problems.
The only example I know of are the local distribution lists.

> I tested a KDE 3.5.5 setup and noticed that 
> its Kontact does not seem to have the local
subscription feature, which
> allows to split accounts into DIMAP/IMAP, thus gaining
a significant
> performance advantage.

Hmm I will ask Till about this, maybe this is the second
example.

-- 
Managing Director - Owner, www.intevation.net       (Free
Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for
Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution,
Professional Service)
_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Friday 24 November 2006 18:45, you wrote:
> On Thursday 23 November 2006 12:19, ITSEF Admin wrote:
> > > The Proko2 branch is the conservative choice
for production
> > > systems. We are forwardporting all fixes to
KDE 3.5
> >
> > But not all features, right?
>
> We do port all features as well, except the ones that
KDE developer
> do not want in their because of architecture problems.
> The only example I know of are the local distribution
lists.
>
> > I tested a KDE 3.5.5 setup and noticed that
> > its Kontact does not seem to have the local
subscription feature,
> > which allows to split accounts into DIMAP/IMAP,
thus gaining a
> > significant performance advantage.
>
> Hmm I will ask Till about this, maybe this is the
second example.

Correct. This feature (and other things, like quota support)
is slated 
for integration into the 3.5+ branch, which is the staging
area for 
kdepim 3.5, and then forward port to 4.0. In contrast to the
local 
distribution lists which cannot be merged because they break
the 
format, these features can be merged, during partial feature
freeze 
lifts of 3.5, and will be. 3.5 is not a development branch
and under 
stricter rules for what can go in and when, which is one
reason why 
features don't make it upstream directly. The other major
reason is 
workload, since these are not trivial merges and thus
require quite a 
bit of time to integrate.

-- 
Till Adam -- tillkdab.net, adamkde.org
Klarälvdalens Datakonsult AB, Platform-independent software
solutions
_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users