Hi,
Not really a problem for me but I noticed this in the GUI:
let $c := client:connect('localhost', 1984, 'admin', 'admin') let $d:= client:query($c, "2+ 2") return client:info($c)
Improper use? Potential bug? Your feedback is welcome: Contact: basex-talk@mailman.uni-konstanz.de Version: BaseX 8.2.3 Java: Oracle Corporation, 1.8.0_45 OS: Windows 7, amd64 Stack Trace: java.lang.NullPointerException at org.basex.query.func.client.ClientInfo.item(ClientInfo.java:17) at org.basex.query.expr.ParseExpr.iter(ParseExpr.java:43) at org.basex.query.expr.gflwor.GFLWOR$1.next(GFLWOR.java:99) at org.basex.query.MainModule$1.next(MainModule.java:114) at org.basex.query.QueryContext.cache(QueryContext.java:660) at org.basex.query.QueryProcessor.cache(QueryProcessor.java:103) at org.basex.core.cmd.AQuery.query(AQuery.java:83) at org.basex.core.cmd.XQuery.run(XQuery.java:22) at org.basex.core.Command.run(Command.java:398) at org.basex.core.Command.execute(Command.java:100) at org.basex.gui.GUI.exec(GUI.java:472) at org.basex.gui.GUI.access$400(GUI.java:43) at org.basex.gui.GUI$7.run(GUI.java:412)
And slightly related..
In the DBA query window let $c := client:connect('localhost', 1984, 'admin', 'admin') return client:query($c, "2+ 2")
will block the basex server for all http users and basexclient (s). Sad, but I can see why this might be :-), Another way to achieve this is on the dba login page enter "localhost:1984" as a *remote *host.
but is there any way to programmatically detect this situation has occurred or cancel these queries without restarting the server?
/Andy
Hi Andy,
Improper use? Potential bug? Your feedback is welcome:
Fixed, thanks. As client:info will only return information on executed commands, it will now return an empty string instead. I thought if query info could be returned instead, but this would also effect the client bindings, so I dropped the idea again..
let $c := client:connect('localhost', 1984, 'admin', 'admin') return client:query($c, "2+ 2")
will block the basex server for all http users and basexclient (s).
Good observation.. We should ensure that a user can never create a deadlock situation. But the given cases are tricky indeed, as there is currently no way to detect patterns of this kind. I have added a new GitHub issue [1], and I'll wait for an inspiration how to tackle this.
Christian
In the DBA query window let $c := client:connect('localhost', 1984, 'admin', 'admin') return client:query($c, "2+ 2")
will block the basex server for all http users and basexclient (s). Sad, but I can see why this might be :-), Another way to achieve this is on the dba login page enter "localhost:1984" as a remote host.
Interestingly, I just ran your examples, and I didn't manage to get the server blocked. This is what I was doing:
* downloading the latest ZIP snapshot * starting basexhttp * visiting http://localhost:8984/dba * entering localhost:1984 as remote host, or * running your query in the DBA query window * running a query via basexclient
What did you do differently? Christian
MIXUPDATES=true
Which I do like, but I am wondering if the issues outweigh the advantages.
/Andy
On 12 August 2015 at 16:24, Christian Grün christian.gruen@gmail.com wrote:
In the DBA query window let $c := client:connect('localhost', 1984, 'admin', 'admin') return client:query($c, "2+ 2")
will block the basex server for all http users and basexclient (s). Sad, but I can see why this might be :-), Another way to achieve this is on the dba login page enter
"localhost:1984"
as a remote host.
Interestingly, I just ran your examples, and I didn't manage to get the server blocked. This is what I was doing:
- downloading the latest ZIP snapshot
- starting basexhttp
- visiting http://localhost:8984/dba
- entering localhost:1984 as remote host, or
- running your query in the DBA query window
- running a query via basexclient
What did you do differently? Christian
basex-talk@mailman.uni-konstanz.de
-
Andy Bunce -
Christian Grün