All,
I number of issues have been reported during the past few days when
sharing and synching calendars on the Cosmo Demo server. This email
is an attempt to summarize the issues, what we know so far and what
is being done to fix them. We are aware that these problems are
preventing some people from dogfooding the application effectively.
Currently an event is stored on the server in 2 parts, an XML piece
and an ics piece. Something is happening to cause the XML portion to
be written to the server correctly but the ics portion fails. This
creates a somewhat half-baked event that generates weird errors for
the publishers that write these events to the server and for other
subscribers whom are synching and getting these changes.
There are a few ways this situation could happen.
1. We can run into a network error or cancel during a synch operation.
2. The VOBJECT fails to generate an ics file (Chandler issue)
3. We have a valid ics file but for some reason Cosmo cannot write
this to the server.
After much research on the part of Morgen, Jeffrey and Brian Moseley
we have identified that case #3 is indeed happening. Cases #1 is
possible and #2 happens sometimes but may be related to #3. We have
determined that the ical4j library that Cosmo uses to parse iCalendar
is not translating some events correctly that have timezone
information in a particular format. This has something to do with the
way timezone information is stored in iCalendar format. According to
the RFC, the format is valid but when we import these events into
Chandler then export of share to the server, Cosmo can't translate
the ics information.
The fix for #3 is to upgrade the ical4j library on Cosmo to the next
version. Apparently the next version handles timezones different and
this will not be a problem. Brian Moseley has done this and we are
now in the process of getting a build to Aparna for QA. Once
validated, we will have Jared update Cosmo 0.2.2 onto the Cosmo Demo
server. We expect to log the ticket for Jared to update Cosmo Demo
early tomorrow...maybe this evening.
PLEASE NOTE: We will be creating a new instance on Cosmo Demo for
0.2.2. therefore you will have to republish your calendars onto the
server again.
Morgen has also added a fix for Chandler that causes these 1/2 baked
events to be skipped when we encounter them when synching. This
partially handles unexpected cases like #1. This means that if I
publish an event that ends up in this 1/2 state any client that
synchs with this calendar will not see this particular event. We
realize this creates inconsistencies but felt it was necessary to
handle this as best as we could. Our goal was to at least prevent
other sharers from synching with these corrupted events.
In addition to all this, we have experienced a Cosmo "out of memory"
that we haven't tracked down yet. We are working on getting the
proper tools to analyze the code. We also encountered a scaling
problem where Cosmo would only write so many files then stop.
Apparently jackrabbit was hitting the operating system's limits on
the number of child files/directories within a parent directory. We
would end up in a situation where we had to wipe all the data. Brian
M implemented a fix last week which is part of Cosmo 0.2.2.
Let me know if you have any questions. Brian M, Morgen, Jeffrey -
feel free to add any additional details you think are missing.
Sheila
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
