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

Groups > comp.arch.embedded > #26424

Re: Dynamic upgrading/Hot-swapping a service

Show all headers | View raw

On 4/25/2017 0:37, Don Y wrote:
> 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"
>

I used the word "you" to mean the system providing the service 
(including the programmer who implemented the new algorithm).  However, 
a factorial calculation is a poor example in that it is not persistent. 
It may make sense for you (the system) to dump the work you've done and 
start over, or to continue with the old algorithm for this instance.
> 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?  :>  )

I think the example you're trying for is that you run a word processor 
service and that I'm a client.  I'm typing into a document using 
/WordProcessor25/ (which I think of as /WordProcessor/).  You want to 
upgrade to /WordProcessor29/ while I'm typing right here.
                                                       ^
In this case, perhaps in most cases, there's some point where the system 
can save its state as a checkpoint, start the new software and continue. 
  If the system can do the change between user inputs, the change will 
be transparent.  The case where the inputs come too fast is where it 
gets tricky and you may have to keep a copy of the old code running.

Best wishes,
--Phil
pomartel At Comcast(ignore_this) dot net

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