| 01234567890123456789012345678901234567890123456789012345678901234567890123456789
1. Introduction
1.1. Project/Component Working Name:
Sun Java System Message Queue integration 1.2. Name(s) and e-mail address of Document Author(s)/Supplier:
Sivakumar Thyagarajan [sivakumart@dev.java.net, sivakumart@Sun.COM]
with inputs from Binod PG, Ramesh Parthasarathy. 1.3. Date of This Document:
v0.8 - Aug/11/06
v0.9 - Aug/28/06 (Clarified DIRECT mode and 4.1.iii)
v1.0 - Nov/08/06 (Clarified updates from asarch and added section
on ConfigurableTransactionSupport SPI) 2. Project Summary
2.1. Project Description:
To outline the new features in the application server to enable
tighter integration of Sun Java System Message Queue 4.1,
especially in the areas of improving MDB/JMS performance and
HA AS/MQ clusters. 2.2. Risks and Assumptions:
The integration depends on timely deliverables of binaries from
the MQ team. 3. Problem Summary
3.1. Problem Area:
Enteprises increasingly require a performant and highly available
JMS/MDB path for their loosely coupled JMS/Java EE applications.
To address these requirements the key goals of the next generation
Sun Java System Message Queue, based on Project Open Message Queue
https://mq.java.net are around providing enhanced performance
by closely integrating with the application server's runtime [when
housed within the appserver] and providing a new Highly Available
cluster type. This project aims to integrate this version of the
Message Queue project with the application server. 3.2. Justification:
Enhanced performance in the MDB/JMS path, out-of-the-box easy
configuration of AS/MQ clusters. 4. Technical Description:
4.1. Details:
i. "DIRECT" AS/MQ integration mode
One of the optimizations planned is to bypass the networking stack
for JMS operations when the application server and the
JMS broker is co-located in the same VM. This would enable all JMS
operations within a co-located setup to not incur the overhead of
inter-socket communication and would result in a much more performant
system for low-end deployments. To support this form of integration,
the current EMBEDDED mode would be modified to act as the new DIRECT
mode. (A system property to revert to non-DIRECT mode would also be
provided for backward compatability reasons) PE and EE DAS would continue to have EMBEDDED as the default. Clustered
and standalone server instances by default would be LOCAL. EMBEDDED
would be available as an option for clustered and standalone server
instances but would not be tested as a primary configuration. ii. HA cluster support in AS EE
The "Highly Available" cluster type to be available in SJSMQ 4.1 would
provide a peer-to-peer broker cluster topology with a shared persistent
data store offering "Data Availability". The "HA-Cluster" mode also does
away with the master broker topology supported in SJSMQ 3.6. In this
release we would allow "auto-clustering" feature as explained in
"4.1.1.4 SJSMQ high availability cluster support in SJSAS9.0" of the AS
9.0 "Connectors and JMS" functional specification when the administrator
chooses to have a HA AS/MQ cluster. A table showing all possible
AS/MQ integration options, and their pros/cons is available at
http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=AppserverMqIntegrationOptions iii. "Auto-clustering" for non-HA AS/MQ clusters
In SJSAS 8.x, non-HA MQ clusters [traditional master broker styled MQ
clusters] had to be setup separately from the AS cluster by the
administrator. Since the common use-case is to have a MQ cluster
associated with an AS cluster, this release would automatically create a
LOCAL (co-located) non-HA cluster while a user creates an AS cluster
by default. Therefore when an adminstrator creates an AS cluster with 3 AS
instances, each AS instance would be configured to work with a LOCAL
broker, and the result 3 MQ broker instances would be made to form a
MQ cluster transparently. The first AS instance's MQ broker would be
set to be the master broker. The user has to use MQ's tools to migrate the
master broker should they choose to delete the first cluster instance
(instance that hosts the master broker). See discussion at
http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=NonHA_ASMQ_Clustering
for more information. iv. ConfigurableTransactionSupport SPI
To support MQ RA and other resource adapters to understand the current
transactional context in which a ManagedConnectionFactory is used, a new
appserver SPI interface
com.sun.appserv.connectors.spi.ConfigurableTransactionSupport would be
provided. Please see
http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=ManagedConnectionFactoryContext
for more details. 4.2. Bug/RFE Number(s):
None 4.3. In Scope: 4.4. Out of Scope: 4.5. Interfaces: 4.5.1 Exported Interfaces 4.5.2 Imported interfaces
This integration depends on the interfaces exposed by the Sun Java
System Message Queue Resource Adapter for broker lifecycle control,
MQ "HA-cluster" integration. 4.5.3 Other interfaces (Optional) 4.6. Doc Impact:
Application Server's Developer's Guide and Administration Guide. 4.7. Admin/Config Impact:
Changes to the admin GUI to indicate
- new integration mode
- HA related changes
4.8. HA Impact:
Enhanced HA. See also the last note on 4.1.iii 4.9. I18N/L10N Impact:
None 4.10. Packaging & Delivery:
None 4.11. Security Impact:
None 4.12. Compatibility Impact
None 4.13. Dependencies:
Dependent on Sun Java System Message Queue 4.1 5. Reference Documents:
Sun Java System Application Server 9.0 "Connectors and JMS" Functional
Specification 6. Schedule:
6.1. Projected Availability:
Aligns with GlassFish V2/Sun Java System Application Server
9.1 schedule |
