I understand what you're saying, but it does sound quite network chatty. As cautionary note: I have known customers of commercial app servers really bitch about the chattiness /between/ nodes in a cluster. This should be kept to an absolute minimum
On Fri, 8 Aug 2003 21:52:27 +0100, "Alex Blewitt" <[EMAIL PROTECTED]> said: > It would be a single service, but could easily be adapted for > distributed systems. For example, each Geronimo app server is likely to > have a server VM running server services, which could include the JNDI > server. Then, each other node has a JNDI server which synchronizes its > state with the others. > > With a backend DB, it's very likely that the DB could be used to > provide the synchronization. Files may be more problematic, unless they > are on a network device. > > So, doesn't necessarily need to be a single point of failure although > it would be a single service. > > Alex. > > On Friday, Aug 8, 2003, at 20:31 Europe/London, Gareth Bryan wrote: > > > I like this idea:- but wouldn't it introduce a single point of failure? > > > > (I guess the same problem will hold for any config node in a cluster) > > > > On Fri, 8 Aug 2003 19:28:26 +0100, "Philip Dodds" > > <[EMAIL PROTECTED]> said: > >> I certainly agree. The idea of holding all configuration information > >> in > >> a > >> repository such as LDAP would certainly be useful within clustered and > >> grid > >> style environments. > >> > >> Philip > >> > >> -----Original Message----- > >> From: Alex Blewitt [mailto:[EMAIL PROTECTED] > >> Sent: Friday, August 08, 2003 6:55 PM > >> To: [EMAIL PROTECTED] > >> Subject: [JNDI] [Config] Thought > >> > >> Why can't/shouldn't all configuration be stored in JNDI, presumably as > >> subdirectory (sorry, subcontext) specific to geronimo? > >> (java:comp/env/genronimo, or other such domain). > >> > >> JNDI supports pretty much everything you need -- contexts (one per > >> server/node/app/ejb/servlet/whatever) and an unlimited amount of > >> configuration entries (poolsize, max thread, min thread). > >> > >> And if the JNDI is going to be backed by Technology X, then that > >> provides a way for users to administer the data directly. But a app > >> configurator can just be based on reading/writing JNDI values. > >> > >> JNDI also not only supports tree-like structures, but also references > >> to other parts of the tree as well which would be ideal (for instance) > >> to represent relationships like 'App Y is in node Z' > >> > >> And lastly, XML extraction of a JNDI source would be a doddle, or even > >> be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be > >> more scalable for read-write data synchronised across multiple nodes > >> for clustering). > >> > >> Can anyone think of a good reason why JNDI cannot/should not be used > >> as > >> /the/ place to store config information? That way, the server will > >> only > >> need one start-up parameter -- the JNDI server to connect to. > >> > >> Alex. > >> > >> PS Isn't this what Windows 2000 uses for its registry, and what > >> Windows > >> XP uses to mount its Active Directory? Certainly, Mac OS X is moving > >> more towards a directory-managed approach (be it backed by LDAP or > >> whatever) -- so why don't we do the same for Geronimo? > >> > >> > >> > >> > > -- > > Gareth Bryan > > [EMAIL PROTECTED] > > > > -- > > http://www.fastmail.fm - mmm... Fastmail... > -- Gareth Bryan [EMAIL PROTECTED] -- http://www.fastmail.fm - Does exactly what it says on the tin
