On Sat, Jun 23, 2012 at 8:14 AM, Christian Grün <[email protected]>wrote:
> 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/Lock.java > > 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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > >
_______________________________________________ BaseX-Talk mailing list [email protected] https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
