Unsolved
This post is more than 5 years old
2 Posts
0
1965
March 28th, 2011 10:00
FP_query returns before returning all objects.
We offer our customers a tool to rebuild our indexing information for files stored on a Centera device for the case where they have lost the clip id of their documents. We use the FPPoolQuery_FetchResult() command in a loop, after initializing StartTime to zero, and EndTime to -1. We have our own 'SelectField' , DOC_ID, that we compare to the users input range,
We get this with the FPQueryResult_GetField() call, after FPQueryResult_GetResultCode() returns FP_QUERY_RESULT_CODE_COMPLETE or FP_QUERY_RESULT_CODE_OK.
If FPQueryResult_GetResultCode() returns FP_QUERY_RESULT_CODE_PROGRESS or FP_QUERY_RESULT_CODE_INCOMPLETE, we just delay for the FP_OPTION_RETRYSLEEP value.
Our issue is that we get FP_QUERY_RESULT_CODE_END, before we get all the documents that are on the device returned to us.
We are able to read these objects successfully using the clip_id, however, we need to be able to get them with the query command..
We actually have a bad node, and our query will fail, if we reset the start time to the last returned,
FPQueryExpression_SetStartTime (expRef, nt_stamp); If we do this reset for status of FP_QUERY_RESULT_CODE_INCOMPLETE.
/* nt_stamp is the value from last FPQueryResult_GetTimeStamp() after previous query stat FP_QUERY_REULT_CODE_OK */
gstuartemc
2 Intern
•
417 Posts
0
March 29th, 2011 05:00
If you have a "bad" node (i.e. one which is unable to respond properly to internal query iteration) then you will never get a complete query result. The solution is to get the issues on the node fixed. Resuming a query after receiving such an error will only complete properly if the node issues are addressed and Query is able to iterate across clips within the date range in question on the "bad" node.
I would also suggest that while this is a useful Disaster Recovery approach, customers "losing" the Content Addresses of objects that they store should also be addressed in other procedural / operational ways.
cballantine
2 Posts
0
March 30th, 2011 14:00
Hi Graham,
The faulty node does not really figure in the problem, in this case, since documents I am querying are not on that node.
To get around it, I displayed the FPQueryResult_GetTimestamp() time for the first document found in my query range.
Then I used that value for the starttime of the query, and I get most of my documents quite quickly since the documents were written to the device as a single batch, but I am aways missing three to six documents from the end of my range, using the query. I use an endtime of -1.