glassfish
  1. glassfish
  2. GLASSFISH-15638

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

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1_b38
    • Fix Version/s: 4.1
    • Component/s: orb
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Anissa Lam added a comment -

        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.

        Show
        Anissa Lam added a comment - 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.
        Hide
        Harshad Vilekar added a comment -

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

        Show
        Harshad Vilekar added a comment - 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".
        Hide
        Harshad Vilekar added a comment -

        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

        Show
        Harshad Vilekar added a comment - 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
        Hide
        Anissa Lam added a comment -

        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.

        Show
        Anissa Lam added a comment - 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.
        Hide
        Anissa Lam added a comment -

        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.

        Show
        Anissa Lam added a comment - 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.
        Hide
        Harshad Vilekar added a comment -

        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

        Show
        Harshad Vilekar added a comment - 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
        Hide
        Tom Mueller added a comment -

        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.

        Show
        Tom Mueller added a comment - 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.
        Hide
        Tom Mueller added a comment -

        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.

        Show
        Tom Mueller added a comment - 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.
        Hide
        Ken Cavanaugh added a comment -

        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.

        Show
        Ken Cavanaugh added a comment - 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.
        Hide
        Ken Cavanaugh added a comment -

        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.

        Show
        Ken Cavanaugh added a comment - 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.
        Hide
        Tom Mueller added a comment -

        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.

        Show
        Tom Mueller added a comment - 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.
        Hide
        Ken Cavanaugh added a comment -

        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.

        Show
        Ken Cavanaugh added a comment - 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.
        Hide
        Tom Mueller added a comment -

        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.

        Show
        Tom Mueller added a comment - 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.
        Hide
        Ken Cavanaugh added a comment -

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

        Show
        Ken Cavanaugh added a comment - One last question: is this fix needed for 3.1, or should we defer it to 3.2?
        Hide
        kumara added a comment -

        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.

        Show
        kumara added a comment - 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.
        Hide
        Ken Cavanaugh added a comment -

        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.

        Show
        Ken Cavanaugh added a comment - 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.
        Hide
        Scott Fordin added a comment -

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

        Show
        Scott Fordin added a comment - Added topic under "Restart Required" umbrella issue ( http://java.net/jira/browse/GLASSFISH-16040 ) in 3.1 Release Notes.
        Hide
        Tom Mueller added a comment -

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

        Show
        Tom Mueller added a comment - Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.

          People

          • Assignee:
            Harshad Vilekar
            Reporter:
            Harshad Vilekar
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: