[GLASSFISH-18234] Restart required not cleared with instance restart Created: 21/Jan/12  Updated: 26/Jan/12

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2_b18
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lidiam Assignee: Byron Nevins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Attachments: Text File server.log.txt    
Tags: 312_qa, 312_regression, 3_1_2-exclude


Restart required is not cleared with instance restart but it is cleared when executing stop and then start instance. Steps to reproduce:

1. Follow steps from issue 18233 to get a clustered instance in restart required state, since it's inconsistent right now.
2. Go to clustered instance page and click on Restart button. After server restarts, the instance is still displayed as requiring restart.
3. Click on Stop and then Start buttons. Now the instance is reported as running.

This does not work in CLI either:

  1. asadmin list-instances
    Enter admin password for user "admin">
    cll01 running; requires restart
    clj01 running
    Command list-instances executed successfully.
  2. asadmin restart-instance cll01
    Enter admin password for user "admin">
    cll01 was restarted.
    Command restart-instance executed successfully.
  3. asadmin list-instances
    Enter admin password for user "admin">
    cll01 running; requires restart
    clj01 running
    Command list-instances executed successfully.

There are no errors in server.log

Comment by Tom Mueller [ 25/Jan/12 ]

The cause of this is that synchronization is not working with restart-instance. The restart-instance command does not pass a limited use token to the _restart-instance command that runs on the instance, so it does not pass it to start-local-instance, so start-local-instance is unable to authenticate with the DAS to do resynchronization. This means that the restart required flag is not cleared on the DAS when the instance is restarted.

Comment by Tom Mueller [ 26/Jan/12 ]

Byron, please take a look at whether there would be a simple fix for this for 3.1.2.
If not, we'll defer this for 3.1.2 and fix it on the trunk only.

Comment by Joe Di Pol [ 26/Jan/12 ]

Since this isn't a 3.1.2 stopper I'm excluding it. If we happen to quickly come up with a simple, low risk fix we can revisit this for 3.1.2.

Comment by Byron Nevins [ 26/Jan/12 ]

1-2 days work to implement a solution.
1 day for thorough testing and adding devtests.
Total = 3 days

Notes -

see NodeRunner.java ~~ line 150 to see how to make a token
JavaClassRunner in common-util needs to be expanded to allow writng lines to stdin
restartinstance.java needs tocall restartrestartinstance with the magic temp. certificate.
restartrestartinstance then calls JavaClassRunner's new ctor (see below) with the "stdinlines"

Why is this hairy?

  • Have to handle the case where the instance was originally started with --_auxinput. I.e. can't just blindly add the follo9wing to the process command line:
    "--_auxinput -"
  • 90% of the code is handling NON-ASADMIN ways of starting:
    java -jar glassfish.jar
    etc., etc.
    Is the auxinput going to work for these non-asadmin calls? Needs plenty of testing.


Comment by Byron Nevins [ 26/Jan/12 ]

Definitely exclude this from 3.1.2

Comment by Byron Nevins [ 26/Jan/12 ]

The question was asked:

"Why doesn't restart-instance just do stop-instance followed by start-instance"?

1) Feature – we remember to restart with exactly the same possibly long & complicated list of arguments. A plain start could not do that.

2) if the instance is running in verbose mode, the output window is elegantly re-used (try it). It would be impossible with a plain start at least on Windows.

3) you can start many different (non-asadmin) ways and it will work.

4) This is the big one. If the instance is remote and is using a config node (i.e. no SSH, no DCOM) then once you stop the instance – that's it. You can never start it again from DAS. User has to go to the remote.

Comment by Byron Nevins [ 26/Jan/12 ]

One final note. When restart was implemented there was no such temporary security token. When that code was added for start-xxx, restart was not included in the change!

Comment by Tom Mueller [ 26/Jan/12 ]

To reproduce:

1. start the domain, change the admin password to something, create a node on another host, create an instance i1

2. start the instance

3. do something to cause the restart-required flag to be set, such as:
asadmin set-log-attributes --target i1-config com.sun.enterprise.server.logging.GFFileHandler.rotationTimelimitInMinutes=3

4. restart the instance:

asadmin restart-instance i1

5. look at the status of the instances:

asadmin list-instance -l

Observer that the restart-required flag is still set on i1.

If you turn on the admin logging (javax.enterprise.system.tools.admin.level=FINE) then you will see log messages in the log that show that a user was not able to login from the host that is running the instance. These are the _synchronize-instance commands that are failing.

[GLASSFISH-15638] Show "restart required" status when IIOP service configuration / port is changed Created: 20/Jan/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b38
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Harshad Vilekar Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude, 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude


Per Admin Guide, "Impact of Configuration Changes" section, Configuration Changes That Require Server Restart include: Managing IIOP services.

However, "restart required" is not indicated by Admin CLI/GUI when IIOP service configuration is changed.

Example Steps:

on Admin Console

Click Server Config - ORB - IIOP Listeners - orb-listener-1 - Listener Port - Change to "3702" - Save

Expected: Restart Required notification is displayed.

Comment by Anissa Lam [ 20/Jan/11 ]

Can you tell me which 'Admin Guide' and the location of this doc ?
Maybe this is a doc bug, i think most configuration change is dynamic now.

Comment by Harshad Vilekar [ 21/Jan/11 ]

The link to the Admin Guide that I got from the DOC team (included in GLASSFISH-15516) worked earlier - but is broken as of yesterday. Let's get the updated link from the Doc team (I just sent separate email to Paul).

If somebody can send out the list of the the configuration changes that are changed to "dynamic" as of 3.1 - that information will be very useful. Restart required notification is not generated for most of the config changes that are listed in the "Oracle GlassFish Server 3.0.1 Administration Guide" under section "Configuration Changes That Require Server Restart".

Comment by Harshad Vilekar [ 21/Jan/11 ]

Admin Guide:
> On 01/21/11 09:52, Paul M Davies (Oracle) wrote:
> Here's the link to this information in its new home on OTN: http://download.oracle.com/docs/cd/E19798-01/821-1751/gitzw/index.html

Comment by Anissa Lam [ 21/Jan/11 ]

I see. You were talking about the Admin Guide for 3.0.1.
The docs has been moved. It is now available under


I see this bug has no component/owner and assigned to Nazrul.
I believe Tom should own this, look at this section
"http://download.oracle.com/docs/cd/E19798-01/821-1751/gitzw/index.html" and provide the list that actually requires server restart to the doc team.

I see this list is very out-dated.
Maybe the doc team has changed this list for 3.1 already, i don't know. If so, please use the 3.1 list and file bug accordingly.

Comment by Anissa Lam [ 21/Jan/11 ]

Where is the corresponding list for 3.1 ?
Harshad should be using the 3.1 list instead of those from 3.0.1 to file bug.

Comment by Harshad Vilekar [ 21/Jan/11 ]

That part of the doc is not updated since 3.0.1.

On 12/29/10 13:48, Paul Davies wrote:
> Hi Harshad,
> :
> :
> We have not updated Impact of Configuration Changes since 3.0.1, so you can refer to that for the current information.
> Regards,
> -Paul

Comment by Tom Mueller [ 21/Jan/11 ]

Reassigning to the orb category to determine whether changing the IIOP port requires a server restart in 3.1. For HTTP listener ports, a server restart is not necessary, so the documentation at the given link is definitely wrong. Just want to confirm whether this is also the case for the IIOP ports.

Comment by Tom Mueller [ 21/Jan/11 ]

If a server restart is not required when changing the IIOP ports, please change this to be a doc bug so that the documentation can be updated.

Comment by Ken Cavanaugh [ 21/Jan/11 ]

Changing IIOP ports definitely requires a server restart in the present implementation.
It's technically possible to change IIOP ports, but this requires ORB changes, as well as
some sort of notification mechanism between admin and the ORB. I know how to change the
ORB to support this, but I don't know how to hook something like this into admin.

In any case, this is not supported in GF 3.1, and the docs should reflect this.
Changing this to a doc bug as Tom suggested.

Comment by Ken Cavanaugh [ 21/Jan/11 ]

Oops, I mis-read Tom's comment before I made my last reply.
Changing ORB configuration requires server restart in GF 3.1.

