[
https://issues.apache.org/jira/browse/JENA-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384248#comment-15384248
]
ASF GitHub Bot commented on JENA-1212:
--------------------------------------
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
The most cost a `volatile` usually incurs is a few times the time to
retrieve the value (and I shouldn't think that happens normally on x86 archs,
see [here](http://gee.cs.oswego.edu/dl/jmm/cookbook.html)). You are balancing
that that against an integer increment, a modulo operation, and an integer
comparison. Some of that may get optimized, but then the cost of the `volatile`
may be much lower. Even more, to do this with precision, you'd have to make
`count` into a `volatile`, too, which makes the whole thing work out again the
extra machinery. Otherwise, threads might be using cached values of `count`.
> allow ORDER BY sort to be cancelled
> -----------------------------------
>
> Key: JENA-1212
> URL: https://issues.apache.org/jira/browse/JENA-1212
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Reporter: christopher james dollin
> Priority: Minor
> Fix For: Jena 3.1.1
>
>
> When a query with an ORDER BY is cancelled, the component
> Arrays.sort() that sorts the chunk(s) of the result
> bindings runs to completion before the cancel finishes.
> [See QueryIterSort and SortedDataBag.]
> For a large result set, this results in a long wait
> before the cancelled request finally finishes. This
> can be inconvenient.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
