[Glass] Help understanding a RcReadSet commit conflict

[Mariano Martinez Peck via Glass]

On Wed, Jun 22, 2016 at 5:21 PM, Dale Henrichs <
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>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!


>
>
Dale
>
> [1] https://github.com/dalehenrich/obex#object-explorer-for-gemstones-64
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160623/4b6bd749/attachment.html>