If you write server-side admin commands, read on...
I just checked in changes that introduce a shared/exclusive lock for
admin commands. Before executing each admin command, the framework
will acquire a shared lock, the exclusive lock, or no lock. The
purpose of this lock is to coordinate admin commands so that, for
example, the command that synchronizes files when a server is starting
can get a consistent snapshot of the configuration state. The
_synchronize-files command acquires the exclusive lock.
The choice of which lock to acquire is controlled by the @CommandLock
annotation on an AdminCommand class. The default, if no annotation is
present, is to acquire the shared lock.
A few commands that execute other commands that eventually result in
calls to _synchronize-files are annotated to require no lock, so as to
prevent deadlock. (If the command acquired the shared lock, then called
something that required the exclusive lock, deadlock would occur.)
Commands that are read-only (that don't modify the configuration of the
server) could also safely be annotated with
@CommandLock(CommandLock.LockType.NONE), although that's not necessary.
We might annotate more commands in this way later.
Right now there's no timeout on acquiring this lock, but we will add that.
If you run into any problems that might be related to this, let me know.
(I've been fighting with quicklook for days, but eventually got it to pass.)