On 1/17/2013 3:32 AM, Uwe Reh wrote:
one entry in my long list of self made problems is:
"Done the commit before the ConcurrentUpdateSolrServer was finished."
Since the ConcurrentUpdateSolrServer is asynchronous, it's very easy to
create a race conditions. Make sure that your program is waiting ()
before it's doing the commit.
if (solrserver instanceof ConcurrentUpdateSolrServer) {
((ConcurrentUpdateSolrServer) solrserver).blockUntilFinished();
}
If you are using the same ConcurrentUpdateSolrServer object for all
update interaction with Solr (including commits) and you still have to
do the blockUntilFinished() in your own code before you issue an
explicit commit, that sounds like a bug, and you should put all the
details in a Jira issue.
The following code is part of the request method in CUSS:
// this happens for commit...
if (req.getDocuments() == null || req.getDocuments().isEmpty()) {
blockUntilFinished();
return server.request(request);
}
This means that if you use the same CUSS object for update interaction
with Solr (including commits), the object will do the waiting for you
when you make an explicit commit() call. If you issue a commit with a
different object (either another instance of CUSS or HttpSolrServer),
then this won't work and you'd have to handle it yourself.
For error handling, I filed SOLR-3284 and provided a patch. It hasn't
been committed, I think mostly because it doesn't give any specific
information about what failed. I have an idea for how to improve the
patch to address committer concerns, but until I have some time to
actually look at it, I won't know if it's viable. When I have a moment,
I'll update the issue with details about my idea.
Thanks,
Shawn
