See https://issues.apache.org/jira/browse/SOLR-476
On Feb 22, 2008, at 5:17 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
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
--------------------------
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
