Hi,
Two further questions:
1. What's the cleanest way to get a log containing the actual query strings? AFAIU BaseX doesn't use any logging framework and the BaseXServlet.service has a finally block that prints the request headers (if Prop.debug is enabled) but not the request body. I thought about writing my own Filter for that purpose.
2. I've been trying to update BaseX to the latest snapshot, but the queries generated by my application, that used to work with 7.2.1 and 7.3 don't seem to work now. The body of a POST looks like this (\n means a newline character):
<?xml version="1.0" encoding="UTF-8"?>\n <command xmlns="http://basex.org/rest"><text><![CDATA[\n ADD TO 5d03ebad-dc6a-492c-9527-bd2ce3830080\n <tx id="5d03ebad-dc6a-492c-9527-bd2ce3830080"\n dbId=""\n xmlns="http://our.namespace.com/xmlns/"\n xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"\n xmlns:xs="http://www.w3.org/2001/XMLSchema"\n <commit />\n <skip />\n </tx>\n \n ]]></text></command>
Now the question is what's wrong with this query. I get a 400 Bad Request response with the following error message.
Stopped at line 1, column 43:\n Syntax: ADD (TO [path]) [input]\n Add resource to database.\n \n Adds [input] as [path] to the database.\n
As I said this used to work with 7.3. I tried to diff the StringParser class between 7.3 and the current trunk. It seems to use the InputParser on a single line and not on the entire query. I can't spot anything that would explain this behaviour though.
All kinds of comments welcome.
-- Antoni Myłka Software Engineer
basis06 AG, Birkenweg 61, CH-3013 Bern - Fon +41 31 311 32 22 http://www.basis06.ch - source of smart business
-- Antoni Myłka Software Engineer
basis06 AG, Birkenweg 61, CH-3013 Bern - Fon +41 31 311 32 22 http://www.basis06.ch - source of smart business
----- Ursprüngliche Mail ----- Von: "Antoni Mylka" amy@basis06.ch An: "Christian Grün" christian.gruen@gmail.com Gesendet: Montag, 12. November 2012 15:42:42 Betreff: Re: [basex-talk] Database corruption
Dear Christian,
Thanks for the tip. Will fix the logging settings and retest with the latest snapshot.
Best regards,
-- Antoni Myłka Software Engineer
basis06 AG, Birkenweg 61, CH-3013 Bern - Fon +41 31 311 32 22 http://www.basis06.ch - source of smart business
----- Ursprüngliche Mail ----- Von: "Christian Grün" christian.gruen@gmail.com An: "Antoni Mylka" amy@basis06.ch CC: "basex-talk" basex-talk@mailman.uni-konstanz.de Gesendet: Montag, 12. November 2012 15:34:23 Betreff: Re: [basex-talk] Database corruption
Dear Antoni,
without having read all the elaborate details in your mail (thanks), I would strongly advise to try the latest stable 7.5 snapshot [1], which contains some important improvements reg. concurrent updates. I'm well aware that it feels inconvenient to use beta releases in productive environments, but the current version of 7.5 is very stable, and will be released soon without any major enhancements or legacy issues.
Hope this helps, Christian
[1] http://files.basex.org/releases/latest/ ___________________________
On Mon, Nov 12, 2012 at 3:30 PM, Antoni Mylka amy@basis06.ch wrote:
Hi,
We're developing an application that uses BaseX. In our tests, the application works properly for a couple of hours, makes queries to BaseX adds and removes data. Then suddenly some BaseX request will return the HTTP 500 response. From that point on all queries that make modifications in the database end in an error and the entire system grinds to a screeching halt. One of the experiments ran for four days, then we examined the access log to see that only the first 6 hours were OK, after that all BaseX queries would end in error.
I'm going to investigate and will try to come up with as detailed a description of the issue as possible. For now the things I know are:
- In our experiment, the application would make about 80000 successful queries over a period of 6 hours. Then it would get the first 500 error.
- Afterwards it "seems" that the queries which don't modify anything end with 200, while all the modification queries end with a 500 error. That's to be confirmed.
- BaseX 7.2.1 runs in a war deployed on Tomcat 7.0.32 on a linux system.
- The access logs don't show anything interesting.
- The catalina.out that shows the Tomcat standard output contains hundreds of exceptions of the following kind:
Exception in thread "Thread-78197" java.lang.RuntimeException: Data Access out of bounds [pre:1422612, indexSize:5540, access:5540 > 5539] at org.basex.util.Util.notexpected(Util.java:55) at org.basex.io.random.TableDiskAccess.cursor(TableDiskAccess.java:478) at org.basex.io.random.TableDiskAccess.read5(TableDiskAccess.java:211) at org.basex.data.Data.textOff(Data.java:432) at org.basex.data.DiskData.text(DiskData.java:228) at org.basex.index.value.DiskValues.get(DiskValues.java:295) at org.basex.index.value.UpdatableDiskValues.index(UpdatableDiskValues.java:133) at org.basex.data.DiskData$1.run(DiskData.java:461)
The thread name is different every time and the numbers in square brackets are also different. I don't see any patterns (yet). 6. BaseX is accessed from a single thread in a single application. AFAIK there are no concurrent requests, though that is to be confirmed. 7. The GC log shows that basex stays below 100M of used heap, which is well below the allotted Xmx setting of 2G. 8. We did three experiments and the same effect has been observed in all three, albeit after different periods of time: (59K queries and 4:25 hours, 37K queries and 2:56 hours, 76.8K queries and 6 hours).
Things I intend to do:
- Set up proper logging for BaseX, so that these errors don't end up in catalina.out, but in the proper log file.
- Catch the first offending query, see if there is anything unusual about it. It certainly doesn't differ much from the successful queries. It simply updates the BaseX state to keep it in sync with an external data source. All the update queries are generated by the same template and there have been hundreds of successful ones before the first error occurs.
- Manipulate the log settings, to see if it's possible to get something more meaningful out of them.
- Try newer versions: 7.3 and the current trunk.
I've seen emails similar about "Data Access out of bounds" but they don't seem relevant.
As I said, I'll try to come up with more information, but if the error or the stack trace looks familiar - I'd be grateful for pointers.
Thanks in advance,
-- Antoni Myłka Software Engineer
basis06 AG, Birkenweg 61, CH-3013 Bern - Fon +41 31 311 32 22 http://www.basis06.ch - source of smart business
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk