Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F516EA9.5060909@mortbay.com>
Date: Sun, 31 Aug 2003 13:42:33 +1000
From: Jan Bartel <janb@mortbay.com>
Reply-To: janb@mortbay.com
Organization: Mort Bay Consulting
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.3) Gecko/20030430 Debian/1.3-5
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: Re: [jndi] Have we found a JNDI impl yet?
References: <02BFCA10-D95C-11D7-B0AA-0003934D3EA4@ioshq.com>
 <000001c36d72$472df780$090110ac@trunk.joshuatree.org>
 <BB74550B.FB9F%Richard@Monson-Haefel.com>
In-Reply-To: <BB74550B.FB9F%Richard@Monson-Haefel.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Richard Monson-Haefel wrote:
> All this sounds great, Alex, but I�m a little concerned that its 
> overkill for the JNDI ENC.  
Totally agree.


> The JNDI ENC is totally static at runtime 
> (per deployment) and therefore a very simple, and fast, in-memeory 
> caching strategy works best. 
Yes, as far as the ejb deployment unit is concerned, it's java ENC is 
immutable (although this might be mutable by, eg, the ejb container).


> Will your impl support this type of 
> caching?  In OpenEJB, the JNDI ENC impl caches lookups in a HashMap so 
> that subsequent lookups using the same JNDI name are wicked fast � fast 
> as a Hashtable lookup on a small data set.  I know that we can use the 
> advanced features of LDAPd in many areas of Geronimo (security, 
> configuration, etc.) but for the JNDI ENC, I think it would be best if 
> we used something lighter.  Perhaps, you can provide a caching impl for 
> static data sets like this?  The thing is, in most deployments, the 
> number of items stored in the JNDI ENC for a particular component is 
> very small. Speed is of the essence � you can�t get much faster than a 
> HashMap. ;-)

Just to lend further weight to the in-memory vs external storage 
java:comp/env namespace, the experience over at JBoss was that stress 
testing showed up that just thread sychronisation on the context 
environment Properties used by NamingParsers was a significant 
performance bottleneck. Therefore the throughput could only get worse if 
we added an external storage mechansism to the lookup process.


Jan


> 
> On 8/28/03 7:40 AM, in article 
> 000001c36d72$472df780$090110ac@trunk.joshuatree.org, "Alex Karasulu" 
> <aok123=Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
> 
>     The current architecture has a primitive server side LDAP JNDI provider
>     which is about 70-80% functional.  The provider directly accesses
>     entries
>     within the backend apparatus within the server.  When contexts are
>     initialized they represent an instance/point of access (hence a context)
>     into the directory information tree of the server bypassing the LDAP
>     protocol stack.
> 
>     In the new architecture, to be completed by mid October, the JNDI
>     provider
>     is at the core of the server's backend apparatus and shall be
>     completed by
>     then.  The server side JNDI LDAP provider will wrap something we call a
>     nexus that attaches several databases each with a suffix in the
>     namespace to
>     a central point in the server.  The nexus performs name based
>     routing to the
>     backend that has jurisdiction over the region of the namespace
>     specified by
>     its suffix.  Anyway this apparatus is wrapped by JNDI.  The JNDI
>     becomes the
>     only way to enter the nexus and hence a target backend in the new
>     architecture.  The JNDI is thus a shell around the backend subsystem
>     of the
>     server.  All orthogonal services implemented as Interceptors enable
>     things
>     like triggers, and change notification between calls made by the JNDI
>     provider on the nexus.  This is how we introduce new services into JNDI
>     calls on our provider.
> 
>     There are two ways I can immediately conceive of in which this code
>     can be
>     leveraged to enable a persistant java:comp/env namespace for
>     Geronimo.  But
>     first consider this.  There may be areas where Geronimo will need to
>     access
>     and search over persistent data without having to bring this information
>     into memory - this requires the industrial power of database indexing.
>     Geronimo's configuration is a perfect candidate for storage in the
>     directory
>     - it will most likely be hierarchical in nature and very fitting.
>      Another
>     excellent possibility is the use of the embedded server as the
>     foundation
>     for a security subsystem.  With that in mind lets just look at the
>     way in
>     which we can just enable the java:comp/env namespace while using
>     LDAPd code.
> 
>     First you can build over the LDAP namespace using it as a hierarchical
>     relational database to manage environment data.  A java:comp/env
>     namespace
>     could be implemented using another JNDI provider to wrap the LDAP
>     provider
>     which has the super set of JNDI functionality (Context, DirContext, and
>     LdapContext).  The wrapper provider would simply transform
>     operations into
>     the LDAP namespace according to the designed DIT structure and the
>     schema
>     used for java:comp/env objects.  The neat thing is you would have
>     the power
>     of search to find anything you needed very rapidly.  Much faster than a
>     non-indexed solution - you're getting the power of a database at your
>     disposal this way.  If you go this route then other aspects like
>     configurations can also be stored in different areas of the directory
>     information tree.  Also LDAP replication can be used to replicate your
>     environment and configuration information for clustering in the
>     future.  I
>     would recommend this approach.  Although you don't expose all the LDAP
>     functionality you can still leverage it under the hood of the
>     java:comp/env
>     provider to make it extremely fast.  I can help write this or add
>     Geronimo
>     developers to the LDAPd project to make it come to fruition.
> 
>     The other approach involves the generalization of the Backend
>     interface to
>     store any kind of entry that does not necessarily need to be an
>     entry within
>     the LDAP namespace: see the attached xref file for the Backend
>     interface.
>     This way the backend apparatus is a generalized entry storage
>     subsystem that
>     could be used for any kind of namespace - directory enabled or
>     otherwise.
> 
>     Noel Bergman and I are in the process of discussing these details
>     and anyone
>     from the Geronimo team is welcome to join us.  Basically we reduce
>     the JNDI
>     methods into a minimal set of storage oriented operations very close in
>     nature to the methods on Context and its subclasses.  This reduced
>     instruction set if you could call it that is extremely simplified
>     enabling
>     storage for entries in any namespace.  The nexus multiplexes different
>     backends for different namespaces almost federating them.
> 
>     If a generalized provider with a pluggable NameParser is written
>     then the
>     provider can theoretically be used for any namespace.  Think of the
>     concept
>     as miniature framework for JNDI to enable storage and retrieval
>     without the
>     pain of having to implement all those methods on the Context
>     interface and
>     its subclasses.
> 
>     These concepts are at the stage where new comers can join the
>     conversation
>     with a minimal learning curve to rapidly be able to participate.  We
>     would
>     welcome the collaboration to enable both projects to progress together.
> 
>     Good luck & BU,
>     Alex Karasulu
> 
>