On Nov 14, 2006, at 1:28 PM, Jeff Genender wrote:
Hi Guys,
I need to get OpenEJB3 ready for some clustering. Here is a plan...
I am going to add a multicast agent to openejb so that the containers
can "find each other". The containers will create a list of endpoints
(other servers) and stuff the list in the ServerMetaData as a list of
URLs. That list will go to the client for use in the proxy.
Currently
OEJB2 uses round robin, but I would like to port it up to OEJB3 with a
plugable strategy, so we can use "random" for EJB connectivity to
provide for load balancing, as well as round robin.
I would like to know about preferences for insertion points for the
multicast agent, deployment configuration (to turn it on and use
it), etc.
Couple notes. Go with URI instead of URL (don't know if that's what
you meant). As I described to Mark the ServerMetaData in 3 already
uses a URI instead of the InetAddress object like 2 does. 2 has a
list of ServerMetaData objects, but really there should be one
ServerMetaData object with a list of URIs inside.
There are a couple ways too cook the round-robin or random type code
into the client. One is to create a new ConnectionFactory
implementation. The ConnectionFactory used should get selected by
the ConnectionManager based on the URI scheme. So you could pick
some scheme of your choosing 'oejb+rr' or you could even use nested
URIs and have your ConnectionFactory implementation delegate back to
ConnectionManager round-robin or random style such as
'random:oejb'... here the ConnectionManager will find the
ConnectionFactory for 'random' then your RandomConnectionFactory
would scrape of the "random:" part and try a connect to the inner
URI, example "oejb:..." or "http:...". That's kind of crazy, but if
you like it it works.
The other way is to simply hack the plain "oejb" ConnectionFactory to
accept a new URI param which states what cluster style you want if
any 'oejb:...?cluster=round-robin' etc. That's pretty simple, but
the downside is you'd have to hack it in for each protocol 'oejb',
'http' and anything else we use as an actual transport.
You could even just do a hybrid of the first two ideas and make a new
ConnectionFactory, say ClusteredConnectionFactory that takes the URI
scheme 'cluster:...' then use query params to configure that such as
'cluster:...?style=round-robin', etc. Now that I'm typing this, that
seems like the best option. It's all likely clear as mud as I'm more
or less just rambling my thoughts :) .. but just trying to get the
conversation started :)
-David
All comments are welcome.
Thanks,
Jeff
