As an additional remark I set the MIXUPDATES = true option.
Moreover I notice the wording "Creating database..." among the request logs that are output when running with -d [1].
This sounds strange (the only point I see the string in the code is the Builder class [2]) but it happens also with 8.6.7 which doesn't show this misbehaviour.

M.

[1]
_ REQUEST _________________________________
(GET /hlcm/xdwapi/v2/xdw/2.25.8046764881955849894)@912634350 org.eclipse.jetty.server.Request@3665b1ee
- Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
- Connection: keep-alive
- User-Agent: Java/13
- Host: 10.17.217.1:8984
_ RESPONSE ________________________________
HTTP/1.1 200
Set-Cookie: JSESSIONID=a2ryzgdm4t941ra9jmes9mj87;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: application/xml; charset=UTF-8

Creating Database...
. 5.58 ms (100 MB)
_ REQUEST _________________________________
(GET /hlcm/taskviewer/showworkflow?workflowid=2.25.8046764881955849894)@1286045891 org.eclipse.jetty.server.Request@4ca780c3
- Accept: */*
- Connection: keep-alive
- Referer: http://localhost:8984/ui/hlcm/main.cameo?config=HLCM_1&patient=test1&owner=rossi
- Accept-Encoding: gzip, deflate, br
- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/75.0.3770.90 Chrome/75.0.3770.90 Safari/537.36
- Accept-Language: it,en-US;q=0.9,en;q=0.8
- Cookie: COOKIE_SUPPORT=true; GUEST_LANGUAGE_ID=en_US; pnctest=1; JSESSIONID=2g5ep7mzq0ah1ktre4b398hfc
- Host: localhost:8984
_ RESPONSE ________________________________
HTTP/1.1 200

[2] https://github.com/BaseXdb/basex/blob/f7a5492c46d55e1c1f58df24b8ed9567c176e8c1/basex-core/src/main/java/org/basex/build/Builder.java

On 26/07/19 16:29, Marco Lettere wrote:
Hi all,

starting with 9.2.1 we experience a strange error with a RESTXQ API  of ours that we have been using for years.

The typical pattern is lookup a document update it and store it back.

We have done this milions of time and also all the tests work neatly.

But when using it from inside the web application, at around the tenth operation we get the DB corrupted with the stack trace [1]. This seems to happen only when the database is nearly empty and, for sure, it doesn't appear on 8.x series.

It feels like some concurrency flaw is introduced somewhere but it's hard to say because the API is eight years in age and it never changed significantly.

I know it's hard without an SSCE... but while working to insulate this byzantine behaviour (I've been trying for days now) maybe someone in the list has a clue or is able to interpret the stack trace?

Thanks and have a nice weekend,

Marco.


[1]

Improper use? Potential bug? Your feedback is welcome:
Contact: basex-talk@mailman.uni-konstanz.de
Version: BaseX 9.3 beta
Java: Ubuntu, 13
OS: Linux, amd64
Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
    at org.basex.io.random.TableDiskAccess.fpre(TableDiskAccess.java:507)
    at org.basex.io.random.TableDiskAccess.cursor(TableDiskAccess.java:468)
    at org.basex.io.random.TableDiskAccess.read1(TableDiskAccess.java:156)
    at org.basex.data.Data.kind(Data.java:304)
    at org.basex.query.value.node.DBNode.<init>(DBNode.java:50)
    at org.basex.query.value.seq.DBNodeSeq.get(DBNodeSeq.java:139)
    at org.basex.query.value.seq.DBNodeSeq.get(DBNodeSeq.java:164)
    at org.basex.query.func.db.DbOpen.value(DbOpen.java:19)
    at org.basex.query.func.StandardFunc.optimize(StandardFunc.java:82)
    at org.basex.query.expr.Arr.inline(Arr.java:69)
    at org.basex.query.expr.path.Path.inline(Path.java:962)
    at org.basex.query.expr.gflwor.ForLet.inline(ForLet.java:66)
    at org.basex.query.expr.gflwor.GFLWOR.inline(GFLWOR.java:804)
    at org.basex.query.expr.gflwor.GFLWOR.inlineLets(GFLWOR.java:339)
    at org.basex.query.expr.gflwor.GFLWOR.optimize(GFLWOR.java:106)
    at org.basex.query.expr.gflwor.GFLWOR.inline(GFLWOR.java:785)
    at org.basex.query.expr.Try.inline(Try.java:106)
    at org.basex.query.expr.gflwor.GFLWOR.inline(GFLWOR.java:816)
    at org.basex.query.expr.gflwor.GFLWOR.inlineLets(GFLWOR.java:339)
    at org.basex.query.expr.gflwor.GFLWOR.optimize(GFLWOR.java:106)
    at org.basex.query.func.StaticFunc.inline(StaticFunc.java:294)
    at org.basex.query.func.StaticFuncCall.compile(StaticFuncCall.java:67)
    at org.basex.query.scope.MainModule.comp(MainModule.java:81)
    at org.basex.query.QueryCompiler.compile(QueryCompiler.java:114)
    at org.basex.query.QueryCompiler.compile(QueryCompiler.java:105)
    at org.basex.query.QueryContext.compile(QueryContext.java:312)
    at org.basex.query.QueryContext.iter(QueryContext.java:331)
    at org.basex.http.restxq.RestXqResponse.serialize(RestXqResponse.java:73)
    at org.basex.http.web.WebResponse.create(WebResponse.java:63)
    at org.basex.http.restxq.RestXqServlet.run(RestXqServlet.java:53)
    at org.basex.http.BaseXServlet.service(BaseXServlet.java:65)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1700)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1667)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.server.Server.handle(Server.java:505)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
    at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804)
    at java.base/java.lang.Thread.run(Thread.java:835)