-
1. Re: Limit MDB max instances cluster-wide ?
JCA resources are deployed per node and are not cluster 'aware'. As a result, there is no cluster wide resource throttling that can be applied. Obviously dividing your max number of connections by the number of nodes in your cluster will give you the number of connections you can allocate for each node.
-
2. Re: Limit MDB max instances cluster-wide ?
I know that (maybe I should have put standard-based as an optional requirement) that's why Im asking you for advices, the question is :
Can you think of a clever/simple way of dynamically updating a node's RAR attributes (pool sizing, endpoint activation/deactivation etc...) based on cluster aware metadatas ?
Thanks -
3. Re: Limit MDB max instances cluster-wide ?
I know that (maybe I should have put standard-based as an optional requirement)
What does this mean? I am not following.
Can you think of a clever/simple way of dynamically updating a node's RAR attributes (pool sizing, endpoint activation/deactivation etc...) based on cluster aware metadatas ?
If you are referring to cluster metadata that you mantain (this is really your only option) then the easiest solution would be to update attributes via JMX. -
4. Re: Limit MDB max instances cluster-wide ?
What does this mean? I am not following.
I did not mean to limit the solutions to strict JCA usage ; )If you are referring to cluster metadata that you mantain (this is really your only option) then the easiest solution would be to update attributes via JMX.
We are not clustering our instances yet, hence not maintaining any kind of metadata thru the cluster or any straight distributed jboss-cache usage.
Im trying to challenge several architectures to deal with that kind of subject and applicative-oriented cluster management as a whole, and that's why I want to get your expert vision on it before getting into any exotic/unnecessary implementation.
Example scenario overview :
We might have to drive a large/heterogenous transcoding-servers array in a near future. Composed by 3rd party (.Net Web services interface in general) and later proprietary (straight Jboss mdb / ejb) instances.
As of now the transcoding requests are enqueued and asynchronously processed through JMS queues, with to-be-ported spring consumers (on a single Jboss Messaging instance for now and soon 1.2GA cluster with distributed queues).
The requirements in term of processing power on the mdbs side would be low for 3rd party transacoder scenarios where the mdb mostly implements a connection to a .net WS (90% of the work is done on the transcoder side).
But we definitly need several nodes to be able to provide hot standby as a first step and then scale out if the number of transcoding servers explodes.
Another constraint is to try to optimize the computing capacity available while not exceeding it as the behaviour of these servers on load varies: some of them being able to queue /reject incoming requests, while others might crash/freeze, explaining my desire to be to try and control precisely the cluster-wide pools and/or activations.
I could open a jboss-network issue for design assistance on that subject if you want, as Id really like to get feedback from you guys, I think there is quite a few things to be said..
We're using 4.0.5 in production and Im going to contact our jboss respresentative for more insights regarding the AS roadmap (4.x and 5.0)
Best regards -
5. Re: Limit MDB max instances cluster-wide ?
I could open a jboss-network issue for design assistance on that subject if you want, as Id really like to get feedback from you guys, I think there is quite a few things to be said..
Yes, this is probably your best bet. The JCA forum is solely for JCA related issues. Anything broader than this should be addressed in a more approriate context. -
6. Re: Limit MDB max instances cluster-wide ?
Done, FYI :
https://network.jboss.com/jbossnetwork/restricted/caseDetail.html?caseId=500300000034luhAAA
I've also given that url to the clustering team on their forum.
Thanks.
Olivier