<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 7/25/22 08:29, Johan Brichau wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3616D698-DCEB-4175-B6E9-D7C73F64B363@yesplan.be">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">Hi Martin,
<div class=""><br class="">
</div>
<div class="">Thanks for that extensive feedback!</div>
<div class="">I think this is going to help us in finding a
solution here. <br>
</div>
</div>
</blockquote>
Hi Johan,<br>
Glad to hear that.<br>
<blockquote type="cite"
cite="mid:3616D698-DCEB-4175-B6E9-D7C73F64B363@yesplan.be">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">
<div class="">Besides checking for oopIsDead: first, we’re
thinking of completely avoiding the problem by keeping the
‘deleted’ objects connected for the time that the user log
displays actions in the past. We can then remove them later
on when it’s safe to do so.</div>
</div>
</div>
</blockquote>
If an object never becomes disconnected while a user log might
display it, that should avoid the problem.<br>
<blockquote type="cite"
cite="mid:3616D698-DCEB-4175-B6E9-D7C73F64B363@yesplan.be">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">Given that I noticed that the problem
disappeared without a gem crash/restart: do you think it
would also be ok to just capture the ObjDoesNotExist error
and do nothing with it? </div>
<div class="">That would allow us to prevent an entire crash
of the application session while we create a solution to
prevent the error altogether.</div>
</div>
</div>
</blockquote>
It probably is OK to ignore the error and then not try to use the
object that caused the error, as long as you can identify which
object that is.<br>
<blockquote type="cite"
cite="mid:3616D698-DCEB-4175-B6E9-D7C73F64B363@yesplan.be">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Because it does look like we are doing things in
such a way that make it is more likely for this case to
appear….</div>
<div class=""><br class="">
</div>
<div class="">The objectForOop: is used in code that is
continuously executed (i.e. every minute for every user
session in our Seaside app) because it displays the list of
user actions that happened in the last xxx hours in the
application.</div>
<div class="">Because ‘delete actions’ are definitely on that
‘user action log’, the oops that are retrieved can be of
disconnected/dead objects.</div>
<div class="">We notice that many of our users just keep their
app session logged-in overnight and therefore this gets
executed many times concurrently with an MFC+reclaim run.</div>
</div>
</blockquote>
<br>
I agree that this pattern is more likely to get this kind of error.
I'd recommend keeping deleted objects referenced, in the log or
elsewhere, until xxx hours have passed. Which is what you were
describing above, I think?<br>
<br>
<blockquote type="cite"
cite="mid:3616D698-DCEB-4175-B6E9-D7C73F64B363@yesplan.be">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
<div class="">Finally, the Seaside error handler logs the
continuation of the error to the objectLog, so a commit
happens when the dead object retrieved via the objectForOop:
is on the stack. In fact, because the continuation is saved,
it is probably even committed again?</div>
</div>
</blockquote>
I don't immediately know whether it would be possible to commit a
reference to the disconnected or dead object. Maybe. At certain
times in the GC process committing a reference to a disconnected
object would connect it and keep it from being GCed. After the
object was promoted to dead, if a reference to that oop succeeded in
being committed, you'd end up with a reference to a non-existent
object. Eventually if that OOP was reused it would become a
reference to the new object. Generally a situation to avoid. In your
case it sounds like these objects are parts of object graphs that
are considered "deleted" by your application, so are less likely to
cause problems.<br>
<br>
Regards,<br>
-Martin <br>
</body>
</html>