Configuration & Management

[ovidiu.feodorov]

This is a thread to discuss configuration and management facilities. I put together a document that contains my thoughts on the subject: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingConfigurationAndManagementDesign. Please read and comment here.

[timfox]

Looks good.

A few comments:

1) By threadpool I'm assuming this is the pooled executor used to dispatch messages to jms clients.
(We also have another executor on the client side - how is this configured?).
I think these should be configurable but do they really need to be mbeans? I'm not convinced.
Also, I wouldn't name these thread pools, since typically they're actually pools + queues (although this should be configurable).

2) There's quite a bit of client side config. - I'm assuming this goes in the client side aop config too?

3) We need some way of configuring jms connection factories - currently these are hard coded - I would imagine redeployable mbeans are appropriate here (like in JBossMQ)

4) Destination MBeans (Queue and Topic) seem to be missing from the wiki page. I'm asumming they exist and have a lifecycle (are redeployable a la JBossMQ)

5) Default JBoss5 connector. Our default connector is going to be multiplex so I don't think we can use this (it is a socket transport).
I think we should define our own default connector as an MBean in our config. and use that (i.e. have no dependency on the default JBoss5 one)
Moreover the multiplex transport is configured somewhat differently to the socket one - I'm not sure if switching from multiplex to socket is going to be as simple as just changing the Connector config. There may be programmatic changes in the code necessary to get this to work (I am investigating this now).

6) Queue and Topic config. There is a whole set of config local to Queues and Topics - e.g. related to lazy loading, queue depth, receiversimpl stuff etc. This is not specified on the wiki page - I guess this is a TODO?

[ovidiu.feodorov]

1) By threadpool I'm assuming this is the pooled executor used to dispatch messages to jms clients.
(We also have another executor on the client side - how is this configured?).

Yes, the thread pool I am talking about in the document is the (current) server-side pooled executor. I updated http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingConfigurationAndManagementDesign
to include client-side pool configuration ("Client-side Configuration" section)

I think these should be configurable but do they really need to be mbeans? I'm not convinced.

The partial list of managed attributes for a thread pool implementation based on the concurrent's PooledExecutor is: PoolSize, MaxPoolSize, MinPoolSize, KeepAliveTime.

JBossMQ has its own implementation of a thread pool that comes with its own configuration parameters (MinimumPoolSize, MaximumPoolSize, QueueSize, MaximumQueueSize, BlockingMode, ThreadGroupName, KeepAliveTime).

Just these two examples should be sufficient to demonstrate the usefulness of deploying the thread pool as separate MBeans: an XMBean's (or a simple StandardMBean's) management interface is generated dynamically so it won't be necessary to modify ServerPeer's management interface to accommodate a new ThreadPool implementation.

Again, the fact that an arbitrary ThreadPool implementation is deployed as a service doesn't mean the ThreadPool will be hot redeployable, nor does it need to be. The effects of a thread pool hot redeployment on the messaging core are hard to predict and no such feature is necessary. The ServerPeer will get a hard reference to the ThreadPool during its start() sequence, and that would be all.

Also, I wouldn't name these thread pools, since typically they're actually pools + queues (although this should be configurable).

OK. What do you suggest?

2) There's quite a bit of client side config. - I'm assuming this goes in the client side aop config too?

See "Client-side configuration" in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingConfigurationAndManagementDesign

3) We need some way of configuring jms connection factories - currently these are hard coded - I would imagine redeployable mbeans are appropriate here (like in JBossMQ)

This is a good idea. However, the "ConnectionFactory MBean" will be much more lightweight than JBossMQ's since in our case the transport support has already been deployed. I added a Connection Factories" paragraph to the wiki document that describes how I would do it.

4) Destination MBeans (Queue and Topic) seem to be missing from the wiki page. I'm assuming they exist and have a lifecycle (are redeployable a la JBossMQ)

6) Queue and Topic config. There is a whole set of config local to Queues and Topics - e.g. related to lazy loading, queue depth, receiversimpl stuff etc. This is not specified on the wiki page - I guess this is a TODO?

