[
https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041047#comment-17041047
]
Jan Høydahl commented on SOLR-599:
----------------------------------
Should be enough with optimistic, yes. Gus' concern I guess was that if things
change in ZK before a request, then something could go wrong? I assume that the
worst that can happen is that SolrJ sends updates to a dead node (in which case
it will retry to another node) or to a non-leader (in which case a new state
will be cached for the next request?). What do you mean could go wrong with
aliases Gus?
> Lightweight SolrJ client
> ------------------------
>
> Key: SOLR-599
> URL: https://issues.apache.org/jira/browse/SOLR-599
> Project: Solr
> Issue Type: Improvement
> Components: clients - java, SolrJ
> Reporter: Shalin Shekhar Mangar
> Priority: Minor
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch,
> SOLR-599.patch
>
>
> SolrJ provides a SolrServer implementation backed by commons-httpclient which
> introduces many dependency jars (commons-codec, commons-io and
> commons-logging). Apart from that SolrJ also uses StAX API for XML parsing
> which introduces dependencies like stax-api, stax and stax-utils.
> This enhancement will add a SolrServer implementation backed by
> java.net.HttpUrlConnection and will use BinaryResponseParser as the default
> response parser. Using this basic implementation out of the box would require
> no dependencies on either commons-httpclient or StAX. The only dependency
> would be on solr-commons making this a very lightweight and distribution
> friendly Java client for Solr.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
