On 01/27/2011 07:26 AM, Vincent Massol wrote: > Hi Caleb, > > Thanks for the detailed information. > > So if my count is ok there's work left for a minimum of 21 men/days to finish > it. We have 6 days till 3.0M2, 10 more for RC1 and 10 more for final, so a > total of 26 days. > > However if we want to include it in 3.0 final (and we do want this since it's > in our roadmap :)), I suggest that you'd need to have something usable (with > known issues/limitations) in XE 3.0M2, planned for the 7th of February 2011. > Is that doable on your side? The idea is to let users start using it and > provide feedback and find potential issues which we could fix in 3.0 RC1 and > RC2.
I could shift my attention back to FilesystemAttachmentStore and FilesystemAttachmentVersioningStore so that people can use the code and avoid memory exhaustion by disabling the attachment recycle bin (which is not currently available the user interface IIRC). Locking is the only part which critically needs attention for that path. WDYT? > > I'm also +1 to move your work in platform ASAP (you need to start an official > vote for this in a separate thread). Could you explain where it would go? > Would you suggest to have it all go in platform/core/xwiki-store module? Does > it have deps on the old xwiki-core? Yes, platform/core/xwiki-store module is the path I have so far taken. xwiki-store/xwiki-store-filesystem-attachments depends on the old core. xwiki-store/xwiki-store-filesystem, xwiki-store/xwiki-store-serialization, xwiki-store/xwiki-store-transaction and xwiki-store-api do not. > > Thanks > -Vincent > > On Jan 26, 2011, at 6:59 PM, Caleb James DeLisle wrote: > >> Hello, >> Here's an update on the current state of new filesystem attachment storage: >> There are a couple platforms on which attachment storage sits: >> * Transaction handling - This is finished to my satisfaction. We may decide >> later that it is >> inadequate or needs changing but it serves this purpose now. >> * Transaction safe file save/delete - Finished (based on transaction >> handling) >> * Serialization - Finished refactoring of XMLWriter and generic Serializer >> and XMLSerializer. >> * Providing of files - Mostly finished, needs review to see if there is a >> cleaner way. Barring any >> major changes, this should not take longer than 1 day to complete. >> * Locking - Needed, lock management exists but does not handle deadlock nor >> "greedy thread" >> situations. 3 days needed to do code review on Apache commons LockManager to >> determine if it handles >> these situations, I'm guessing 2 days are needed to integrate LockManager >> and in place of the >> existing lock mechanism and a further 3 days to implement one of the >> features on top of LockManager >> if need be. >> >> "Consumer" code: >> * FilesystemAttachmentStore - Complete, enabling requires adding the .jar >> file to WEB-INF and >> changing a line in xwiki.cfg. Suffers from deadlock because the locking >> mechanism, is inadequate. >> * FilesystemAttachmentVersioningStore - Complete but needs tests, enabling >> is same as for >> FilesystemAttachmentStore. 1-2 days should be adequate for testing. >> * FilesystemAttachmentRecycleBinStore - in progress, 3 days to complete and >> test (?). Finished >> DeletedFilesystemAttachment, need TransactionRunnables for saving and >> deleting and serializer for >> deleted attachment meta-data. >> * Need a plan for migrating data from old system. FilesystemAttachmentStore >> fails over to old store >> if an attachment cannot be found. Is this correct? Should migration scripts >> be distributed instead? >> WDYT? >> * Consumer code all needs more tests. Any amount of time could be spent on >> this, I think a week is >> adequate. >> >> Since this contains a large amount of code and all storage code is critical, >> I think this should go >> through a release cycle in the platform but disabled by default so that it >> can be beta tested before >> it becomes official. WDYT? >> >> Caleb > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
