Solr
  1. Solr
  2. SOLR-4471

Replication occurs even when a slave is already up to date.

    Details

      Description

      Scenario: master/slave replication, master delta index runs every 10 minutes, slave poll interval is 10 sec.

      There was an issue SOLR-4413 - slave reads index from wrong directory, so slave is full copy index from master every time, which is fixed after applying this patch from 4413 (see script below).

      Now on replication the slave downloads only updated files, but slave is create a new segement file and also a new version of index (generation is identical with master). On next polling the slave is download the full index again, because the new version slave is force a full copy.

      Problem is the new version of index on the slave after first replication.

      mkdir work
      cd work
      svn co http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_1/
      cd lucene_solr_4_1
      patch -p0 < ../../patches/SOLR-4413.patch
      cd solr
      ant dist
      
      1. SOLR-4471_TestRefactor.diff
        16 kB
        Amit Nithian
      2. SOLR-4471_Tests.patch
        11 kB
        Amit Nithian
      3. SOLR-4471.patch
        14 kB
        Mark Miller
      4. SOLR-4471.patch
        12 kB
        Mark Miller
      5. SOLR-4471.patch
        2 kB
        Amit Nithian

        Issue Links

          Activity

          Hide
          Amit Nithian added a comment -

          I have a proposed solution with a bit of extra commentary on it in the code so it's clear what I am doing.

          Show
          Amit Nithian added a comment - I have a proposed solution with a bit of extra commentary on it in the code so it's clear what I am doing.
          Hide
          Mark Miller added a comment -

          Looks like we need a test for this.

          Show
          Mark Miller added a comment - Looks like we need a test for this.
          Hide
          Amit Nithian added a comment -

          I'll work on the test if no one else is. I think I see that my slave_gen > master_gen+1 is not needed but simply slave_gen > mater. I'll see if I can put some tests around it and re-submit a patch soon.

          Show
          Amit Nithian added a comment - I'll work on the test if no one else is. I think I see that my slave_gen > master_gen+1 is not needed but simply slave_gen > mater. I'll see if I can put some tests around it and re-submit a patch soon.
          Hide
          Mark Miller added a comment -

          I'm working on some improved tests in this area, but I'd appreciate any help or additional test work. We can't have too many for this stuff.

          Show
          Mark Miller added a comment - I'm working on some improved tests in this area, but I'd appreciate any help or additional test work. We can't have too many for this stuff.
          Hide
          Andre Charton added a comment -

          Today after debugging in a bigger environment I found slave marked the index as stale (method isStale() in SnapPuller). This is because segment the file, which comes from master and is different in size than the file on slave. This only happens if there are enough data and also 'delta-date'. With few data file looks same (exists + same size).
          So again: problem is that slave generates this segment file after replication (and also a new version). In the end the version number is may a "subproblem" of this new segment file. I'm note sure how lucene work, but that looks for me as the general problem.
          I also checked solr 3.6.1, the version is same. Also 3.6 didn't create index dir with time stamp (eg. index.12345) and segment files are same slave <-> master.

          Show
          Andre Charton added a comment - Today after debugging in a bigger environment I found slave marked the index as stale (method isStale() in SnapPuller). This is because segment the file, which comes from master and is different in size than the file on slave. This only happens if there are enough data and also 'delta-date'. With few data file looks same (exists + same size). So again: problem is that slave generates this segment file after replication (and also a new version). In the end the version number is may a "subproblem" of this new segment file. I'm note sure how lucene work, but that looks for me as the general problem. I also checked solr 3.6.1, the version is same. Also 3.6 didn't create index dir with time stamp (eg. index.12345) and segment files are same slave <-> master.
          Hide
          Helder Sepulveda added a comment -

          I also tested this:

          Upgraded servers to the latest n-Build

          • Do a commit on the Master
          • The Slave seems replicate only what it needs (correct way)
          • Next replication cycle comes and slave will download entire index

          First I noticed this behavior when clicking two times on the replicate now button
          but I changed my pollInterval to 30 seconds and the problem is more evident.

          Show
          Helder Sepulveda added a comment - I also tested this: Upgraded servers to the latest n-Build Do a commit on the Master The Slave seems replicate only what it needs (correct way) Next replication cycle comes and slave will download entire index First I noticed this behavior when clicking two times on the replicate now button but I changed my pollInterval to 30 seconds and the problem is more evident.
          Hide
          Andre Charton added a comment -

          One shot: I tried to set commit after replication as soft commit and it works for me:

          SnapPuller line 622 ff
                // update our commit point to the right dir
                CommitUpdateCommand cuc = new CommitUpdateCommand(req, false);
                ...
                cuc.softCommit = true; // use soft commit here, so on commit no new segment info are generated - on slave.
                ...
          

          Now slave didn't generate new segment file, also index version looks fine.

          Somebody agree?

          Show
          Andre Charton added a comment - One shot: I tried to set commit after replication as soft commit and it works for me: SnapPuller line 622 ff // update our commit point to the right dir CommitUpdateCommand cuc = new CommitUpdateCommand(req, false ); ... cuc.softCommit = true ; // use soft commit here, so on commit no new segment info are generated - on slave. ... Now slave didn't generate new segment file, also index version looks fine. Somebody agree?
          Hide
          Amit Nithian added a comment -

          When your replication is downloading the full index what is the value of the isFullCopyNeeded variable? Are you getting a full copy b/c the variable value is true or b/c the index is "stale"?

          Show
          Amit Nithian added a comment - When your replication is downloading the full index what is the value of the isFullCopyNeeded variable? Are you getting a full copy b/c the variable value is true or b/c the index is "stale"?
          Hide
          Mark Miller added a comment -

          Somebody agree?

          It's kind of a workaround, but there is more to this. I've already advanced a bit beyond this though - I'm not using a soft commit, I'm just not doing that commit unless isFullCopyNeeded. I'm running into an issue with the version though. Somehow, after the replication happens, the commit timestamp we store is not getting set to the value of the index we replicated in - it's like it's stale.

          Show
          Mark Miller added a comment - Somebody agree? It's kind of a workaround, but there is more to this. I've already advanced a bit beyond this though - I'm not using a soft commit, I'm just not doing that commit unless isFullCopyNeeded. I'm running into an issue with the version though. Somehow, after the replication happens, the commit timestamp we store is not getting set to the value of the index we replicated in - it's like it's stale.
          Hide
          Andre Charton added a comment -

          @Amit: First thought was version, but it was because setup was to small. Now I see it's stale b/c file exits and size is diff (-> segment file).
          @Mark: why this comment "// update our commit point to the right dir" - how we mark replicated index as ready for search?

          Show
          Andre Charton added a comment - @Amit: First thought was version, but it was because setup was to small. Now I see it's stale b/c file exits and size is diff (-> segment file). @Mark: why this comment "// update our commit point to the right dir" - how we mark replicated index as ready for search?
          Hide
          Mark Miller added a comment -

          why this comment "// update our commit point to the right dir"

          It's needed when you switch Directory's.

          Show
          Mark Miller added a comment - why this comment "// update our commit point to the right dir" It's needed when you switch Directory's.
          Hide
          Mark Miller added a comment -

          Or it was at one point - once we have some more thorough testing and some more fixes, we will have to see how that turns out.

          Show
          Mark Miller added a comment - Or it was at one point - once we have some more thorough testing and some more fixes, we will have to see how that turns out.
          Hide
          Mark Miller added a comment -

          In the test i was building on, pre commit was screwing with things. I've taken that out for now and am making some progress.

          Show
          Mark Miller added a comment - In the test i was building on, pre commit was screwing with things. I've taken that out for now and am making some progress.
          Hide
          Amit Nithian added a comment -

          One question in the unit tests, I noticed that it's one method test() which I am trying to break out into multiple unit test methods but was wondering if there is an order to the private test method invocations that caused this one single test() method.

          Show
          Amit Nithian added a comment - One question in the unit tests, I noticed that it's one method test() which I am trying to break out into multiple unit test methods but was wondering if there is an order to the private test method invocations that caused this one single test() method.
          Hide
          Mark Miller added a comment -

          Your guess is as good as mine - someone else originally wrote these. I think it tries to make order not matter, I don't know how successful it is. I generally just comment out the methods I'm not currently working with.

          Show
          Mark Miller added a comment - Your guess is as good as mine - someone else originally wrote these. I think it tries to make order not matter, I don't know how successful it is. I generally just comment out the methods I'm not currently working with.
          Hide
          Amit Nithian added a comment -

          So I tried to create a @BeforeClass and @AfterClass annotation to keep the server static.. now I just moved them to setup and teardown so each test creates and destroys jetty instances. I hate single methods that test 10 things so I hope that others agree.

          Show
          Amit Nithian added a comment - So I tried to create a @BeforeClass and @AfterClass annotation to keep the server static.. now I just moved them to setup and teardown so each test creates and destroys jetty instances. I hate single methods that test 10 things so I hope that others agree.
          Hide
          Andre Charton added a comment -

          Sorry for the spam - but which test method - can't find any related to the SnapPuller on trunk. But may is better to have no test method than the one with 10 aspects.

          Show
          Andre Charton added a comment - Sorry for the spam - but which test method - can't find any related to the SnapPuller on trunk. But may is better to have no test method than the one with 10 aspects.
          Hide
          Amit Nithian added a comment -

          It's in the TestReplicationHandler.java file.

          Show
          Amit Nithian added a comment - It's in the TestReplicationHandler.java file.
          Hide
          Mark Miller added a comment -

          Here is where I am at. A couple fixes, a test that catches at least some of this.

          Show
          Mark Miller added a comment - Here is where I am at. A couple fixes, a test that catches at least some of this.
          Hide
          Mark Miller added a comment -

          Amit: I think that's a fine change - I'd only check if it affects the overall test time much.

          Show
          Mark Miller added a comment - Amit: I think that's a fine change - I'd only check if it affects the overall test time much.
          Hide
          Amit Nithian added a comment -

          Mark, do you have any details you can provide about the underlying issue that you are trying to resolve in case there is something we can do to help?

          Show
          Amit Nithian added a comment - Mark, do you have any details you can provide about the underlying issue that you are trying to resolve in case there is something we can do to help?
          Hide
          Mark Miller added a comment -

          I think that patch may solve things for you. It at least fixes some things. Next I want to write more tests or try and think of what is not currently being tested. If you can break that patch, that would help as I can then add that test and fix it.

          Show
          Mark Miller added a comment - I think that patch may solve things for you. It at least fixes some things. Next I want to write more tests or try and think of what is not currently being tested. If you can break that patch, that would help as I can then add that test and fix it.
          Hide
          Mark Miller added a comment -

          One thing that does seem to mess things up is precommit. I'm not sure that's the most useful feature at the moment anyway, but avoid it in your testing

          Show
          Mark Miller added a comment - One thing that does seem to mess things up is precommit. I'm not sure that's the most useful feature at the moment anyway, but avoid it in your testing
          Hide
          Mark Miller added a comment -

          Another test and fix for when a new index directory is forced. Turns out we are doing things different somehow currently and don't need that commit at all any more to update our commit points. Some other improvement or bug fix.

          Show
          Mark Miller added a comment - Another test and fix for when a new index directory is forced. Turns out we are doing things different somehow currently and don't need that commit at all any more to update our commit points. Some other improvement or bug fix.
          Hide
          Amit Nithian added a comment -

          This doesn't add anything new other than break out the test() method into separate actual junit tests. Also it's better to ensure each test has a clean set of jetty servers initialized so as to ensure state from previous tests don't leak into future ones.

          Show
          Amit Nithian added a comment - This doesn't add anything new other than break out the test() method into separate actual junit tests. Also it's better to ensure each test has a clean set of jetty servers initialized so as to ensure state from previous tests don't leak into future ones.
          Hide
          Amit Nithian added a comment -

          Sorry I'm trying to read the patch and perhaps I'm missing something but where is the commit that I thought was needed to signal new data? If that's not needed can you explain why just for my understanding?

          Also why is there such a distinction between getIndexDir and getNewIndexDir and why can't all calls route through one? It's a bit confusing to me at the moment.

          Show
          Amit Nithian added a comment - Sorry I'm trying to read the patch and perhaps I'm missing something but where is the commit that I thought was needed to signal new data? If that's not needed can you explain why just for my understanding? Also why is there such a distinction between getIndexDir and getNewIndexDir and why can't all calls route through one? It's a bit confusing to me at the moment.
          Hide
          Mark Miller added a comment -

          No, the commit was not to single new data - see the comment - it was mainly about fixing an issue when restarting the writer.

          At one point, it may have also been what triggered a new searcher, but we have done that explicitly instead for a while now.

          getIndexDir and getNewIndexDir are kind of complicated. getNewIndexDir should always be safe to use, but it does this extra step of reading a properties file sometimes. Technically, it's mainly supposed to be critical to use getNewIndexDir when making new writers and searchers - i sometimes use it elsewhere in replication to be sure any kind of race is not an issue.

          Show
          Mark Miller added a comment - No, the commit was not to single new data - see the comment - it was mainly about fixing an issue when restarting the writer. At one point, it may have also been what triggered a new searcher, but we have done that explicitly instead for a while now. getIndexDir and getNewIndexDir are kind of complicated. getNewIndexDir should always be safe to use, but it does this extra step of reading a properties file sometimes. Technically, it's mainly supposed to be critical to use getNewIndexDir when making new writers and searchers - i sometimes use it elsewhere in replication to be sure any kind of race is not an issue.
          Hide
          Mark Miller added a comment -

          I think I'm about ready to commit what I have. I think it fixes the glaring issues and has some improved tests. Then it will be easier to build on top of that if needed.

          Show
          Mark Miller added a comment - I think I'm about ready to commit what I have. I think it fixes the glaring issues and has some improved tests. Then it will be easier to build on top of that if needed.
          Hide
          Helder Sepulveda added a comment -

          Once you commit, Can you generate a .war file?
          I would like to test it on the servers

          Solr 4.1 reduced my index size by more than 50%, Me so happy!
          But this problem with the replication is a show stopper.

          Let me know if there is anything I can do to help.

          Show
          Helder Sepulveda added a comment - Once you commit, Can you generate a .war file? I would like to test it on the servers Solr 4.1 reduced my index size by more than 50%, Me so happy! But this problem with the replication is a show stopper. Let me know if there is anything I can do to help.
          Hide
          Andre Charton added a comment -

          For me patch looks good, together with 4413 replication in solr 4.x is working.
          Thanks for that ( especially from network team, because angry about heavy network usage during replications)!

          @Helder try:

          build script to apply patches in solr, copy content in build.sh an run - may it works for you
          mkdir patches
          cd patches
          wget https://issues.apache.org/jira/secure/attachment/12570408/SOLR-4471.patch
          wget https://issues.apache.org/jira/secure/attachment/12569673/SOLR-4413.patch
          cd ..
          mkdir work
          cd work
          svn co http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_1/
          cd lucene_solr_4_1
          patch -p0 < ../../patches/SOLR-4413.patch
          patch -p0 < ../../patches/SOLR-4471.patch
          cd solr
          ant dist
          
          Show
          Andre Charton added a comment - For me patch looks good, together with 4413 replication in solr 4.x is working. Thanks for that ( especially from network team, because angry about heavy network usage during replications)! @Helder try: build script to apply patches in solr, copy content in build.sh an run - may it works for you mkdir patches cd patches wget https://issues.apache.org/jira/secure/attachment/12570408/SOLR-4471.patch wget https://issues.apache.org/jira/secure/attachment/12569673/SOLR-4413.patch cd .. mkdir work cd work svn co http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_1/ cd lucene_solr_4_1 patch -p0 < ../../patches/SOLR-4413.patch patch -p0 < ../../patches/SOLR-4471.patch cd solr ant dist
          Hide
          Helder Sepulveda added a comment -

          I think I will have to start by installing SVN and ANT...
          My servers are VM clones of production servers, they have the bare minimum to run solr, no extra bells and whistles.
          Anything else I might need?

          Show
          Helder Sepulveda added a comment - I think I will have to start by installing SVN and ANT... My servers are VM clones of production servers, they have the bare minimum to run solr, no extra bells and whistles. Anything else I might need?
          Hide
          Helder Sepulveda added a comment -

          Andre if you already have a .war file, I would appreciate it very much if you can upload it somewhere, it will save me a lot of troubles

          Show
          Helder Sepulveda added a comment - Andre if you already have a .war file, I would appreciate it very much if you can upload it somewhere, it will save me a lot of troubles
          Hide
          Commit Tag Bot added a comment -

          [trunk commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1449115

          SOLR-4471: Replication occurs even when a slave is already up to date.

          SOLR-4484: ReplicationHandler#loadReplicationProperties still uses Files rather than the Directory to try and read the replication properties files.

          SOLR-4488: Return slave replication details for a master if the master has also acted like a slave.

          Show
          Commit Tag Bot added a comment - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1449115 SOLR-4471 : Replication occurs even when a slave is already up to date. SOLR-4484 : ReplicationHandler#loadReplicationProperties still uses Files rather than the Directory to try and read the replication properties files. SOLR-4488 : Return slave replication details for a master if the master has also acted like a slave.
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1449117

          SOLR-4471: Replication occurs even when a slave is already up to date.

          SOLR-4484: ReplicationHandler#loadReplicationProperties still uses Files rather than the Directory to try and read the replication properties files.

          SOLR-4488: Return slave replication details for a master if the master has also acted like a slave.

          Show
          Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1449117 SOLR-4471 : Replication occurs even when a slave is already up to date. SOLR-4484 : ReplicationHandler#loadReplicationProperties still uses Files rather than the Directory to try and read the replication properties files. SOLR-4488 : Return slave replication details for a master if the master has also acted like a slave.
          Hide
          Mark Miller added a comment -

          I've put up an intermediate build of the current 4X branch at http://people.apache.org/~markrmiller/solr-4.2-SNAPSHOT.tgz that includes the current fixes.

          Show
          Mark Miller added a comment - I've put up an intermediate build of the current 4X branch at http://people.apache.org/~markrmiller/solr-4.2-SNAPSHOT.tgz that includes the current fixes.
          Hide
          Amit Nithian added a comment -

          Sorry to spam again. Thanks for the explanation! I saw a bunch of changes and I thought they were all to this patch but didn't realize it was for other bugs. I am attaching my latest test class with some refactorings to hopefully make new tests easier. I think it's as fast but even if it's a bit slower, I'd rather have a slower clean test class than a dirtier fast one

          Show
          Amit Nithian added a comment - Sorry to spam again. Thanks for the explanation! I saw a bunch of changes and I thought they were all to this patch but didn't realize it was for other bugs. I am attaching my latest test class with some refactorings to hopefully make new tests easier. I think it's as fast but even if it's a bit slower, I'd rather have a slower clean test class than a dirtier fast one
          Hide
          Mark Miller added a comment -

          Thanks, I'll commit this shortly.

          I'd rather have a slower clean test class than a dirtier fast one

          It depends on the time difference I think.

          In this case, it doesn't look like a problem. I'm not sure what the original motivation to have them together was.

          Show
          Mark Miller added a comment - Thanks, I'll commit this shortly. I'd rather have a slower clean test class than a dirtier fast one It depends on the time difference I think. In this case, it doesn't look like a problem. I'm not sure what the original motivation to have them together was.
          Hide
          Mark Miller added a comment -

          but didn't realize it was for other bugs.

          I did SOLR-4484 because it was causing me problems with the test so had to be fixed for this fix.

          I did SOLR-4488 because I used it as part of the new testing.

          Show
          Mark Miller added a comment - but didn't realize it was for other bugs. I did SOLR-4484 because it was causing me problems with the test so had to be fixed for this fix. I did SOLR-4488 because I used it as part of the new testing.
          Hide
          Shikhar Bhushan added a comment -

          We ran into the same issue with full copies happening with each incremental. Patch works! Thank you.

          Show
          Shikhar Bhushan added a comment - We ran into the same issue with full copies happening with each incremental. Patch works! Thank you.
          Hide
          Helder Sepulveda added a comment -

          I just tested the .war in the solr-4.2-SNAPSHOT.tgz and replication is working as intended!
          Thanks a bunch

          Show
          Helder Sepulveda added a comment - I just tested the .war in the solr-4.2-SNAPSHOT.tgz and replication is working as intended! Thanks a bunch
          Hide
          Commit Tag Bot added a comment -

          [trunk commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1449240

          SOLR-4471: Improve and clean up TestReplicationHandler.

          Show
          Commit Tag Bot added a comment - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1449240 SOLR-4471 : Improve and clean up TestReplicationHandler.
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1449241

          SOLR-4471: Improve and clean up TestReplicationHandler.

          Show
          Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1449241 SOLR-4471 : Improve and clean up TestReplicationHandler.
          Hide
          Commit Tag Bot added a comment -

          [trunk commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1449258

          SOLR-4471: Fix up test.

          Show
          Commit Tag Bot added a comment - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1449258 SOLR-4471 : Fix up test.
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1449259

          SOLR-4471: Fix up test.

          Show
          Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1449259 SOLR-4471 : Fix up test.
          Hide
          Mark Miller added a comment -

          Thanks all for the help!

          Show
          Mark Miller added a comment - Thanks all for the help!
          Hide
          Raúl Grande added a comment -

          I have problems with 4.2-SNAPSHOT version. My slaves doesn't replicate even when master's version is higher than theirs. See image here: http://oi50.tinypic.com/o8uzad.jpg

          Why logs say "Slave in sync with master" when clearly isn't??

          Show
          Raúl Grande added a comment - I have problems with 4.2-SNAPSHOT version. My slaves doesn't replicate even when master's version is higher than theirs. See image here: http://oi50.tinypic.com/o8uzad.jpg Why logs say "Slave in sync with master" when clearly isn't??
          Hide
          Amit Nithian added a comment -

          I'm curious about something. What does:
          1) http://localhost:17045/solr/replication?command=indexversion yield
          2) http://localhost:<your slave port>/solr/replication?command=details yield

          I have noticed that what you see on the UI vs what you see in the indexversion and details sometimes differ and I wonder if that is a culprit here? Does #1,#2 jive with the versions that you see in the UI?

          Show
          Amit Nithian added a comment - I'm curious about something. What does: 1) http://localhost:17045/solr/replication?command=indexversion yield 2) http://localhost: <your slave port>/solr/replication?command=details yield I have noticed that what you see on the UI vs what you see in the indexversion and details sometimes differ and I wonder if that is a culprit here? Does #1,#2 jive with the versions that you see in the UI?
          Hide
          Raúl Grande added a comment -

          When I do http://localhost:17045/solr/replication?command=indexversion response is:
          <long name="generation">29037</long>

          That's the same version than slaves have, but on the UI generation in master is now 29082.

          Show
          Raúl Grande added a comment - When I do http://localhost:17045/solr/replication?command=indexversion response is: <long name="generation">29037</long> That's the same version than slaves have, but on the UI generation in master is now 29082.
          Hide
          Mark Miller added a comment -

          When I do http://localhost:17045/solr/replication?command=indexversion response is:
          <long name="generation">29037</long>
          That's the same version than slaves have, but on the UI generation in master is now 29082.

          Sounds like perhaps that needs it's own new JIRA issue?

          Show
          Mark Miller added a comment - When I do http://localhost:17045/solr/replication?command=indexversion response is: <long name="generation">29037</long> That's the same version than slaves have, but on the UI generation in master is now 29082. Sounds like perhaps that needs it's own new JIRA issue?
          Hide
          Raúl Grande added a comment -
          Show
          Raúl Grande added a comment - SOLR-4511
          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.

            People

            • Assignee:
              Mark Miller
              Reporter:
              Andre Charton
            • Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development