Geronimo
  1. Geronimo
  2. GERONIMO-4795

Multiple Server Instances: Uninstalling an application does not remove the entry from config.xml of other server instances

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.1.3, 2.1.4
    • Fix Version/s: Wish List
    • Component/s: commands
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Windows XP G 214

      Description

      1) Setup another geronimo instance out of the same installation directory.
      2) Deploy an applicaton to one instance. This will result in entry being created in config.xml for both the instances
      3) Undeploy the application. This results in entry being removed from config.xml of one instance and other instance
      still has entry of the application in config.xml.

      1. GERONIMO-4795.patch
        3 kB
        Ashish Jain
      2. MultipleServer-1.0.jar
        5 kB
        Ashish Jain
      3. plan.xml
        1 kB
        Ashish Jain

        Activity

        Ashish Jain made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Won't Fix [ 2 ]
        Hide
        Ashish Jain added a comment -

        Closing it.

        Show
        Ashish Jain added a comment - Closing it.
        Ashish Jain made changes -
        Fix Version/s Wish List [ 12310202 ]
        Fix Version/s 2.1.5 [ 12313729 ]
        Hide
        Ashish Jain added a comment -

        Moving to wish list as no action is required for g 2.1.5 release.

        Show
        Ashish Jain added a comment - Moving to wish list as no action is required for g 2.1.5 release.
        Hide
        David Jencks added a comment -

        I'm reluctant to include either of the approaches in geronimo because I think they are founded on inappropriate ways of dealing with multiple servers sharing a repository.

        IIUC, in order to get into trouble, you have to:
        1. have more than one server running off the same repository. (this is ok to do)
        2. install a plugin into the repository and onto one of the servers (whether by deploying an app or installing a plugin, doesn't matter)
        3. start the plugin on the other server(s)

        (all of this is fine so far)
        4. uninstall the app from one of the servers without stopping it on the other servers first. This is a no-no.

        IIUC if you stop the app on all servers and then uninstall it everything is fine.

        Also IIUC the big problem is if you stop and try to restart the "broken" server that thinks the app is still there.
        I think both approaches have the problem that if the server is stopped before cleanup takes place you still can't restart it.

        I think a better approach is to manage the start/stop state of all the apps as a plugin farm of some kind as is possible in 2.2.

        Show
        David Jencks added a comment - I'm reluctant to include either of the approaches in geronimo because I think they are founded on inappropriate ways of dealing with multiple servers sharing a repository. IIUC, in order to get into trouble, you have to: 1. have more than one server running off the same repository. (this is ok to do) 2. install a plugin into the repository and onto one of the servers (whether by deploying an app or installing a plugin, doesn't matter) 3. start the plugin on the other server(s) (all of this is fine so far) 4. uninstall the app from one of the servers without stopping it on the other servers first. This is a no-no. IIUC if you stop the app on all servers and then uninstall it everything is fine. Also IIUC the big problem is if you stop and try to restart the "broken" server that thinks the app is still there. I think both approaches have the problem that if the server is stopped before cleanup takes place you still can't restart it. I think a better approach is to manage the start/stop state of all the apps as a plugin farm of some kind as is possible in 2.2.
        Ashish Jain made changes -
        Attachment plan.xml [ 12435297 ]
        Hide
        Ashish Jain added a comment -

        Attaching the MultipleServer-1.0.jar and the plan file.

        Show
        Ashish Jain added a comment - Attaching the MultipleServer-1.0.jar and the plan file.
        Ashish Jain made changes -
        Attachment MultipleServer-1.0.jar [ 12435296 ]
        Hide
        Ashish Jain added a comment -

        I have written a new Timer gbean which will periodically scan the repository and will accordingly update the config.xml. The time interval in which the gbean will scan the repository is configurable. Please review the uploaded code.

        Thanks
        Ashish

        Show
        Ashish Jain added a comment - I have written a new Timer gbean which will periodically scan the repository and will accordingly update the config.xml. The time interval in which the gbean will scan the repository is configurable. Please review the uploaded code. Thanks Ashish
        Ashish Jain made changes -
        Fix Version/s 2.1.5 [ 12313729 ]
        Fix Version/s Wish List [ 12310202 ]
        Hide
        Ashish Jain added a comment -

        Can someone help review and provide comments over the patch?

        Show
        Ashish Jain added a comment - Can someone help review and provide comments over the patch?
        David Jencks made changes -
        Fix Version/s Wish List [ 12310202 ]
        Fix Version/s 2.2 [ 12312965 ]
        Hide
        David Jencks added a comment -

        Not getting into 2.2, whether or not its a good idea.

        Show
        David Jencks added a comment - Not getting into 2.2, whether or not its a good idea.
        Hide
        Ashish Jain added a comment -

        Please advice if this approach is agreeable.

        Show
        Ashish Jain added a comment - Please advice if this approach is agreeable.
        Ashish Jain made changes -
        Field Original Value New Value
        Attachment GERONIMO-4795.patch [ 12421553 ]
        Hide
        Ashish Jain added a comment -

        Just an explanation :

        Let us suppose we have two instances of server instance A and instance B. Instance B is created by copying var/* to myserver/var*.

        Step 1: Deploy an application to the server instance A. The application goes to the common repository. Access the config.xml for instance A...entry is created for the application deployed. Access the config.xml for instance B....no entry created.

        Step 2: Now access the admin console for instance B-- EAR or WAR portlet ( depending on the type of the application). Now check the config.xml for instance B. An entry for the application is created in the config.xml however with load=false.

        Step 3: Start the application in instance B config.xml entry changes to load=true.

        Step 4: Uninstall the application from instance A..Admin console entry is removed for entry A as well as B. Verify the config.xml for A and B. Entry from A is removed however entry from B is not removed.

        So this is the first problem we hit.

        I am uploading a patch for this issue. However this works only when the admin console EAR or WAR portlet is accessed for that particular instance.

        In case the admin console from instance B is not accessed the entry will still remain however there are no side effects.

        Second problem comes when instance B is restarted.

        If instance B is restarted after un-installation of application but w/o accessing the admin console than in that case the entry in config.xml for instance B will still remain present so restart will fail as instance B will not be able to to find the module in the configuration store. So to fix this issue another patch has to be generated I hope by using the shutdown hooks whose run method will just do the same thing as the patch uploaded, however just before shutdown.

        In my opinion these two fixes will take care of the multiple server instances w/o introducing much complexity.

        Please review the approach. The patch is just a rough one and I will create a neat one if the approach is agreeable.

        Show
        Ashish Jain added a comment - Just an explanation : Let us suppose we have two instances of server instance A and instance B. Instance B is created by copying var/* to myserver/var*. Step 1: Deploy an application to the server instance A. The application goes to the common repository. Access the config.xml for instance A...entry is created for the application deployed. Access the config.xml for instance B....no entry created. Step 2: Now access the admin console for instance B-- EAR or WAR portlet ( depending on the type of the application). Now check the config.xml for instance B. An entry for the application is created in the config.xml however with load=false. Step 3: Start the application in instance B config.xml entry changes to load=true. Step 4: Uninstall the application from instance A..Admin console entry is removed for entry A as well as B. Verify the config.xml for A and B. Entry from A is removed however entry from B is not removed. So this is the first problem we hit. I am uploading a patch for this issue. However this works only when the admin console EAR or WAR portlet is accessed for that particular instance. In case the admin console from instance B is not accessed the entry will still remain however there are no side effects. Second problem comes when instance B is restarted. If instance B is restarted after un-installation of application but w/o accessing the admin console than in that case the entry in config.xml for instance B will still remain present so restart will fail as instance B will not be able to to find the module in the configuration store. So to fix this issue another patch has to be generated I hope by using the shutdown hooks whose run method will just do the same thing as the patch uploaded, however just before shutdown. In my opinion these two fixes will take care of the multiple server instances w/o introducing much complexity. Please review the approach. The patch is just a rough one and I will create a neat one if the approach is agreeable.
        Hide
        Ashish Jain added a comment -

        Yes I am referring to 2.1.x and in 2.1.x we have to use the copying var/* mechanism to create multiple server instances. However my setup is pre-set to have another instance up and the operations like deploy/undeploy are performed after the multiple server setup is ready.

        However as David has suggested that there are no compelling use cases where this is being used or can be used. IMO there are two ways to use it as far as 2.1.x is considered

        1) Set up each server with its own repository so that the undeploy/deploy can be performed individually.

        2) As David has suggested that there are not so imp scenarios in which this feature can be used I would suggest to use this with a cluster setup to get the best out of this feature.

        Show
        Ashish Jain added a comment - Yes I am referring to 2.1.x and in 2.1.x we have to use the copying var/* mechanism to create multiple server instances. However my setup is pre-set to have another instance up and the operations like deploy/undeploy are performed after the multiple server setup is ready. However as David has suggested that there are no compelling use cases where this is being used or can be used. IMO there are two ways to use it as far as 2.1.x is considered 1) Set up each server with its own repository so that the undeploy/deploy can be performed individually. 2) As David has suggested that there are not so imp scenarios in which this feature can be used I would suggest to use this with a cluster setup to get the best out of this feature.
        Hide
        Kevan Miller added a comment -

        Right. My 2) should have referred to install, not "deploy".

        I was thinking about our 2.1.x support, not 2.2. So, deploy/new-instance would not be available... Copying var/* is the mechanism for creating multiple server instances on 2.1.x. I'm assuming that Ashish is referring to 2.1, not 2.2

        Show
        Kevan Miller added a comment - Right. My 2) should have referred to install, not "deploy". I was thinking about our 2.1.x support, not 2.2. So, deploy/new-instance would not be available... Copying var/* is the mechanism for creating multiple server instances on 2.1.x. I'm assuming that Ashish is referring to 2.1, not 2.2
        Hide
        David Jencks added a comment -

        IMO the techniques you mention are usually not the best way to deal with multiple server instances. (2) doesn't make any sense to me – a plugin has already made use of a deployment plan, and is in a state where an additional deployment plan cannot be interpreted.

        Recommended (by me) ways to deal with more than one server instance in an installation:

        a. add a new server instance using the new server instance command: this will create the base directory and proceed to install all the plugins installed in the source server. Since the repo is shared, nothing will change in the repo, but the plugins being installed into the new server will set up the config.xml, and related files and unpack any plugin specific content into the appropriate places.

        b. Giving an existing additional server instance with a plugin present in the geronimo repo but not installed in the additional instance, installing it into the additional instance will add the config.xml content and related file content and unpack any files needed.

        if you copy a var directory per your (1) you will get any local changes and edits and data that happen to be present in the server instance, so the results are inherently unpredictable. (a) produces a fresh server without local modifications.

        Show
        David Jencks added a comment - IMO the techniques you mention are usually not the best way to deal with multiple server instances. (2) doesn't make any sense to me – a plugin has already made use of a deployment plan, and is in a state where an additional deployment plan cannot be interpreted. Recommended (by me) ways to deal with more than one server instance in an installation: a. add a new server instance using the new server instance command: this will create the base directory and proceed to install all the plugins installed in the source server. Since the repo is shared, nothing will change in the repo, but the plugins being installed into the new server will set up the config.xml, and related files and unpack any plugin specific content into the appropriate places. b. Giving an existing additional server instance with a plugin present in the geronimo repo but not installed in the additional instance, installing it into the additional instance will add the config.xml content and related file content and unpack any files needed. if you copy a var directory per your (1) you will get any local changes and edits and data that happen to be present in the server instance, so the results are inherently unpredictable. (a) produces a fresh server without local modifications.
        Hide
        Kevan Miller added a comment -

        That may be how you think the server should be used. Although I think a "disposable" server model for using Geronimo is an excellent technique, it's not the only technique. I certainly talk with users who have decided not to manage their Geronimo environment in this way... So, I'm not so quick to dismiss this basic scenario...

        That said, I think I agree that we should not support this undeploy behavior...

        Seems like there are 3 potential ways to end up in the state described by Ashish:

        1) deploy an app/plugin to the default server, then copy var/* to a new server instance
        2) deploy a plugin to any server (using the default repository), then deploy the plugin only using a deployment plan (I'm only guessing that this might work).
        3) deploy an app/plugin, then manually copy the config.xml changes into the other server's config.xml

        I don't think these "deploy" techniques imply that we'll automatically "undeploy" the apps. User management was required, when deploying the apps to the multiple servers. User Management will be required, when undeploying.

        Personally, I think the best technique for handling this scenario is with server specific repositories on each server instance. If you want to run the same app on all server instances, you should explicitly deploy/undeploy to each server instance.

        Show
        Kevan Miller added a comment - That may be how you think the server should be used. Although I think a "disposable" server model for using Geronimo is an excellent technique, it's not the only technique. I certainly talk with users who have decided not to manage their Geronimo environment in this way... So, I'm not so quick to dismiss this basic scenario... That said, I think I agree that we should not support this undeploy behavior... Seems like there are 3 potential ways to end up in the state described by Ashish: 1) deploy an app/plugin to the default server, then copy var/* to a new server instance 2) deploy a plugin to any server (using the default repository), then deploy the plugin only using a deployment plan (I'm only guessing that this might work). 3) deploy an app/plugin, then manually copy the config.xml changes into the other server's config.xml I don't think these "deploy" techniques imply that we'll automatically "undeploy" the apps. User management was required, when deploying the apps to the multiple servers. User Management will be required, when undeploying. Personally, I think the best technique for handling this scenario is with server specific repositories on each server instance. If you want to run the same app on all server instances, you should explicitly deploy/undeploy to each server instance.
        Hide
        David Jencks added a comment -

        I don't think we should try to fix this. IMO the proper use of servers is to construct them with the plugins you want, and possibly add more plugins. However removing plugins is not generally the reverse of adding them. For instance we don't try to delete data files installed when the plugin was unpacked, remove config.xml entries, config-substitutions.properties, or artifact aliases. Trying to change this will introduce near infinite complexity for no good reason. Just dont' uninstall apps, assemble a new server instead.

        In particular, I think that altering the behavior for mulitple server instances here would require some kind of registry of all the servers running off of a particular geronimo repository. I don't think there's any need for this. I'm not aware of any compelling uses for multiple server instances so I'm very much against introducing more complexity to make a small aspect of uninstalling plugins slightly less problematical.

        Show
        David Jencks added a comment - I don't think we should try to fix this. IMO the proper use of servers is to construct them with the plugins you want, and possibly add more plugins. However removing plugins is not generally the reverse of adding them. For instance we don't try to delete data files installed when the plugin was unpacked, remove config.xml entries, config-substitutions.properties, or artifact aliases. Trying to change this will introduce near infinite complexity for no good reason. Just dont' uninstall apps, assemble a new server instead. In particular, I think that altering the behavior for mulitple server instances here would require some kind of registry of all the servers running off of a particular geronimo repository. I don't think there's any need for this. I'm not aware of any compelling uses for multiple server instances so I'm very much against introducing more complexity to make a small aspect of uninstalling plugins slightly less problematical.
        Ashish Jain created issue -

          People

          • Assignee:
            Ashish Jain
            Reporter:
            Ashish Jain
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development