Issue Details (XML | Word | Printable)

Key: GLASSFISH-15638
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Harshad Vilekar
Reporter: Harshad Vilekar
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

Show "restart required" status when IIOP service configuration / port is changed

Created: 20/Jan/11 05:26 PM   Updated: 07/Feb/13 03:25 PM
Component/s: orb
Affects Version/s: 3.1_b38
Fix Version/s: 4.0.1

Time Tracking:
Not Specified

Tags: 3_1-exclude 3_1-next 3_1_1-exclude 3_1_1-scrubbed 3_1_2-exclude
Participants: Anissa Lam, Harshad Vilekar, Ken Cavanaugh, kumara, Scott Fordin and Tom Mueller


 Description  « Hide

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.



Anissa Lam added a comment - 20/Jan/11 09:24 PM

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.


Harshad Vilekar added a comment - 21/Jan/11 09:21 AM

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".


Harshad Vilekar added a comment - 21/Jan/11 09:58 AM

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


Anissa Lam added a comment - 21/Jan/11 09:59 AM

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

http://download.oracle.com/docs/cd/E19798-01/

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.


Anissa Lam added a comment - 21/Jan/11 10:03 AM

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.


Harshad Vilekar added a comment - 21/Jan/11 10:14 AM

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


Tom Mueller added a comment - 21/Jan/11 11:02 AM

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.


Tom Mueller added a comment - 21/Jan/11 11:04 AM

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.


Ken Cavanaugh added a comment - 21/Jan/11 10:49 PM

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.


Ken Cavanaugh added a comment - 21/Jan/11 10:53 PM

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.


Tom Mueller added a comment - 24/Jan/11 07:20 AM

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:

ejb/ejb-container/src/main/java/com/sun/ejb/containers/EJBTimerServiceConfigListener.java

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:

core/logging/src/main/java/com/sun/enterprise/server/logging/LogManagerService.java

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.


Ken Cavanaugh added a comment - 24/Jan/11 09:32 AM

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
updatable.


Tom Mueller added a comment - 24/Jan/11 10:12 AM

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:

ejbContainerUtil.getDefaultHabitat().getComponent(EJBTimerServiceConfigListener.class);

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.


Ken Cavanaugh added a comment - 24/Jan/11 10:32 AM

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


kumara added a comment - 24/Jan/11 10:50 AM

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.


Ken Cavanaugh added a comment - 24/Jan/11 11:21 AM

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.


Scott Fordin added a comment - 18/Mar/11 01:16 PM

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


Tom Mueller added a comment - 07/Feb/13 03:25 PM

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