Following are the Comments for man pages:

1. configure-jms-cluster

Under Options->clustertype, it should be configstoretype instead of configstorstype

2.create-jmsdest

Under Options, remove -T option

3. create-jms-host

create-jms-host doesn't work without mqusername & mqpassword options. So example needs to be updated with those options. Are they part of passfile???

4. delete-jmsdest

remove -T option under Options

5.flush-jmsdest

remove -T option under Options

6.jms-ping, create-jms-resource etc

I am seeing the connector statements printed along with jms statements. I am not sure if they should be included in the examples.

For example:
intg-v60x-1# ./asadmin jms-ping
JMS-ping command executed successfully
Connector resource test_jms_adapter created.
Command jms-ping executed successfully.

7.list-jmsdest

remove -T option under Options

8.I am also seeing  "This subcommand is supported in remote mode only" for most of the jms commands. Is it jms REMOTE mode or something completely different? If it is jms REMOTE mode then the comment should be removed for most of the commands.

1. change-master-broker
Its probably worth mentioning here that by default the master broker is the first configured instance in the GF cluster

2. configure-jms-cluster
Remove the --force option. This is no longer valid.

3. create-jms-resource/delete-jms-resource/list-jms-resources:
config is not a valid target type. Valid targets for these commands are - server, domain, cluster_name, instance_name

Thanks for the thorough review Sarada.

RE: your comment no 8: the REMOTE mode being referred to here is the asadmin REMOTE mode not the JMS integration REMOTE mode, so this should be fine.

1. configure-jms-cluster
Done. See updated pdf.
2. create-jmsdest
Done. See updated pdf.
3. create-jms-host
Done. Discovered through trying it out that all the --mq* options are required. See updated pdf.
4. delete-jmsdest
Done. See updated pdf.
5.flush-jmsdest
Done. See updated pdf.
6.jms-ping, create-jms-resource etc
Done. See updated pdfs of jms-ping, create-jms-resource, delete-jms-resource.
7.list-jmsdest
Done. See updated pdf.
8.I am also seeing "This subcommand is ...
Done. Added the text "Remote asadmin subcommands require a running domain administration server (DAS)." as appropriate to all man pages in an effort to clarify the confusion. See updated pdfs.

1. change-master-broker
Done. See updated pdf.
2. configure-jms-cluster
Done. See updated pdf.
3. create-jms-resource/delete-jms-resource/list-jms-resources:
Done. See updated pdf.

Comments for chapter 16 Administering the Java Message Service (JMS)

Comments for chapter 1 and 10 of GlassFish High Availability Administration Guide

Comments on GF HA Guide:

1. Connection Pooling and failover (Page 157)- "By default, the JMS service selects the primary JMS host (Message Queue broker) randomly from the specified JMS host list." The above is true only for Remote mode. For EMBEDDED and LOCAL, it should be - "By default, the JMS Service selects the co-located JMS Host (MQ Broker). When failover occurs, MQ transparently transfers the load to another JMS host in the list..."

2. Page 164 "Configure the GlassFish Server cluster to use a Message Queue enhanced broker cluster with master broker by using the configure-jms-cluster(1) subcommand: asadmin --passwordfile password-file configure-jms-cluster --clustertype=enhanced
--dbvendor database-vendor-name --dbuser database-user-name --dburl database-url
--property list-of-database-specific-properties glassfish-cluster-name"

This is incorrect there is no master-broker option in enhanced broker clusters. The command will need the --configstore and --messagestore to point to JDBC

3. To Migrate Between Types of Conventional Broker Clusters (Page 162)- "If the need arises to convert from a conventional broker cluster with master broker to a conventional broker cluster of peer brokers, or the reverse, follow the instructions in 'Managing Conventional Clusters' in Oracle GlassFish Message Queue 4.5 Administration Guide." This should be changed into a note of caution and mentioned right in the beginning of this section.

Comments on GF Admin Guide:

1. Page 292:
"If the broker property name includes dots, preface the dots with backslashes (); for example, to set the imq.system.max_count property, specify imq\.system\.max_count in the set subcommand."

