geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
Date Sat, 10 Jun 2006 03:48:08 GMT
Hi Dave,

Thanks for pointing this problem out. I simply forget to provide an AMQ 
patch to fix it; this is now done:

Also, this feature is broken in 1.1. Basically, SharedLib and 
FileKeystoreManager do not properly resolve their resources and, as a 
consequence, the server simply shuts down.


Dave Colasurdo wrote:

> BTW, I think additional fixes are required in 1.1.1 before claiming 
> support for multiple concurrent server instances from a single 
> installation..
> Awhile back I was able to start the server using an external var 
> directory (via -Dorg.apache.geronimo.server.dir).  After changing all 
> the ports and trying to start a second instance from the default 
> location, I encountered a startup exception regarding the activemq 
> transaction journal.  Suspect code changes are needed to relocate the 
> journal to a location outside the installation directory.
> Thanks
> -Dave-
> John Sisson (JIRA) wrote:
>>     [ 

>> ]
>> John Sisson commented on GERONIMO-1638:
>> ---------------------------------------
>> Currently working on scripts as discussed at 
>> . 
>> Have made changes but they need to be tested on windows, cygwin and 
>> unix, so looks like this is going to be for 1.1.1 .
>>> Multiple servers sharing the same repo and config store
>>> -------------------------------------------------------
>>>          Key: GERONIMO-1638
>>>          URL:
>>>      Project: Geronimo
>>>         Type: New Feature
>>>     Security: public(Regular issues)   Components: usability
>>>     Versions: 1.0
>>>     Reporter: Gianny Damour
>>>     Assignee: John Sisson
>>>      Fix For: 1.1
>>> David J. sent to the dev mailing list:
>>> Many people have talked on and off about how to set up multiple  
>>> servers sharing the same repository and config-store, but we 
>>> haven't  arrived at an agreed on way to do it.  We have a 
>>> prospective customer  for this feature (Vincent Massol with Cargo) 
>>> so I'd like to move  beyond thinking about it in my head, discuss 
>>> it, and have someone  implement it.  I believe any implementation 
>>> will be more or less  trivial, the hard part is figuring out what to 
>>> do.
>>> I've only thought of ways to extend what we have now, rather than  
>>> restructure anything or add big new capabilities.  If someone sees 
>>> a  better way, please speak up.
>>> So, we have a ServerInfo gbean that knows where geronimo is located  
>>> and can resolve absolute locations for other components.  Then we  
>>> have things like the repository and config store gbeans that  
>>> typically are "located" outside the var dir and things like the  
>>> logging framework,  local attribute manager, derby, and tomcat, 
>>> that  typically keep stuff in the var directory.
>>> All or most of these start with the first configuration loaded so  
>>> they can't have any attributes overridden by config.xml: in fact 
>>> this  file is read by one of the gbeans that we need to "relocate".
>>> I've thought of two related solutions.  Both of them involve giving  
>>> ServerInfo knowledge of another path and another resolve method.
>>> One would be something like "resolveVar" and would normally resolve  
>>> to geronimo_home/var.  This would involve all the gbeans currently  
>>> looking inside var having the "var" trimmed off the front of their  
>>> paths and using the new resolveVar method.  In this case we'd have  
>>> different servers represented as e.g.
>>> var1
>>> var2
>>> var3
>>> ...
>>> The other would give ServerInfo something like resolveServer which  
>>> would normally resolve to geronimo_home.  The gbeans looking inside  
>>> var would keep their current paths and just call the new resolve  
>>> method instead of the old one.  In this case we'd have servers like
>>> var
>>> server1/var
>>> server2/var
>>> ...
>>> In either case I think starting geronimo with a command line 
>>> argument  pointing to the var directory is the only way to specify 
>>> which server  you want to run; the default would presumably be as 
>>> now "var".
>>> Several people have suggested putting an additional config-store 
>>> into  var for "private" use by a particular server.  At the moment I 
>>> think   that providing a different config-store class that uses the 
>>> new  resolve  method on server info would be the best way to do this.
>>> I'm not attached to these ideas but this is as far as my thinking 
>>> has  gone.  Please comment.
>>> thanks
>>> david jencks

View raw message