Test Case:
1. Create four Cosmo User Accounts
2. For each account upload / sync the Office Calendar via Chandler
3. After each upload run the Garbage Collector and take a memory usage snapshot

Memory usage after the first upload of the Office Calendar. The org.apache.derby.impl.store.raw.data.RecordId and the org.apache.derby.impl.store.raw.data.StoredRecordHeader as well as the org.apache.commons.collections.* and the java.util.HashMap have all grown in heap amount and number of instances.

Memory usage after the second upload of the Office Calendar. The number of org.apache.derby.impl.store.raw.data.StoredRecordHeader instances have doubled.

Memory usage after the third upload of the Office Calendar. The org.apache.derby.impl.store.raw.data.StoredRecordHeader continues to grow exponentially. The byte[] array heap amount and instances continue to grow as well.

Memory usage after the fourth and final upload of the Office Calendar. It appears that there is a memory leak related to the the org.apache.derby.impl.store.raw.data.RecordId and the org.apache.derby.impl.store.raw.data.StoredRecordHeader classes. The number of byte[] array instances has decreased but their heap amount continues to grow.

Looking at the org.apache.derby.impl.store.raw.data.RecordId shows that its classes hold 40,509 instances of org.apache.derby.impl.store.data.StoredRecordHeader.

Looking at the org.apache.derby.impl.store.raw.data.StoredRecordHeader shows that its classes have 94,780 instances of org.apache.derby.imple.store.raw.data.storedRecordHeader[]

The number of byte[] arrays have grown considerably. After four runs there are 5 times more instances taking up 44.82% of the heap.

Looking at what objects are using byte[] arrays reveals that the Derby database Input and Output streams are holding on to the instances.

Also of note is that Derby creates and manages 32 internal ClassLoaders. This number stayed consistent during the four Calendar uploads.

Also interesting was the 16,526 instances of String held by org.jackrabbit.name.Qname

A memory usage report after the four Calendar uploads reveals that there are 659 old collections managed by the Garbage Collector. Old collections are where the Garbage Collector sticks long lived object instances that still maintain references to other objects. It does so to make room in the nursery (young collections) for new object instances. A large number of old collections is a potential indicator of a memory leak.

Conclusion:
With each Calendar request the number of org.apache.derby.impl.store.raw.data.StoredRecordHeader objects doubles. This is troubling. It does seem that there is a memory leak related to the Derby database. Although the database itself may not be the culprit. It may be that either Cosmo or Jackrabbit is not closing / releasing Derby connections. If the connections are not released object references still remain and the Garbage Collector will not reclaim that memory.