[GLASSFISH-16962] Adding an instance to cluster causes false indication to restart other cluster instances Created: 06/Jul/11  Updated: 02/Dec/11  Resolved: 08/Jul/11

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1_b11
Fix Version/s: 3.1.1_b11, 4.0

Type: Bug Priority: Major
Reporter: lidiam Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

ogs-3.1.1-b11-07_04_2011-aix.zip, Firefox 5 on Windows XP

Attachments: File server.log.cl1in1     File server.log.das    
Tags: 3_1_1-approved, 3_1_1-verified


When a new instance is added to an existing cluster, status for all previously running instances is changed from "running" to "restart required". Adding an instance to a cluster should not require cluster restart. This is specifically problematic, since user cannot look up the reason for restart required messages for instances other than DAS in Admin Console.

Steps to reproduce:

In Admin Console:
1. Create a cluster with one instance, e.g. cl1 with cl1in1, on localhost-domain1 node.
2. Start cluster.
3. Go to cluster cl1, Instances page and click on New.
4. Fill in the instance name, e.g. cl1in2, and click OK. Note that after creation page with instances is displayed and the existing instance, cl1in1, has status "restart required".

The same status is reported by CLI:

/export/sqe/lidia/glassfish3/glassfish/nodes/localhost-domain1/cl1in1/logs % asadmin list-instances
in1 running
cl1in1 running; requires restart
cl1in2 not running

No errors or warnings are present in DAS server.log and the following warning is present in the first clustered instance server.log (cl1in1):

_ThreadName=Thread-9;|Unprocessed event : UnprocessedChangeEvent

{PropertyName=sy stem-property, OldValue = null, NewValue = GlassFishConfigBean.com.sun.enterpris e.config.serverbeans.SystemProperty, Source = GlassFishConfigBean.com.sun.enterp rise.config.serverbeans.Server}

, reason = The system-property, OSGI_SHELL_TELNET
_PORT, that is referenced by the Java configuration, was modified, when = 130991

Comment by Tom Mueller [ 06/Jul/11 ]

Confirmed the reported behavior.

The root cause of this problem is that the GenericJavaConfigListener assumes that it is receiving SystemProperty change events only for its own system properties. However, it also receives change events for other instances that are added to the configuration. To fix this, it needs to ignore those events.

Comment by lidiam [ 06/Jul/11 ]

Changed Summary to better reflect the problem. Also, this is a regression compared with Glassfish 3.1 b43.

Comment by Tom Mueller [ 07/Jul/11 ]

The reason why this bug doesn't show up in 3.1 but does show up in 3.1.1 is because there was a mistake in the implement of the fix for issue GLASSFISH-15987 which was implemented during the 3.1.1 release cycle.

Why fix this issue in 3.1.1?
This is a regression of functionality from a previous release (3.1).

Which is the targeted build of 3.1.1 for this fix?
Build 11

Do regression tests exist for this issue?

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Tests related to changing system-properties that are referenced by JVM options.

Comment by Tom Mueller [ 08/Jul/11 ]

Fixed in revision 47933 on the trunk
and in revision 47934 on the 3.1.1 branch.

Comment by lidiam [ 12/Jul/11 ]

Verified in promoted build ogs-3.1.1-b11-aix.zip.

Generated at Mon Oct 05 18:13:51 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.