[Dev] Cosmo/Chandler sharing errors

Sheila Mooney sheila at osafoundation.org
Mon Nov 7 17:26:46 PST 2005


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



More information about the Dev mailing list