[Glass] Help understanding a RcReadSet commit conflict

Fri Jun 17 12:56:07 PDT 2016

Hi Dale,

On Fri, Jun 17, 2016 at 4:20 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Okay ... I'm interested in the TransactionError that is not a
> TransactionError ... that is a bit surprising to me and I'd be interested
> in addtional details ... don't think that it's related to the current
> problem, but who knows :)
>

Yes, but I don't know how to give more information. More below.

What does the #commitConflicts: method do?
>

It's a simple setter. The method #runInForeground I published is in
FaBackgroundProcess (persistent domain object). And so this
#commitConflicts simply stores the commit conflicts into an instVar of it
for further analysis.

> So far I don't see anything suspicious ...
>
> Is this problem reproducable?
>

No, unfortunately, it's not :(

> It may be time to record a stack in the log
>

I already record into the stack, maybe not exactly what you suggest next,
but at least, please see attached file.

 As you can see in the stack, it looks like the normal / domain logic
finished (in #runProcessBlock) and so the line 10 of #runInForeground does
the #commit. So it simply looks like  a commit conflict when the job
finished.

Does this stack helps somehow? Note that it shows some OOP etc and I can
still get this OOP if you need them.

> and perhaps take a look at System class>>_commitPrintingDiagnostics for
> logging the commit conflicts to the log as well ... The code in System
> class>>_commitPrintingDiagnostics implies that not all fields are in the
> transactionConflicts dictionary are set, so that may be a red herring.
>
Thanks for pointing out to #_commitPrintingDiagnostics. In fact it looks
pretty similar to what I do, right? And yeah, those #ifAbsent:[] may
suggest we may not be able to get all fields. But then...how do we get
them???

Thanks!

Dale
> On 6/17/16 11:56 AM, Mariano Martinez Peck wrote:
>
>
> On Fri, Jun 17, 2016 at 3:17 PM, Dale Henrichs via Glass <
> <glass at lists.gemtalksystems.com>glass at lists.gemtalksystems.com> wrote:
>
>> Mariano,
>>
>>
>> It has been awhile since I've done any reduced conflict work, so the
>> details of the reduced conflict mechanism need to be paged back in ... with
>> a bit of poking around I believe that the RcReadSet is not involved
>> directly in the actual conflict, especially since the #Write-Write set is
>> empty ... from the information I've seen here, there shouldn't have been a
>> conflict ...
>>
>
> That was the part I didn't understand. As the rest of the keys were empty
> and the result was #failure , I couldn't understand why RcReadSet (the
> only none empty key) would make the commit to fail....
>
>
>> Is there a reason that you are not showing the full set of fields in a
>> conflictDictionary? I would expect to see fields for each of the following
>> (from System class>>transactionConflicts):
>>
> No. Actually, I pasted all I can see from that dictionary. So maybe the
> problem is how I am capturing and persisting this?
> Here [1] you can see how I do my best to capture the transaction conflicts
> for later analysis. Note that since this is a background process I cannot
> immediatly debug it. That's why I try to persist the commit conflicts
> together with my persistent background instance before I loose it
>
>
>
>>      Key                Conflicts
>>  Read-Write          StrongReadSet and WriteSetUnion conflicts.
>>  Write-Write         WriteSet and WriteSetUnion conflicts.
>>  Write-Dependency    WriteSet and DependencyChangeSetUnion conflicts.
>>  Write-WriteLock     WriteSet and WriteLockSet conflicts.
>>  Write-ReadLock      WriteSet and ReadLockSet conflicts.
>>  Rc-Write-Write      Logical write-write conflict on reduced conflict
>> object.
>>  WriteWrite_minusRcReadSet  (WriteSet and WriteSetUnion conflicts) -
>> RcReadSet)
>>
>> Both the Write-Dependency and Rc-Write-Write fields would have useful
>> information if they weren't empty ...
>>
>> Barring additional information I suppose it might be useful to see the
>> error message and any other information from the log file (perhaps a stack?)
>>
>
> I suspect I am capturing/persisting wrongly the commit conflicts.
>
>
> Thanks in advance for any help.
>
>
> [1] http://ws.stfx.eu/JRWK7K047PUO
>
>
>
>
>> Dale
>> On 6/16/16 7:54 AM, Mariano Martinez Peck via Glass wrote:
>>
>> Hi,
>>
>> My code that runs background jobs on a separate gem (based on Otto's
>> code...similar to ServiceVM), stores the commit conflict information inside
>> the persistent background process instance for post commit conflict
>> analysis.
>>
>> I have a job that failed today and with the following commit conflict
>> info:
>>
>> 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(
>> ))
>>
>>
>> So... commitResult is #failure and the only thing set up is RcReadSet. I
>> have searched in the programming guides for RcReadSet and I found nothing.
>> I am inspecting the array of it, but it is of size 973...which makes it
>> impossible to understand what it really caused the conflict.
>>
>> Is there any tip on how can analyze this better?
>>
>> Thanks,
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>> _______________________________________________
>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160617/9ce937c1/attachment-0001.html>
-------------- next part --------------
--transcript--'BackgroundProcess 13450908673 finished.'
--transcript--'BackgroundProcess 13450908673 failed with details: a TransactionError occurred (error 2738), reason:commitConflicts, commit conflicts'
--transcript--'StackTrace:  1 FAGemStoneCompatibility class >> printExceptionStack:toLevel:on: @2 line 2  [GsNMethod 35369103617]
2 [] in  ExecBlock1 (FaBackgroundProcess) >> handleException: @3 line 4  [GsNMethod 35404088833]
3 String class (SequenceableCollection class) >> new:streamContents: @5 line 5  [GsNMethod 32541057793]
4 String class (SequenceableCollection class) >> streamContents: @2 line 3  [GsNMethod 32541057281]
5 [] in  ExecBlock0 (FaBackgroundProcess) >> handleException: @2 line 4  [GsNMethod 35395572737]
6 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
7 FaBackgroundProcess >> handleException: @5 line 5  [GsNMethod 35385763073]
8 [] in  ExecBlock1 (FaBackgroundProcess) >> runInForeground @3 line 32  [GsNMethod 35404088321]
9 TransactionError (AbstractException) >> _executeOuterHandler: @3 line 7  [GsNMethod 26844481025]
10 TransactionError (AbstractException) >> _pass:with: @4 line 13  [GsNMethod 26844477953]
11 TransactionError (AbstractException) >> pass @2 line 14  [GsNMethod 26844477185]
12 [] in  ExecBlock1 (FaBackgroundProcess) >> runInForeground @10 line 24  [GsNMethod 35408906241]
13 TransactionError (AbstractException) >> _executeHandler: @3 line 8  [GsNMethod 26844481537]
14 TransactionError (AbstractException) >> _signalWith: @1 line 1  [GsNMethod 26844482049]
15 TransactionError (AbstractException) >> signal: @3 line 7  [GsNMethod 26844479745]
16 System class >> commit @9 line 37  [GsNMethod 26844863745]
17 [] in  ExecBlock0 (FaBackgroundProcess) >> runInForeground @2 line 10  [GsNMethod 35408906497]
18 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
19 [] in  ExecBlock0 (FaBackgroundProcess) >> runInForeground @3 line 11  [GsNMethod 35404088577]
20 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
21 [] in  ExecBlock0 (FaBackgroundProcess) >> runInForeground @7 line 28  [GsNMethod 35395568129]
22 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
23 FaCurrentUserContextInformation class (WADynamicVariable class) >> use:during: @2 line 4  [GsNMethod 34963568897]
24 FaUserContextInformation class >> withLoggedInUsername:do: @5 line 6  [GsNMethod 35367815681]
25 FaBackgroundProcess >> runInForeground @3 line 3  [GsNMethod 35385758977]
26 Executed Code  @15 line 7  [GsNMethod 15059547393]
27 <Reenter marker>
'