The multi-threaded cases are interesting. I tried to keep the initial implementation super-simple, though arguably it would have been better to skip getLastServerException() and just throw an exception on the client side when a non-zero server side status came back. That would improve thread safety.
One additional issue that comes to mind in option 2 below is that different kinds of clients may have different requirements or expectations when it comes to dealing with errors coming back from the server. In the standard async kind of model with one or more producers (those calling add()) dropping work into a queue, and one or more consumers pulling work from the queue and actually contacting the server, there is little or nothing a consumer can do to alert the original producer of an add that a server-side error occurred. Indeed the consumer is unlikely to be able to do much other than log the error, hope that is enough, and move on. In many cases this is perfectly good enough. But in cases where the original producer actually cares there was an error, it's problematic. I suspect we would just punt and go for the logging solution, but that then drags in log4j or commons logging or whatever else you want to use, all of which have the feature that they are different than what someone who wants to call this very low level client code is using in the rest of their application. Or you could have a callback mechanism, and let people write logging callbacks if they want. I'm not saying we shouldn't do all of this, but merely that we should think about it and have an actual plan. I think you will agree that it's significantly more nuanced than the client code we have so far, which more or less wrote itself. FWIW, in my own work on top of DocumentManagerClient I have just set myself up with one DocumentManagerClient per thread and left it at that. It won't work for all applications, but it happens to work for mine at the moment. -D -----Original Message----- From: Yonik Seeley [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:39 AM To: [email protected] Subject: Re: [jira] Updated: (SOLR-20) A simple Java client with Java APIs for add(), delete(), commit() and optimize(). Thanks for contributing this Darren! Some thoughts about future directions: How would someone go about maximizing throughput by using multiple connections and multiple requests to a Solr server? There are two cases from the client perspective: 1) client has a single thread calling add() 2) client has multiple threads generating documents and calling add() Interface: 1) We could have a pool of DocumentManagerClient objects, and create a *new* interface that accepts updates and dispatches to an available DocumentManagerClient. 2) We could make DocumentManagerClient an interface, and have both a single threaded version and a multi-threaded, multi-connection version (which could simply use multiple single threaded versions). - if we opted for (2), then we should make the single-threaded version MT safe so the client wouldn't have to know that one implementation is and one isn't. Wouldn't be too hard - might need to get rid of getLastServerException(). Implementation: Java5 concurrency classes! -Yonik
