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