JBossMQ management of general settings

[ccrouch]

Lets use this thread to discuss how to implement the management of some of the general attributes of the JBossMQ service.

The attributes I'm thinking we need to manage are the following
1) Cache Manager: High Memory Mark
2) Cache Manager: Max Memory Mark
3) Persistence Manager: DataSource
4) Persistence Manager: Connection Retry Attempts
5) State Manager: DataSource
6) Security Manager: Security Domain
7) Security Manager: Default Security Config, i.e. Role Name, Read Permission, Write Permission, Create Permission.

All these attributes are available via the corresponding service MBeans under the jboss.mq domain. The next questions are which actual xml configuration files hold the persistent values of these attributes, and how we should go about update those files using the DeploymentService.

Thoughts?

[jc2005]

The general attributes of the JBossMQ service for the admin console to manage will include but not limit to the attributes available from the service MBeans under the jboss.mq domain:

1. Cache Manager
2. Persistence Manager
3. State Manager
4. Security Manager

The following sections list the attributes available via the MBeans and the xml configuration files that hold the persistent values of these attributes.

1. Cache Manager

MBean: jboss.mq:service=MessageCache

Attributes:

HighMemoryMark
MaxMemoryMark
CacheStore (default: jboss.mq:service=PersistenceManager)
MinimumHard
MaximumHard
SoftenAtLeastEveryMillis
SoftenNoMoreOftenThanMillis
MakeSoftReferences
SoftenWaitMillis

XML configuration file:

- Assume that the default Hypersonic database is used for message cache and persistence

For ?default? server config:
%jboss_home%/server/default/deploy/jms/hsqldb-jdbc2-service.xml

For ?all? server config:
%jboss_home%/server/all/deploy-hassingleton/jms/hsqldb-jdbc2-service.xml

The MBeans and attributes and dependant?s optional attributes included in the xml configuration file are:

MBean - jboss.mq:service=DestinationManager
MessageCache
PersistenceManager
StateManager

MBean - jboss.mq:service=MessageCache
HighMemoryMark
MaxMemoryMark
CasheStore (default: jboss.mq:service=PersistenceManager)

MBean - jboss.mq:service=PersistenceManager
ConnectionManager (default: jboss.jca: name=DefaultDS,service=DataSourceBinding)
SqlProperties
RecoveryTimeout

- If a different database is to be used, the corresponding xml configuration file can be found at
%jboss_home%/doc/examples/jms


2. Persistence Manager

MBean: jboss.mq:service=PersistenceManager

Attributes:

SqlProperties
ConnectionRetryAttempts
ConnectionManager (default: jboss.jca:name=DefaultDS,service=DataSourceBinding)
RecoveryRetries
RecoveryTimeout
MessageCache

XML configuration file: see Cache Manager


3. State Manager

MBean: jboss.mq:service=StateManager

Attributes:

SqlProperties
ConnectionManager (default: jboss.jca:name=DefaultDS,service=DataSourceBinding)


XML configuration file:

- Assume that the default Hypersonic database is used for message persistence.

For ?default? server config:
%jboss_home%/server/default/deploy/jms/hsqldb-jdbc-state-service.xml

For ?all? server config:
%jboss_home%/server/all/deploy-hassingleton/jms/hsqldb-jdbc-state-service.xml

The MBeans and attributes and dependant?s optional attributes included in the xml configuration file are:

MBean - jboss.mq:service=StateManager
ConnectionManager (default: jboss.jca:name=DefaultDS,service=DataSourceBinding)
SqlProperties


- If a different database is to be used, the xml configuration file will be the same as the hsqldb-jdbc-state-service.xml with the only difference in the value of the ?SqlProperties? attribute with respect to the DDL and DML of the selected database.


4. Security Manager

MBean: jboss.mq:service=SecurityManager

Attributes:

SecurityDomain
DefaultSecurityConfig
NextInterceptor

XML configuration file:

For ?default? server config:
%jboss_home%/server/default/deploy/jbossmq-service.xml

For ?all? server config:
%jboss_home%/server/all/deploy-hassingleton/jms/jbossmq-service.xml

Note: The security configuration data of a destination is stored at the following locations -
for the pre-configured destinations: deploy/jms/jbossmq-destination-service.xml
for an admin-console-created destination: deploy/deployment-service/xxxx-service.xml.
The jms destination module of the admin-console manages these security config data.

The MBeans and attributes and dependant?s optional attributes included in the xml configuration file are:

MBean - jboss.mq:service=Invoker
NextInterceptor

MBean - jboss.mq:service=TracingInterceptor
InterceptorClass
NextInterceptor

MBean - jboss.mq:service=SecurityManager
DefaultSecurityConfig
SecurityDomain
NextInterceptor

MBean - jboss.mq:service=ThreadPool
Name
ThreadGroupName
MaximumPoolSize
MaximumQueueSize
BlockingMode

MBean - jboss.mq:service=ClientMonitorInterceptor
ClientTimeout
NextInterceptor

MBean - jboss.mq:service=ClientReconnectInterceptor
InterceptorClass
NextInterceptor

MBean - jboss.mq.destination:service=Queue,name=DLQ
DestinationManager
SecurityManager

[ccrouch]

Great work Jack. Very detailed, if slightly indentation-challenged :-), information.

By analysing the above one can see that the current DeploymentService implementation is going to be insufficient for our needs with respect to managing the general JBoss MQ configuration.

Looking at 4) above, consider that we want to update the SecurityDomain on JBossMQ's security manager. This means we need to update the XML configuration file changing...

<attribute name="SecurityDomain">java:/jaas/jbossmq</attribute>

to be something else, e.g.

<attribute name="SecurityDomain">java:/jaas/new_jbossmq</attribute>

However as Jack outlines in 4) there are a myriad of other MBeans also defined in this file, e.g. jboss.mq:service=TracingInterceptor, which we don't care about when updating the SecurityDomain. Using the DeploymentService's current implementation, where updating of a file is achieved by an undeploy followed by a create, we would have to keep track of all of the information related to these ancillary MBeans so they would not be lost during an "update". In general this would not be possible since users may have added additional MBeans definitions to this file which we won't know about when building our Deployment Service Velocity template. Therefore I suggest that a true update operation be added the Deployment Service which supports updating the contents of part of a configuration while leaving the rest untouched.

Thoughts on how an update function for the Deployment Service could be implemented?

Thanks