Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #26414

Re: Dynamic upgrading/Hot-swapping a service

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: Dynamic upgrading/Hot-swapping a service
Date 2017-04-24 21:37 -0700
Organization A noiseless patient Spider
Message-ID <odmjk5$5ue$1@dont-email.me> (permalink)
References (7 earlier) <s55LA.31416$8F6.17676@fx26.iad> <odipe4$1ns$1@dont-email.me> <weoLA.18035$3e5.648@fx24.iad> <odljoe$ium$1@dont-email.me> <I6yLA.6231$Es4.1266@fx20.iad>

Show all headers | View raw


On 4/24/2017 7:02 PM, Phil Martel wrote:
>>> Provided you translate and replace the existing state vector also.
>>
>> That may not be practical.
>>
>> factorial(n: int) : int
>>    ASSERT( n >= 1 )
>>    result := 1
>>    while (n > 1) {
>>       result *= n
>>       n--
>>    }
>>    return result
>> }
>>
>> factorial(n: int) : int
>>    ASSERT( n >= 1 )
>>    if (n == 1)
>>       return 1
>>    return N * factorial(n-1)
>> )
>>
>> have vastly different state vectors (assuming I haven't botched the
>> implementations).
>>
>> So, just assuming you can <somehow> map one state vector into another
>> won't give you a "fix".
> So, lets say you're in the middle of calculating factorial(1,000,000,000,000)
> with algorithm 2.  Then you find out about algorithm 1 (or maybe decide that
> Stirling's approximation is close enough).

You (as an executing client who has called upon the "factorial service"
to perform that calculation) don't "find out about" anything!  To *you*,
nothing appears remiss.  That's the whole point; as long as the API
hasn't changed, you shouldn't care that the service has been replaced
with an equivalent service.

How the *system* ensures that illusion is maintained is the problem
being addressed.

The remedy that "makes most sense" will vary with the design (and
functionality) of the service being upgraded.  And, the approach the
maintainer chooses to address those "rolling updates"

As it would be heavy-handed for the system to dictate how EVERY service
is coded AND the constraints placed upon their algorithms, the system
can only offer (prefabricated) *mechanisms* that the service designer
(and maintainer) can exploit to facilitate the upgrade.

And, the system has to rely on the designer/maintainer to make best use
of the mechanisms that it provides -- because the designer/maintainer
has more intimate knowledge of the way the service is intended to work.

A "lazy" designer may choose not to address live upgrade issues.
In which case, the system will resort to draconian measures when
an upgrade is installed:  it will KILL the running service and
let the clients deal with the resulting mess.  *Users* will then
either avoid products from that provider *or* will avoid upgrading
(if the consequences are too painful -- where "too" is a subjective
criteria defined by the user in question).

> What *can* you do with the
> unfinished solution other than dump the work and restart the problem with the
> new algorithm or let it finish? (and next time use the new algorithm)?

I prepare a document using /WordProcessor25/.  The document can be seen
as a snapshot of the "conceptual document" that I seek to prepare.
I upgrade to /WordProcessor29/.  Is all of the work that I did prior
to that upgrade lost?  (Why not?  :>  )

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-20 16:05 -0700
  Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-20 16:11 -0700
  Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-21 10:45 +0300
    Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-21 10:43 -0700
      Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-21 23:06 +0300
        Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-21 17:51 -0700
          Re: Dynamic upgrading/Hot-swapping a service upsidedown@downunder.com - 2017-04-22 14:09 +0300
            Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-22 08:55 -0700
              Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-23 13:01 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-23 10:52 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-24 10:48 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-24 12:33 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-24 22:02 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-24 21:37 -0700
                Re: Dynamic upgrading/Hot-swapping a service Phil Martel <pomartel@comcast.net> - 2017-04-25 12:19 -0400
                Re: Dynamic upgrading/Hot-swapping a service Don Y <blockedofcourse@foo.invalid> - 2017-04-25 13:54 -0700

csiph-web