[GemStone-Smalltalk] [GBS] How often does this error affect you?

[Dennis Smith]

I agree with all of this, except the connections -- we cannot connect 
all our classes.  We have, in the largest client, about 6,000 classes 
that can be connected.
Not only would that take a very long time to do, but it tends to slow 
things down operationally.

In any given session, the number is more likely on the order 500 or 600, 
but we cannot predict -- so connects are done as needed (except for 
about 50 or so
that everyone would use).

I agree with errors for non-migrated (either direction) -- they are 
likely a serious problem.


On 2014-05-14 12:44 PM, Paul Baumann wrote:
> Hi Richard,
>
> Problems like that are familiar, and are reduced with procedure. A related GBS issue is that replication can't behave according to spec as classes are connected on demand. Primarily from replication side effects, we turn off all on-demand generation of classes and connectors. An error is the proper way to show something as serious as a missing class or connector; arguably, an error is also a proper way to show class skew was discovered since connection. Client and server builds are deployed together. Gem Kit-produced GS patches with class changes or migrations are a special "cold" patch that is deployed with no active clients sessions. If someone changes a GS class that development clients are connected to then that session gets an error and the session works fine after reconnection. It is not a problem for us because the tools and processes we use are oriented toward working around it. With suitable procedure, an error like that becomes an environment management issue more t
>   han a GB
>   S bug.
>
> It is an old problem. GBS attempts to do things that it can't do well (like using traversal content to discover in-traversal what the traversal content should have been). I remember looking at how to avoid it many years ago. The modifications required were in sensitive areas of code with far more risk than potential reward, so the problem endured. It sounds like 3.2 dives deep into those sensitive areas, so good luck. Replication policy is still incorrect even if you avoid the error, so I'd still configure GBS to raise errors instead. The approach that I'd explored was to discard the report and replay after clamps have been rebuilt, but that is imperfect because some of the cached objects have already been updated by the time the problem is discovered.
>
> Paul Baumann
>
>
> -----Original Message-----
> From: gemstone-smalltalk-bounces at lists.gemtalksystems.com [mailto:gemstone-smalltalk-bounces at lists.gemtalksystems.com] On Behalf Of Richard Sargent
> Sent: Wednesday, May 14, 2014 11:44
> To: gemstone-smalltalk at lists.gemtalksystems.com
> Subject: [GemStone-Smalltalk] [GBS] How often does this error affect you?
>
> If you have a class in your client image mapped to the latest (or only) version of a server class, creating a new version of the server class will result in replication errors until you reconnect the client class to the new server class version.
>
> GBS is designed to automatically migrate instances of older versions of a server class to the version that the client is connected to when you replicate such an instance. This is the "skew" case.
>
> The problem case is the anti-skew, in which the automatic migration - if it were to happen - would have migrated instances of newer versions of the class to older versions. GBS throws an error. This error can arise as soon as you change the class definition and agree to "commit and migrate", if you already have an instance of the class replicated into the client image. It can also occur at any point following this event, if any subsequent replication tries to bring back an object graph referencing an instances of the new class version.
>
> The error is a GbsClassGenerationError. It will occur more frequently starting with server version 3.2, since we corrected the problem of #become:
> not notifying the GCI client (GBS in this case) of the change. Migration of instances to the new class version uses #become:.
>
> There are two workarounds to the error. One is to log out and back in again.
> The second is to use the Connector Browser and reconnect the class to the server. (The browser would show the class as disconnected, since the class is mapped to an older version, rather than the latest version of the named
> class.)
>
>
> We would appreciate your feedback on how much of a problem this has been for you in the past, and if you have started to upgrade to 3.2, how much it impacts you now. Additionally, feedback on how you would like GBS to handle this case (other than "don't throw an error") would help us determine what we need to do.
>
>
> Thank you,
> Richard Sargent
>
>
>
>
> --
> View this message in context: http://forum.world.st/GBS-How-often-does-this-error-affect-you-tp4759041.html
> Sent from the Gemstone/S mailing list archive at Nabble.com.
> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
>
> This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

-- 
Dennis Smith
Cherniak Software Development Corporation
416.798.7948  x208