The '.' should be escaped with double slashes - '
' like in the following example

asadmin set server-config.jms-service.property.imq\\.admin\\.tcp
.port=12345

2. page 293: typo- JMS servuce -> JMS Service

3. Page 294: ...varhome... This location is domain-root-dir/domain-name/imq.

This varhome location is only for DAS. We will need to specify the varhome location for stand-alone instances and clustered-instances also.

4. Page 293: About JMS Host Modes:
"Local mode: the JMS Service starts the MQ broker specified ... on the same host"
You may want to add that the broker is started as a separate process.

5. Trouble shooting (page 302):
"When you start GlassFish Server, the JMS service is available but is not loaded until it is needed"

This is true only for Embedded mode. The service is started eagerly in LOCAL mode.

Comments for Message Queue Technical Overview

Comments on GlassFish High Availability Administration Guide

Chapter 1
---------

P18 "High Availability Java Message Service"

Change "Connection Pooling and Failover
The JMS service pools JMS connections automatically."
To: "Failover"

Connection pooling is nothing to do with high availability. It's a performance/resource management feature. Suggest you delete all references to connection pooling from this section.)

Change:
"For more information about JMS connection pooling and failover, see "Connection Pooling
and Failover" on page xxx."
To:
"For more information about JMS high availability, see (name of chapter 10) on page xxx."

I make more comments about chapter 10 later.

Page 19: "How GlassFish Server Provides High Availability"

In the list that follows "GlassFish Server provides high availability through the following subcomponents and features:", Add a link to "Using Message Queue Broker Clusters with GlassFish Server" on page xxx" (or perhaps to the whole of chapter 10)

I know we mentioned it earlier, but if we're listing here the ways in which GlassFish provides HA then we need to mention MQ high availability.

Page 19: "Message Queue Broker Clusters"

Change "This automatically created broker cluster is configurable to
take advantage of the different types of broker clusters supported by Message Queue."
To: "This automatically created broker cluster is configurable to
take advantage of the two types of broker clusters (conventional and enhanced) supported by Message Queue."

Change: "Additionally, Message Queue broker clusters created and managed using Message Queue
itself can be used as external, or remote, JMS hosts to provide JMS messaging high
availability to both GlassFish standalone instances and clusters."

To: "Additionally, Message Queue broker clusters created and managed using Message Queue
itself can be used as external, or remote, JMS hosts. This provides additional deployment options, such
as deploying a Message Queue broker on a different machine from the GlassFish instance, or deploying
different numbers of GlassFish instances and Message Queue brokers."

Page 20: "Highly Available Clusters"

Is it worth spelling out that in this context we're not talking about JMS HA?

Page 22: "Recovering MessageQueue"

Change "hostconfigurations" to "host configurations"

Change "maintain by Message Queue brokers" to "maintained by Message Queue brokers"

This statement that private data is stored with the GlassFish instances does not apply in the case of enhanced clusters. In that case the message data will be stored in a centralised HA database. Add that in that case you may need to follow any backup/restore procedure defined for that database.

Chapter 10: "Java Message Service Load Balancing and Failover"
-------------------------------------------------------------

I think the name of this chapter, and its introductory sentence, should refer to "High Availability", for consistency with the previous chapter.

I suggect changing the name of the chapter to "Configuring Java Message Service High Availability, Load Balancing and Failover", or, of this is too long, leave out the mention of load balancing since that's a relatively short part of the chapter.

Then change "This chapter describes how to configure load balancing and failover of the JavaMessage Service
(JMS) for use with the GlassFish Server."
to:
"This chapter describes how to configure high availability, load balancing and failover of the Java Message Service
(JMS) for use with the GlassFish Server."

Under "The following topics are addressed here:"
add a reference to Load-Balanced Message Inflow on p158.

Page 157: "For more information about JMS connection pooling and failover, see "Connection Pooling
and Failover" on page xxx."

Page 157: "Connection Pooling and Failover"

Connection pooling is nothing to do with HA (you get connection pooling in standalone instances as well). Please remote all references to connection pooling.

Change: "Connection Pooling and Failover. GlassFish Server supports JMS connection pooling and failover. The Oracle GlassFish Server pools JMS connections automatically."
To: "Connection Failover. GlassFish Server supports JMS connection failover."

Page 159: "Conventional cluster with master broker." You could add that this is the simplest to configure and is the default for a GlassFish cluster.

Page 159: "Conventional cluster of peer brokers."
I haven't seen this term before. I like it. Do the updated MQ docs (admin guide and technical overview) use the same term?

Page 160: Embedded (at bottom of page). Add the comment that there is one broker for each GlassFish instance, and that each pair is colocated in the same JVM.

Page 161: Local (at top of page). Add the comment that there is one broker for each GlassFish instance, and that each pair is colocated on the same machine.

Page 161: Remote (near top of page).
I suggest replacing "Any" with the same list as for "Local", since the use of the word "Any" suggests that there are other possibilities.

Add the comment that this option allows a different number of brokers to GlassFish instance, and that may be on different machines.

Page 161: "To Configure a Conventional Broker Cluster With Master Broker as an Embedded or Local JMS Host for a GlassFish Server Cluster"

This heading is a rather convoluted form of words. Can't we drop the words "JMS Host" (which in this context is synonymous with "Broker", and using two terms for the same thing is confusing) and change it to
"To Configure a GlassFish Server Cluster to use a conventional broker cluster with master broker"

Change "Use the configure-jms-cluster subcommand in remote mode to configure a conventional
broker cluster with master broker to service a GlassFish Server cluster that uses Embedded or
Local JMS hosts."
To: "Use the configure-jms-cluster subcommand to configure a conventional
broker cluster with master broker to service a GlassFish Server cluster that uses either Embedded or
Local brokers"

(I don't know why the words "in remote mode" were used previously)

Change "Note that this configuration, with embedded brokers, is the default for GlassFish Server clusters"

Page 161: "To Configure a Conventional Broker Cluster of Peer
Brokers as an Embedded or Local JMS Host for a
GlassFish Server Cluster"

Change heading to
"To Configure a GlassFish Server Cluster to use a conventional cluster of peer brokers"

Change "Use the configure-jms-cluster subcommand in remote mode to configure a conventional
broker cluster of peer brokers to service a GlassFish Server cluster that uses Embedded or Local
JMS hosts."
To: "Use the configure-jms-cluster subcommand to configure a conventional
broker cluster of peer brokers to service a GlassFish Server cluster that uses Embedded or Local
brokers"

Page 163: "To Change the Master Broker in a Broker Cluster
Serving as an Embedded or LocalHost"

Change to "To change the master broker in a broker cluster that uses either embedded or
local brokers"

(N.B. I'm not trying to impose my own capitalisation preferences here)

Page 163: Fix incorrect use of bold font in "If the need arises to convert froma conventional broker cluster with master broker to a conventional broker cluster of peer brokers, or the reverse, follow the instructions in"Managing
Conventional Clusters" in"

Comments for Message Queue Administration Guide Changes

The following properties were not explicitly mentioned in the func spec, please add

Connecting brokers to a cluster on command line involves starting each broker with the imqbrokerd command using the -cluster option to specify the complete list of brokers to be included in the cluster, For example the following command... (taken text from "2 If you are ..").

The value specified for the -cluster option must be the same for all brokers in the cluster.

The following steps assumes you have set the necessary broker properties (except the imq.cluster.brokerlist) in each broker instance's configuration file:

1 If using .. of peer ..

• Use the imqdbmgr ..
• Place a copy of ..
• Then start each broker with imqbrokerd using -cluster option

2 If you are using a master broker

• Start the master broker first with imqbrokerd using -cluster option
• Once the master broker is runing, start each of the other brokers in the cluster with the imqbrokerd command using -cluster option

Hey Satish,
I just updated the GenericJMSRA and WebSphere MQ section with a new graphic. I think you'll really like this one too.