Geronimo
  1. Geronimo
  2. GERONIMO-4369

The new attribute values are overwrote while restarting the DB pool connector

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2
    • Fix Version/s: 2.1.4, 2.2
    • Component/s: console
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Geronimo 2.2 snapshot
      JDK 1.5
      Windows XP

    • Patch Info:
      Patch Available
    • Regression:
      Regression

      Description

      After editing the values in the db pool, then restart it in the console, the new values lost.
      When saving the new attribute values, such as user name, the gbeandata in the configurationManager is not updated, so while restarting the connector, the gbinstance copies those old values from it. So the new persistent values do not take effect,
      Do I miss anything, thanks for any comment !

      1. G-4369-0205.patch
        5 kB
        Manu T George
      2. G4369-0209.patch
        5 kB
        Manu T George
      3. Geronimo-4369-01.21.patch
        10 kB
        Ivan
      4. Geronimo-4369-11.13.patch
        2 kB
        Ivan
      5. Geronimo-4369-11.17.patch
        2 kB
        Ivan
      6. Geronimo-4369-11.19.patch
        1 kB
        Ivan

        Activity

        Hide
        Donald Woods added a comment -

        added affects and target fix releases

        Show
        Donald Woods added a comment - added affects and target fix releases
        Hide
        Ivan added a comment -

        It seems that the reason is that while invoking the configurationManager.restart method, it does not reload the configuration data from the store, for some attributes' values may be changed
        I added the unload action and load action in the restart method.
        Please help to review it, thanks !

        Show
        Ivan added a comment - It seems that the reason is that while invoking the configurationManager.restart method, it does not reload the configuration data from the store, for some attributes' values may be changed I added the unload action and load action in the restart method. Please help to review it, thanks !
        Hide
        Joe Bohn added a comment -

        Thanks for the patch. I haven't looked into the problem or potential solutions much yet, but I did give your patch a try. Unfortunately, it results in some test failures during the build:

        Failed tests:
        testRestart(org.apache.geronimo.kernel.config.ConfigurationManagerTest)
        testRestartException(org.apache.geronimo.kernel.config.ConfigurationManagerTest)

        Show
        Joe Bohn added a comment - Thanks for the patch. I haven't looked into the problem or potential solutions much yet, but I did give your patch a try. Unfortunately, it results in some test failures during the build: Failed tests: testRestart(org.apache.geronimo.kernel.config.ConfigurationManagerTest) testRestartException(org.apache.geronimo.kernel.config.ConfigurationManagerTest)
        Hide
        Joe Bohn added a comment -

        It seems that the test specifically verifies that during a restart the configuration is only stopped and started, not unloaded, loaded, or failed. So, perhaps rather than attempting to force unload/reload into the restart we need to look at adding the capability to reload the configuration?

        Show
        Joe Bohn added a comment - It seems that the test specifically verifies that during a restart the configuration is only stopped and started, not unloaded, loaded, or failed. So, perhaps rather than attempting to force unload/reload into the restart we need to look at adding the capability to reload the configuration?
        Hide
        Joe Bohn added a comment -

        It also looks like this is related to http://issues.apache.org/jira/browse/GERONIMO-3269

        Show
        Joe Bohn added a comment - It also looks like this is related to http://issues.apache.org/jira/browse/GERONIMO-3269
        Hide
        Ivan added a comment -

        Thanks, Joe, I should run the testcase first, I just verified that whether the issue is fixed.
        From my side, the restart action is a more user-oriented action, it should use the newest configuration.
        A reload action is a good suggestion, but I am not sure that it is feasible to update the configuration gbean while it is in the running state.
        I wonder why we should not unload/load the configurations, is there a story about it ?
        Thanks again !

        Show
        Ivan added a comment - Thanks, Joe, I should run the testcase first, I just verified that whether the issue is fixed. From my side, the restart action is a more user-oriented action, it should use the newest configuration. A reload action is a good suggestion, but I am not sure that it is feasible to update the configuration gbean while it is in the running state. I wonder why we should not unload/load the configurations, is there a story about it ? Thanks again !
        Hide
        Joe Bohn added a comment -

        I don't know the full rationale, but I know that it has always been a goal to keep the concepts of load/unload and start/stop independent. It certainly provides for more flexibility. I'm starting to wonder if the problem is really in the portlet itself. There are several attributes that are similar between generic and non-generic pools. User name falls into that category. Perhaps we're not updating the name in some local config structure and it is only update when reloaded.

        This is unrelated but I also noticed something strange with user name when creating an embedded derby (non-xa) pool. For some reason we get another attribute called "Shutdown Database" which seems to be getting confused with User Name since the value for "Shutdown Database" is by default the user name and the value for "User Name" is null.

        Show
        Joe Bohn added a comment - I don't know the full rationale, but I know that it has always been a goal to keep the concepts of load/unload and start/stop independent. It certainly provides for more flexibility. I'm starting to wonder if the problem is really in the portlet itself. There are several attributes that are similar between generic and non-generic pools. User name falls into that category. Perhaps we're not updating the name in some local config structure and it is only update when reloaded. This is unrelated but I also noticed something strange with user name when creating an embedded derby (non-xa) pool. For some reason we get another attribute called "Shutdown Database" which seems to be getting confused with User Name since the value for "Shutdown Database" is by default the user name and the value for "User Name" is null.
        Hide
        Ivan added a comment -

        Thanks, Joe, it does let me know more about how the kernel works.
        I found we could use reload instead of the restart in the port let while user try to restart the j2ee connector. I am running some console testcases, then upload the patch.
        Thanks !

        Show
        Ivan added a comment - Thanks, Joe, it does let me know more about how the kernel works. I found we could use reload instead of the restart in the port let while user try to restart the j2ee connector. I am running some console testcases, then upload the patch. Thanks !
        Hide
        Ivan added a comment -

        Let's do the restart action step by step, first stop it, then start it, do not use any shortcut method in the configuration manager.
        So that it will be same behavior with GERONIMO-3269.
        Please help to review the patch, thanks !

        Show
        Ivan added a comment - Let's do the restart action step by step, first stop it, then start it, do not use any shortcut method in the configuration manager. So that it will be same behavior with GERONIMO-3269 . Please help to review the patch, thanks !
        Hide
        Ivan added a comment -

        Update the components, it is belong to console category.

        Show
        Ivan added a comment - Update the components, it is belong to console category.
        Hide
        Manu T George added a comment -

        The JIRA is related to https://issues.apache.org/jira/browse/GERONIMO-4219. The attached patch may not be optimal or working.

        Actually the restart functionality in the admin console starts a configuration and all its child configurations also. That is the functionality of the restartConfiguration method in the configuration Manager. Does the attached patch do this?

        The issue is that the attribute store is not updated during restart. We should first decide whether to fix it here or in the configuration manager. Why shouldn't the restart method in the configurationManager update the attribute store in case any changes are made?

        Show
        Manu T George added a comment - The JIRA is related to https://issues.apache.org/jira/browse/GERONIMO-4219 . The attached patch may not be optimal or working. Actually the restart functionality in the admin console starts a configuration and all its child configurations also. That is the functionality of the restartConfiguration method in the configuration Manager. Does the attached patch do this? The issue is that the attribute store is not updated during restart. We should first decide whether to fix it here or in the configuration manager. Why shouldn't the restart method in the configurationManager update the attribute store in case any changes are made?
        Hide
        Manu T George added a comment -

        Just a clarification. By the attached patch not optimal/working i meant the one attached in Geronimo-4219

        Show
        Manu T George added a comment - Just a clarification. By the attached patch not optimal/working i meant the one attached in Geronimo-4219
        Hide
        Manu T George added a comment -

        The workaround that i followed was to update the gbeanDatas in the configuration as well as write to config.xml. Updating the gbeandatas in the configuration will be reflected on restart of the configuration while the persisted values were reflected on stop and start. Maybe there is a method that does both these things which we just need to call?

        Show
        Manu T George added a comment - The workaround that i followed was to update the gbeanDatas in the configuration as well as write to config.xml. Updating the gbeandatas in the configuration will be reflected on restart of the configuration while the persisted values were reflected on stop and start. Maybe there is a method that does both these things which we just need to call?
        Hide
        Ivan added a comment -

        Yes, the gbeanDatas held by the configuration gbean is the reason that the modifications do not take effect.
        From the API of the configuration manager, I guess the method reload is the one that does the both thing.

        Show
        Ivan added a comment - Yes, the gbeanDatas held by the configuration gbean is the reason that the modifications do not take effect. From the API of the configuration manager, I guess the method reload is the one that does the both thing.
        Hide
        Manu T George added a comment -

        But we also need to restart the child configurations

        I think that the reason that restart doesn't re-read the configuration is to improve the performance. So its faster than stop and start since it just restarts the configuration instead of loading and starting. Also users will be usually restarting webapps etc which may not have gbean updates that need to be picked up most of the time.

        So I think it may be better to have a new console utility method that does both these things and all the console portlets that want to make changes can call that method. Maybe there is one already and i am not aware of it.

        Just my 2 cents

        Show
        Manu T George added a comment - But we also need to restart the child configurations I think that the reason that restart doesn't re-read the configuration is to improve the performance. So its faster than stop and start since it just restarts the configuration instead of loading and starting. Also users will be usually restarting webapps etc which may not have gbean updates that need to be picked up most of the time. So I think it may be better to have a new console utility method that does both these things and all the console portlets that want to make changes can call that method. Maybe there is one already and i am not aware of it. Just my 2 cents
        Hide
        Manu T George added a comment -

        Clarification: So I think it may be better to have a new console utility method that does both these things and all the console portlets that want to make changes can call that method.

        Here by both these things I mean update both the config.xml and the gbeandatas in the configuration.

        Show
        Manu T George added a comment - Clarification: So I think it may be better to have a new console utility method that does both these things and all the console portlets that want to make changes can call that method. Here by both these things I mean update both the config.xml and the gbeandatas in the configuration.
        Hide
        Ivan added a comment -

        Re-create the patch from the root folder.
        Current steps to restart the service are stop, unload, load, start.
        Please help to review the patch, thanks !

        Show
        Ivan added a comment - Re-create the patch from the root folder. Current steps to restart the service are stop, unload, load, start. Please help to review the patch, thanks !
        Hide
        Donald Woods added a comment -

        Quick review of updated patch looks ok. Will try integrating it after I finish other work in-progress.

        Show
        Donald Woods added a comment - Quick review of updated patch looks ok. Will try integrating it after I finish other work in-progress.
        Hide
        Joe Bohn added a comment -

        I don't think this is the correct fix. IMO we need to ensure the RAR/GBean content matches what is in config.xml such that restart will not revert changes.

        Show
        Joe Bohn added a comment - I don't think this is the correct fix. IMO we need to ensure the RAR/GBean content matches what is in config.xml such that restart will not revert changes.
        Hide
        Ivan added a comment -

        If the gbeans copy held by the running configuration gbean matches what is in config,xml (or the configurationStore), it would be better.
        I am not familiar with the kernel, I just feel it is hard to keep the sync between the config.xml and the running configuration.
        I notice that there is a reloadconfiguration method in the configurationManager, it is equal to restart + load the newest configurations from the store. Also, I tried to use it to replace the restart method in the portlet, it works well.

        Show
        Ivan added a comment - If the gbeans copy held by the running configuration gbean matches what is in config,xml (or the configurationStore), it would be better. I am not familiar with the kernel, I just feel it is hard to keep the sync between the config.xml and the running configuration. I notice that there is a reloadconfiguration method in the configurationManager, it is equal to restart + load the newest configurations from the store. Also, I tried to use it to replace the restart method in the portlet, it works well.
        Hide
        Ivan added a comment -

        Using reloadConfigurtion instead of restart.

        Show
        Ivan added a comment - Using reloadConfigurtion instead of restart.
        Hide
        Joe Bohn added a comment -

        I looked into both the lastest patch attached to this JIRA and the patch attached to Geronimo-4219. Both have the same behavior and effectively do the same thing - reloading the configuration during a restart. This seems to work for the "basic connection properties" (like username and LoginTimeout. However, it doesn't seem to work for the Connection Pool Parameters like Pool Min Size, Max Size, Idle Timeout, etc...

        Also, I'd still like to learn if there is a better way other than forcing reload ... just haven't dug in deep enough yet.

        Show
        Joe Bohn added a comment - I looked into both the lastest patch attached to this JIRA and the patch attached to Geronimo-4219. Both have the same behavior and effectively do the same thing - reloading the configuration during a restart. This seems to work for the "basic connection properties" (like username and LoginTimeout. However, it doesn't seem to work for the Connection Pool Parameters like Pool Min Size, Max Size, Idle Timeout, etc... Also, I'd still like to learn if there is a better way other than forcing reload ... just haven't dug in deep enough yet.
        Hide
        Joe Bohn added a comment -

        I'm going to go ahead and apply the latest patch from Ivan for this problem. There are still some lingering problems with the other attributes but at least this resolves the immediate problem mentioned here. We can always reopen this issue or create a new one for the other attribute update issues. The patch on Geronimo-4219 might be a more complete fix but I also don't know if there is just one instance of LocalAttributeManager and it might cause some other issues.

        Show
        Joe Bohn added a comment - I'm going to go ahead and apply the latest patch from Ivan for this problem. There are still some lingering problems with the other attributes but at least this resolves the immediate problem mentioned here. We can always reopen this issue or create a new one for the other attribute update issues. The patch on Geronimo-4219 might be a more complete fix but I also don't know if there is just one instance of LocalAttributeManager and it might cause some other issues.
        Hide
        Donald Woods added a comment -

        Manu T George commented on GERONIMO-4509:
        -----------------------------------------

        I think this issue occurs because of the patch made in https://issues.apache.org/jira/browse/GERONIMO-4369.
        In ConfigManagerPortlet restartConfiguration was replaced by reloadConfiguration which appears to be causing this issue. I think that JIRA needs to be reopened

        Show
        Donald Woods added a comment - Manu T George commented on GERONIMO-4509 : ----------------------------------------- I think this issue occurs because of the patch made in https://issues.apache.org/jira/browse/GERONIMO-4369 . In ConfigManagerPortlet restartConfiguration was replaced by reloadConfiguration which appears to be causing this issue. I think that JIRA needs to be reopened
        Hide
        Ivan added a comment -

        I am working on this issue, it seems that the reason is not only that child configurations are not started. In the reloadConfiguration function, I found that there is no invocations of configurationModule.stop()/unload() to sync the configuration status between the configutationManager and configurationModel, which will cause a IllegalStateException threw by ConfigurationStatus.destroy().
        Any comment ? Thanks !

        Show
        Ivan added a comment - I am working on this issue, it seems that the reason is not only that child configurations are not started. In the reloadConfiguration function, I found that there is no invocations of configurationModule.stop()/unload() to sync the configuration status between the configutationManager and configurationModel, which will cause a IllegalStateException threw by ConfigurationStatus.destroy(). Any comment ? Thanks !
        Hide
        Ivan added a comment -

        There should be some issues in the reload function of the configuration manager, if the component which needs to restart has child configurations, the exception will be threw on the 1186th line
        removeConfigurationFromModel(configurationId);
        Currently , the solution is first to stop, then start the service, and will try to start all the stopped service, maybe we need to revert to reload function once it works properly.
        By the way, I found the j2ee-corba-yoko could not be restarted, while we stop the service, it does not release the port 1050.
        Please help to review the patch, thanks !

        Show
        Ivan added a comment - There should be some issues in the reload function of the configuration manager, if the component which needs to restart has child configurations, the exception will be threw on the 1186th line removeConfigurationFromModel(configurationId); Currently , the solution is first to stop, then start the service, and will try to start all the stopped service, maybe we need to revert to reload function once it works properly. By the way, I found the j2ee-corba-yoko could not be restarted, while we stop the service, it does not release the port 1050. Please help to review the patch, thanks !
        Hide
        Manu T George added a comment -

        This patch provides an alternative approach and applies the over ridden values to the configuration object before calling restart from the ConfigManagerPortlet. We lookup the ManageableAttributeStore and then call the applyOverrides method to achieve the same. There seems to be only one attribute store namely the

        <!-User-editable attribute service->
        <gbean name="AttributeManager" class="org.apache.geronimo.system.configuration.LocalAttributeManager">
        <reference name="ServerInfo">
        <name>ServerInfo</name>
        </reference>
        <attribute name="configFile">var/config/config.xml</attribute>
        <attribute name="substitutionsFile">var/config/config-substitutions.properties</attribute>
        <attribute name="substitutionPrefix">org.apache.geronimo.config.substitution.</attribute>
        </gbean>

        If there are any objections or errors that you see with this patch please point them out on the jira

        Show
        Manu T George added a comment - This patch provides an alternative approach and applies the over ridden values to the configuration object before calling restart from the ConfigManagerPortlet. We lookup the ManageableAttributeStore and then call the applyOverrides method to achieve the same. There seems to be only one attribute store namely the <!- User-editable attribute service -> <gbean name="AttributeManager" class="org.apache.geronimo.system.configuration.LocalAttributeManager"> <reference name="ServerInfo"> <name>ServerInfo</name> </reference> <attribute name="configFile">var/config/config.xml</attribute> <attribute name="substitutionsFile">var/config/config-substitutions.properties</attribute> <attribute name="substitutionPrefix">org.apache.geronimo.config.substitution.</attribute> </gbean> If there are any objections or errors that you see with this patch please point them out on the jira
        Hide
        Manu T George added a comment -

        With patch Geronimo-4369-01.21.patch i faced the following errors

        1) On restart from console changes are lost
        2) Admin console shows stop start and restart messages
        3) Failure to start some modules
        4) Significant increase in startup time
        5) Stopping and Starting the server also results in all changes being lost

        I also think that this is just not a restart problem. There are two separate issues at work here that I am seeing

        1) Changes made are lost during restart from admin console of the connector
        This is because the changes made to the attributeStore are not applied to the configurations on restart. Can be fixed by patch G-4369-0205.patch

        2) Some Changes made are lost on stopping and starting the server or the connector
        Not fixed by any of the patches

        1) is fixed with the patch i have supplied. Also changes to some of the fields like database name and createDatabase are getting reflected even on server restart of config stop and start.

        however 2 is still open and This leads me to believe that this problem is localized to the db manager portlet. On seeing config.xml I see only a few values are persisted

        <module name="console.dbpool/Testman/1.0/rar">
        <gbean name="console.dbpool/Testman/1.0/rar?J2EEApplication=null,JCAConnectionFactory=Testman,JCAResource=console.dbpool/Testman/1.0/rar,ResourceAdapter=console.dbpool/Testman/1.0/rar,ResourceAdapterModule=console.dbpool/Testman/1.0/rar,j2eeType=JCAManagedConnectionFactory,name=Testman">
        <attribute name="DatabaseName">TESTMANT</attribute>
        <attribute name="CreateDatabase">false</attribute>
        <attribute name="ShutdownDatabase">system</attribute>
        <attribute name="Password">

        {Simple}

        rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwAAAAEHnh03EmiNu4VTuWH+xZiRBwdAADQUVT</attribute>
        <attribute name="LoginTimeout">0</attribute>
        <attribute name="UserName"/>
        </gbean>
        </module>

        Changes to these values are reflected on stop and start as expected and to the other fields that are not in config.xml are not reflected

        If fix for 1 is acceptable then we can reduce the severity of this JIRA as it won't affect other portlets with that fix
        If not acceptable I think we should revert back to restartConfiguration in the ConfigManagerPortlet as that seems better than what we have now.

        Note:
        The geronimo build I am testing on is a few weeks old. I will test with a new build as soon as I can
        I tested the above for an embedded derby datasource . I am not sure whether the same will occur for other datasources

        Show
        Manu T George added a comment - With patch Geronimo-4369-01.21.patch i faced the following errors 1) On restart from console changes are lost 2) Admin console shows stop start and restart messages 3) Failure to start some modules 4) Significant increase in startup time 5) Stopping and Starting the server also results in all changes being lost I also think that this is just not a restart problem. There are two separate issues at work here that I am seeing 1) Changes made are lost during restart from admin console of the connector This is because the changes made to the attributeStore are not applied to the configurations on restart. Can be fixed by patch G-4369-0205.patch 2) Some Changes made are lost on stopping and starting the server or the connector Not fixed by any of the patches 1) is fixed with the patch i have supplied. Also changes to some of the fields like database name and createDatabase are getting reflected even on server restart of config stop and start. however 2 is still open and This leads me to believe that this problem is localized to the db manager portlet. On seeing config.xml I see only a few values are persisted <module name="console.dbpool/Testman/1.0/rar"> <gbean name="console.dbpool/Testman/1.0/rar?J2EEApplication=null,JCAConnectionFactory=Testman,JCAResource=console.dbpool/Testman/1.0/rar,ResourceAdapter=console.dbpool/Testman/1.0/rar,ResourceAdapterModule=console.dbpool/Testman/1.0/rar,j2eeType=JCAManagedConnectionFactory,name=Testman"> <attribute name="DatabaseName">TESTMANT</attribute> <attribute name="CreateDatabase">false</attribute> <attribute name="ShutdownDatabase">system</attribute> <attribute name="Password"> {Simple} rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwAAAAEHnh03EmiNu4VTuWH+xZiRBwdAADQUVT</attribute> <attribute name="LoginTimeout">0</attribute> <attribute name="UserName"/> </gbean> </module> Changes to these values are reflected on stop and start as expected and to the other fields that are not in config.xml are not reflected If fix for 1 is acceptable then we can reduce the severity of this JIRA as it won't affect other portlets with that fix If not acceptable I think we should revert back to restartConfiguration in the ConfigManagerPortlet as that seems better than what we have now. Note: The geronimo build I am testing on is a few weeks old. I will test with a new build as soon as I can I tested the above for an embedded derby datasource . I am not sure whether the same will occur for other datasources
        Hide
        Donald Woods added a comment -

        go ahead and apply to 2.1.4 and 2.2 and #2 can be addressed in 2.1.5 and 2.2 if time permits

        Show
        Donald Woods added a comment - go ahead and apply to 2.1.4 and 2.2 and #2 can be addressed in 2.1.5 and 2.2 if time permits
        Hide
        Ivan added a comment -

        Thanks for your comments, Manu.
        I partly agreed your suggestions,
        1. On restart from console changes are lost
        what I did in the patch Geronimo-4369-01.21 is the same with the previous one, except for trying to restart all the stopped configurations. Not sure which changes will be lost (except for those properties mentioned in 2))?
        2. Admin console shows stop start and restart messages.
        I just want to show the full cycle about the restart process, maybe I print two much messages.
        3. Failure to start modules.
        Not sure which modules are not started ?
        4. Significant increase in startup time
        It is sure, I have no idea about it, anyway, it needs time to restart so much components.
        5. Stopping and Starting the server also results in all changes being lost
        Not sure which changes are lost ? Could you please give an example.
        For your solution, basicly, it is better. Only one concern is that, if I restart configuration A, and A has a child configurtion B, only applies the changes to A may be not enough, some changes on B maybe lost.
        I have not try it, wish I made a mistake, _

        Show
        Ivan added a comment - Thanks for your comments, Manu. I partly agreed your suggestions, 1. On restart from console changes are lost what I did in the patch Geronimo-4369-01.21 is the same with the previous one, except for trying to restart all the stopped configurations. Not sure which changes will be lost (except for those properties mentioned in 2))? 2. Admin console shows stop start and restart messages. I just want to show the full cycle about the restart process, maybe I print two much messages. 3. Failure to start modules. Not sure which modules are not started ? 4. Significant increase in startup time It is sure, I have no idea about it, anyway, it needs time to restart so much components. 5. Stopping and Starting the server also results in all changes being lost Not sure which changes are lost ? Could you please give an example. For your solution, basicly, it is better. Only one concern is that, if I restart configuration A, and A has a child configurtion B, only applies the changes to A may be not enough, some changes on B maybe lost. I have not try it, wish I made a mistake, _
        Hide
        Manu T George added a comment -

        Ivan,
        Regarding 1
        I was not able to get the changes to persist on restart from admin console using the patch you provided. (Remember #2 above In case of stop and start #2 applies that is the reason none are getting saved).
        Actually this is due to #2

        Regarding 2
        Yes too many messages are printed. Try starting openejb module the entire screen is filled with messages

        Regarding 3
        The j2ee-corba-yoko configuration as you mentioned doesn't restart. But if you use restartConfiguration it does.

        Regarding 4
        I built two servers one with restartConfiguration (w/o ur patch) and one with yours and saw restart takes a lot of time with yours but less time with the restartConfiguration
        The reason for restart itself is to reduce the time taken to start again. Doing stop and start results in more time taken

        5) This is regarding #2. Just pointing out that both patches don't fix it

        Regarding your point I thought of that but what I thought was that that use case occurrence is very rare(I dont see users making changes to parent and child configurations and restarting the parent that often) and maybe the overhead of applying overrides to
        each child configuration will not be worth it. Smacks of laziness .I will try that out and see what the overhead is and update my patch. If the overhead is too high then I will need figure out a way to applyOverrides only for configurations that are dirty.
        Maybe the applyOverrides method already does that or there is some other way to check this.

        Thank you for analyzing my patch and pointing this out and for contributing all the other patches that helped.

        Show
        Manu T George added a comment - Ivan, Regarding 1 I was not able to get the changes to persist on restart from admin console using the patch you provided. (Remember #2 above In case of stop and start #2 applies that is the reason none are getting saved). Actually this is due to #2 Regarding 2 Yes too many messages are printed. Try starting openejb module the entire screen is filled with messages Regarding 3 The j2ee-corba-yoko configuration as you mentioned doesn't restart. But if you use restartConfiguration it does. Regarding 4 I built two servers one with restartConfiguration (w/o ur patch) and one with yours and saw restart takes a lot of time with yours but less time with the restartConfiguration The reason for restart itself is to reduce the time taken to start again. Doing stop and start results in more time taken 5) This is regarding #2. Just pointing out that both patches don't fix it Regarding your point I thought of that but what I thought was that that use case occurrence is very rare(I dont see users making changes to parent and child configurations and restarting the parent that often) and maybe the overhead of applying overrides to each child configuration will not be worth it. Smacks of laziness .I will try that out and see what the overhead is and update my patch. If the overhead is too high then I will need figure out a way to applyOverrides only for configurations that are dirty. Maybe the applyOverrides method already does that or there is some other way to check this. Thank you for analyzing my patch and pointing this out and for contributing all the other patches that helped.
        Hide
        Ivan added a comment -

        Two clarification:
        Regarding 1: I have unloaded the configuration in the patch, at least, for type 1, those changes should be kept. I have tested it before I uploaded the patch file.
        Regarding 3: There should a defect about j2ee-corba-yoko, I have opened a JIRA for it. No matter which way is used, that module could not be restarted.
        Thanks !

        Show
        Ivan added a comment - Two clarification: Regarding 1: I have unloaded the configuration in the patch, at least, for type 1, those changes should be kept. I have tested it before I uploaded the patch file. Regarding 3: There should a defect about j2ee-corba-yoko, I have opened a JIRA for it. No matter which way is used, that module could not be restarted. Thanks !
        Hide
        Manu T George added a comment -

        This is a patch that addresses the use case of child configurations being updated and restarted via a parent restart. The patch exposes a new method on Configuration i.e. getManageableAttributeStore that is accessible to all classes in the same package and the SimpleConfigurationManager applies overrides during a restart by calling the method appl.

        If no objections will apply within a few days

        Show
        Manu T George added a comment - This is a patch that addresses the use case of child configurations being updated and restarted via a parent restart. The patch exposes a new method on Configuration i.e. getManageableAttributeStore that is accessible to all classes in the same package and the SimpleConfigurationManager applies overrides during a restart by calling the method appl. If no objections will apply within a few days
        Hide
        Manu T George added a comment -

        Fixed the general restart issue. What is remaining to be fixed is portlet specific

        Show
        Manu T George added a comment - Fixed the general restart issue. What is remaining to be fixed is portlet specific
        Hide
        Jarek Gawor added a comment -

        I believe this is done but if there is more work for this that needs to be done please reopen.

        Show
        Jarek Gawor added a comment - I believe this is done but if there is more work for this that needs to be done please reopen.

          People

          • Assignee:
            Manu T George
            Reporter:
            Ivan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development