Solr
  1. Solr
  2. SOLR-4923

Replica index is one version behind sending the commit to non-leader instance

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.2
    • Fix Version/s: 4.4, 6.0
    • Component/s: replication (java)
    • Labels:
      None
    • Environment:

      Solr 4.2.1
      OS X 10.8.3

      Description

      I was actually trying to debug an issue we experiencing in production where the replica version is ahead from the leader when I noticed this problem.

      For my tests I'm running two Solr instances with distributed updates (SolrCloud). ZK runs embedded within one of the instances.

      The test consists on updating one field in single document. If I send an update to the leader the index is replicated correctly. However, if I run the update against the follower replica only the leader is updated correctly. I can reproduce this using both hard and soft commits. Here is the command I'm running:

      curl "http://localhost:8999/solr/rulePreview/update?commit=true&softCommit=true" -H "Content-Type: text/xml" --data-binary '<add>...</add>

      If I execute a second commit against the follower the leader will have the most recent update and the follower will be update from the first commit.

      For example, my field is named category and initially it contains the value cat_1. If update the value to cat_2 the leader sees the change but the follower doesn't. If a second commit updates the field to cat_3 the leader will return cat_3 but the follower return cat_2.

      Reloading the core in the follower fixes the problem.

      The logs seem to confirm the follower gets the latest index version. However, the version in the logs doesn't matches the on in the Core Admin UI nor Luke. Here are some logs from the leader:

      Jun 12, 2013 10:34:19 PM org.apache.solr.update.processor.LogUpdateProcessor finish
      INFO: [rulePreview_en] webapp=/solr path=/update params=

      {distrib.from=http://192.168.1.106:8998/solr/rulePreview_en/&update.distrib=TOLEADER&wt=javabin&version=2}

      {add=[importedRedirect1 (1437700518392627200)]} 0 11
      Jun 12, 2013 10:34:19 PM org.apache.solr.update.DirectUpdateHandler2 commit
      INFO: start commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
      Jun 12, 2013 10:34:19 PM org.apache.solr.search.SolrIndexSearcher <init>
      INFO: Opening Searcher@47e4e06c main
      Jun 12, 2013 10:34:19 PM org.apache.solr.update.DirectUpdateHandler2 commit
      INFO: end_commit_flush
      Jun 12, 2013 10:34:19 PM org.apache.solr.core.QuerySenderListener newSearcher
      INFO: QuerySenderListener sending requests to Searcher@47e4e06c main{StandardDirectoryReader(segments_3g:467:nrt _2a(4.2.1):C134/1 _3c(4.2.1):C1)}
      Jun 12, 2013 10:34:19 PM org.apache.solr.core.QuerySenderListener newSearcher
      INFO: QuerySenderListener done.
      Jun 12, 2013 10:34:19 PM org.apache.solr.core.SolrCore registerSearcher
      INFO: [rulePreview_en] Registered new searcher Searcher@47e4e06c main{StandardDirectoryReader(segments_3g:467:nrt _2a(4.2.1):C134/1 _3c(4.2.1):C1)}
      Jun 12, 2013 10:34:19 PM org.apache.solr.update.processor.LogUpdateProcessor finish
      INFO: [rulePreview_en] webapp=/solr path=/update params={waitSearcher=true&commit=true&wt=javabin&expungeDeletes=false&commit_end_point=true&version=2&softCommit=true} {commit=} 0 12

      And the logs from the follower:

      Jun 12, 2013 10:34:19 PM org.apache.solr.update.DirectUpdateHandler2 commit
      INFO: start commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
      Jun 12, 2013 10:34:19 PM org.apache.solr.search.SolrIndexSearcher <init>
      INFO: Opening Searcher@1e23cfc main
      Jun 12, 2013 10:34:19 PM org.apache.solr.update.DirectUpdateHandler2 commit
      INFO: end_commit_flush
      Jun 12, 2013 10:34:19 PM org.apache.solr.core.QuerySenderListener newSearcher
      INFO: QuerySenderListener sending requests to Searcher@1e23cfc main{StandardDirectoryReader(segments_3i:463:nrt _2a(4.2.1):C134/1 _3b(4.2.1):C1)}
      Jun 12, 2013 10:34:19 PM org.apache.solr.core.QuerySenderListener newSearcher
      INFO: QuerySenderListener done.
      Jun 12, 2013 10:34:19 PM org.apache.solr.core.SolrCore registerSearcher
      INFO: [rulePreview_en] Registered new searcher Searcher@1e23cfc main{StandardDirectoryReader(segments_3i:463:nrt _2a(4.2.1):C134/1 _3b(4.2.1):C1)}
      Jun 12, 2013 10:34:19 PM org.apache.solr.update.processor.LogUpdateProcessor finish
      INFO: [rulePreview_en] webapp=/solr path=/update params={distrib.from=http://192.168.1.106:8999/solr/rulePreview_en/&update.distrib=FROMLEADER&wt=javabin&version=2} {add=[importedRedirect1 (1437700518392627200)]}

      0 4
      Jun 12, 2013 10:34:19 PM org.apache.solr.update.SolrCmdDistributor distribCommit
      INFO: Distrib commit to:[StdNode: http://192.168.1.106:8999/solr/rulePreview_en/] params:commit_end_point=true&commit=true&softCommit=true&waitSearcher=true&expungeDeletes=false
      Jun 12, 2013 10:34:19 PM org.apache.solr.update.processor.LogUpdateProcessor finish
      INFO: [rulePreview_en] webapp=/solr path=/update params=

      {softCommit=true}

      {add=[importedRedirect1],commit=}

      0 41

      1. SOLR-4923_hoss_test.patch
        8 kB
        Hoss Man
      2. SOLR-4923.patch
        7 kB
        Mark Miller
      3. SOLR-4923-test-1.patch
        4 kB
        Mark Miller

        Activity

        Hide
        Hoss Man added a comment -

        Hmmm...

        I can't explain it – but i can reproduce this fairly trivially on trunk using the example configs...

        • Spin up two ports using numShards=1...
        $ java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=myconf -DzkRun -DnumShards=1 -jar start.jar 
        $ java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
        
        • use UI to confirm that 8983 is the leader and 7574 is it's replica
        • send a doc to the 7574 replica and observe the results of querying against the two distinct replicas...
        $ curl "http://localhost:8983/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/update?commit=true&wt=json&omitHeader=true" -H 'Content-Type: text/xml' --data-binary '<add><doc><field name="id">HOSS</field><field name="cat_s">1</field></doc></add>'
        {}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:8983/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":1,"start":0,"docs":[{"id":"HOSS","cat_s":"1","_version_":1437767149083951104}]}}
        
        • wait a bit and retry in case there is some delay in replication...
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":0,"start":0,"docs":[]}}
        
        • send a new version of the doc to the 7574 replica and observe the results of querying against the two distinct replicas...
        $ curl "http://localhost:7574/solr/collection1/update?commit=true&wt=json&omitHeader=true" -H 'Content-Type: text/xml' --data-binary '<add><doc><field name="id">HOSS</field><field name="cat_s">2</field></doc></add>'
        {}
        $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":1,"start":0,"docs":[{"id":"HOSS","cat_s":"1","_version_":1437767149083951104}]}}
        $ curl "http://localhost:8983/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true"
        {"response":{"numFound":1,"start":0,"docs":[{"id":"HOSS","cat_s":"2","_version_":1437767405646381056}]}}
        

        I'll see if i can work up a JUnit test.

        Show
        Hoss Man added a comment - Hmmm... I can't explain it – but i can reproduce this fairly trivially on trunk using the example configs... Spin up two ports using numShards=1... $ java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=myconf -DzkRun -DnumShards=1 -jar start.jar $ java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar use UI to confirm that 8983 is the leader and 7574 is it's replica send a doc to the 7574 replica and observe the results of querying against the two distinct replicas... $ curl "http://localhost:8983/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/update?commit=true&wt=json&omitHeader=true" -H 'Content-Type: text/xml' --data-binary '<add><doc><field name="id">HOSS</field><field name="cat_s">1</field></doc></add>' {} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:8983/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":1,"start":0,"docs":[{"id":"HOSS","cat_s":"1","_version_":1437767149083951104}]}} wait a bit and retry in case there is some delay in replication... $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":0,"start":0,"docs":[]}} send a new version of the doc to the 7574 replica and observe the results of querying against the two distinct replicas... $ curl "http://localhost:7574/solr/collection1/update?commit=true&wt=json&omitHeader=true" -H 'Content-Type: text/xml' --data-binary '<add><doc><field name="id">HOSS</field><field name="cat_s">2</field></doc></add>' {} $ curl "http://localhost:7574/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":1,"start":0,"docs":[{"id":"HOSS","cat_s":"1","_version_":1437767149083951104}]}} $ curl "http://localhost:8983/solr/collection1/select?q=id:HOSS&wt=json&omitHeader=true" {"response":{"numFound":1,"start":0,"docs":[{"id":"HOSS","cat_s":"2","_version_":1437767405646381056}]}} I'll see if i can work up a JUnit test.
        Hide
        Hoss Man added a comment -

        Sample logs from the replica during my manual testing...

        replica @ moment of update
        580025 [qtp541763983-15] INFO  org.apache.solr.update.UpdateHandler  – start commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
        580142 [qtp541763983-15] INFO  org.apache.solr.core.SolrCore  – SolrDeletionPolicy.onCommit: commits: num=2
        	commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_b,generation=11}
        	commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_c,generation=12}
        580143 [qtp541763983-15] INFO  org.apache.solr.core.SolrCore  – newest commit generation = 12
        580144 [qtp541763983-15] INFO  org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@60d2cd99 main
        580145 [qtp541763983-15] INFO  org.apache.solr.update.UpdateHandler  – end_commit_flush
        580145 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – QuerySenderListener sending requests to Searcher@60d2cd99 main{StandardDirectoryReader(segments_b:15:nrt _3(5.0):c1)}
        580146 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – QuerySenderListener done.
        580151 [searcherExecutor-5-thread-1] INFO  org.apache.solr.core.SolrCore  – [collection1] Registered new searcher Searcher@60d2cd99 main{StandardDirectoryReader(segments_b:15:nrt _3(5.0):c1)}
        580170 [qtp541763983-18] INFO  org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] webapp=/solr path=/update params={distrib.from=http://127.0.1.1:8983/solr/collection1/&update.distrib=FROMLEADER&wt=javabin&version=2} {add=[HOSS (1437769792183336960)]} 0 4
        580173 [qtp541763983-15] INFO  org.apache.solr.update.SolrCmdDistributor  – Distrib commit to:[StdNode: http://127.0.1.1:8983/solr/collection1/] params:commit_end_point=true&commit=true&softCommit=false&waitSearcher=true&expungeDeletes=false
        580426 [qtp541763983-15] INFO  org.apache.solr.update.processor.LogUpdateProcessor  – [collection1] webapp=/solr path=/update params={omitHeader=true&commit=true&wt=json} {add=[HOSS],commit=} 0 402
        
        replica a few seconds later
        595170 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  – start commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
        595355 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – SolrDeletionPolicy.onCommit: commits: num=2
        	commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_c,generation=12}
        	commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_d,generation=13}
        595355 [commitScheduler-7-thread-1] INFO  org.apache.solr.core.SolrCore  – newest commit generation = 13
        595359 [commitScheduler-7-thread-1] INFO  org.apache.solr.search.SolrIndexSearcher  – Opening Searcher@140ffc1 realtime
        595360 [commitScheduler-7-thread-1] INFO  org.apache.solr.update.UpdateHandler  – end_commit_flush
        

        You can see that the "explicit" commit (with "openSearcher=true") seems to be happening first, then the replica recieves the distrib update back from the leader, then a "Distrib commit to: <leader>" (that i'm not familiar with) is logged by the replica. A few seconds later, the autoCommit on the replica kicks in, but this uses openSearcher=false since that's what's in solrconfig.xml

        Show
        Hoss Man added a comment - Sample logs from the replica during my manual testing... replica @ moment of update 580025 [qtp541763983-15] INFO org.apache.solr.update.UpdateHandler – start commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false} 580142 [qtp541763983-15] INFO org.apache.solr.core.SolrCore – SolrDeletionPolicy.onCommit: commits: num=2 commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_b,generation=11} commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_c,generation=12} 580143 [qtp541763983-15] INFO org.apache.solr.core.SolrCore – newest commit generation = 12 580144 [qtp541763983-15] INFO org.apache.solr.search.SolrIndexSearcher – Opening Searcher@60d2cd99 main 580145 [qtp541763983-15] INFO org.apache.solr.update.UpdateHandler – end_commit_flush 580145 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener sending requests to Searcher@60d2cd99 main{StandardDirectoryReader(segments_b:15:nrt _3(5.0):c1)} 580146 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener done. 580151 [searcherExecutor-5-thread-1] INFO org.apache.solr.core.SolrCore – [collection1] Registered new searcher Searcher@60d2cd99 main{StandardDirectoryReader(segments_b:15:nrt _3(5.0):c1)} 580170 [qtp541763983-18] INFO org.apache.solr.update.processor.LogUpdateProcessor – [collection1] webapp=/solr path=/update params={distrib.from=http://127.0.1.1:8983/solr/collection1/&update.distrib=FROMLEADER&wt=javabin&version=2} {add=[HOSS (1437769792183336960)]} 0 4 580173 [qtp541763983-15] INFO org.apache.solr.update.SolrCmdDistributor – Distrib commit to:[StdNode: http://127.0.1.1:8983/solr/collection1/] params:commit_end_point=true&commit=true&softCommit=false&waitSearcher=true&expungeDeletes=false 580426 [qtp541763983-15] INFO org.apache.solr.update.processor.LogUpdateProcessor – [collection1] webapp=/solr path=/update params={omitHeader=true&commit=true&wt=json} {add=[HOSS],commit=} 0 402 replica a few seconds later 595170 [commitScheduler-7-thread-1] INFO org.apache.solr.update.UpdateHandler – start commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false} 595355 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore – SolrDeletionPolicy.onCommit: commits: num=2 commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_c,generation=12} commit{dir=NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/home/hossman/lucene/dev/solr/example2/solr/collection1/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@2d508aed; maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_d,generation=13} 595355 [commitScheduler-7-thread-1] INFO org.apache.solr.core.SolrCore – newest commit generation = 13 595359 [commitScheduler-7-thread-1] INFO org.apache.solr.search.SolrIndexSearcher – Opening Searcher@140ffc1 realtime 595360 [commitScheduler-7-thread-1] INFO org.apache.solr.update.UpdateHandler – end_commit_flush You can see that the "explicit" commit (with "openSearcher=true") seems to be happening first, then the replica recieves the distrib update back from the leader, then a "Distrib commit to: <leader>" (that i'm not familiar with) is logged by the replica. A few seconds later, the autoCommit on the replica kicks in, but this uses openSearcher=false since that's what's in solrconfig.xml
        Hide
        Mark Miller added a comment -

        You can see that the "explicit" commit (with "openSearcher=true") seems to be happening first, then the replica recieves the distrib update back from the leader

        That sounds like the issue here - the local commit on the replica really needs to come after that update comes back?

        then a "Distrib commit to: <leader>" (that i'm not familiar with) is logged by the replica.

        After the local commit, we ask everyone else in the colleciton to commit.

        Show
        Mark Miller added a comment - You can see that the "explicit" commit (with "openSearcher=true") seems to be happening first, then the replica recieves the distrib update back from the leader That sounds like the issue here - the local commit on the replica really needs to come after that update comes back? then a "Distrib commit to: <leader>" (that i'm not familiar with) is logged by the replica. After the local commit, we ask everyone else in the colleciton to commit.
        Hide
        Mark Miller added a comment -

        I think your test will be key hossman.

        The following patch is also a good idea, though it does not catch this. It randomly turns off sending only to leaders on CloudSolrServers in tests.

        Show
        Mark Miller added a comment - I think your test will be key hossman. The following patch is also a good idea, though it does not catch this. It randomly turns off sending only to leaders on CloudSolrServers in tests.
        Hide
        Mark Miller added a comment -

        Chris Hostetter (Unused) if you can write a test, I think the attached patch will likely make it pass.

        It's also an improvement in general as we were doing a local commit and then committing on everyone else in the collection - it really took the length of two commits at least essentially. This does them all in parallel, and should address the issue by having the replica push it's commit through the solr cmd distributor so that it should play nicer with buffering - rather than just nailing it locally right away.

        Show
        Mark Miller added a comment - Chris Hostetter (Unused) if you can write a test, I think the attached patch will likely make it pass. It's also an improvement in general as we were doing a local commit and then committing on everyone else in the collection - it really took the length of two commits at least essentially. This does them all in parallel, and should address the issue by having the replica push it's commit through the solr cmd distributor so that it should play nicer with buffering - rather than just nailing it locally right away.
        Hide
        Hoss Man added a comment -

        Mark Miller here's a patch that modifies BasicDistributedZkTest to reliably produce a failure which i think is the same as the one being dicussed here.

        with your patch applied, my patch stops failing.

        Show
        Hoss Man added a comment - Mark Miller here's a patch that modifies BasicDistributedZkTest to reliably produce a failure which i think is the same as the one being dicussed here. with your patch applied, my patch stops failing.
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] markrmiller
        http://svn.apache.org/viewvc?view=revision&revision=1493779

        SOLR-4923: Commits to non leaders as part of a request that also contain updates can execute out of order.

        Show
        Commit Tag Bot added a comment - [trunk commit] markrmiller http://svn.apache.org/viewvc?view=revision&revision=1493779 SOLR-4923 : Commits to non leaders as part of a request that also contain updates can execute out of order.
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] markrmiller
        http://svn.apache.org/viewvc?view=revision&revision=1493782

        SOLR-4923: add optimization CHANGES entry

        Show
        Commit Tag Bot added a comment - [trunk commit] markrmiller http://svn.apache.org/viewvc?view=revision&revision=1493782 SOLR-4923 : add optimization CHANGES entry
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] markrmiller
        http://svn.apache.org/viewvc?view=revision&revision=1493829

        SOLR-4923: add missing credit

        Show
        Commit Tag Bot added a comment - [trunk commit] markrmiller http://svn.apache.org/viewvc?view=revision&revision=1493829 SOLR-4923 : add missing credit
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] markrmiller
        http://svn.apache.org/viewvc?view=revision&revision=1493846

        SOLR-4923: Commits to non leaders as part of a request that also contain updates can execute out of order.

        Show
        Commit Tag Bot added a comment - [branch_4x commit] markrmiller http://svn.apache.org/viewvc?view=revision&revision=1493846 SOLR-4923 : Commits to non leaders as part of a request that also contain updates can execute out of order.
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] markrmiller
        http://svn.apache.org/viewvc?view=revision&revision=1493861

        SOLR-4923: do not test if not sending to leaders first

        Show
        Commit Tag Bot added a comment - [trunk commit] markrmiller http://svn.apache.org/viewvc?view=revision&revision=1493861 SOLR-4923 : do not test if not sending to leaders first
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] markrmiller
        http://svn.apache.org/viewvc?view=revision&revision=1493885

        SOLR-4923: Commits to non leaders as part of a request that also contain updates can execute out of order.
        SOLR-4923: add optimization CHANGES entry
        SOLR-4923: add missing credit

        Show
        Commit Tag Bot added a comment - [branch_4x commit] markrmiller http://svn.apache.org/viewvc?view=revision&revision=1493885 SOLR-4923 : Commits to non leaders as part of a request that also contain updates can execute out of order. SOLR-4923 : add optimization CHANGES entry SOLR-4923 : add missing credit
        Hide
        Mark Miller added a comment -

        Thanks guys!

        Show
        Mark Miller added a comment - Thanks guys!
        Hide
        Steve Rowe added a comment -

        Bulk close resolved 4.4 issues

        Show
        Steve Rowe added a comment - Bulk close resolved 4.4 issues

          People

          • Assignee:
            Mark Miller
            Reporter:
            Ricardo Merizalde
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development