: 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.
yeah .. if i remember ight,you have a SOlrClientException right/ .. you could also have a SolrServerException to distinguish the two cases. : 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 1) given enough information about hte nature of hte error, the producer could choose to reattempt the operation. 2) i've been told that this is the use case the "Future" interface in Java1.5 attempts to solve, but i've never had a chance (or a serious need) to play with it. : 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. I think that may be a pretty legitimate approach to take provided your goal is for DocumentManagerClient to be a "low level" API (whatever that may mean) ... "high level" APIs can worry about consuming/queing actions and managing pools of DocumentManagerClient objects. (or something like that) The one thing that you may want to incorporate at the low level is persistent HTTP connections when clients ask DocumentManagerClient to add multiple documents at the same time. : -----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 : -Hoss
