Hi Christian,

The client code is tiny and is all based on the Java API (although it's in Scala).  Even for people not familar with Scala it should be readable.  I'm curious if somebody sees a fatal flaw or something that could be improved.

This is it:

  def withSession[T](block: ClientSession => T): T = {
    val session = new ClientSession(host, port, user, pass)
    try {
      block(session)
    }
    finally {
      session.close()
    }
  }

  def withDbSession[T](database: String)(block: ClientSession => T): T = {
    withSession {
      session =>
        session.execute(new Open(database))
        session.execute(new Set("autoflush", "false"))
        val result = block(session)
        session.execute(new Flush())
        result
    }
  }

  def add(database: String, path: String, document: String) =
    withDbSession(database)(_.add(path, new ByteArrayInputStream(document.getBytes("utf-8"))))

This add() function gets called about a million times, ha ha, literally.

Creating an SSCCE might be tricky for such a concurrency issue.  I'll see if the crashing persists and maybe find a way to reproduce it if so.

I've really come to enjoy doing everything on the back end with XQuery/BaseX.  Quite fun composing queries using Scala multi-line string interpolation.

  def getIds(since: String): String = db {
    session =>
      val q = s"""
        |
        | let $$records := collection('$recordDb')/narthex
        | return
        |    <ids>{
        |       for $$narthex in $$records
        |       where $$narthex/@mod >= ${quote(since)}
        |       order by $$narthex/@mod descending
        |       return
        |          <id>{$$narthex/@mod}{string($$narthex/@id)}</id>
        |    }</ids>
        |
        |""".stripMargin.trim
      session.query(q).execute()
  }



Gerald




> Ah I found out how to remove the lock from
> http://docs.basex.org/wiki/Transaction_Management.  Just deleted the upd
> file.
>
> After that and a restart it seems to be working again, but the reality is
> that it died on me.  I still need clues to figure out why.  Are there some
> tricks, like increasing memory or something, which will prevent it being
> overwhelmed?  (if that's what happened).

It's difficult to say in general what may have causes the faulty
behavior. You could check out the information stored in the database
logs [1]. Maybe there was one particular query that caused the
slowdown?

> Exception in thread "Thread-1637" java.lang.IllegalMonitorStateException
> at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryRelease(ReentrantReadWriteLock.java:374)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1260)
> at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.unlock(ReentrantReadWriteLock.java:1131)
> at org.basex.core.DBLocking.release(DBLocking.java:219)
> at org.basex.core.Context.unregister(Context.java:249)
> at org.basex.core.Command.execute(Command.java:104)
> at org.basex.core.Command.execute(Command.java:117)
> at org.basex.server.ClientListener.execute(ClientListener.java:384)
> at org.basex.server.ClientListener.add(ClientListener.java:355)
> at org.basex.server.ClientListener.run(ClientListener.java:100)

This usually indicates that the client/server code is used in some
unorthodox way. Do you think you can provide us with an SSCCE?

Thanks,
Christian

[1] http://docs.basex.org/wiki/Logging



--
Delving BV, Vasteland 8, Rotterdam
http://www.delving.eu
http://twitter.com/fluxe
skype: beautifulcode
+31629339805