My current solution is to use the ping() function -- which doesn't run in a thread -- to test the connection before trying to send the data to the Solr index. It isn't elegant, but it works.
If anyone has a better idea, I'd like to hear it. -- Chris On Thu, Dec 30, 2010 at 11:10 AM, Christopher Gross <cogr...@gmail.com>wrote: > Hi all. > > I have designed a synchronizer that goes out to various databases, > extracts some data, does some processing, and then uses the > StreamingUpdateSolrServer to send the records to a Solr index. When > everything is up, it works just fine. > > Now I'm trying to account for problems, like if the Solr index is down > for some reason. I'm trying to get it so that I can keep track of items > that were missed for synchronization, so that they can get replayed when the > index comes back up. Before I was using the StreamingUpdateSolrServer, I'd > get a message back immediately that there was a problem. Now that it > streams, the error comes outside of the thread that I'm using to run the > updates, so I can't catch the exception, so my thread isn't aware of the > error, and just chugs along. > > Has anyone run into this problem? Is there anything built into the > server so that I can know which records it was unable to send, and then pull > them out in order to try running them again later? Any insight that anyone > has would be greatly appreciated. > > Thanks! > > -- Christopher Gross >
