Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.2, master (7.0)
    • Component/s: None
    • Labels:
      None
    1. SOLR-9181.patch
      20 kB
      Alan Woodward
    2. SOLR-9181.patch
      19 kB
      Scott Blum
    3. SOLR-9181.patch
      18 kB
      Alan Woodward
    4. SOLR-9181.patch
      7 kB
      Alan Woodward
    5. SOLR-9181-2.patch
      10 kB
      Alan Woodward
    6. SOLR-9181-2.patch
      10 kB
      Alan Woodward
    7. stderr
      0.5 kB
      Erick Erickson
    8. stdout
      68 kB
      Erick Erickson

      Issue Links

        Activity

        Hide
        romseygeek Alan Woodward added a comment -

        This is a test bug, I think. There's a race when a collection is migrated from state format 1 to state format 2, where the state reader may briefly see the collection removed from collectionstate.json before it sees the new collection/state.json znode. The test fails to take that into account, and assumes that clusterState.getCollection() will always return a DocCollection object. It can be fixed by using waitForState() instead of polling. I'll put up a patch shortly.

        Show
        romseygeek Alan Woodward added a comment - This is a test bug, I think. There's a race when a collection is migrated from state format 1 to state format 2, where the state reader may briefly see the collection removed from collectionstate.json before it sees the new collection/state.json znode. The test fails to take that into account, and assumes that clusterState.getCollection() will always return a DocCollection object. It can be fixed by using waitForState() instead of polling. I'll put up a patch shortly.
        Hide
        romseygeek Alan Woodward added a comment -

        Patch. This also uncovered a couple of bugs in the collection state watcher API to do with collections in state format 1:

        • format-1-collections wouldn't trigger notifications on updates if they hadn't already been registered
        • registering a watcher on a format-1 collection wouldn't check the current state if the collection wasn't already watched
        Show
        romseygeek Alan Woodward added a comment - Patch. This also uncovered a couple of bugs in the collection state watcher API to do with collections in state format 1: format-1-collections wouldn't trigger notifications on updates if they hadn't already been registered registering a watcher on a format-1 collection wouldn't check the current state if the collection wasn't already watched
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 950fd913354912f9c84a07dcf60258726d6d6f4f in lucene-solr's branch refs/heads/master from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=950fd91 ]

        SOLR-9181: Fix test bug in ZkStateReaderTest

        Show
        jira-bot ASF subversion and git services added a comment - Commit 950fd913354912f9c84a07dcf60258726d6d6f4f in lucene-solr's branch refs/heads/master from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=950fd91 ] SOLR-9181 : Fix test bug in ZkStateReaderTest
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 0cfe43164a95de530907de4818b32891f62a95f8 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0cfe431 ]

        SOLR-9181: Fix test bug in ZkStateReaderTest

        Show
        jira-bot ASF subversion and git services added a comment - Commit 0cfe43164a95de530907de4818b32891f62a95f8 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0cfe431 ] SOLR-9181 : Fix test bug in ZkStateReaderTest
        Hide
        romseygeek Alan Woodward added a comment -

        I'm seeing a whole bunch of failures after this, and can reproduce via beasting locally - digging now.

        Show
        romseygeek Alan Woodward added a comment - I'm seeing a whole bunch of failures after this, and can reproduce via beasting locally - digging now.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1e2ba9fe9be84f0b5defe4965735eae892fabf7b in lucene-solr's branch refs/heads/master from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e2ba9f ]

        Revert "SOLR-9181: Fix test bug in ZkStateReaderTest"

        This reverts commit 950fd913354912f9c84a07dcf60258726d6d6f4f.

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1e2ba9fe9be84f0b5defe4965735eae892fabf7b in lucene-solr's branch refs/heads/master from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e2ba9f ] Revert " SOLR-9181 : Fix test bug in ZkStateReaderTest" This reverts commit 950fd913354912f9c84a07dcf60258726d6d6f4f.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 3595b9ab2e51a6e040915db98d48d242197c151e in lucene-solr's branch refs/heads/branch_6x from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3595b9a ]

        Revert "SOLR-9181: Fix test bug in ZkStateReaderTest"

        This reverts commit 0cfe43164a95de530907de4818b32891f62a95f8.

        Show
        jira-bot ASF subversion and git services added a comment - Commit 3595b9ab2e51a6e040915db98d48d242197c151e in lucene-solr's branch refs/heads/branch_6x from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3595b9a ] Revert " SOLR-9181 : Fix test bug in ZkStateReaderTest" This reverts commit 0cfe43164a95de530907de4818b32891f62a95f8.
        Hide
        romseygeek Alan Woodward added a comment -

        Reverting this while I work out what's broken.

        Show
        romseygeek Alan Woodward added a comment - Reverting this while I work out what's broken.
        Hide
        romseygeek Alan Woodward added a comment -

        Turns out that ZkStateReaderTest is very helpful for finding bugs and races in the collection state watcher implementation! This patch fixes the following:

        • notifications were being run before constructState() was called, which meant that threads waiting on notifications could see stale state if they then called .getClusterState(). Notifications are now always run afterwards.
        • DocCollection.equals() didn't take into account state formats, so a migration from state format 1 to state format 2 could sometimes not fire a notification
        • When choosing which state format 1 collections should be notified, the code checked to see if there was a watcher on the collection. This lead to a race, where a watch could be set after the legacy state change had fired, but before constructState() was called, so that it would check against stale state but not be notified of the new state. The code now just raises notifications for all changed collections.

        Beasting ZkStateReaderTest for several thousand iterations now passes consistently, so I think this should sort out the issues. I'm pretty sure that the final point above is also the reason for the failures in SOLR-9189.

        Show
        romseygeek Alan Woodward added a comment - Turns out that ZkStateReaderTest is very helpful for finding bugs and races in the collection state watcher implementation! This patch fixes the following: notifications were being run before constructState() was called, which meant that threads waiting on notifications could see stale state if they then called .getClusterState(). Notifications are now always run afterwards. DocCollection.equals() didn't take into account state formats, so a migration from state format 1 to state format 2 could sometimes not fire a notification When choosing which state format 1 collections should be notified, the code checked to see if there was a watcher on the collection. This lead to a race, where a watch could be set after the legacy state change had fired, but before constructState() was called, so that it would check against stale state but not be notified of the new state. The code now just raises notifications for all changed collections. Beasting ZkStateReaderTest for several thousand iterations now passes consistently, so I think this should sort out the issues. I'm pretty sure that the final point above is also the reason for the failures in SOLR-9189 .
        Hide
        dragonsinth Scott Blum added a comment -

        Hi Alan Woodward! I'm about to upload a slightly different patch to fix a few nits, but I did notice a potential problem: most callers of refreshLegacyClusterState() throw away the results. In certain code paths, observers of collections in the legacy format won't see any changes even though our in-memory rep is updated.

        Show
        dragonsinth Scott Blum added a comment - Hi Alan Woodward ! I'm about to upload a slightly different patch to fix a few nits, but I did notice a potential problem: most callers of refreshLegacyClusterState() throw away the results. In certain code paths, observers of collections in the legacy format won't see any changes even though our in-memory rep is updated.
        Hide
        dragonsinth Scott Blum added a comment -

        Patch updated, just a few tweaks.

        Show
        dragonsinth Scott Blum added a comment - Patch updated, just a few tweaks.
        Hide
        romseygeek Alan Woodward added a comment -

        Here's an attempt to clean this up a bit. Notifications are now fired from constructState(), which takes a map of changed collections. This should ensure that a) we always take into account what has changed, and b) we fire notifications on every state updated. Tests pass under beasting.

        Show
        romseygeek Alan Woodward added a comment - Here's an attempt to clean this up a bit. Notifications are now fired from constructState(), which takes a map of changed collections. This should ensure that a) we always take into account what has changed, and b) we fire notifications on every state updated. Tests pass under beasting.
        Hide
        romseygeek Alan Woodward added a comment -

        Given that we're still finding timing-related bugs in this code, I think it might be a good idea to remove the .waitForState() and .registerCollectionStateWatcher() methods from 6.1, and push it all back to 6.2?

        Show
        romseygeek Alan Woodward added a comment - Given that we're still finding timing-related bugs in this code, I think it might be a good idea to remove the .waitForState() and .registerCollectionStateWatcher() methods from 6.1, and push it all back to 6.2?
        Hide
        dragonsinth Scott Blum added a comment -

        I think I'd probably leave the APIs there, but maybe mark them experimental in 6.1 and just not have the rest of Solr rely on them yet?

        Show
        dragonsinth Scott Blum added a comment - I think I'd probably leave the APIs there, but maybe mark them experimental in 6.1 and just not have the rest of Solr rely on them yet?
        Hide
        dragonsinth Scott Blum added a comment -

        BTW, I have to admit I'm stalling on reviewing the update because there's no easy way to compare two patch files except to patch each one in turn and diff the result...

        Show
        dragonsinth Scott Blum added a comment - BTW, I have to admit I'm stalling on reviewing the update because there's no easy way to compare two patch files except to patch each one in turn and diff the result...
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 057c317a9d781a15eb9b47341d247d9a98902f24 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=057c317 ]

        SOLR-9181: Fix some races in ZkStateReader collection watch updates

        Show
        jira-bot ASF subversion and git services added a comment - Commit 057c317a9d781a15eb9b47341d247d9a98902f24 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=057c317 ] SOLR-9181 : Fix some races in ZkStateReader collection watch updates
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit cefab1dffc514309734699d0031e7e08aac24dfc in lucene-solr's branch refs/heads/master from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cefab1d ]

        SOLR-9181: Fix some races in ZkStateReader collection watch updates

        Show
        jira-bot ASF subversion and git services added a comment - Commit cefab1dffc514309734699d0031e7e08aac24dfc in lucene-solr's branch refs/heads/master from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cefab1d ] SOLR-9181 : Fix some races in ZkStateReader collection watch updates
        Hide
        romseygeek Alan Woodward added a comment -

        Meant to commit this for 6.1, and it completely dropped off my radar. Oh well...

        Show
        romseygeek Alan Woodward added a comment - Meant to commit this for 6.1, and it completely dropped off my radar. Oh well...
        Hide
        steve_rowe Steve Rowe added a comment -

        Around the cefab1dfff commit under this issue, my Jenkins master Lucene/Solr test job went from about 50% overall job failure rate (i.e. at least one test failure in a run - this unfortunately has been the case for quite some time) to nearly 100% failures (28 runs with at least one failure out of 29 runs) - see the trend here <http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/buildTimeTrend>. I think Policeman and ASF Jenkins are seeing increases in failure rates too but I haven't counted yet. The few failing tests I attempted with don't reproduce. The ZK reader and writer tests seem to be failing quite a bit more often now, but that's anecdotal; I didn't look at the numbers.

        So I stopped all other jobs on my Jenkins and did a brute force search for which commit to blame, by pinning 7 jobs each at a different non-trivial commit in the suspect time frame - you can see these jobs here: <http://jenkins.sarowe.net/view/Enabled/>. Each job has run about 20 times now, and c3fab1dfff stands out as failing signficantly more often:

        push date/time (UTC) issue commit failures runs % failures
        29 Jun 18:27 SOLR-9246 1ae0d8d6 6 19 32%
        30 Jun 06:40 SOLR-9216 1dc7480b 10 19 53%
        30 Jun 09:52 SOLR-9264 015e0fc1 10 19 53%
        30 Jun 17:02 SOLR-8787 0a15699c 11 20 55%
        01 Jul 07:46 SOLR-9262 51fde1cb 11 20 55%
        01 Jul 13:07 SOLR-9076 2c96c91d 9 19 47%
        01 Jul 15:13 SOLR-9181 cefab1df 13 19 68%
        Show
        steve_rowe Steve Rowe added a comment - Around the cefab1dfff commit under this issue, my Jenkins master Lucene/Solr test job went from about 50% overall job failure rate (i.e. at least one test failure in a run - this unfortunately has been the case for quite some time) to nearly 100% failures (28 runs with at least one failure out of 29 runs) - see the trend here < http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/buildTimeTrend >. I think Policeman and ASF Jenkins are seeing increases in failure rates too but I haven't counted yet. The few failing tests I attempted with don't reproduce. The ZK reader and writer tests seem to be failing quite a bit more often now, but that's anecdotal; I didn't look at the numbers. So I stopped all other jobs on my Jenkins and did a brute force search for which commit to blame, by pinning 7 jobs each at a different non-trivial commit in the suspect time frame - you can see these jobs here: < http://jenkins.sarowe.net/view/Enabled/ >. Each job has run about 20 times now, and c3fab1dfff stands out as failing signficantly more often: push date/time (UTC) issue commit failures runs % failures 29 Jun 18:27 SOLR-9246 1ae0d8d6 6 19 32% 30 Jun 06:40 SOLR-9216 1dc7480b 10 19 53% 30 Jun 09:52 SOLR-9264 015e0fc1 10 19 53% 30 Jun 17:02 SOLR-8787 0a15699c 11 20 55% 01 Jul 07:46 SOLR-9262 51fde1cb 11 20 55% 01 Jul 13:07 SOLR-9076 2c96c91d 9 19 47% 01 Jul 15:13 SOLR-9181 cefab1df 13 19 68%
        Hide
        romseygeek Alan Woodward added a comment -

        Thanks Steve. I'll take a look at this tomorrow.

        Show
        romseygeek Alan Woodward added a comment - Thanks Steve. I'll take a look at this tomorrow.
        Hide
        romseygeek Alan Woodward added a comment -

        OK, I've gone through the logs for a number of these test failures, and what they all have in common is a ZK session expiry causing the cluster state to not be properly updated. What I can't work out though is why these expiries are happening - the timestamps on the logs don't show any pauses, and there's nothing as far as I can tell that's changed in the zk code itself.

        Show
        romseygeek Alan Woodward added a comment - OK, I've gone through the logs for a number of these test failures, and what they all have in common is a ZK session expiry causing the cluster state to not be properly updated. What I can't work out though is why these expiries are happening - the timestamps on the logs don't show any pauses, and there's nothing as far as I can tell that's changed in the zk code itself.
        Hide
        romseygeek Alan Woodward added a comment -

        Also, I get no failures on local beasting, so it's presumably something to do with contention on the slow-ish Jenkins machines.

        Show
        romseygeek Alan Woodward added a comment - Also, I get no failures on local beasting, so it's presumably something to do with contention on the slow-ish Jenkins machines.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit e6e0765e864132185549e91a64d76fcac63f7335 in lucene-solr's branch refs/heads/master from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e6e0765 ]

        SOLR-9181: Add some logging to ZkStateReader to try and debug test failures

        Show
        jira-bot ASF subversion and git services added a comment - Commit e6e0765e864132185549e91a64d76fcac63f7335 in lucene-solr's branch refs/heads/master from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e6e0765 ] SOLR-9181 : Add some logging to ZkStateReader to try and debug test failures
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 521764ffa572650f9e8c8b4ac5c0dba7ba5ee5e3 in lucene-solr's branch refs/heads/master from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=521764f ]

        SOLR-9181: More logging

        Show
        jira-bot ASF subversion and git services added a comment - Commit 521764ffa572650f9e8c8b4ac5c0dba7ba5ee5e3 in lucene-solr's branch refs/heads/master from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=521764f ] SOLR-9181 : More logging
        Hide
        romseygeek Alan Woodward added a comment -

        I've added some logging, and I think that this is a race somewhere between refreshCollectionList() and forceUpdateCollection(), where a new lazy collection is being added halfway through the update. Still digging...

        Show
        romseygeek Alan Woodward added a comment - I've added some logging, and I think that this is a race somewhere between refreshCollectionList() and forceUpdateCollection(), where a new lazy collection is being added halfway through the update. Still digging...
        Hide
        romseygeek Alan Woodward added a comment -

        Got it - if I stick a Thread.sleep() in refreshCollectionList() then the ZkStateWriterTest errors reproduce for me. It looks as though forceUpdateCollection() needs to hold both the general update lock and the collections list update lock, although I'm going to beast this for a while to make sure that this doesn't deadlock anywhere.

        This still leaves the ZkStateReaderTest failures. I think these are caused by notifications using potentially stale DocCollection states, rather than the the latest state available. I'm beasting tests locally now, and will commit the fix to master shortly and see if it actually works.

        Show
        romseygeek Alan Woodward added a comment - Got it - if I stick a Thread.sleep() in refreshCollectionList() then the ZkStateWriterTest errors reproduce for me. It looks as though forceUpdateCollection() needs to hold both the general update lock and the collections list update lock, although I'm going to beast this for a while to make sure that this doesn't deadlock anywhere. This still leaves the ZkStateReaderTest failures. I think these are caused by notifications using potentially stale DocCollection states, rather than the the latest state available. I'm beasting tests locally now, and will commit the fix to master shortly and see if it actually works.
        Hide
        erickerickson Erick Erickson added a comment -

        Alan Woodward

        I was looking at this too fearing that my recent changes might have introduced yet another problem (insert rant about windows here) and found that the NPE in testExternalCollectionWatchedNotWatched could be avoided by adding a wait if any of these were null around line 166

        assertTrue(reader.getClusterState().getCollectionRef("c1").isLazilyLoaded()

        FYI. Didn't log which of the above, but I assume the getCollectionRef("c1") returned null. Not pursuing this further, but the NPE is quite reproducible on my machine. I can beast your patch if that'd help, let me know.

        Show
        erickerickson Erick Erickson added a comment - Alan Woodward I was looking at this too fearing that my recent changes might have introduced yet another problem (insert rant about windows here) and found that the NPE in testExternalCollectionWatchedNotWatched could be avoided by adding a wait if any of these were null around line 166 assertTrue(reader.getClusterState().getCollectionRef("c1").isLazilyLoaded() FYI. Didn't log which of the above, but I assume the getCollectionRef("c1") returned null. Not pursuing this further, but the NPE is quite reproducible on my machine. I can beast your patch if that'd help, let me know.
        Hide
        romseygeek Alan Woodward added a comment -

        Here's a patch which should solve the issue - if you could beast it Erick that would be great! Am travelling the next couple of days, but I'll commit it if I get half-decent wifi anywhere.

        Show
        romseygeek Alan Woodward added a comment - Here's a patch which should solve the issue - if you could beast it Erick that would be great! Am travelling the next couple of days, but I'll commit it if I get half-decent wifi anywhere.
        Hide
        erickerickson Erick Erickson added a comment -

        Besting now.

        I'm assuming I should just apply your most recent patch (SOLR-9181-2) to a current master...

        Show
        erickerickson Erick Erickson added a comment - Besting now. I'm assuming I should just apply your most recent patch ( SOLR-9181 -2) to a current master...
        Hide
        erickerickson Erick Erickson added a comment -

        No luck, still getting:
        ERROR 0.32s | ZkStateReaderTest.testExternalCollectionWatchedNotWatched <<<
        [junit4] > Throwable #1: java.lang.NullPointerException
        [junit4] > at __randomizedtesting.SeedInfo.seed([D27D8A51F09E7A68:D9C67B7DA1C78CC1]:0)
        [junit4] > at org.apache.solr.cloud.overseer.ZkStateReaderTest.testExternalCollectionWatchedNotWatched(ZkStateReaderTest.java:167)
        [junit4] > at java.lang.Thread.run(Thread.java:745)

        Full log attached in a minute.

        Show
        erickerickson Erick Erickson added a comment - No luck, still getting: ERROR 0.32s | ZkStateReaderTest.testExternalCollectionWatchedNotWatched <<< [junit4] > Throwable #1: java.lang.NullPointerException [junit4] > at __randomizedtesting.SeedInfo.seed( [D27D8A51F09E7A68:D9C67B7DA1C78CC1] :0) [junit4] > at org.apache.solr.cloud.overseer.ZkStateReaderTest.testExternalCollectionWatchedNotWatched(ZkStateReaderTest.java:167) [junit4] > at java.lang.Thread.run(Thread.java:745) Full log attached in a minute.
        Hide
        romseygeek Alan Woodward added a comment -

        Think I've got it now - there was one case in forceUpdateCollection() where constructState() wasn't being called. I'm going to commit this to master and watch for the next few hours, and then backport.

        Show
        romseygeek Alan Woodward added a comment - Think I've got it now - there was one case in forceUpdateCollection() where constructState() wasn't being called. I'm going to commit this to master and watch for the next few hours, and then backport.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit be8d56ada69c885342bfae80d73f9f5b89c11504 in lucene-solr's branch refs/heads/master from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=be8d56a ]

        SOLR-9181: Fix race in constructState() and missing call in forceUpdateCollection()

        Show
        jira-bot ASF subversion and git services added a comment - Commit be8d56ada69c885342bfae80d73f9f5b89c11504 in lucene-solr's branch refs/heads/master from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=be8d56a ] SOLR-9181 : Fix race in constructState() and missing call in forceUpdateCollection()
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 60232cd028e41c427b686a6cab720ac3989ba289 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=60232cd ]

        SOLR-9181: Add some logging to ZkStateReader to try and debug test failures

        Show
        jira-bot ASF subversion and git services added a comment - Commit 60232cd028e41c427b686a6cab720ac3989ba289 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=60232cd ] SOLR-9181 : Add some logging to ZkStateReader to try and debug test failures
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 86d8d3a937802f47add8408bdd05117ec0fc2137 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86d8d3a ]

        SOLR-9181: More logging

        Show
        jira-bot ASF subversion and git services added a comment - Commit 86d8d3a937802f47add8408bdd05117ec0fc2137 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86d8d3a ] SOLR-9181 : More logging
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit fda3d8b7c2069d9cbd2445b397e9cceb38851be6 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fda3d8b ]

        SOLR-9181: Fix race in constructState() and missing call in forceUpdateCollection()

        Show
        jira-bot ASF subversion and git services added a comment - Commit fda3d8b7c2069d9cbd2445b397e9cceb38851be6 in lucene-solr's branch refs/heads/branch_6x from Alan Woodward [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fda3d8b ] SOLR-9181 : Fix race in constructState() and missing call in forceUpdateCollection()
        Hide
        mikemccand Michael McCandless added a comment -

        Bulk close resolved issues after 6.2.0 release.

        Show
        mikemccand Michael McCandless added a comment - Bulk close resolved issues after 6.2.0 release.

          People

          • Assignee:
            romseygeek Alan Woodward
            Reporter:
            romseygeek Alan Woodward
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development