[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Y Store /Closures



Avi Bryant wrote:

>On Sat, 1 Mar 2003, Daniel Weinreb wrote:
>
>> the continuation state is all in
>>virtual
>>memory and lost when there's a crash.  What can anyone recommend?
>>
>
>
>The real problem is that snapshotting is expensive
>
Indeed. What's needed here is something cheap enough to do on every request.

>
>I don't claim to have this entirely worked out - disentangling the
>important bits of a session from the rest of the image such that you have
>something reasonably small and yet self contained is a bit tricky, and for
>now when I checkpoint I use the way too heavyweight approach of just
>saving the entire image - but in Smalltalk at any rate this isn't anywhere
>near as much of a showstopper as folks make it out to be.
>
Indeed, checkpointing the entire state of VM is not appropriate if you 
might need to roll back
the state of one session but not roll back the state of everything else 
(unless there's one VM
per session and nothing else happens in the VM, I guess).

>
>As for the load balancing question, people always bring it up, and
>I've never really understood it - every application server I know of with
>significant server side state ensures session affinity, so that all
>requests for the same session come back to the same instance of the
>application.  As long as that instance stays alive, this isn't a problem
>(distributing the load session by session will, on average, work out to
>the same thing as distributing it request by request).  If a server
>instance goes down, you're back to the same problem as above - when is the
>last persistent checkpoint you have of the session that some other server
>can take over from?
>
Yes, that's probably how it's always handled. It's "not as good" in the 
sense that the balancing
is at a coarser grain (if three expensive sessions happen to get 
assigned to server 1, and none
to server 2, you're stuck), but as long as there are a "lot" of sessions 
and a "lot" of servers and
the amount of work per session is pretty random, then you're OK, and 
this gets better as the
scale goes up, which is good.

>  
>