[
https://issues.apache.org/jira/browse/BLUR-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556909#comment-13556909
]
Aaron McCurry commented on BLUR-46:
-----------------------------------
1. Yes on the data structure, but I think that we will need Long types as the
key instead of Integer types, since the QueryArgs had the id as long. Also I
think that we will only need to store the QueryArgs object, not a parsed object.
2. Yes. I think that we may need a status object that we create and return out
of the add method so that we can update the status of the query as it executes.
The basic query status enum can be found in QueryState, we can add more as we
need. However if we return a status object back from the add method call we
can set the status of the query as completed once the result is returned or an
exception is thrown. Take a look at the search method in the BlurServer class,
there is a massive try/catch block. We should add a finally block and set the
status to completed there (if the status is not interrupted).
3. I'm thinking that we need to call for the status object off the session info
object just after the search method is in BlurServer. You will see that the
SessionInfo object is looked up based on the session that is passed in, we can
just call the necessary method off that object. I think that with these couple
additions we can then track currently running queries.
4. I have created a sub task for the tracking of currently running queries. I
am going to create another sub-task for the cancelation part of the task. The
biggest reason for this is that the tracking of running queries and their
status is going to be blur native code, and the cancelation code is really
Lucene code and depending on how the internals of Lucene 4.x may be very
complex. So they should be 2 different tasks.
Some other thoughts the status object is going to need to probably carry with
it the QueryArgs and an AtomicBoolean for whether the query should be running
or not. The AB will be used in the cancelation process.
Aaron
> Implement cancelQuery
> ---------------------
>
> Key: BLUR-46
> URL: https://issues.apache.org/jira/browse/BLUR-46
> Project: Apache Blur
> Issue Type: Improvement
> Affects Versions: 0.2.0
> Environment: 0.2-dev-removing-old-thrift branch
> Reporter: Aaron McCurry
> Fix For: 0.2.0
>
>
> Implement the ability to cancel any currently running queries via
> cancelQuery. The thrift api will likely evolve during implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
