Thanks Jason, yep the cluster sounds like the go, what I'm a bit stuck
on now is just binding simple properties to JNDI so each node can obtain
a slightly different configuration e.g. a string or set of strings. I'm
used to retrieving mail sessions, datasources etc but not simple
properties.
Where I'm headed with it, is each node is going to fire up a server
socket (leaving aside the fact that's probably not a compliant thing to
do), so I'd like to give each instance of the application a different
port number (an external application is going to be configured with a
list of ports it can try to communicate with the application on).
I guess my current line of thinking is to define a custom JNDI resource
in GF, with a Resoure Type like com.mycompany.SomeConfigHolder, and a
factory class like com.mycompany.SomeConfigFactory, and then define the
concrete values using the 'Additional Properties' section... not sure if
this approach makes sense.
If it does, do my classes mentioned above need to be available at the
time of configuring the custom resource, or only when actually
referenced (as they'll only be available after the app is deployed).
Cheers
Joe
> Why not just run in clustered configuration, i.e. multiple
> app-servers, on the same or different machines? In my
> experience (with clustering), the rate-limiting thing is the
> amount of processor available to GF, not the number of copies
> of code available to the app-server. The classloader isn't
> going to care which JNDI tree your particular instance of
> some @Stateless interface is coming from, right? It's just
> going to grab the "nearest" one out of the cache. As long as
> the server thread is running on one CPU core, it doesn't
> matter how many copies of your jar file you have lying
> around, your requests are just going to logjam on the processor.
>
> Just my 2cents...
> Jason
>
>
> On 5/10/07, Shevland, Joe <joe.shevland_at_capgemini.com> wrote:
>
>
> > * If instead its clustered, because there's just one
> > deployment ear, how would I map three 'instances' to three
> > different configurations or different JNDI names for each?
> > Each module is going to open a server socket (yes its
> > probably going outside the spec) and I'd like to feed them
> > each a different port.
>
> I guess each server instance is going to have its own
> JNDI tree... in
> any case, what ObjectFactory would you use for
> 'simple'/constant JNDI
> resources?
>
> Cheers
> Joe
>
> This message contains information that may be
> privileged or confidential and is the property of the
> Capgemini Group. It is intended only for the person to whom
> it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate,
> distribute, or use this message or any part thereof. If you
> receive this message in error, please notify the sender
> immediately and delete all copies of this message.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
>
>
>
>
>
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.