You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org> on 2006/06/08 06:02:29 UTC

[jira] Created: (GERONIMO-2090) Confirm that if version N is deployed, you can distribute version N+1 and later start it somehow

Confirm that if version N is deployed, you can distribute version N+1 and later start it somehow
------------------------------------------------------------------------------------------------

         Key: GERONIMO-2090
         URL: http://issues.apache.org/jira/browse/GERONIMO-2090
     Project: Geronimo
        Type: Bug
    Security: public (Regular issues) 
  Components: kernel  
    Versions: 1.1    
    Reporter: Aaron Mulder
     Fix For: 1.1.1


Let's say you deploy foo/MyApp/1.1/war, to 10 identical servers.

Now you have version 1.2 ready.

It would be nice if you could distribute 1.2 to all 10 servers (while 1.1 is still running).  Then you'd have to be able to run a command to essentially say "switch off 1.1 and switch on 1.2" in one shot (perhaps using a sticky load balancer to upgrade part of the cluster and let the rest of the cluster handle old sessions until they're finished).  This isn't precisely a redeploy (the stuff is already distributed, whereas a redeploy expects to send the new files).  More of a "cutover" command.

I suspect there may be bugs in the console and/or tool that manifest if you have two different versions of the same module installed simultaneously.  The deploy tool may also not let you distribute a second version of the same module.  But we also need a new command to do the cutover.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Updated: (GERONIMO-2090) Confirm that if version N is deployed, you can distribute version N+1 and later start it somehow

Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
     [ http://issues.apache.org/jira/browse/GERONIMO-2090?page=all ]

Alan Cabrera updated GERONIMO-2090:
-----------------------------------

    Fix Version/s: 1.1.x
                       (was: 1.1.1)

Moving unassigned issues over to the 1.1.x pool where they can be worked on for the, in all probability, 1.1.2 patch.

> Confirm that if version N is deployed, you can distribute version N+1 and later start it somehow
> ------------------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-2090
>                 URL: http://issues.apache.org/jira/browse/GERONIMO-2090
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: kernel
>    Affects Versions: 1.1
>            Reporter: Aaron Mulder
>             Fix For: 1.1.x
>
>
> Let's say you deploy foo/MyApp/1.1/war, to 10 identical servers.
> Now you have version 1.2 ready.
> It would be nice if you could distribute 1.2 to all 10 servers (while 1.1 is still running).  Then you'd have to be able to run a command to essentially say "switch off 1.1 and switch on 1.2" in one shot (perhaps using a sticky load balancer to upgrade part of the cluster and let the rest of the cluster handle old sessions until they're finished).  This isn't precisely a redeploy (the stuff is already distributed, whereas a redeploy expects to send the new files).  More of a "cutover" command.
> I suspect there may be bugs in the console and/or tool that manifest if you have two different versions of the same module installed simultaneously.  The deploy tool may also not let you distribute a second version of the same module.  But we also need a new command to do the cutover.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira