On 13 April 2017 at 11:43, Andy Seaborne <[email protected]> wrote: > > > On 12/04/17 15:43, Chris Dollin wrote: > >> Andy, >> >> If I can work out how to look at logs when >> running tests (viz Log.warn in E_Regex) then >> I can make a test that shows duplicate log lines >> are dropped. >> > > I tested the changes locally - the functionality change is the fact that > FILTER becomes false, not a query error. >
And I checked by execution that the duplicate-removing code was working. > For log messages, as long as there no stacktraces (which I checked), the > volume is much less. Much responsibility is on the deployment to configure > logs. Jena can only do so much. > That's true, if we were still getting too many log messages we could disable E_Regex's log messages. Do you think the changes we've been working >> on will land in 3.3.0? >> > > It would be quicker if you could provide the content in unbroken form. > Yes. Chris (tips/guidelines/protocols?) > Andy > > > >> Chris >> >> >> >> On 12 April 2017 at 13:11, Chris Dollin <[email protected]> >> wrote: >> >> On 12 April 2017 at 11:53, Andy Seaborne <[email protected]> wrote: >>> >>> >>>> >>>> On 11/04/17 15:49, Chris Dollin wrote: >>>> >>>> diff --git >>>>> a/jena-arq/src/main/java/org/apache/jena/sparql/engine/itera >>>>> tor/QueryIterSort.java >>>>> b/jena-arq/src/main/java/org/apache/jena/sparql/engine/itera >>>>> tor/QueryIterSort.java >>>>> index 173da34..04c2655 100644 >>>>> --- >>>>> a/jena-arq/src/main/java/org/apache/jena/sparql/engine/itera >>>>> tor/QueryIterSort.java >>>>> +++ >>>>> b/jena-arq/src/main/java/org/apache/jena/sparql/engine/itera >>>>> tor/QueryIterSort.java >>>>> @@ -92,6 +92,7 @@ public class QueryIterSort extends >>>>> QueryIterPlainWrapper { >>>>> // iterator in a try/finally block, and thus will call >>>>> // close() themselves. >>>>> catch (QueryCancelledException e) { >>>>> + QueryIterSort.this.close(); >>>>> >>>>> >>>> Is this needed? The query is cancelled so QueryIterSort.requestCancel >>>> happens? >>>> >>>> >>> Without it, the test fails, but of course that could be an error >>> in the test. >>> >>> I ran the failing test in the debugger with a breakpoint >>> at the QueryIterSort.close() and println()s at the catch above >>> and in requestCancel -- the former message was printed, the >>> latter not. >>> >>> I went back to the close() and looked at the call stack. All >>> the active methods from the test to the breakpoint were in >>> code that did not obviously catch exceptions. Interestingly >>> at line 113/114 of QueryIteratorBase we see >>> >>> // Handles exceptions >>> boolean r = hasNextBinding() ; >>> >>> which will let any QueryCancelledExceptions on upwards >>> without doing, say, a local cancel or close. >>> >>> In actual use the code at the top of the query execution >>> will itself catch any QueryCancelledException and then >>> close() the entire query, so there's a case for saying the >>> code is overkill and that the test can be dropped. >>> Belt and braces or clutter? >>> >>> Chris >>> >>> (Same applies to QueryIteratorTopN) >>> >>> -- >>> "What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck >>> Affair/ >>> >>> Epimorphics Ltd, http://www.epimorphics.com >>> Registered address: Court Lodge, 105 High Street, Portishead, Bristol >>> BS20 >>> 6PT >>> Epimorphics Ltd. is a limited company registered in England (number >>> 7016688) >>> >>> >> >> >> -- "What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck Affair/ Epimorphics Ltd, http://www.epimorphics.com Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT Epimorphics Ltd. is a limited company registered in England (number 7016688)
