Configuring JBossCluster

[urisherman]

Hello,
I'm am looking into integrating JBossCache into a clustered application we will have running on WLS9.2.
I tried digging into the docs trying to figure out how to define cluster members from jbosscache but I kept ending up with that unclear "ClusterConfig" element in the xml configuration file that has no informative english documentation to come with (or at least none that I found).
Does the cache service load the cluster definition from weblogic classes at runtime? I don't have the cluster up and running yet so I couldn't check that out.
Even if so, I'd still like to know how I can manually configure it since the cluster won't necessarily be defined in weblogic.
Thanks!

[brian.stansberry]

The clustering configuration comes from the ClusterConfig element, not from anywhere in WLS.

That element defines a JGroups protocol stack. See http://www.jgroups.org/javagroupsnew/docs/manual/html/index.html for general JGroups documentation.

Each subelement within the stack defines a particular protocol. See pages linked from http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups for a discussion of what each protocol does and what the config options are.

In brief, if you are using UDP, all servers on the network with the same mcast_addr and mcast_port config will see each other and form a group. If you are using TCP, you need to list your servers in the TCPPING protocol, or use the MPING protocol.

[urisherman]

Thanks a lot!
Very helpfull.
If I may make a suggestion about the documentation -
Indeed when I took another look I saw in the docs references to JGroups, the thing is, the reference appears in the preface. When a new user that doesn't know what JGroups is just reads through the docs for the first time, he won't remeber a single sentence from the small introduction ;-)
When he plunges into the docs with numerous places showing xml files defining the ClusterConfig element, with no explanation whatsoever for what the elements represent (which would be ok if the fact that it is defined by JGroups was written there) it becomes really frasturating not understanding why in the name of god no one wrote somewhere what all this means ;-)
Then my next step was to try and look through the api docs, which describe the methods setClusterConfig() and setClusterProperties() which as well don't mention this information.

Anyway, there should be more references to JGroups, at least in the configuration section.....

Thank you very much for your reply,
Uri.

[urisherman]

One more thing -
Do you have any comments regarding the fact that the cache will be used from within the context of an ejb container? That is, thread management and network IO isn't exactly "ideal" to be done from an ejb, and is kind of "forbidden" by the spec....
I'll appreciate any comments,
thanks!

[brian.stansberry]

You're right about the docs. It's an area that can be improved.

You're not *deploying* the cache from an EJB, right? It should be a separate deployment, either standalone or packaged with the ejb jar(s) in an ear or a sar.

If not deploying the cache from the EJB, you're not creating threads from the EJB either, and there is no issue using the cache from the EJB.

[urisherman]

> You're not *deploying* the cache from an EJB, right?
What do you mean by "*deploying*"? Creating it and starting it?
Lets say I won't do that from an EJB, that's not the issue.

> It should be a separate deployment, either standalone or packaged with
> the ejb jar(s) in an ear or a sar.
It won't be standalone, it is intended to "live" inside our application. What do you mean by packaged with the ejb jars? The cache implementation is provided by u guys, it's in the server's lib directory. I use it inside my application, which is an ear that includes a bunch of ejb jars and wars.


> If not deploying the cache from the EJB, you're not creating threads
> from the EJB either, and there is no issue using the cache from the EJB.
Even if I don't deploy the cache from within an ejb (assuming "deploy"="create and start"), when I manipulate it from within an ejb the cache has to replicate itself, thus creating/dispatching a call to another thread (if working with async replication), or issue network io calls from the containers thread (if working with sync replication).

[brian.stansberry]

"urisherman" wrote:
> You're not *deploying* the cache from an EJB, right?
What do you mean by "*deploying*"? Creating it and starting it?
Lets say I won't do that from an EJB, that's not the issue.

Yes, deploying means instantiating, creating and starting the service.

> It should be a separate deployment, either standalone or packaged with
> the ejb jar(s) in an ear or a sar.
It won't be standalone, it is intended to "live" inside our application. What do you mean by packaged with the ejb jars? The cache implementation is provided by u guys, it's in the server's lib directory. I use it inside my application, which is an ear that includes a bunch of ejb jars and wars.

Having a couple jars in lib doesn't mean we provide a cache service. It means we provide classes you can use to deploy a cache service by deploying a -service.xml file. You need to do that, unless you plan to hijack one of the existing running caches that the AS uses for http session and EJB3 replication. Using those caches for other purposes is not good practice.

Even if I don't deploy the cache from within an ejb (assuming "deploy"="create and start"), when I manipulate it from within an ejb the cache has to replicate itself, thus creating/dispatching a call to another thread (if working with async replication), or issue network io calls from the containers thread (if working with sync replication).

Async replication doesn't mean your EJB creates a thread or "calls" a thread. Your ejb call puts an object (a replication message) in a queue, that's all. The fact that another thread is polling that queue and doing things with the objects found there is not a function of your EJB. The fact that you're using async replication means your EJB is not concerned with the object after it puts it in the queue.

Re: synchronous and network io, if you set down_thread="false" in every protocol in the JGroups config, yes, your EJB thread will end up doing network io. I don't think that's a big issue; hard for me to see how network io isn't involved in common things like session beans putting messages in a JMS queue, or session beans making remote calls to other EJBs. If this is a concern for you, leave one of the protocols set to down_thread="true" and your EJB thread will no longer be the one doing the network io.

BTW, clustered SFSB's and entity beans in JBoss all end up making JGroups calls to keep state consistent across the cluster.

[urisherman]

Having a couple jars in lib doesn't mean we provide a cache service. It means we provide classes you can use to deploy a cache service by deploying a -service.xml file.

Deploying a -service.xml file? We are using WLS9.2/WLS8.1 not JBoss.....

Async replication doesn't mean your EJB creates a thread or "calls" a thread. Your ejb call puts an object (a replication message) in a queue, that's all. The fact that another thread is polling that queue and doing things with the objects found there is not a function of your EJB. The fact that you're using async replication means your EJB is not concerned with the object after it puts it in the queue.

Fair enough, I understand.

I don't think that's a big issue; hard for me to see how network io isn't involved in common things like session beans putting messages in a JMS queue, or session beans making remote calls to other EJBs.

The problem isn't network io nor thread/synchronization management in general, the problem is someone else doing it that's not the app server. of course the application server messes around with all that all the time, that's exactly why no one else *should* according to the spec.
I think u didn't understand me because I failed to mention (or only mentioned it in my very first post) we aren't running on JBossCache on JBoss (in that case I wouldn't have any thoughts about the issue, AFAIC JBossCache is part of JBoss appserver) but rather integarting it into WLS.

[manik]

Do you have any comments regarding the fact that the cache will be used from within the context of an ejb container? That is, thread management and network IO isn't exactly "ideal" to be done from an ejb, and is kind of "forbidden" by the spec....

You don't necessarily need to start and manage the cache from an EJB in WLS. Try some of the techniques on http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheAndWebLogic

[urisherman]

There are no techinques described there, but anyway, as I wrote in my previous posts I do not want to deploy (create and start) the cache from within an EJB, but I will access it and manipulate it's contents.
I was asking about the implication of this since the underlaying implementation might be executing IO instructions/thread management/etc. that are highly unrecomended by the J2EE specification to be done in a context of an EJB container.