[Glass] Help understanding a RcReadSet commit conflict

[Dale Henrichs via Glass]

On 6/23/16 12:20 PM, Mariano Martinez Peck wrote:
>
>
> On Wed, Jun 22, 2016 at 5:21 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>
>     On 06/22/2016 12:20 PM, Mariano Martinez Peck wrote:
>>
>>
>>     On Wed, Jun 22, 2016 at 2:52 PM, Dale Henrichs via Glass
>>     <glass at lists.gemtalksystems.com
>>     <mailto:glass at lists.gemtalksystems.com>> wrote:
>>
>>
>>
>>         On 06/16/2016 07:54 AM, Mariano Martinez Peck via Glass wrote:
>>
>>
>>
>>             Inspect aFaBackgroundProcess/aSymbolDictionary(
>>             #'WriteWrite_minusRcReadSet'->anArray( aDictionary( )),
>>             #'commitResult'->#'failure', #'RcReadSet'->anArray(
>>             aRcCollisionBucket( aRcKeyValueDictionary( ,........)
>>             --------------------
>>             .                -> aSymbolDictionary(
>>             #'WriteWrite_minusRcReadSet'->anArray( aDictionary( )),
>>             #'commitResult'->#'failure', #'RcReadSet'->anArray(
>>             aRcCollisionB...
>>             ..               -> aFaBackgroundProcess
>>             (class)@         -> SymbolDictionary
>>             (oop)@           -> 15059544321
>>             (committed)@     -> true
>>             (notTranlogged)@ -> nil
>>             1@               -> #'commitResult'->#'failure'
>>             2@               -> #'RcReadSet'->anArray(
>>             aRcCollisionBucket( aRcKeyValueDictionary(
>>             'siteDB-debris-gemstone'->aFaGemStoneDataStore)),
>>             aRcCollisionBucket( aRcK...
>>             3@               -> #'Write-Write'->anArray( aDictionary( ))
>>             4@               ->
>>             #'WriteWrite_minusRcReadSet'->anArray( aDictionary( ))
>>
>>         Mariano,
>>
>>         I guess we are both blind:) ... While describing the
>>         "problem" to a co-worker I noticed that the the Write-Write
>>         set is NOT EMPTY :):
>>
>>           3@               -> #'Write-Write'->anArray( aDictionary( ))
>>
>>         The conflict that you are getting is on the empty dictionary
>>         (aDictionary( )) ... presumably you are creating an empty
>>         Dictionary somewhere in shared state and two sessions are
>>         trying to update the dictionary...
>>
>>
>>
>>     Uff  wtf!!!! Crap, we were both blind. Sorry to bother. Ok...the
>>     hunting (findAllReferencePathsTo... )  has become... will see if
>>     I can track down this guilty empty dict.
>>
>>     Thanks!
>>
>     haha ... happy hunting ...
>
>
> OK, it was quite easy. Thanks for the extra pair of eyes.
>
>     BTW, if you find traipsing through the output of
>     findAllReferencePathsTo... to be frustrating, you might want to
>     try Obex[1] for visualizing the referencespath structure... Obex
>     is still under development and it might require a bit of tweaking,
>     but one of it's features is to allow you to build a visual network
>     of the objects in the findAllReferencePathsTo... result set ...
>     '
>
>
> Yes, I am aware of it... but:
>
> 1) I still cannot use latest tODE and won't be able until we have all 
> the none-DataCurator thingy
> 2) findAllReferencePathsTo takes a lifetime for my repo. I am talking 
> of an hour or so... so I cannot imagine a UI with that performance.
>
> What I end up doing is to fire the findAllReferencePathsTo in a gem 
> (like in tODE) and then do a "tail -f " of the gem log. Most of the 
> times, the most important reference paths is the first one or so... 
> then I see first..analyze code, then get the OOP which may be pointing 
> to it. Then kill gem and start again the findAllReferencePathsTo with 
> the new OOP ... and like that until I find the guilty one.
>
> Thanks!
>
For 3.4 we are working on a fast reference scan based on quickly finding 
the parents of a particular set ofobjects in a single scan and this scan 
can be done relatively quickly ... the result of this scan will also 
yield a single single reference path ... if I'm not mistaken this is 
equivalent to "getting the first reference and killing the gem" ...the 
obex gui is really targeted at supporting this model as well as other 
schemes for analyzing objects in your repo ...  while working on this I 
am creating visualizations for all of the existing repo analysis methods 
as well ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160624/a19cd662/attachment-0001.html>