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

Wed May 14 11:04:01 PDT 2014

Sounds like we both had similar issues -- our solutions were a bit 
different ...
1) fault level 1 -- two special Array subclasses fault 2 and 3, specific 
ivars can get 2 or 3, usually auto-specified
2) individual connects were not a critical issue, but a large number at 
login got complaines
     - connect about 50 at login
     - open UI it figures out what it needs and connects them in a group
3) we deal a lot with Dates/Times/Fixed-Point -- they mostly get stored 
as SmallInteger, expanded via read-accessor
4) store lots of nil's and use lazy initialization (actually no, just 
returns the initial value, never stored)
5) our major Collections (Customers, Orders, Sales-Reps, .... -- 5000 
things) live on Gemstone, objects accessed and cached
         to VW

Took some time, but performance is pretty darn good now.

On 2014-05-14 1:32 PM, Paul Baumann wrote:
> Hi Dennis,
>
> We use bulk class connection (perhaps tuned here) of about 1,000 classes in sessions that are long-lived. Connection performance isn't a concern here anymore. Proper replication-spec behavior is important for us, so on-demand connection is not an option. The specs were required to avoid performance issues that are hopefully fixed since the GBS release we use. If the problems still exist then you may be missing out on huge performance gains by not carefully controlling replication policy. This is a short description of our replication configuration:
>
> 1) 2 is default fault level (1 is preferred, but some collections need 2 for specs to behave properly through them)
> 2) Simple objects like strings and dates are always replicated because a proxy takes as much time to create.
> 3) A home-grown spec framework generates a type-specific default replication spec that leaves the non-simple objects in GS unless requested.
> 4) The active window determines what spec is used, and specs can be customized for every window.
> 5) GBS has a few modifications to cause it to always use the application-specific spec for every replication (including replication by proxy).
> 6) Deliberate replication is through our own framework that specifies depth.
> 7) We use the Collection Views framework that I'd demonstrated at a Smalltalk conference some years ago.
> 8) Code is designed for one-trip-per-click to reduce the number of trips to GS while returning a minimum number of non-simple objects.
> 9) #instVarMap declarations are used avoid transporting data for unpaired attributes.
>
> The great attention to replication was required to regain adequate performance. Any replication problems get noticed by users.
>
> Paul Baumann
>
> -----Original Message-----
> From: gemstone-smalltalk-bounces at lists.gemtalksystems.com [mailto:gemstone-smalltalk-bounces at lists.gemtalksystems.com] On Behalf Of Dennis Smith
> Sent: Wednesday, May 14, 2014 12:49
> To: gemstone-smalltalk at lists.gemtalksystems.com
> Subject: Re: [GemStone-Smalltalk] [GBS] How often does this error affect you?
>
> 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
>
>
> _______________________________________________
> 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.

-- 
Dennis Smith
Cherniak Software Development Corporation
416.798.7948  x208