Github user HeartSaVioR commented on the pull request: https://github.com/apache/storm/pull/977#issuecomment-169146734 I am not an expert on the Solr code, and Solr itself. So below comment may need to have corrections via other contributors / committers. Looking into SolrCommitStrategy and CountBasedCommit I feel the same thing with @revans2. State for the SolrCommitStrategy could be out of sync because it cannot know `internal commit` (not requested via commit()) yet, and looking into javadoc for SolrClient, there's no way to check internal commit. Here's description for rollback, which describes the internal commit. https://lucene.apache.org/solr/5_2_0/solr-solrj/org/apache/solr/client/solrj/SolrClient.html#rollback() > rollback > >Performs a rollback of all non-committed documents pending. Note that this is not a true rollback as in databases. Content you have previously added may have been committed due to autoCommit, buffer full, other client performing a commit etc. Based on internal commit, I see current code has an issue, which could be minor, or maybe major. > There could be some requests which are committed internally via Solr but not acked / failed via Bolt's side. (It will be resolved when SolrUpdateBolt deals with tick tuple.) It means acknowledges of some tuples can be lost though tuples are committed to Solr. If we intend to let requests buffered and in perfect sync with ack / fail, I think it shouldn't request for each execute() but just stores requests and do actual requests / external commit to Solr / ack & fail when commit condition has been made. Or if we don't need to be accurate, I'm fine with the code change.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---