[Glass] Help understanding a RcReadSet commit conflict

[Dale Henrichs via Glass]

On 6/17/16 12:56 PM, Mariano Martinez Peck wrote:
> Hi Dale,
>
> On Fri, Jun 17, 2016 at 4:20 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto: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.
Well, right now you are resuming a TransactionError and I would want to 
see the stack and the description of the actual error ... it might be 
related to the current problem ... if you are "ignoring a meaningful" it 
may have an impact of future commits.
>
>
>     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???
>
well, the transactionConflicts report shows no conflicts, so we are 
getting a commit conflict where there are not actual conflicts ... this 
could be a bug, but I would like to know for sure that the "ignored" 
TransactionError is not involved ... so perhaps some additional logging 
for the "resumed TransactionError" is called for ..

The stack isn't useful - as you claim - so right now I can only be 
suspicious of the "resumed Transaction errors" ...

I'm not in the office today --- not feeling well --- so on Monday I will 
talk to some folks about additional measures we can take --- it's also 
time to ask about the version of GemStone that you are using:)

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