[
https://issues.apache.org/jira/browse/SOLR-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13648606#comment-13648606
]
Jack Krupansky commented on SOLR-4783:
--------------------------------------
As the wiki notes, "This is an expert-level API that should only be used if the
application is taking complete responsibility for update concurrency,
replication, and sharding." So, any difficulties with rollback are not relevant
for non-experts, people who have multiple, un-coordinated clients, using
auto-commit or commit within, etc. So... what's the problem with keeping it for
the experts who have configured their application so that they do have the
level of control needed?
Still unanswered: is there a specific bug/design problem with SolrCloud? I
mean, if auto-commit/commitWithin are not enabled and "the" client does
explicit commits, is there still some bug?
And maybe rollback should fail if auto-commit or commitWithin are configured or
the latter is explicitly used on update requests or in update documents.
> Rollback is not working in SolrCloud
> ------------------------------------
>
> Key: SOLR-4783
> URL: https://issues.apache.org/jira/browse/SOLR-4783
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.2.1
> Environment: AWS Instance
> Linux OS
> Reporter: Shekar R
> Labels: features
> Fix For: 4.2.1
>
>
> I have 4 Solr 4.2.1 and 3 zookeeper cluster with frontend haproxy to Solr
> instances.
> 1. Add a doc (without inline commit and autocommit is disabled in
> solrconfig.xml)
> 2. Issue rollback.
> 3. Again add another doc.
> 4. Issue commit.
> Both docs will be committed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
