You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Patricia Shanahan <pa...@acm.org> on 2011/07/01 19:56:31 UTC
A thought on JVM migration
I've seen some discussion of using a separate JVM for security. Does it
also provide a solution to the problem of JVM migration in a
continuously operating River-based system?
Suppose the objective is to migrate from 1.5 to 1.6.
The first step would be to get each client and server into a state in
which it can recognize that a proxy needs 1.6, and spawn a 1.6 JVM, with
1.6 versions of River jars, to run it. That can be done on a gradual,
machine-by-machine basis.
The second step is to replace each program installation with its JVM 1.6
version, again on a machine-by-machine basis. During this phase, there
will be times when a 1.5 application needs to run a proxy that needs
1.6, and solves the problem by spawning a 1.6 JVM to run it.
At the end of the second step the system is fully 1.6, and the 1.5 JVM
and libraries can be uninstalled.
If a service is implemented on multiple servers, and the servers are
updated at different times, the service remains continuously available.
Does this make any sense?
Patricia
RE: A thought on JVM migration
Posted by Christopher Dolan <ch...@avid.com>.
Oh, I see. Sorry for the misunderstanding.
Chris
-----Original Message-----
From: Peter [mailto:jini@zeus.net.au]
Sent: Friday, July 01, 2011 8:59 PM
To: dev@river.apache.org
Subject: Re: A thought on JVM migration
I think Patracia means a hot upgrade. Eg install new jvm, migrate without shutdown, state could be transferred using serialization.
----- Original message -----
> Sorry, I don't think that makes sense. It's rarely a problem to run 1.5
> code in a 1.6 JVM. Instead the problem is usually that there is no 1.6
> JVM available on the system. I've had two real-world cases: older OS
> (Fedora Core 3 and Mac OS 10.4) and licensing (an redistribution
> agreement with Sun that covered only 1.4 and 1.5).
>
> Chris
>
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Friday, July 01, 2011 12:57 PM
> To: dev@river.apache.org
> Subject: A thought on JVM migration
>
> I've seen some discussion of using a separate JVM for security. Does it
> also provide a solution to the problem of JVM migration in a
> continuously operating River-based system?
>
> Suppose the objective is to migrate from 1.5 to 1.6.
>
> The first step would be to get each client and server into a state in
> which it can recognize that a proxy needs 1.6, and spawn a 1.6 JVM, with
>
> 1.6 versions of River jars, to run it. That can be done on a gradual,
> machine-by-machine basis.
>
> The second step is to replace each program installation with its JVM 1.6
>
> version, again on a machine-by-machine basis. During this phase, there
> will be times when a 1.5 application needs to run a proxy that needs
> 1.6, and solves the problem by spawning a 1.6 JVM to run it.
>
> At the end of the second step the system is fully 1.6, and the 1.5 JVM
> and libraries can be uninstalled.
>
> If a service is implemented on multiple servers, and the servers are
> updated at different times, the service remains continuously available.
>
> Does this make any sense?
>
> Patricia
Re: A thought on JVM migration
Posted by Peter <ji...@zeus.net.au>.
I think Patracia means a hot upgrade. Eg install new jvm, migrate without shutdown, state could be transferred using serialization.
----- Original message -----
> Sorry, I don't think that makes sense. It's rarely a problem to run 1.5
> code in a 1.6 JVM. Instead the problem is usually that there is no 1.6
> JVM available on the system. I've had two real-world cases: older OS
> (Fedora Core 3 and Mac OS 10.4) and licensing (an redistribution
> agreement with Sun that covered only 1.4 and 1.5).
>
> Chris
>
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Friday, July 01, 2011 12:57 PM
> To: dev@river.apache.org
> Subject: A thought on JVM migration
>
> I've seen some discussion of using a separate JVM for security. Does it
> also provide a solution to the problem of JVM migration in a
> continuously operating River-based system?
>
> Suppose the objective is to migrate from 1.5 to 1.6.
>
> The first step would be to get each client and server into a state in
> which it can recognize that a proxy needs 1.6, and spawn a 1.6 JVM, with
>
> 1.6 versions of River jars, to run it. That can be done on a gradual,
> machine-by-machine basis.
>
> The second step is to replace each program installation with its JVM 1.6
>
> version, again on a machine-by-machine basis. During this phase, there
> will be times when a 1.5 application needs to run a proxy that needs
> 1.6, and solves the problem by spawning a 1.6 JVM to run it.
>
> At the end of the second step the system is fully 1.6, and the 1.5 JVM
> and libraries can be uninstalled.
>
> If a service is implemented on multiple servers, and the servers are
> updated at different times, the service remains continuously available.
>
> Does this make any sense?
>
> Patricia
RE: A thought on JVM migration
Posted by Christopher Dolan <ch...@avid.com>.
Sorry, I don't think that makes sense. It's rarely a problem to run 1.5
code in a 1.6 JVM. Instead the problem is usually that there is no 1.6
JVM available on the system. I've had two real-world cases: older OS
(Fedora Core 3 and Mac OS 10.4) and licensing (an redistribution
agreement with Sun that covered only 1.4 and 1.5).
Chris
-----Original Message-----
From: Patricia Shanahan [mailto:pats@acm.org]
Sent: Friday, July 01, 2011 12:57 PM
To: dev@river.apache.org
Subject: A thought on JVM migration
I've seen some discussion of using a separate JVM for security. Does it
also provide a solution to the problem of JVM migration in a
continuously operating River-based system?
Suppose the objective is to migrate from 1.5 to 1.6.
The first step would be to get each client and server into a state in
which it can recognize that a proxy needs 1.6, and spawn a 1.6 JVM, with
1.6 versions of River jars, to run it. That can be done on a gradual,
machine-by-machine basis.
The second step is to replace each program installation with its JVM 1.6
version, again on a machine-by-machine basis. During this phase, there
will be times when a 1.5 application needs to run a proxy that needs
1.6, and solves the problem by spawning a 1.6 JVM to run it.
At the end of the second step the system is fully 1.6, and the 1.5 JVM
and libraries can be uninstalled.
If a service is implemented on multiple servers, and the servers are
updated at different times, the service remains continuously available.
Does this make any sense?
Patricia