river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: A thought on JVM migration
Date Sat, 02 Jul 2011 01:58:42 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message