The SolrJ client is designed with the ResponseParser as an abstract class (which is good). But I have no means to plugin my custom ResponseParser class. Add a setter method . setResponseParser(ResponseParser parser) and have a lazy initialization of Responseparser . if(_processor == null) _processor = new XMLResponseParser();
in the beginning of the request method. While it is a good idea to use commons HttpClient It is a huge ball and chain to put those extra jars (comons-http-client, commons-logging, commons-codec ) in my simple client application . It is too much to ask by a client API which is just supposed to parse an xml response. If httpclient is not available we must be able to fall back to new URL().openConnection(); --Noble On Fri, Feb 22, 2008 at 9:46 AM, Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]> wrote: > For the case where we use Solrj (we control both ends) It is best to resort > to a custom binary format. It works fastest and with least cost /bandwidth . > We can use a custom object serialization/deserialization mechanism (java > standard serialization is verbose ) which is lightweight . > > I can create a patch which can be used for the same if you think it is useful. > > --Noble > > > > > > > > On Fri, Feb 22, 2008 at 12:20 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > > > XML can be a problem when it is really lengthy (lots of results, large > > results) such that a binary format could be useful in certain cases > > where we control both ends of the pipe (i.e. SolrJ.) I've seen apps > > that deal with really large files wrapped in XML where the XML parsing > > takes a significant amount of time as compared to a more compact > > binary format. > > > > I think it at least warrants profiling/testing. > > > > -Grant > > > > On Feb 21, 2008, at 12:07 PM, Noble Paul നോബിള് > > > > > > > > नोब्ळ् wrote: > > > > > hi, > > > The format over the wire is not of great significance because it gets > > > unmarshalled into the corresponding language object as soon as it > > > comes out > > > of the wire. I would say XML/JSON should meet 99% of the requirements > > > because all the platforms come with an unmarshaller for both of these. > > > > > > But,If it can offer good performance improvement it is worth trying. > > > --Noble > > > > > > On Thu, Feb 21, 2008 at 3:41 AM, alexander lind <[EMAIL PROTECTED]> > > > wrote: > > > > > >> On Feb 20, 2008, at 9:31 AM, Doug Steigerwald wrote: > > >> > > >>> A few months back I wrote a YAML update request handler to see if we > > >>> could post documents faster than with XMl. We did see some small > > >>> speed improvements (didn't write down the numbers), but the hacked > > >>> together code was probably making it slower as well. Not sure if > > >>> there are faster YAML libraries out there either. > > >>> > > >>> We're not actually using it, since it was just a small proof of > > >>> concept type of project, but is this anything people might be > > >>> interested in? > > >>> > > >> > > >> Out of simple preference I would love to see a YAML request handler > > >> just because I like the YAML format. If its also faster than XML, > > >> then > > >> all the better. > > >> > > >> Cheers > > >> Alec > > >> > > > > > > > > > > > > -- > > > --Noble Paul > > > > -------------------------- > > Grant Ingersoll > > http://www.lucenebootcamp.com > > Next Training: April 7, 2008 at ApacheCon Europe in Amsterdam > > > > Lucene Helpful Hints: > > http://wiki.apache.org/lucene-java/BasicsOfPerformance > > http://wiki.apache.org/lucene-java/LuceneFAQ > > > > > > > > > > > > > > > > -- > --Noble Paul -- --Noble Paul
