Solr
  1. Solr
  2. SOLR-820

replicate After startup for new replication

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4
    • Component/s: replication (java)
    • Labels:
      None

      Description

      add another option of

       <str name="replicateAfter">startup</str>
      

      so that replication can be triggered w/o a commit

      1. SOLR-820.patch
        7 kB
        Akshay K. Ukey
      2. SOLR-820.patch
        1 kB
        Akshay K. Ukey
      3. SOLR-820.patch
        1 kB
        Noble Paul
      4. SOLR-820.patch
        3 kB
        Noble Paul

        Issue Links

          Activity

          Hide
          Noble Paul added a comment -
          • added an option for replicateafter startup
          • fixed issues w/ registering the listeners
          Show
          Noble Paul added a comment - added an option for replicateafter startup fixed issues w/ registering the listeners
          Hide
          Shalin Shekhar Mangar added a comment -

          This was accidentally committed with the SOLR-561 fixes.

          I'm marking this issue as resolved. We can re-open it if we find a problem.

          Show
          Shalin Shekhar Mangar added a comment - This was accidentally committed with the SOLR-561 fixes. I'm marking this issue as resolved. We can re-open it if we find a problem.
          Hide
          Michael Henson added a comment - - edited

          I have not been able to get this to work in my configuration. The slave instance, starting with an empty target directory, creates segments files for itself on startup. It then has an "index version" that is a higher number than the master's index version. The replication never starts, unless I do a commit on the master.

          My replication config is very straightforward. My configuration assumes that the slave machine is starting off completely empty of all data (aside from the essentials necessary to get Solr to start), and will pull everything from the master instance.

          NOTE: I tested this with nightly build solr-2009-01-12.zip

          Show
          Michael Henson added a comment - - edited I have not been able to get this to work in my configuration. The slave instance, starting with an empty target directory, creates segments files for itself on startup. It then has an "index version" that is a higher number than the master's index version. The replication never starts, unless I do a commit on the master. My replication config is very straightforward. My configuration assumes that the slave machine is starting off completely empty of all data (aside from the essentials necessary to get Solr to start), and will pull everything from the master instance. NOTE: I tested this with nightly build solr-2009-01-12.zip
          Hide
          Shalin Shekhar Mangar added a comment -

          Thanks for reporting this Michael. I'll try to reproduce the issue.

          Show
          Shalin Shekhar Mangar added a comment - Thanks for reporting this Michael. I'll try to reproduce the issue.
          Hide
          Peter Wolanin added a comment -

          Jacob and I are seeing the exact same issue today - is there some way to set the timestamp in the index on the slave server ?

          Show
          Peter Wolanin added a comment - Jacob and I are seeing the exact same issue today - is there some way to set the timestamp in the index on the slave server ?
          Hide
          Noble Paul added a comment -

          is the version on the master showing zero?

          Show
          Noble Paul added a comment - is the version on the master showing zero?
          Hide
          Noble Paul added a comment - - edited

          An untested patch. can you try it out?
          When there are no commits on the master the list of files associated with the current commit point is not avalable because onCommit/onInit is not called on the deletionpolicy.

          So if we do a force open of the writer , the onInit() gets called on the deletionpolicy and we get a chance to read the file names

          Show
          Noble Paul added a comment - - edited An untested patch. can you try it out? When there are no commits on the master the list of files associated with the current commit point is not avalable because onCommit/onInit is not called on the deletionpolicy. So if we do a force open of the writer , the onInit() gets called on the deletionpolicy and we get a chance to read the file names
          Hide
          Shalin Shekhar Mangar added a comment -

          Re-opening to investigate/fix problems reported on this feature.

          Show
          Shalin Shekhar Mangar added a comment - Re-opening to investigate/fix problems reported on this feature.
          Hide
          Akshay K. Ukey added a comment - - edited

          Patch in sync with trunk. This is working now. Do we need a test case for this Shalin?

          Show
          Akshay K. Ukey added a comment - - edited Patch in sync with trunk. This is working now. Do we need a test case for this Shalin?
          Hide
          Shalin Shekhar Mangar added a comment -

          Committed revision 740678.

          Thanks Akshay. I'll keep the issue open until we can add a test.

          Show
          Shalin Shekhar Mangar added a comment - Committed revision 740678. Thanks Akshay. I'll keep the issue open until we can add a test.
          Hide
          Akshay K. Ukey added a comment -

          Patch with test case.

          Show
          Akshay K. Ukey added a comment - Patch with test case.
          Hide
          Shalin Shekhar Mangar added a comment -

          Committed revision 741451.

          Thanks Akshay!

          Show
          Shalin Shekhar Mangar added a comment - Committed revision 741451. Thanks Akshay!
          Hide
          Grant Ingersoll added a comment -

          Bulk close for Solr 1.4

          Show
          Grant Ingersoll added a comment - Bulk close for Solr 1.4

            People

            • Assignee:
              Shalin Shekhar Mangar
              Reporter:
              Noble Paul
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development