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 ___________________________

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

So I grepped through your code.

Turns out you did in fact, make at least one such a fix so that your code complies with the correct idiom. Lock appears to be used only in Context.register, requiring a matching call to Context.unregister

The first one is in Command.java and was fixed Mar 4, 2012:

https://github.com/dimitarp/basex/commit/a805b265954e115bddd840ff4f42564c1d5...

This fix would correct deadlocks occurring when there is an exception during the execution of a command (I'm guessing here this means commands such "CREATE DB", etc.

The second one is in basex/server/QueryListener. This one is more difficult to track down. The try/finally pattern appears to have been used since eb2d16152e92252a43bb94d6965e3ac342de949b in Sep 14/2011. Before that, the unregister call was in a close() method.

(BTW, Christian, my question was not about "support for old versions", but whether you recall fixing the bug without someone else having to track down the entire BaseX history. I was assuming that perhaps you'd remember had you fixed such a bug.)

Anyway, since the code *may* be broken prior to eb2d16152e92252a43bb94d6965e3ac342de949b, and definitely was broken prior to a805b265954e115bddd840ff4f42564c1d553b46 for Commands, and since these could account for the behavior I'm seeing, I'll try the latest BaseX (let's cross fingers it doesn't have namespace handling regressions).

- Godmar

On Sat, Jun 23, 2012 at 8:37 AM, Godmar Back godmar@gmail.com wrote:

On Sat, Jun 23, 2012 at 8:14 AM, Christian Grün <christian.gruen@gmail.com

...

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...

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