I would suggest that a DistributedRequestUpdateHandler run single-threaded, doing only one document at a time. If I want more than one, I run it twice or N times with my own program.
Also, this should have a policy object which decides exactly how documents are distributed. There are different techniques for different use cases. Lance On Sat, Jan 29, 2011 at 12:34 PM, Soheb Mahmood <soheb.luc...@gmail.com> wrote: > Hello Yonik, > > On Thu, 2011-01-27 at 08:01 -0500, Yonik Seeley wrote: >> Making it easy for clients I think is key... one should be able to >> update any node in the solr cluster and have solr take care of the >> hard part about updating all relevant shards. This will most likely >> involve an update processor. This approach allows all existing update >> methods (including things like CSV file upload) to still work >> correctly. >> >> Also post.jar is really just for testing... a command-line replacement >> for "curl" for those who may not have it. It's not really a >> recommended way for updating Solr servers in production. > > OK, I've abandoned the post.jar tool idea in favour of a > DistributedUpdateRequestProcessor class (I've been looking into other > classes like UpdateRequestProcessor, RunUpdateRequestProcessor, > SignatureUpdateProcessorFactory, and SolrQueryRequest to see how they > are used/what data they store - hence why I've taken some time to > respond). > > My big question now is that is it necessary to have a Factory class for > DistributedUpdateRequestProcessor? I've seen this lots of times, as in > RunUpdateProcessorFactory (where the factory class was only a few lines > of code) to SignatureUpdateProcessorFactory? At first I was thinking it > would be a good design idea to include it in (in a generic sense), but > then I thought harder and I thought that the > DistributedUpdateRequestHander would only be running once, taking in all > the requests, so it seems sort of pointless to write one in. > > That is my "burning" question for now. I have got a few more questions, > but I'm sure that when I look further into the code, I'll either have > more or all of my questions are answered. > > Many thanks! > > Soheb Mahmood > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Lance Norskog goks...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