For the time being we are recycling (and I don't see a good reason to change that) JBossMQ destination deployment descriptors. They have support for all configuration parameters you mentioned, and even if some of them may need adjusting to our implementation, that's the way (and place) to do it.

5) Default JBoss5 connector. Our default connector is going to be multiplex so I don't think we can use this (it is a socket transport).
I think we should define our own default connector as an MBean in our config. and use that (i.e. have no dependency on the default JBoss5 one)

This is a non-issue. ServerPeer is configured with ObjectName of the connector to use. It doesn't care if it's the default JBoss5.0 connector or a new one deployed specifically for it. We only need to deploy our own, if we want to. We already doing this for a JBoss 4.0 scoped deployment, since the remoting available in JBoss 4.0 is too old to be useful.

[timfox]

Also, I wouldn't name these thread pools, since typically they're actually pools + queues (although this should be configurable).

OK. What do you suggest?

Executor? (Borrowing from Doug Lea) - Actually I don't really have a strong opinion on this.

2) There's quite a bit of client side config. - I'm assuming this goes in the client side aop config too?

See "Client-side configuration" in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingConfigurationAndManagementDesign

There are some config. params (such as numbe of messages to buffer in a BrowserInterceptor) who's natural home is in the normal jboss aop interceptor configuration in the client aop xml file.
However, as you point out it would be nice to be able to specify these on a per connection factory basis.
How about if the client aop xml file provides the default values which can be overridden in the connection factory config if specified.

5) Default JBoss5 connector. Our default connector is going to be multiplex so I don't think we can use this (it is a socket transport).
I think we should define our own default connector as an MBean in our config. and use that (i.e. have no dependency on the default JBoss5 one)

This is a non-issue. ServerPeer is configured with ObjectName of the connector to use. It doesn't care if it's the default JBoss5.0 connector or a new one deployed specifically for it. We only need to deploy our own, if we want to. We already doing this for a JBoss 4.0 scoped deployment, since the remoting available in JBoss 4.0 is too old to be useful.

I am currently trying to make our code 100% agnostic to the remoting transport in use, so we can just specify the Connector in the config as you described on a per connection factory basis.
This is a little tricky with multiplex since it requires specific parameters on the locator uri to match up connections - but hopefully will be doable.

[ovidiu.feodorov]

Also, I wouldn't name these thread pools, since typically they're actually pools + queues (although this should be configurable).

OK. What do you suggest?

Executor? (Borrowing from Doug Lea) - Actually I don't really have a strong opinion on this.

Let's leave it to ThreadPool. This is how most people call it anyway.

[ovidiu.feodorov]

There are some config. params (such as numbe of messages to buffer in a BrowserInterceptor) who's natural home is in the normal jboss aop interceptor configuration in the client aop xml file.
However, as you point out it would be nice to be able to specify these on a per connection factory basis.
How about if the client aop xml file provides the default values which can be overridden in the connection factory config if specified.

Yes. You can always specify aspect initialization values in the aop.xml file, no extra work is needed for that. Those will be the defaults. The values specified in the ConnectionFactory MBean deployment descriptor will override the defaults.

[ovidiu.feodorov]

JIRA tasks

http://jira.jboss.org/jira/browse/JBMESSAGING-201
http://jira.jboss.org/jira/browse/JBMESSAGING-202
http://jira.jboss.org/jira/browse/JBMESSAGING-203
http://jira.jboss.org/jira/browse/JBMESSAGING-204
http://jira.jboss.org/jira/browse/JBMESSAGING-205
http://jira.jboss.org/jira/browse/JBMESSAGING-209
http://jira.jboss.org/jira/browse/JBMESSAGING-207

[ovidiu.feodorov]

Tim,

I was playing with new destination management interface and remembered some requirements from conversations with users. I updated the "Destinations" paragraph of the configuration wiki page http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingConfigurationAndManagementDesign. Please let me know what you think. It's not more than a half day work to implement that and I think I'll go for it.