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

[Paul Baumann]

>> Paul, is this something that should be incorporated into the GBS product?
>> i.e., is it generally useful for any GBS customer?

I think that would be useful, but I'm not sure how practical that will be. Martin had already moved in a useful direction by doing queries through #newMessageSend or #newServerTraversal; however, those were not application-configurable and hook points needed a little more control and monitoring than that alone. Our form of the command pattern allows simpler control of what is executed and how it is data is returned; the protocol is different. How it interacts with GBS was able to change as GBS had evolved. When a rare bug in single-trip GBS code appeared we were able to avoid it with one method change because we use our own command pattern. Here are our hooks in case your are interested:

GbsForwarder>>gbxPerform: sel withArguments: args
        ...
        delegate validateSessionForProxy: self.
        gsResult := (IcxGsQuery newForActiveView session: delegate session)
                                spec: (isForwarder ifTrue: [#delegate] ifFalse: [#current])
                                object: self
                                execute: selector
                                withArgs: args.
        isForwarder ifFalse: [^gsResult].
        gsResult == delegate ifTrue: [^self].
        isUncachedForwarder ifTrue: [^gsResult asUncachedForwarder].
        ^gsResult asForwarder

GbxObjectStub>>faultToLevel: levelOrNil
        ...
        "self faultToLevel: levelOrNil session: session delegate: delegate."
        IcxGsQuery stub: self faultToLevel: levelOrNil session: session delegate: delegate.
        self zzzisStub
        ...

IcxGsQuery class>>stub: gbsStub faultToLevel: levelOrNil session: gbsSession delegate: gbsDelegate
        "This is our hook into GBS stub faults. We do this so that we can tune replication."

        "gbsStub faultToLevel: levelOrNil session: gbsSession delegate: gbsDelegate."
        | serverTraversal level result |
        level := levelOrNil == nil
                ifTrue: [gbsSession defaultGStoSTLevel]
                ifFalse: [levelOrNil].
        serverTraversal := gbsSession newServerTraversal.
        result := serverTraversal
                rootDelegate: gbsDelegate;
                replicationSpecSelector: #icxRepSpec;
                replicationLevel: level;
                execute.
        result ~~ gbsStub ifTrue: [[result == self] gbxAssert].
        #faultToLevel:session:delegate: yourself.

        (gbsStub zzzisStub not and: [GbsConfiguration current stubDebugging and: [gbsStub respondsTo: #icxObserveAttributeTypes]])
                ifTrue: [gbsStub icxObserveAttributeTypes].

GbxObjectStub>>gbxPerform: selector withArguments: anArray
        "This does a double-dispatch so that we can monitor or tune replication."

        ^IcxGsQuery stub: self gbxPerform: selector withArguments: anArray

IcxGsProxy class>>stub: gbsProxy gbxPerform: sel withArguments: args
        "This is our hook into GBS proxy interactions so that we can monitor and tune replication."

        | answer |
        answer := gbsProxy overridden_gbxPerform: sel withArguments: args.
        "The next line was just to aid debugging."
        "(#(asText isEmpty) includes: sel) not ifTrue: [gbsProxy yourself]."
        ^answer


The #icxObserveAttributeTypes automatically updates code for the default type-specific minimal replication (#icxRepSpec). I generally consider stub faulting to be a replication spec bug, and I abhore replication as cached forwarders due to their multi-session limitations. If a fault happens then the specs can often self-tune the problem away for the next session login. Developers see the method changes and publish them with their other changes. It is a form of incremental optimization through automatic discovery of the object model in response to an inefficiency. Stub faulting is configured to use #icxRepSpec instead of the our default #icxRepSpec_minimal. Replication through a forwarder is what gets customized for the active window. It is rare to interact with GS by accident of a proxy; most interactions are through our own command pattern with automatic view-specific replication configuration.

A recent performance issue was the discovery of #remotePerform: type code in the application model that became replication costs that were not being monitored like a fault or forward. It is useful to for application code to be able to monitor the costs of every kind of interaction with GS. It is also useful to add artificial development-only delays to interactions to simulate network latency that can happen outside of development. It is a testing and tuning feature.

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 15:00
To: gemstone-smalltalk at lists.gemtalksystems.com
Subject: Re: [GemStone-Smalltalk] [GBS] How often does this error affect you?

This is a great discussion, guys. Thanks!


Paul Baumann wrote
> 5) GBS has a few modifications to cause it to always use the
> application-specific spec for every replication (including replication
> by proxy).

Paul, is this something that should be incorporated into the GBS product?
i.e., is it generally useful for any GBS customer?




--
View this message in context: http://forum.world.st/GBS-How-often-does-this-error-affect-you-tp4759041p4759065.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.