On Sat, Jun 23, 2012 at 8:14 AM, Christian Grün christian.gruen@gmail.comwrote:
Hi Godmar,
in parallel to our commercial offerings, we can't provide free support for older versions of BaseX, which is why we always recommend users to switch to the latest version. If you want to know more about our Locking class and previous versions, you are invited to trace back its history:
https://github.com/BaseXdb/basex/commits/master/src/main/java/org/basex/core...
Christian,
the problem, if it is the one I'm surmising, is probably not related to the *implementation* of the Lock class (though you could have had bugs there, too), but more likely to its *use*.
In correct use, you'd probably do:
try { contextlock.lock();
....
} finally { contextlock.unlock(); }
If you don't follow this pattern *always*, the lock may be held - even though Lock itself in Lock.java is correctly implemented! - and you'll eventually deadlock.
Other BaseX users - do you see the same problems? I know from A. Weiler at least some other users did at one point.
- Godmar
Christian ___________________________
On Sat, Jun 23, 2012 at 5:14 AM, Godmar Back godmar@gmail.com wrote:
Hi,
18 months ago, I reported a bug against 6.2.7 (see email appended below) where the BaseX server deadlocks. A. Weiler at the time said that this
bug
was fixed in 6.5.1. However, I'm still seeing the bug in 6.6.3-SNAPSHOT. Before you say we don't care about 6.6.3, try it against 7.3, please
read on
for a few more paragraphs.
What happens is that the server stops processing queries after a while.
If
you connect to it via the client and type 'XQUERY ...', it just hangs.
jstack shows many threads stuck like so:
"Thread-15" prio=10 tid=0x00007fa958125800 nid=0x5823 in Object.wait() [0x00007fa957dfc000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007d84a8130> (a java.lang.Object) at java.lang.Object.wait(Object.java:502) at org.basex.core.Lock.lock(Lock.java:57) - locked <0x00000007d84a8130> (a java.lang.Object) at org.basex.core.Context.register(Context.java:198) at org.basex.core.Command.exec(Command.java:294) at org.basex.core.Command.execute(Command.java:71) at org.basex.server.ServerProcess.run(ServerProcess.java:187)
Presumably, org.basex.core.Lock is a custom lock implementation, and (I'm guessing), it's not released by whoever held it, perhaps due to bad exception handling for a previous problem.
Could that be the reason and have you addressed such issues in releases since then? (Also, is it ok to upgrade from 6.6.3 SNAPSHOT to a later version?)
Note that this issue is a show stopper for production use - it's
impossible
to gracefully stop the server, and it's we'd have to put a timeout on the socket reads in the Java driver, and even then it's difficult to recover
in
the middle of, say, checking that a user is valid in the corresponding
XML
document recording our user database.
Thanks!
- Godmar
[1] http://libx.cs.vt.edu/~gback/basex-hangs.txt
On Thu, Jan 27, 2011 at 11:03 AM, Godmar Back godmar@gmail.com wrote:
Hi,
we're observing that our BaseXServer 6.2.7 deadlocks. The stack traces
are
here: http://top.cs.vt.edu/~gback/bx/deadlock-6.2.7/basex-deadlock.txt
Could you take a look to see if these ring any bells?
Has this problem been addressed in a more recent version?
- Godmar
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk