directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From directory-...@incubator.apache.org
Subject [jira] Updated: (DIREVE-23) Use multiple PartitionNexus' for layered partitioning
Date Fri, 01 Oct 2004 06:55:32 GMT
The following issue has been updated:

    Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
       Date: Thu, 30 Sep 2004 11:55 PM
    Comment:
fixed formatting using dots cuz spaces are parsed out it seems
    Changes:
             description changed from I just got a great idea but it might be a little crazy.
 There is a problem with the current model where there can only be one (singleton) nexus way
at the top of a system.  This severly limits how the namespace can be partitioned.  Because
of BackingStore operation routing concerns to ContextPartitions, one cannot have two ContextPartitions
having a suffix overlap.  Basically ContextPartitions with suffixes like so are not allowed:

.o CP1 suffix is dc=apache,dc=org
.o CP2 suffix is ou=people,dc=apache,dc=org

Here's how the tree might look:

.                            [RootNexus]
.                               /   \
.                            [CP1]  [CP2]
.                               

The suffix of CP1 overlaps the suffix of CP2.  Basically requests recieved under the CP2 suffix
base have a tough time determining where they should route calls.  To avoid this confusion
there is the restriction mentioned above.

What if had a very special kind of nexus that was not a singleton and had a suffix associated
with it?  Furthermore this nexus can contain entries off of that suffix as well instead of
just delagating their storage to partitions it bridges.  This nexus could then eliminate the
routing problem and remove the restriction.  For the time being lets call this a ContextNexus.
 So we could have the following configuration:

 o CN1 suffix is dc=apache,dc=org
 o CP2 suffix is ou=people,dc=apache,dc=org

Here's how the tree might look:

.                            [RootNexus]
.                                 |
.                               [CN1]
.                                 |
.                               [CP2]

Here in this case entries like ou=groups,dc=apache,dc=apache and its contents would be stored
in CN1 and so would the suffix dc=apache,dc=org.  Now because of this extra level of routing
decisions for routing cannot get confusing.   We can then partition the namespace in any manner
we see fit with minimal cost to performance.

 to I just got a great idea but it might be a little crazy.  There is a problem with the current
model where there can only be one (singleton) nexus way at the top of a system.  This severly
limits how the namespace can be partitioned.  Because of BackingStore operation routing concerns
to ContextPartitions, one cannot have two ContextPartitions having a suffix overlap.  Basically
ContextPartitions with suffixes like so are not allowed:

..o CP1 suffix is dc=apache,dc=org
..o CP2 suffix is ou=people,dc=apache,dc=org

Here's how the tree might look:

.............................[RootNexus]
................................/...\
............................[CP1]...[CP2]

The suffix of CP1 overlaps the suffix of CP2.  Basically requests recieved under the CP2 suffix
base have a tough time determining where they should route calls.  To avoid this confusion
there is the restriction mentioned above.

What if had a very special kind of nexus that was not a singleton and had a suffix associated
with it?  Furthermore this nexus can contain entries off of that suffix as well instead of
just delagating their storage to partitions it bridges.  This nexus could then eliminate the
routing problem and remove the restriction.  For the time being lets call this a ContextNexus.
 So we could have the following configuration:

..o CN1 suffix is dc=apache,dc=org
..o CP2 suffix is ou=people,dc=apache,dc=org

Here's how the tree might look:

.............................[RootNexus]
..................................|
................................[CN1]
..................................|
................................[CP2]

Here in this case entries like ou=groups,dc=apache,dc=apache and its contents would be stored
in CN1 and so would the suffix dc=apache,dc=org.  Now because of this extra level of routing
decisions for routing cannot get confusing.   We can then partition the namespace in any manner
we see fit with minimal cost to performance.


    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/DIREVE-23?page=history

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DIREVE-23

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DIREVE-23
    Summary: Use multiple PartitionNexus' for layered partitioning
       Type: Improvement

     Status: Open
   Priority: Major

    Project: Directory Eve
 Components: 
             Backend

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Thu, 30 Sep 2004 11:52 PM
    Updated: Thu, 30 Sep 2004 11:55 PM

Description:
I just got a great idea but it might be a little crazy.  There is a problem with the current
model where there can only be one (singleton) nexus way at the top of a system.  This severly
limits how the namespace can be partitioned.  Because of BackingStore operation routing concerns
to ContextPartitions, one cannot have two ContextPartitions having a suffix overlap.  Basically
ContextPartitions with suffixes like so are not allowed:

..o CP1 suffix is dc=apache,dc=org
..o CP2 suffix is ou=people,dc=apache,dc=org

Here's how the tree might look:

.............................[RootNexus]
................................/...\
............................[CP1]...[CP2]

The suffix of CP1 overlaps the suffix of CP2.  Basically requests recieved under the CP2 suffix
base have a tough time determining where they should route calls.  To avoid this confusion
there is the restriction mentioned above.

What if had a very special kind of nexus that was not a singleton and had a suffix associated
with it?  Furthermore this nexus can contain entries off of that suffix as well instead of
just delagating their storage to partitions it bridges.  This nexus could then eliminate the
routing problem and remove the restriction.  For the time being lets call this a ContextNexus.
 So we could have the following configuration:

..o CN1 suffix is dc=apache,dc=org
..o CP2 suffix is ou=people,dc=apache,dc=org

Here's how the tree might look:

.............................[RootNexus]
..................................|
................................[CN1]
..................................|
................................[CP2]

Here in this case entries like ou=groups,dc=apache,dc=apache and its contents would be stored
in CN1 and so would the suffix dc=apache,dc=org.  Now because of this extra level of routing
decisions for routing cannot get confusing.   We can then partition the namespace in any manner
we see fit with minimal cost to performance.




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message