27 Jan
2011
27 Jan
'11
3:17 p.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs