[GLASSFISH-15686] using "configure-jms-cluster" in a non-recommended way could leave the system in inconsistent state Created: 25/Jan/11  Updated: 19/Sep/14  Resolved: 09/Jun/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b38
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: mathim Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

tested on Oracle Enterprise Linux 5 (but the issue is platform independent)


Tags: 3_1-exclude, 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude, bj-reviewed-t2, glassfish-3-1, jms

 Description   
  • Create a glassfish cluster
  • Create instances
  • use configure-jms-cluster to configure the cluster not to use Master Broker
    The command printed the following warning.

"WARNING: Please ensure that you have followed the instructions specified in the documentation before running this command with this option. Running this command without the required precautions can lead to inconsistent JMS behavior and corruption of configuration and message stores."

The above warning message doesn't say much. There is no way one would know what is wrong. The command doesn't mention that there are instances associated with the cluster and the command need to be executed before creating the instances.

Above all, the command executed and returned successfully.

When the test started the glassfish cluster after this command, the MQ Broker on two of the glassfish instances started with no master broker option and the MQ Broker on the third glassfish instance started with Master Broker Option. The third broker was waiting indefinitely to sync up with the Master Broker. it doesn't happen on all the systems. but can be consistently reproduced on the systems on which it shows up.

command probably should stop executing if it detects the conditions are not met and print clear messages, rather than leaving the system in insistent state.



 Comments   
Comment by Nazrul [ 25/Jan/11 ]

Not a stopper. Excluding from 3.1 count.

Comment by Satish Kumar [ 24/May/11 ]

This is not a bug but a RFE request.

While the consequences of running this command on an existing cluster are well documented, there is potential to make this command more intelligent and handle error conditions betters. However, this work is out-of-scope for the 3.1.* release and would be looked at as a enhancement request in a later release. Hence marking this issue as 3_1-next.

Comment by Satish Kumar [ 08/Jul/11 ]

Downgrading the priority of this issue since it is not critical for the 3.1.1 release. Also, the current functionality of configure-jms-cluster command and the issue being reported here is by design. This is more of a RFE request. We can look at improving this functionality in a future release.

Comment by David Zhao [ 09/Jun/13 ]

Fixed.

Check instances running.
Revise warning message if there are instances running.

Generated at Thu Dec 08 08:30:12 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.