deadlock saving a script when it is running

[KitWallace]

Deadlock occurs if an xquery script is edited and saved whilst it is running and using the db. Monex is unresponsive so query cant be stopped; shutdown hangs and a dirty restart needed (6.4)

Generate

xquery version "3.1";
<trips>
    {for $i in 1 to 1000
    return
        <Trip>
            <id>{concat("trip-",$i)}</id>
        </Trip>
    }
</trips>

Run

xquery version "3.1";
let $tripid := "trip-250"
return
      <test>
        {count(for $i in 1 to 1000
               return  doc("/db/apps/test/data/trips.xml")//Trip[id  = $tripid])
        }
      </test>

[line-o]

@KitWallace Unfortunately, this is a known issue that we hoped was solved with the new locking introduced in exist version 5. So thanks for bringing this up and especially providing a reproducer.

[line-o]

It would help us if you could tell us how you run your instance. Which operating system, which java version and what CPU architecture?

I always use xst info for that.

[adamretter]

that we hoped was solved with the new locking introduced in exist version 5.

@line-o Nope! This was actually introduced in eXist-db 5 with the locking rewrite that my company contributed to eXist-db to reduce the likely hood of ending up with corrupted resources or a corrupted database.

[adamretter]

@KitWallace Thanks, is it possible that you could provide us with a dump of the Lock Table when this occurs please?

[KitWallace]

@line-o This the sort of thing? (but what's xst info ?)

eXist 6.4.0 2e4182841b38317324877c0b2e1febcaa26ed83a 2025-05-06T14:29:27Z

kitwallace@kitwallace:~$ java -version openjdk version "21.0.8" 2025-07-15 OpenJDK Runtime Environment (build 21.0.8+9-Debian-1) OpenJDK 64-Bit Server VM (build 21.0.8+9-Debian-1, mixed mode, sharing)

lsb_release -a Description: Debian GNU/Linux 13 (trixie) Release: 13 Codename: trixie

Server at Bitfolk https://bitfolk.com/plans.html

Name | RAM | Storage | Data Transfer | Host | Operating System | Arch. kitwallace | 3,072 | 30.00 | 2,000 | paradox | Debian 13.x (trixie) | x86_64

2 virtual CPUs (ability to burst to [two full physical CPU cores]

[KitWallace]

@adamretter How would I do that?

[KitWallace]

This issue looks to be the same https://github.com/eXist-db/exist/issues/4022

[adamretter]

@adamretter How would I do that?

@KitWallace You need to have remote JMX enabled temporarily for your server. If you don't have that, you can set the JAVA_OPTS like so before running startup.sh:

$ JAVA_OPTS="-Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false" bin/startup.sh

Then you can simply run:

bin/jmxclient.sh --locks

[duncdrum]

@KitWallace thank you for reporting this. We spend some time trying to reproduce this, and we were able to do so with specific combinations of editor interfaces. So while this is a pretty bad bug, the good news is that it's reproducible, and also that sticking with a single editor interface does not create the deadlog.

[KitWallace]

@duncdrum Thanks for the work done to look at this bug. I'm not sure what you mean about "sticking with a single editor interface does not create the deadlog." Do you mean there are editors which don't cause the deadlock? What are they?

[line-o]

@KitWallace Which editor are you using at the moment? We were not able to reproduce the deadlock when editing the file from eXide.

[KitWallace]

eXide