How is this supposed to be changed in the admin CLI commands?
Assigning to Tom for further consideration.
If you want me to update the orb-listener commands, please tell me
how to do this.

Comment by Tom Mueller [ 24/Jan/11 ]

To trigger the "restart required" behavior, it is necessary for some code to detect that a change that has been made that cannot be processed without restarting, and for that code to create and send an UnprocessedChangeEvent. One way of doing this is to have a service that implements the ConfigListener interface, which has a "changed" method that takes an array of PropertyChangeEvent objects and returns list of UnprocessedChangeEvent objects. See this file for an example:


Another way to do this is to explicitly inject the UnprocessedConfigListener class, and call its unprocessedTransactiveEvents method with a List of UnprocessedChangeEvents objects. See this file for an example of this:


I suspect that this is what has happened. In earlier releases, a change to a Grizzly port required a server restart, and Grizzly took care of providing this notification. However, more recently, Grizzly no longer requires a restart to change a port number. For example, the HTTP port can be changed without a restart. However, if IIOP and the ORB still need a restart when the port changes, that could will now have to provide the notification of the unprocessed change event.

The documentation eventually needs to be cleaned up because changes to some ports require a restart, and changes to other ports do not. But the documentation generalized and says a restart is needed for all port changes.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

I don't have a ConfigListener in the ORB interface code, so I don't understand how any of this is
supposed to work.

  • Would I just need to create an implementation of ConfigListener inside an appropriate ORB bundle
    (orb-connector in this case), and annotate it as @Service? Is this automatically picked
    up by admin using hk2?
  • Presumably I would need a changed( PropertyChangeEvent[] ) method. How do I determine what the
    event is that I need to return in unprocessed events? It looks like I need to inject
    IiopListener and then look for event.getSource() of type IiopListener. The operation of
    interest on IiopListener is setPort. So what is event.getPropertyName in this case?

I think a can use a simple implementation here that simply returns everything passed
to the changed event as an unprocessed event, since nothing in the ORB is currently dynamically

Comment by Tom Mueller [ 24/Jan/11 ]

Yes on creating the ConfigListener, except that something needs to reference the service in order to get it loaded. In the EJBTimerService, there is the following call that does this:


See the EJBTimerService.java file.

It sounds like any event on an IiopListener could be made an UnprocessedChangeEvent.
I expect that the property name in the case of the port changing would be "port" since that is what is in the XML.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

One last question: is this fix needed for 3.1, or should we defer it to 3.2?

Comment by kumara [ 24/Jan/11 ]

This is arguably likely to cause confusion to the end users but is lower priority because –

1. port change is a one-time activity in most real deployments
2. After port change, a user is likely to try the application to verify that it works and will discover the problem.
3. Restart is a natural first step towards solving the problem.

I would recommend addressing it in next release and documenting in release notes that clusters/server instances need to be restarted for any configuration changes to IIOP service to take effect.

Comment by Ken Cavanaugh [ 24/Jan/11 ]

Moving to 3.2 per Kumara's comment.

Should add some of the simple cases of ORB dynamic reconfiguration in that release in any case.

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Tom Mueller [ 07/Feb/13 ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.

[GLASSFISH-3850] Changing default realm does not indicate that a server restart required Created: 09/Nov/07  Updated: 25/Apr/14

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 9.1pe
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: r_sudh Assignee: JeffTancill
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 3,850
Status Whiteboard:



When using the web based Admin Console, changing the Default Realm under
Configuration > Security does not indicate that the server needs to be restarted
for the change to take affect.

Either the GUI needs to display the "Restart required" warning message or maybe
this is a bug in the Security module where the change is not being applied right

Comment by Anissa Lam [ 12/Nov/07 ]

I believe changing Default Realm doesn't require server restart. Using CLI, i
did 'list-domains' and it also doesn't say server require restart.

I am transferring this to 'security'.
If changing default realm shouldn't require server restart, then what the user
reported here is expected and is not a bug.

If changing default realm really require server restart, then whatever is told
to GUI and CLI is wrong, someone needs to fix this.

Either way, this is not a GUI issue.

Comment by basler [ 12/Nov/07 ]

Not a show stopper for 91ur1

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Sat Oct 22 20:22:42 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.