On Jan 27, 2011, at 3:17 PM, Caleb James DeLisle wrote: > > > 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?
Sounds good to me, better have something operation that can be tested than nothing! >> 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. Could you send a vote mail on this? Thanks -Vincent >> 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
