This one time, at band camp, James Strachan said:
Please see my comments inline.
JS>On Friday, August 29, 2003, at 01:16 pm, Alex Blewitt wrote:
JS>
JS>> On Friday, Aug 29, 2003, at 12:59 Europe/London, Daniel S. Haischt
JS>> wrote:
JS>>
JS>>> Alex Blewitt wrote:
JS>>>
JS>>> [...]
JS>>>
JS>>>> You also have to consider the case when a clustered system is in
JS>>>> operation. Then, they are likely to need to share data that is
JS>>>> installed, and a sensible back-end may need to synchronize such
JS>>>> writes across a number of nodes/clusters.
JS>>>> I agree for a single-server environment, having an in-memory cache
JS>>>> will be the fastest, but having a switchable JNDI server will allow
JS>>>> both :-)
JS>>>
JS>>> is there already someone working on a clustering solution?
JS>>>
JS>>> sometimes i am wondering whether we are aiming to provide a all-in-one
JS>>> wonder. wouldn't it be possible to start with a more simple in-memory
JS>>> solution and switch to a more complex solution while Geronimo emerges?
JS>>
JS>> Geronimo is currently a single-node system. It would obviously be
JS>> desirable to support clustering at a later stage.
JS>>
JS>> However, thinking about the aspects involved in clustering now, it
JS>> allows us to make better abstractions which will allow us to migrate
JS>> to a clustered solution easier in the future.
JS>
JS>There are many forms of clustering. Off the top of my head this
JS>includes...
JS>
JS>* JNDI clustering (either peer based or LDAP style master-slave model)
JS>* clustered caching (a big topic in and of itself) used for all kinds
JS>of things from arbitrary application data to CMP / JDO caching
JS>* clustered HTTP / session bean state (similar in some ways to the
JS>above with some differences - typically sticky-ness)
JS>* clustered servers - e.g. deploying a WAR / EAR to the cluster & it
JS>runs everywhere in the cluster etc
JS>* clustered JMS implementation (using clustering for persistence for HA
JS>to avoid message loss)
* HA services (failover and load balancing)
* automatic instance discovery
* easy management of the entire cluster (this gets into netboot and other
monitoring functionality)
JS>I'd hope we can implement them all in some modular & configurable way
JS>so users are free to pay whatever cost (in RAM, I/O, CPU, complexity or
JS>whatever) they are happy with to get the quality of service they need
JS>in all aspects of Geronimo.
We definiely need to consider building a decoupled layer allowing
differnet solutions to be plugged in. The first solution that comes
to my mind is JavaGroups (soon to be renamed JGroups), because of
it's capabilities. It's designed to provide exactly this type of
functionality. The problem with JGroups is that it is licensed using
the LGPL. Maybe I could ask Bela about a dual licensing strategy. I was
planning on talking to him soon anyway.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL
PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
