| GlassFish JMS Integration 1.2. Name(s) and e-mail address of Document Author(s)/Supplier: Satish Kumar (kumar.satish@oracle.com) 1.3. Date of This Document: 04/25/11 1.4. Revision History 2. Project Summary 2.1. Project Description: This document captures the changes and enhancements that are proposed to the GlassFish JMS module for the 3.2 release. 2.2. Risks and Assumptions: 3. Problem Summary 3.1. Problem Area: The PaaS based architecture of GlassFish 3.2 introduces a whole new set of challenges on MQ and the GF JMS module. While MQ clusters have traditionally supported up-scaling well, down-scaling should be done with caution since, in conventional MQ clusters, the message store is local to each broker. A MQ broker cannot be decommissioned without migrating the message store over to another broker. Conventional clusters with Master broker introduce additional complexity since one of the brokers in the cluster is designated as a master broker and this broker stores all the configuration related data in its local file store. We should ensure that the MQ instance being removed is not the master broker and if at all this needs to be removed, the config data store is migrated over to another broker instance which would then get designated as the master broker. Enhanced MQ clusters alleviate this problem by using a centralized HA database for both message and config store. But, using this mode requires a separate HA database to be provisioned. Also, there are significant performance differences between conventional and enhanced clusters. Hence, this mode of clustering may not be suitable for users. Following enhancements need to be introduced in GlassFish 3.2 to address some of these concerns :
- MQ service plugin to handle discovery and management of GlassFish MQ in a PaaS environment
- GF integration support for MQ conventional clusters with Berkeley DB as Broker Persistent Store
- IaaS machine templates for GlassFish MQ
- Support for message-store migration through GF
- Integrating existing MQ broker metrics with GF monitoring framework
3.2. Justification: These changes are required to allow MQ to work with GlassFish in a cloud based environment which is the main theme of the 3.2 release. 4. Technical Description: 4.1. Details: The following features and enhancements are planned for the GlassFish JMS module in the 3.2 release: MQ service plugin This is a plugin into the Service orchestrator to help in the discovery, provisioning and management of the JMS service through GlassFish MQ. JMS service dependency discovery: This can either be explicit or implicit. Applications can indicate the need for JMS services implicitly via <resource-ref> in standard deployment descriptors of web/ejb modules or its annotation equivalents or in sun-resources.xml or explicitly through the cloud.xml. Provisioning: Provisioning of a JMS service would depend on the JMS integration mode being used. We currently support three integration modes - Embedded (default in GF 3.1 for stand-alone and clusters), Local and Remote. In Embedded and local modes, MQ is provisioned along with GF instances. A MQ cluster is auto-created along with a GlassFish cluster. There is a one-one correlation between GF instances and MQ instances in these two integration modes with each GF instance associated with one MQ instance. Hence, in these two integration modes, MQ cannot have a separate set of elasticity rules. Remote mode of integration offers more flexibility in terms of elasticity since the cluster size is not dependent on GlassFish. However, since elasticity of non-GF services is out-of-scope for this release, no support for elasticity will be provided in this mode. For the 3.2 release, the embedded mode continues as the default mode of MQ integration. The JMS cluster is lazily initialized as was the case in 3.1. We continue support the LOCAL mode of integration where the MQ instance is co-located with the GF instance but starts as a different process. Remote mode is supported where the MQ cluster has been provisioned and managed separately by the user. No support is provided for managing this remote MQ cluster or for elasticity of this cluster. Adding a new MQ instance to the cluster would require the addressList (connectionURL) to be updated with the new broker information. In EMBEDDED and LOCAL integration modes, a new MQ instance will need to be provisioned along with GF. All the brokers in the cluster will need to updated with a new broker address list when a new instance is added to the cluster. JMSRA is proposing to introducing a new property (connectionURL) that needs to be updated when an instance is added/removed from the cluster. The JMSRA changes are covered in a separate one-pager http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Updating+client+addressList+when+broker+is+added+or+removed+to+or+from+a+cluster. Removing a MQ broker from the cluster:
As mentioned previously (in section 3.1) removing a MQ broker needs the migration of the message store to another broker in the cluster before it can be physically deleted. Also, like in the previous case, the addresslist will need to be updated. Two types of removals are possible - soft removal and hard removal. A GF/MQ instance may be temporarily stopped based on elasticity rules but may not be physically deleted. In this case, the messages remain with the local broker and are delivered when the broker is restarted. Message-store migration is not required in this case. However, when a GF/MQ instance is physically deleted, the MQ plugin would need to migrate the message store over to another broker before the physical delete happens. Also, the MQ plugin will need to ensure that the broker instance being stopped or deleted is not the master broker of the cluster. Auto-creation of JMS resources and destinations: Auto-configuration of JMS related connection factories and connection pools based on resource-refs (where the resource adapter being used is JMSRA) are to be handled by the GlassFish plugin. The modalities for this are still TBD. Auto-creation of JMS destinations and related admin-objects are to be handled by the MQ service plugin. The details of whether this will result in auto-created destinations or pre-created destinations are TBD. * GF integration support for MQ conventional clusters with Berkeley DB as Broker Persistent Store MQ 4.6 is introducing support for Oracle Berkeley DB as a persistent store type to address the elasticity requirements. BDB is a light-weight, highly scalable, embeddable, transactional database with a very low memory foot-print. The details of this feature are covered in the MQ one-pager - http://jpgserv.us.oracle.com/MQ4.6/engineering//onepagers/bdb-store.txt.
This requires changes to the configure-jms-cluster CLI command to enable users to configure this option and to the broker start-up properties that are passed in from the ActiveJMSResourceAdapter at start-up time. A new broker property is being introduced - imq.persist.store=bdb. Message-store migration A new GlassFish CLI command is being proposed for this -
asadmin migrate-message-store --sourceinstance --targetinstance --time --target sourceinstance - the instance name of the GF instance whose message-store has to be migrated
targetinstance- the instance name of the GF instance to which the message-store has to be migrated.
time - the timeout interval for this command.
target - this command can only be run on a cluster. Hence, this should be the name of the affected cluster. The command will call the MQ implementation of the imqcmd command - migratestore through JMX. The details of this command are covered in the MQ one-pager - http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/MQ+Administrative+Store+Migration IaaS machine templates for GlassFish MQ In order to support MQ on various cloud providers, it is necessary to have pre-bundled machine templates of GlassFish MQ that could be used by the GlassFish runtime. These machine templates need to be created according the common guidelines/ best practices laid by IaaS team. For GlassFish 3.2, the plan is to ship templates for GlassFish MQ with JMSRA. Templates for other JMS providers and resource adapters are out-of-scope for this release. The list of cloud providers that need to be supported is still TBD. Integrating MQ monitoring statistics with GF monitoring framework The MQ broker provides a rich set of monitoring statistics that are currently not accessible through GF. A majority of these stats are implemented as JMX MBeans while a smaller number of them are only accessible through the MQ command line. In this release, we plan to provide access to these MQ monitoring statistics through the GF monitoring framework. The GF JMS module will implement the StatsProvider interface and will act as a proxy for these JMX MBeans. The primary focus will be on providing accessibility to the JMX enabled stats. Access to the non-JMX metrics will require code changes from MQ by either making these available through JMX or providing an alternative interface. This approach offers the following advantages:
- Leveraging existing metrics without any code changes to MQ
- No requirement for MQ to be repackaged as an OSGi module
- Since this approach is based on JMX, this approach will work in all three integration modes- Embedded, Local and Remote.
4.2. Bug/RFE Number(s): TBD 4.3. In Scope: 4.4. Out of Scope: Elasticity of remote MQ clusters
Managed remote mode MQ clusters
Elasticity of MQ clusters in non-BDB modes 4.5. Interfaces: 4.5.1 Public Interfaces 4.5.2 Private Interfaces 4.5.3 Deprecated/Removed Interfaces: 4.6. Doc Impact: 4.7. Admin/Config Impact: Config changes for the new persistent store type - BDB
Changes to configure-jms-cluster command to enable configuration of BDB as persistent type 4.8. HA Impact: 4.9. I18N/L10N Impact: 4.10. Packaging, Delivery & Upgrade: 4.10.1. Packaging 4.10.2. Delivery 4.10.3. Upgrade and Migration: 4.11. Security Impact: 4.12. Compatibility Impact 4.13. Dependencies: 4.13.1 Internal Dependencies MQ features for BDB persistent store
MQ feature for message-store migration
Service orchestrator SPI for plugins.
IaaS framework for templates TBD 6.1. Projected Availability: |
