On 7 Oct 2009, at 14:07, Mike Müller (JIRA) wrote:
[ https://issues.apache.org/jira/browse/SLING-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763042
#action_12763042 ]
Mike Müller commented on SLING-1137:
------------------------------------
I think this would be a really cool feature to work around the
performance issue of jackrabbit if you have many nodes under the
same node.
What about a service which can be registered unter a specific path
which addresses this issue very transparent for the client:
1) the service takes care that the subnode under the registered path
is saved in a hierachical tree (eg. a tree based on hashes)
2) the service also acts as a ResourceProvider which returns the
searched resource
For example:
1) You register this new service unter /my/path
2) If you post a new node under /my/path/newnode the service takes
care to save the new node in a non flat structure, for example in a
hashed structure under /my/path/b7/newnode
3) If you get the resource under /my/path/newnode the service
(ResourceProvider) takes care the /my/path/b7/newnode is returned.
WDYT?
IIUC (and this may be off track)
We (Sakai) do this already, its the only way we could get to billions
of child nodes at URL level. For instance we have 3 stores that depend
on this.
MessageStore, a Gmail like store of all messages in the system. chat,
discussion, email, comments etc URL space is /user/ieb/messages/xxxx
where xxx is the message ID, JCR path is hashed at ieb and at xxxx
Contact, a social network graph where each user may have 1000's of
contacts and there are 1000's of users URL space //contacts/ieb/
mikedev JCR path hashed at ieb and mikedev
The final one that really needs to scale for us is a shared pool of
resources /files/xxxx is the permanent URL, which is referenced from
many other places in the URL structure. the xxxx is hashed. We have
chosen a 4x255 hash eg ff/ff/ff/ff which should get us to 4e9 items
without too much contention or update slowdown.
The core code is in an AbstractVirtualServlet that when extended
allows mapping to a parent resource type to indicate the location in
the JCR is hashed, but that one needs a modification to the
JcrResourceResolver2 and the API to work.
I am currently re-writing the ResourceProviderEntry to accommodate the
modification without changing the API, but its complex and slow work
to get it right.
Ian
Support hierarchical child node creation from SlingPostServlet
--------------------------------------------------------------
Key: SLING-1137
URL: https://issues.apache.org/jira/browse/SLING-1137
Project: Sling
Issue Type: Improvement
Components: Servlets
Reporter: Mark Baker
Priority: Minor
The default node creation functionality on "/" terminated paths via
the SlingPostServlet doesn't scale very well as it only supports
creation of nodes immediately under the targeted path. So, for
example, when using this via a CQ form to capture form responses in
the repository, a site can potentially have thousands of child
nodes, leading to well known performance problems.
I think it would be useful to offer an option for the servlet to
save a hierarchy of nodes, perhaps via the common convention of
using the first 4 characters of the would-be node id to create a 2
level hierarchy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
