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/a805b265954e115bddd840ff4f42564c1d553b46 
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/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 <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
>