Bug #2677
openHandgman: handle concurrent modification exception
0%
Description
Hi, I am testing on Mac OS X Mavericks.
If I checkout a recent git revision and run the hangman example, all the HTTP requests are shown as taking 10 seconds in the log, although the browser page is rendered immediately. But, if I open two separate browsers and play hangman at the same time, I can introduce a repeatable race, where one of the two hangman sessions get reloaded with an error in Dbo (I forgot the precise error, but it mentions a stale object I think) and the transaction fails.
Anyway, I did an git bisect starting from 2014-01-01 until the latest commits. The test I used was simply to see if the log was
[2014-Feb-13 22:18:52.927859] 2611 - [info] "WebRequest: took 10005ms" <= the bug
or something more like
[2014-Feb-13 22:18:52.927859] 2611 - [info] \"WebRequest: took 10ms\" <= fine
I could test all the revisions, because many of them have the bug with Boost random and the built itself is broken.
Now, at least revision 11485bb94e432d40b3772e7ed8dda09e209a8fc4 is good.
Here is the trace:
tortellino[~/src/wt.git]$ git checkout `git rev-list -n 1 --before="2014-01-01" master`tortellino[~/src/wt.git]$ git bisect start
HEAD is now at 11485bb... Several updates:
tortellino[~/src/wt.git]$ git bisect good <=== mark good 2014-01-01tortellino[~/src/wt.git]$ git rev-list -n 1 ---before="2014-02-14" master
eedfab588fba7ca594c476bec8675a2817a30edd
tortellino[~/src/wt.git]$ git bisect bad eedfab588fba7ca594c476bec8675a2817a30eddtortellino[~/src/wt.git]$ git bisect bad <= HTTP request 10000ms
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[b794e1e12d866d209ba153699f35b10fa00c5358] Merged in bootstrap3 and httpd-recheck branches:
Bisecting: 2 revisions left to test after this (roughly 1 step)
[bd44598675f1ef7a704149fd6844a6d1c41f2682] fix MSVC preprocessor error, MySQL regression, and boost random build annoyances
@tortellino[~/src/wt.git]$ git bisect skip < build broken
Bisecting: 1 revision left to test after this (roughly 1 step)
[4586458d0c33a796ee7ba2d26f0d8aeb55c574a6] Several changes:
tortellino[~/src/wt.git]$ git bisect skip <=== build brokentortellino[~/src/wt.git]$ git bisect skip
Bisecting: 1 revision left to test after this (roughly 1 step)
[7a76b58f7c5727020262706c495798815822d8d3] Several changes:
Bisecting: 1 revision left to test after this (roughly 1 step)
[e288cfa7c00afbd4b65dfbfc104fc5847ebb3bbd] Several changes:
@tortellino[~/src/wt.git]$ git bisect skip
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
4586458d0c33a796ee7ba2d26f0d8aeb55c574a6
bd44598675f1ef7a704149fd6844a6d1c41f2682
7a76b58f7c5727020262706c495798815822d8d3
e288cfa7c00afbd4b65dfbfc104fc5847ebb3bbd
b794e1e12d866d209ba153699f35b10fa00c5358
We cannot bisect more!
Updated by Koen Deforche about 10 years ago
- Status changed from New to Feedback
Hey Marco,
The WebRequest: took 10005ms message is innocent. We've rearchitected the httpd front-end and as a consequence this message is not actually accurate for the last reply on a connection that is getting timed out (which happens at 10 seconds).
It needs to be fixed but is a low priority; it is completely harmless though.
But I'm interested in the other problem you describe, related to Wt::Dbo: could it be you were logged in twice as the same user and thus you had a (rightful) optimistic concurrency locking problem?
Regards,
koen
Updated by Marco M about 10 years ago
Hey Koen,
ahhh, I thought that the 10000ms was the cause of the race I mention, and I focused on that because it is easier to test :-)
Yes, I was using two browsers and I was logged in as the same user; I thought about the optimistic locking but then I think I forgot. So let's see if I get it straight:
in hangman, in case one transaction fails, the effect is that the whole WApplication is destroyed (cleanly, but still the session is reloaded)? Because this is what I saw. So, one would have to add recover logic to keep the game state, right? Because loosing a game just because a transaction to lookup the score fails seems a bit brutal ;-)
Or should I investigate a bit more and come up with a repeatable test?
Updated by Koen Deforche about 10 years ago
- Subject changed from wt from recent git: "WebRequest: took 10005ms" to Handgman: handle concurrent modification exception
- Status changed from Feedback to New
Hey,
That would indeed be what happens in case of an unhandled exception.
I actually think that we should fix the hangman game to handle this, as an example of how to handle concurrent modification exceptions.
In this case: we should catch the exception, reread() the affected dbo objects and resave on top of the modified state from another session (i.e. combining the two game score).
Regards,
koen