Re: [basex-talk] "database locked" error on DROP DATABASE
Forward to mailing-list...
Begin forwarded message:
> From: Andreas Weiler <andreas.weiler@uni-konstanz.de>
> Date: 8. Juni 2011 09:54:23 MESZ
> To: Godmar Back <godmar@gmail.com>
> Subject: Re: [basex-talk] "database locked" error on DROP DATABASE
>
> Hi,
> It seems that the database isnt closed correctly in your Session.
> If you try to delete the database then with another Session, it fails, cause the first Session has it still open.
>
> On 08.06.2011, at 01:32, Godmar Back wrote:
>
>> On Tue, Jun 7, 2011 at 6:11 PM, Godmar Back <godmar@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm trying to delete an XML document by invoking 'execute("DROP
>>> DATABASE name")' using the Java binding, but I'm getting:
>>>
>>> Tue Jun 07 18:06:10 EDT 2011: Unexpected exception:
>>> java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
>>> currently locked.
>>> java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
>>> currently locked.
>>> at org.libx.libappdatabase.BaseXSessionSupport.execute(BaseXSessionSupport.java:71)
>>>
>>> There are no concurrent accesses to the database. I'm creating a
>>> document, then I'm successfully running a few XUpdate/XQuery's on it,
>>> then I attempt to delete it as part of a unit test.
>>>
>>
>> FWIW, the problem persists in 6.6.2.
>> When the DROP DB fails, show databases shows:
>>> show databases
>> 1 opened database(s):
>> - libx2_feeds_test (1x)
>>
>> Here's a log: http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-07.log
>>
>> The documentation at
>> http://docs.basex.org/wiki/Commands_6.6.3#DROP_DATABASE says "The
>> command fails if the specified database does not exist or is currently
>> locked, or if the database could not be deleted for some other
>> reason." but nowhere else does it mention what 'locking' the database
>> means.
>>
>> In the XQuery model, I can only see a need for locking internally
>> during an XQuery, which means that leaving a database locked, or
>> failing to delete it because of it (instead of waiting until it is no
>> longer accessed) would be a bug.
>>
>>>
>>> ps:
>>> (I'm not issuing any "OPEN" commands. What does OPEN/CLOSE do, anyway?)
>>
>> Never mind about this question - this doesn't apply.
>> _______________________________________________
>> BaseX-Talk mailing list
>> BaseX-Talk@mailman.uni-konstanz.de
>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>
On Wed, Jun 8, 2011 at 3:55 AM, Andreas Weiler <andreas.weiler@uni-konstanz.de> wrote:
Hi, It seems that the database isnt closed correctly in your Session. If you try to delete the database then with another Session, it fails, cause the first Session has it still open.
So that's a bug in BaseX then? Do you need a reproducible test case? - Godmar
On 08.06.2011, at 01:32, Godmar Back wrote:
On Tue, Jun 7, 2011 at 6:11 PM, Godmar Back <godmar@gmail.com> wrote:
Hi,
I'm trying to delete an XML document by invoking 'execute("DROP
DATABASE name")' using the Java binding, but I'm getting:
Tue Jun 07 18:06:10 EDT 2011: Unexpected exception:
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
at org.libx.libappdatabase.BaseXSessionSupport.execute(BaseXSessionSupport.java:71)
There are no concurrent accesses to the database. I'm creating a
document, then I'm successfully running a few XUpdate/XQuery's on it,
then I attempt to delete it as part of a unit test.
FWIW, the problem persists in 6.6.2.
When the DROP DB fails, show databases shows:
show databases
1 opened database(s):
- libx2_feeds_test (1x)
Here's a log: http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-07.log
The documentation at
http://docs.basex.org/wiki/Commands_6.6.3#DROP_DATABASE says "The
command fails if the specified database does not exist or is currently
locked, or if the database could not be deleted for some other
reason." but nowhere else does it mention what 'locking' the database
means.
In the XQuery model, I can only see a need for locking internally
during an XQuery, which means that leaving a database locked, or
failing to delete it because of it (instead of waiting until it is no
longer accessed) would be a bug.
ps:
(I'm not issuing any "OPEN" commands. What does OPEN/CLOSE do, anyway?)
Never mind about this question - this doesn't apply.
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
I guess it's a bug in your testing scenario, A reproducible test case would be perfect. On 08.06.2011, at 10:00, Godmar Back wrote:
On Wed, Jun 8, 2011 at 3:55 AM, Andreas Weiler <andreas.weiler@uni-konstanz.de> wrote:
Hi, It seems that the database isnt closed correctly in your Session. If you try to delete the database then with another Session, it fails, cause the first Session has it still open.
So that's a bug in BaseX then? Do you need a reproducible test case?
- Godmar
On 08.06.2011, at 01:32, Godmar Back wrote:
On Tue, Jun 7, 2011 at 6:11 PM, Godmar Back <godmar@gmail.com> wrote:
Hi,
I'm trying to delete an XML document by invoking 'execute("DROP
DATABASE name")' using the Java binding, but I'm getting:
Tue Jun 07 18:06:10 EDT 2011: Unexpected exception:
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
at org.libx.libappdatabase.BaseXSessionSupport.execute(BaseXSessionSupport.java:71)
There are no concurrent accesses to the database. I'm creating a
document, then I'm successfully running a few XUpdate/XQuery's on it,
then I attempt to delete it as part of a unit test.
FWIW, the problem persists in 6.6.2.
When the DROP DB fails, show databases shows:
show databases
1 opened database(s):
- libx2_feeds_test (1x)
Here's a log: http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-07.log
The documentation at
http://docs.basex.org/wiki/Commands_6.6.3#DROP_DATABASE says "The
command fails if the specified database does not exist or is currently
locked, or if the database could not be deleted for some other
reason." but nowhere else does it mention what 'locking' the database
means.
In the XQuery model, I can only see a need for locking internally
during an XQuery, which means that leaving a database locked, or
failing to delete it because of it (instead of waiting until it is no
longer accessed) would be a bug.
ps:
(I'm not issuing any "OPEN" commands. What does OPEN/CLOSE do, anyway?)
Never mind about this question - this doesn't apply.
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
On Wed, Jun 8, 2011 at 4:02 AM, Andreas Weiler <andreas.weiler@uni-konstanz.de> wrote:
I guess it's a bug in your testing scenario, A reproducible test case would be perfect.
Before I do that, could you tell me what we're looking for? I'm creating a database via the .create() client call, perform retrieval and update queries on it, then issue a drop db call via the .execute() call. That's all. I do not, for instance, issue an .execute("OPEN ..") call or the like where I could forget to "close" the db, leaving it in a locked state. Whatever is leaving the db in this locked state is happening during the query processing - and that would, in my opinion, indicate a BaseX bug. What say you. - Godmar
On 08.06.2011, at 10:00, Godmar Back wrote:
On Wed, Jun 8, 2011 at 3:55 AM, Andreas Weiler <andreas.weiler@uni-konstanz.de> wrote:
Hi, It seems that the database isnt closed correctly in your Session. If you try to delete the database then with another Session, it fails, cause the first Session has it still open.
So that's a bug in BaseX then? Do you need a reproducible test case?
- Godmar
On 08.06.2011, at 01:32, Godmar Back wrote:
On Tue, Jun 7, 2011 at 6:11 PM, Godmar Back <godmar@gmail.com> wrote:
Hi,
I'm trying to delete an XML document by invoking 'execute("DROP
DATABASE name")' using the Java binding, but I'm getting:
Tue Jun 07 18:06:10 EDT 2011: Unexpected exception:
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
at org.libx.libappdatabase.BaseXSessionSupport.execute(BaseXSessionSupport.java:71)
There are no concurrent accesses to the database. I'm creating a
document, then I'm successfully running a few XUpdate/XQuery's on it,
then I attempt to delete it as part of a unit test.
FWIW, the problem persists in 6.6.2.
When the DROP DB fails, show databases shows:
show databases
1 opened database(s):
- libx2_feeds_test (1x)
Here's a log: http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-07.log
The documentation at
http://docs.basex.org/wiki/Commands_6.6.3#DROP_DATABASE says "The
command fails if the specified database does not exist or is currently
locked, or if the database could not be deleted for some other
reason." but nowhere else does it mention what 'locking' the database
means.
In the XQuery model, I can only see a need for locking internally
during an XQuery, which means that leaving a database locked, or
failing to delete it because of it (instead of waiting until it is no
longer accessed) would be a bug.
ps:
(I'm not issuing any "OPEN" commands. What does OPEN/CLOSE do, anyway?)
Never mind about this question - this doesn't apply.
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Godmar, I tried to reproduce the issue with v. 6.6.2 and typing the commands directly, but couldn't get it. I checked the log which you provide. Would it be possible to provide us with a sample JUnit test with the following operations: 1. CREATE DATABASE feeds 2. CREATE DATABASE users 3. XQUERY let $t := doc("users") return $t; 4. XQUERY let $t := doc("feeds") return $t; 5. DROP DB feeds I chose these commands as simplified version of the operations from your log. Could you check if this simplified sequence of operations fails, and if so, please send us the code. The actual data is of course not needed - you can try this with emtpy databases. If I've written something unclear, I'll try to explain it again :) Thanks for your help. Dimitar Am Mittwoch 08 Juni 2011, 11:41:31 schrieb Godmar Back:
On Wed, Jun 8, 2011 at 4:02 AM, Andreas Weiler
<andreas.weiler@uni-konstanz.de> wrote:
I guess it's a bug in your testing scenario, A reproducible test case would be perfect.
Before I do that, could you tell me what we're looking for?
I'm creating a database via the .create() client call, perform retrieval and update queries on it, then issue a drop db call via the .execute() call. That's all. I do not, for instance, issue an .execute("OPEN ..") call or the like where I could forget to "close" the db, leaving it in a locked state.
Whatever is leaving the db in this locked state is happening during the query processing - and that would, in my opinion, indicate a BaseX bug. What say you.
- Godmar
On 08.06.2011, at 10:00, Godmar Back wrote:
On Wed, Jun 8, 2011 at 3:55 AM, Andreas Weiler
<andreas.weiler@uni-konstanz.de> wrote:
Hi, It seems that the database isnt closed correctly in your Session. If you try to delete the database then with another Session, it fails, cause the first Session has it still open.
So that's a bug in BaseX then? Do you need a reproducible test case?
- Godmar
On 08.06.2011, at 01:32, Godmar Back wrote:
On Tue, Jun 7, 2011 at 6:11 PM, Godmar Back <godmar@gmail.com> wrote:
Hi,
I'm trying to delete an XML document by invoking 'execute("DROP
DATABASE name")' using the Java binding, but I'm getting:
Tue Jun 07 18:06:10 EDT 2011: Unexpected exception:
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
at org.libx.libappdatabase.BaseXSessionSupport.execute(BaseXSessionSupport .java:71)
There are no concurrent accesses to the database. I'm creating a
document, then I'm successfully running a few XUpdate/XQuery's on it,
then I attempt to delete it as part of a unit test.
FWIW, the problem persists in 6.6.2.
When the DROP DB fails, show databases shows:
show databases
1 opened database(s):
- libx2_feeds_test (1x)
Here's a log: http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-07.log
The documentation at
http://docs.basex.org/wiki/Commands_6.6.3#DROP_DATABASE says "The
command fails if the specified database does not exist or is currently
locked, or if the database could not be deleted for some other
reason." but nowhere else does it mention what 'locking' the database
means.
In the XQuery model, I can only see a need for locking internally
during an XQuery, which means that leaving a database locked, or
failing to delete it because of it (instead of waiting until it is no
longer accessed) would be a bug.
ps:
(I'm not issuing any "OPEN" commands. What does OPEN/CLOSE do, anyway?)
Never mind about this question - this doesn't apply.
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
The scenario you describe below doesn't fail for me, it works as expected, at least when using org.basex.BaseXClient. (I had tried that already.) If only it were possible to reconstruct a test case from the log that could be replayed! Also, it only it were possible to issue multiple commands and queries with a single org.basex.BaseXClient invocation in one session (by processing multiple arguments). FWIW, at first I thought the problem may be related to the fact that I'm now using a connection pool, and thus (potentially) multiple sessions, but the problem persists even if using only one session. - Godmar On Wed, Jun 8, 2011 at 6:14 AM, Dimitar Popov <Dimitar.Popov@uni-konstanz.de> wrote:
Hi Godmar,
I tried to reproduce the issue with v. 6.6.2 and typing the commands directly, but couldn't get it. I checked the log which you provide. Would it be possible to provide us with a sample JUnit test with the following operations:
1. CREATE DATABASE feeds 2. CREATE DATABASE users 3. XQUERY let $t := doc("users") return $t; 4. XQUERY let $t := doc("feeds") return $t; 5. DROP DB feeds
I chose these commands as simplified version of the operations from your log. Could you check if this simplified sequence of operations fails, and if so, please send us the code. The actual data is of course not needed - you can try this with emtpy databases.
If I've written something unclear, I'll try to explain it again :)
Thanks for your help.
Dimitar
Am Mittwoch 08 Juni 2011, 11:41:31 schrieb Godmar Back:
On Wed, Jun 8, 2011 at 4:02 AM, Andreas Weiler
<andreas.weiler@uni-konstanz.de> wrote:
I guess it's a bug in your testing scenario, A reproducible test case would be perfect.
Before I do that, could you tell me what we're looking for?
I'm creating a database via the .create() client call, perform retrieval and update queries on it, then issue a drop db call via the .execute() call. That's all. I do not, for instance, issue an .execute("OPEN ..") call or the like where I could forget to "close" the db, leaving it in a locked state.
Whatever is leaving the db in this locked state is happening during the query processing - and that would, in my opinion, indicate a BaseX bug. What say you.
- Godmar
On 08.06.2011, at 10:00, Godmar Back wrote:
On Wed, Jun 8, 2011 at 3:55 AM, Andreas Weiler
<andreas.weiler@uni-konstanz.de> wrote:
Hi, It seems that the database isnt closed correctly in your Session. If you try to delete the database then with another Session, it fails, cause the first Session has it still open.
So that's a bug in BaseX then? Do you need a reproducible test case?
- Godmar
On 08.06.2011, at 01:32, Godmar Back wrote:
On Tue, Jun 7, 2011 at 6:11 PM, Godmar Back <godmar@gmail.com> wrote:
Hi,
I'm trying to delete an XML document by invoking 'execute("DROP
DATABASE name")' using the Java binding, but I'm getting:
Tue Jun 07 18:06:10 EDT 2011: Unexpected exception:
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
at org.libx.libappdatabase.BaseXSessionSupport.execute(BaseXSessionSupport .java:71)
There are no concurrent accesses to the database. I'm creating a
document, then I'm successfully running a few XUpdate/XQuery's on it,
then I attempt to delete it as part of a unit test.
FWIW, the problem persists in 6.6.2.
When the DROP DB fails, show databases shows:
show databases
1 opened database(s):
- libx2_feeds_test (1x)
Here's a log: http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-07.log
The documentation at
http://docs.basex.org/wiki/Commands_6.6.3#DROP_DATABASE says "The
command fails if the specified database does not exist or is currently
locked, or if the database could not be deleted for some other
reason." but nowhere else does it mention what 'locking' the database
means.
In the XQuery model, I can only see a need for locking internally
during an XQuery, which means that leaving a database locked, or
failing to delete it because of it (instead of waiting until it is no
longer accessed) would be a bug.
ps:
(I'm not issuing any "OPEN" commands. What does OPEN/CLOSE do, anyway?)
Never mind about this question - this doesn't apply.
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Could you then remove operations from your test until it doesn't fail, so that we have a minimal set of operations which cause the issue. I know it could be cumbersome, but currently, I don't know where to look at for the problem. I also notice from the log, that one insert statement fails. Does the test fail, if you remove the insert operation (although it uses the users db)? Dimitar Am Mittwoch 08 Juni 2011, 12:27:54 schrieb Godmar Back:
The scenario you describe below doesn't fail for me, it works as expected, at least when using org.basex.BaseXClient. (I had tried that already.)
If only it were possible to reconstruct a test case from the log that could be replayed!
Also, it only it were possible to issue multiple commands and queries with a single org.basex.BaseXClient invocation in one session (by processing multiple arguments).
FWIW, at first I thought the problem may be related to the fact that I'm now using a connection pool, and thus (potentially) multiple sessions, but the problem persists even if using only one session.
- Godmar
On Wed, Jun 8, 2011 at 6:14 AM, Dimitar Popov
<Dimitar.Popov@uni-konstanz.de> wrote:
Hi Godmar,
I tried to reproduce the issue with v. 6.6.2 and typing the commands directly, but couldn't get it. I checked the log which you provide. Would it be possible to provide us with a sample JUnit test with the following operations:
1. CREATE DATABASE feeds 2. CREATE DATABASE users 3. XQUERY let $t := doc("users") return $t; 4. XQUERY let $t := doc("feeds") return $t; 5. DROP DB feeds
I chose these commands as simplified version of the operations from your log. Could you check if this simplified sequence of operations fails, and if so, please send us the code. The actual data is of course not needed - you can try this with emtpy databases.
If I've written something unclear, I'll try to explain it again :)
Thanks for your help.
Dimitar
Am Mittwoch 08 Juni 2011, 11:41:31 schrieb Godmar Back:
On Wed, Jun 8, 2011 at 4:02 AM, Andreas Weiler
<andreas.weiler@uni-konstanz.de> wrote:
I guess it's a bug in your testing scenario, A reproducible test case would be perfect.
Before I do that, could you tell me what we're looking for?
I'm creating a database via the .create() client call, perform retrieval and update queries on it, then issue a drop db call via the .execute() call. That's all. I do not, for instance, issue an .execute("OPEN ..") call or the like where I could forget to "close" the db, leaving it in a locked state.
Whatever is leaving the db in this locked state is happening during the query processing - and that would, in my opinion, indicate a BaseX bug. What say you.
- Godmar
On 08.06.2011, at 10:00, Godmar Back wrote:
On Wed, Jun 8, 2011 at 3:55 AM, Andreas Weiler
<andreas.weiler@uni-konstanz.de> wrote:
Hi, It seems that the database isnt closed correctly in your Session. If you try to delete the database then with another Session, it fails, cause the first Session has it still open.
So that's a bug in BaseX then? Do you need a reproducible test case?
- Godmar
On 08.06.2011, at 01:32, Godmar Back wrote:
On Tue, Jun 7, 2011 at 6:11 PM, Godmar Back <godmar@gmail.com> wrote:
Hi,
I'm trying to delete an XML document by invoking 'execute("DROP
DATABASE name")' using the Java binding, but I'm getting:
Tue Jun 07 18:06:10 EDT 2011: Unexpected exception:
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
java.io.IOException: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is
currently locked.
at org.libx.libappdatabase.BaseXSessionSupport.execute(BaseXSessionSupp ort .java:71)
There are no concurrent accesses to the database. I'm creating a
document, then I'm successfully running a few XUpdate/XQuery's on it,
then I attempt to delete it as part of a unit test.
FWIW, the problem persists in 6.6.2.
When the DROP DB fails, show databases shows:
show databases
1 opened database(s):
- libx2_feeds_test (1x)
Here's a log: http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-07.log
The documentation at
http://docs.basex.org/wiki/Commands_6.6.3#DROP_DATABASE says "The
command fails if the specified database does not exist or is currently
locked, or if the database could not be deleted for some other
reason." but nowhere else does it mention what 'locking' the database
means.
In the XQuery model, I can only see a need for locking internally
during an XQuery, which means that leaving a database locked, or
failing to delete it because of it (instead of waiting until it is no
longer accessed) would be a bug.
ps:
(I'm not issuing any "OPEN" commands. What does OPEN/CLOSE do, anyway?)
Never mind about this question - this doesn't apply.
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
On Wed, Jun 8, 2011 at 6:35 AM, Dimitar Popov <Dimitar.Popov@uni-konstanz.de> wrote:
Could you then remove operations from your test until it doesn't fail, so that we have a minimal set of operations which cause the issue. I know it could be cumbersome, but currently, I don't know where to look at for the problem.
I also notice from the log, that one insert statement fails. Does the test fail, if you remove the insert operation (although it uses the users db)?
That was actually a bug in my test code, fixed - the problem persists even when no insert statement at all fails, see http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-08-2.log - Godmar
Here's a reproducible testcase: http://top.cs.vt.edu/~gback/bx/b662bugs.zip Unzip, and then run './runtest.sh' in the b662bugs directory. I created a log replayer that may come in handy for future uses: http://top.cs.vt.edu/~gback/bx/b662bugs/BaseXLogParser.java It replays the log at http://top.cs.vt.edu/~gback/bx/b662bugs/broken.log which results in the problem. The bin/etc/log directories are unchanged except for changes to the bin/ scripts to allow specifying user.home and the port (for stop server). I had already emailed the bugfix for basexserverstop; the diff for basexserver is appended below. It allows a caller to set VM to pass flags to the JVM. - Godmar -- --- /tmp/x/bin/basexserver 2011-03-21 16:23:06.000000000 -0400 +++ ./bin/basexserver 2011-06-08 03:31:41.000000000 -0400 @@ -7,11 +7,12 @@ BASEX=$PWD/../BaseX.jar # Options for virtual machine -VM=-Xmx512m +VM=${VM:--Xmx512m} # Classpath LIB=$PWD/../lib CP=$BASEX:$LIB/lucene-analyzers-3.0.2.jar:$LIB/tagsoup-1.2.jar:$LIB/snowball.jar # Run code +echo java -cp "$BASEX" $VM org.basex.BaseXServer "$@" java -cp "$BASEX" $VM org.basex.BaseXServer "$@"
Hi Godmar, ok, i got the bug. I will let u know when the bug is fixed. -- Andreas On 08.06.2011, at 21:31, Godmar Back wrote:
Here's a reproducible testcase: http://top.cs.vt.edu/~gback/bx/b662bugs.zip Unzip, and then run './runtest.sh' in the b662bugs directory.
I created a log replayer that may come in handy for future uses: http://top.cs.vt.edu/~gback/bx/b662bugs/BaseXLogParser.java
It replays the log at http://top.cs.vt.edu/~gback/bx/b662bugs/broken.log which results in the problem.
The bin/etc/log directories are unchanged except for changes to the bin/ scripts to allow specifying user.home and the port (for stop server). I had already emailed the bugfix for basexserverstop; the diff for basexserver is appended below. It allows a caller to set VM to pass flags to the JVM.
- Godmar
--
--- /tmp/x/bin/basexserver 2011-03-21 16:23:06.000000000 -0400 +++ ./bin/basexserver 2011-06-08 03:31:41.000000000 -0400 @@ -7,11 +7,12 @@ BASEX=$PWD/../BaseX.jar
# Options for virtual machine -VM=-Xmx512m +VM=${VM:--Xmx512m}
# Classpath LIB=$PWD/../lib CP=$BASEX:$LIB/lucene-analyzers-3.0.2.jar:$LIB/tagsoup-1.2.jar:$LIB/snowball.jar
# Run code +echo java -cp "$BASEX" $VM org.basex.BaseXServer "$@" java -cp "$BASEX" $VM org.basex.BaseXServer "$@"
Hi Godmar, good news, the bug should be fixed in the newest source in github. -- Andreas On 09.06.2011, at 12:10, Andreas Weiler wrote:
Hi Godmar,
ok, i got the bug. I will let u know when the bug is fixed.
-- Andreas
On 08.06.2011, at 21:31, Godmar Back wrote:
Here's a reproducible testcase: http://top.cs.vt.edu/~gback/bx/b662bugs.zip Unzip, and then run './runtest.sh' in the b662bugs directory.
I created a log replayer that may come in handy for future uses: http://top.cs.vt.edu/~gback/bx/b662bugs/BaseXLogParser.java
It replays the log at http://top.cs.vt.edu/~gback/bx/b662bugs/broken.log which results in the problem.
The bin/etc/log directories are unchanged except for changes to the bin/ scripts to allow specifying user.home and the port (for stop server). I had already emailed the bugfix for basexserverstop; the diff for basexserver is appended below. It allows a caller to set VM to pass flags to the JVM.
- Godmar
--
--- /tmp/x/bin/basexserver 2011-03-21 16:23:06.000000000 -0400 +++ ./bin/basexserver 2011-06-08 03:31:41.000000000 -0400 @@ -7,11 +7,12 @@ BASEX=$PWD/../BaseX.jar
# Options for virtual machine -VM=-Xmx512m +VM=${VM:--Xmx512m}
# Classpath LIB=$PWD/../lib CP=$BASEX:$LIB/lucene-analyzers-3.0.2.jar:$LIB/tagsoup-1.2.jar:$LIB/snowball.jar
# Run code +echo java -cp "$BASEX" $VM org.basex.BaseXServer "$@" java -cp "$BASEX" $VM org.basex.BaseXServer "$@"
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Thanks - I meant to say this bug isn't critical for me, but I appreciate your prompt response. I'm happy to confirm the bugfix if you point me at a .jar file. - Godmar On Thu, Jun 9, 2011 at 10:24 AM, Andreas Weiler <andreas.weiler@uni-konstanz.de> wrote:
Hi Godmar,
good news, the bug should be fixed in the newest source in github.
-- Andreas
On 09.06.2011, at 12:10, Andreas Weiler wrote:
Hi Godmar,
ok, i got the bug. I will let u know when the bug is fixed.
-- Andreas
On 08.06.2011, at 21:31, Godmar Back wrote:
Here's a reproducible testcase: http://top.cs.vt.edu/~gback/bx/b662bugs.zip Unzip, and then run './runtest.sh' in the b662bugs directory.
I created a log replayer that may come in handy for future uses: http://top.cs.vt.edu/~gback/bx/b662bugs/BaseXLogParser.java
It replays the log at http://top.cs.vt.edu/~gback/bx/b662bugs/broken.log which results in the problem.
The bin/etc/log directories are unchanged except for changes to the bin/ scripts to allow specifying user.home and the port (for stop server). I had already emailed the bugfix for basexserverstop; the diff for basexserver is appended below. It allows a caller to set VM to pass flags to the JVM.
- Godmar
--
--- /tmp/x/bin/basexserver 2011-03-21 16:23:06.000000000 -0400 +++ ./bin/basexserver 2011-06-08 03:31:41.000000000 -0400 @@ -7,11 +7,12 @@ BASEX=$PWD/../BaseX.jar
# Options for virtual machine -VM=-Xmx512m +VM=${VM:--Xmx512m}
# Classpath LIB=$PWD/../lib CP=$BASEX:$LIB/lucene-analyzers-3.0.2.jar:$LIB/tagsoup-1.2.jar:$LIB/snowball.jar
# Run code +echo java -cp "$BASEX" $VM org.basex.BaseXServer "$@" java -cp "$BASEX" $VM org.basex.BaseXServer "$@"
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Bug fixed in the latest version, see: http://files.basex.org/releases/latest/ Am 09.06.2011 um 16:30 schrieb Godmar Back:
Thanks - I meant to say this bug isn't critical for me, but I appreciate your prompt response.
I'm happy to confirm the bugfix if you point me at a .jar file.
- Godmar
On Thu, Jun 9, 2011 at 10:24 AM, Andreas Weiler <andreas.weiler@uni-konstanz.de> wrote:
Hi Godmar,
good news, the bug should be fixed in the newest source in github.
-- Andreas
On 09.06.2011, at 12:10, Andreas Weiler wrote:
Hi Godmar,
ok, i got the bug. I will let u know when the bug is fixed.
-- Andreas
On 08.06.2011, at 21:31, Godmar Back wrote:
Here's a reproducible testcase: http://top.cs.vt.edu/~gback/bx/b662bugs.zip Unzip, and then run './runtest.sh' in the b662bugs directory.
I created a log replayer that may come in handy for future uses: http://top.cs.vt.edu/~gback/bx/b662bugs/BaseXLogParser.java
It replays the log at http://top.cs.vt.edu/~gback/bx/b662bugs/broken.log which results in the problem.
The bin/etc/log directories are unchanged except for changes to the bin/ scripts to allow specifying user.home and the port (for stop server). I had already emailed the bugfix for basexserverstop; the diff for basexserver is appended below. It allows a caller to set VM to pass flags to the JVM.
- Godmar
--
--- /tmp/x/bin/basexserver 2011-03-21 16:23:06.000000000 -0400 +++ ./bin/basexserver 2011-06-08 03:31:41.000000000 -0400 @@ -7,11 +7,12 @@ BASEX=$PWD/../BaseX.jar
# Options for virtual machine -VM=-Xmx512m +VM=${VM:--Xmx512m}
# Classpath LIB=$PWD/../lib CP=$BASEX:$LIB/lucene-analyzers-3.0.2.jar:$LIB/tagsoup-1.2.jar:$LIB/snowball.jar
# Run code +echo java -cp "$BASEX" $VM org.basex.BaseXServer "$@" java -cp "$BASEX" $VM org.basex.BaseXServer "$@"
_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
On Wed, Jun 8, 2011 at 6:14 AM, Dimitar Popov <Dimitar.Popov@uni-konstanz.de> wrote:
I chose these commands as simplified version of the operations from your log.
PS: take a look at http://top.cs.vt.edu/~gback/bx/b662bugs/2011-06-08-2.log with respect to feed_vsony7_at_vt_dot_edu_vijayfeed The only operations affecting this database are: 06:15:12.281 [127.0.0.1:38339] CREATE DATABASE feed_vsony7_at_vt_dot_edu_vijayfeed [...] 06:15:12.287 [127.0.0.1:38339] OK 46.21 ms 06:15:16.761 [127.0.0.1:38339] DROP DB feed_vsony7_at_vt_dot_edu_vijayfeed 06:15:16.762 [127.0.0.1:38339] Error: Database 'feed_vsony7_at_vt_dot_edu_vijayfeed' is currently locked. 0.74 ms There isn't even a single XQUERY referring to it. - Godmar
participants (3)
-
Andreas Weiler -
Dimitar Popov -
Godmar Back