Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-7188

IllegalStateException in NRTCachingDirectory.listAll

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.2.1
    • Fix Version/s: 6.1, 6.0.1, 5.5.1, master (7.0)
    • Component/s: None
    • Labels:
      None
    • Environment:

      Production, QA

    • Lucene Fields:
      New

      Description

      Hey,
      we are getting IllegalStateException in 2 different circumstances. The first one is on Status calls:

      ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: Error handling 'status' action 
      	at org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
      	at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
      	at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
      	at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
      	at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
      	at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
      	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
      	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
      	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
      	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
      	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
      	at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
      	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
      	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
      	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
      	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
      	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
      	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
      	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
      	at org.eclipse.jetty.server.Server.handle(Server.java:497)
      	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
      	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
      	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
      	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
      	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
      	at java.lang.Thread.run(Unknown Source)
      Caused by: java.lang.IllegalStateException: file: MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, _9w_Lucene50_0.doc, _9w_Lucene50_0.pos, _9w_Lucene50_0.tim, _9w_Lucene50_0.tip, _9x.fdt, _9x.fdx, _9x.fnm, _9x.nvd, _9x.nvm, _9x.si, _9x_Lucene50_0.doc, _9x_Lucene50_0.pos, _9x_Lucene50_0.tim, _9x_Lucene50_0.tip, _9y.fdt, _9y.fdx, _9y.fnm, _9y.nvd, _9y.nvm, _9y.si, _9y_Lucene50_0.doc, _9y_Lucene50_0.pos, _9y_Lucene50_0.tim, _9y_Lucene50_0.tip, _9z.fdt, _9z.fdx, _9z.fnm, _9z.nvd, _9z.nvm, _9z.si, _9z_Lucene50_0.doc, _9z_Lucene50_0.pos, _9z_Lucene50_0.tim, _9z_Lucene50_0.tip, _a0.nvd, _a0_Lucene50_0.pos]
      	at org.apache.lucene.store.NRTCachingDirectory.listAll(NRTCachingDirectory.java:103)
      	at org.apache.solr.core.DirectoryFactory.sizeOfDirectory(DirectoryFactory.java:208)
      	at org.apache.solr.handler.admin.CoreAdminHandler.getIndexSize(CoreAdminHandler.java:1195)
      	at org.apache.solr.handler.admin.CoreAdminHandler.getCoreStatus(CoreAdminHandler.java:1173)
      	at org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:736)
      	... 30 more
      

      and the second one is on some kind of replication related request:

      null:java.lang.IllegalStateException: file: MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica3\data\index lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both in delegate and in cache: cache=[_g3x.si, _g3x.fdx, _g3x.fdt],delegate=[pending_segments_eia, segments_ei9, write.lock, _g3q.fdt, _g3q.fdx, _g3q.fnm, _g3q.nvd, _g3q.nvm, _g3q.si, _g3q_6.liv, _g3q_7.liv, _g3q_Lucene50_0.doc, _g3q_Lucene50_0.pos, _g3q_Lucene50_0.tim, _g3q_Lucene50_0.tip, _g3r.fdt, _g3r.fdx, _g3r.fnm, _g3r.nvd, _g3r.nvm, _g3r.si, _g3r_Lucene50_0.doc, _g3r_Lucene50_0.pos, _g3r_Lucene50_0.tim, _g3r_Lucene50_0.tip, _g3s.fdt, _g3s.fdx, _g3s.fnm, _g3s.nvd, _g3s.nvm, _g3s.si, _g3s_Lucene50_0.doc, _g3s_Lucene50_0.pos, _g3s_Lucene50_0.tim, _g3s_Lucene50_0.tip, _g3t.fdt, _g3t.fdx, _g3t.fnm, _g3t.nvd, _g3t.nvm, _g3t.si, _g3t_Lucene50_0.doc, _g3t_Lucene50_0.pos, _g3t_Lucene50_0.tim, _g3t_Lucene50_0.tip, _g3u.fdt, _g3u.fdx, _g3u.fnm, _g3u.nvd, _g3u.nvm, _g3u.si, _g3u_Lucene50_0.doc, _g3u_Lucene50_0.pos, _g3u_Lucene50_0.tim, _g3u_Lucene50_0.tip, _g3v.fdt, _g3v.fdx, _g3v.fnm, _g3v.nvd, _g3v.nvm, _g3v.si, _g3v_Lucene50_0.doc, _g3v_Lucene50_0.pos, _g3v_Lucene50_0.tim, _g3v_Lucene50_0.tip, _g3w.fdt, _g3w.fdx, _g3w.fnm, _g3w.nvd, _g3w.nvm, _g3w.si, _g3w_Lucene50_0.doc, _g3w_Lucene50_0.pos, _g3w_Lucene50_0.tim, _g3w_Lucene50_0.tip, _g3x.fnm, _g3x.nvd, _g3x.nvm, _g3x.si, _g3x_Lucene50_0.doc, _g3x_Lucene50_0.pos, _g3x_Lucene50_0.tim, _g3x_Lucene50_0.tip]
      	at org.apache.lucene.store.NRTCachingDirectory.listAll(NRTCachingDirectory.java:103)
      	at org.apache.solr.core.DirectoryFactory.sizeOfDirectory(DirectoryFactory.java:208)
      	at org.apache.solr.handler.ReplicationHandler.getIndexSize(ReplicationHandler.java:705)
      	at org.apache.solr.handler.ReplicationHandler.getStatistics(ReplicationHandler.java:741)
      	at org.apache.solr.handler.admin.SolrInfoMBeanHandler.addMBean(SolrInfoMBeanHandler.java:165)
      	at org.apache.solr.handler.admin.SolrInfoMBeanHandler.getMBeanInfo(SolrInfoMBeanHandler.java:135)
      	at org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:66)
      	at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
      	at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
      	at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
      	at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
      	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
      	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
      	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
      	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
      	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
      	at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
      	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
      	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
      	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
      	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
      	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
      	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
      	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
      	at org.eclipse.jetty.server.Server.handle(Server.java:497)
      	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
      	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
      	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
      	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
      	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
      	at java.lang.Thread.run(Unknown Source)
      

      The Environment is a 3 node SOLR Cloud setup running SOLR 5.2.1.

      when looking at the code:

      public synchronized String[] listAll() throws IOException {
          final Set<String> files = new HashSet<>();
          for(String f : cache.listAll()) {
            files.add(f);
          }
          for(String f : in.listAll()) {
            if (!files.add(f)) {
              throw new IllegalStateException("file: " + in + " appears both in delegate and in cache: " +
                                              "cache=" + Arrays.toString(cache.listAll()) + ",delegate=" + Arrays.toString(in.listAll()));
            }
          }
          return files.toArray(new String[files.size()]);
        }
      

      i can see that the exception is thrown because the file exists in both the cache and the file system.
      this however doesn't make sense to me, because a file that is in cache will always be in the file system as well.

      1. LUCENE-7188.patch
        0.9 kB
        Yonik Seeley

        Issue Links

          Activity

          Hide
          dsmiley David Smiley added a comment -

          Robert Muir in LUCENE-5945 (cutover to Path API) I see you committed a change to NRTCachingDirectory that does not appear related to that issue. That was a huge patch so I can see how some W.I.P. might have gotten in there by accident. The code here used to not throw this exception reported by this issue. Can you explain why the code was changed? git hash 3eb66fb19ca2aa3d9dce53661f3233b6c9d3f974

          Show
          dsmiley David Smiley added a comment - Robert Muir in LUCENE-5945 (cutover to Path API) I see you committed a change to NRTCachingDirectory that does not appear related to that issue. That was a huge patch so I can see how some W.I.P. might have gotten in there by accident. The code here used to not throw this exception reported by this issue. Can you explain why the code was changed? git hash 3eb66fb19ca2aa3d9dce53661f3233b6c9d3f974
          Hide
          rcmuir Robert Muir added a comment -

          Stuff is broken if NRTCachingDirectory thinks a file is both cached in ram and on disk, the file is "in two places": The safety check is correct, it was no mistake or "WIP". The issue about "mkdirs has not yet been called" becomes impossible due to the changes on that issue so there was no reason to have this as only an assert.

          Show
          rcmuir Robert Muir added a comment - Stuff is broken if NRTCachingDirectory thinks a file is both cached in ram and on disk, the file is "in two places": The safety check is correct, it was no mistake or "WIP". The issue about "mkdirs has not yet been called" becomes impossible due to the changes on that issue so there was no reason to have this as only an assert.
          Hide
          dsmiley David Smiley added a comment -

          (I converted this to a a Lucene issue in JIRA)

          Stuff is broken if NRTCachingDirectory thinks a file is both cached in ram and on disk, the file is "in two places"

          Makes sense, though the circumstance seems benign for listAll(). It appears there is a race condition between listAll() and unCache(). Notice listAll() syncs on "this". unCache only synchronizes on "this" to delete the file form the cache after it has already written to the real backing directory.

          it was no mistake or "WIP"

          Next time, unless it's a trivial change (e.g. formatting, docs, ...) please create separate issues for changes that aren't within the scope of the issue you're including it on. Possibly as a required-by if there is a dependency.

          Show
          dsmiley David Smiley added a comment - (I converted this to a a Lucene issue in JIRA) Stuff is broken if NRTCachingDirectory thinks a file is both cached in ram and on disk, the file is "in two places" Makes sense, though the circumstance seems benign for listAll(). It appears there is a race condition between listAll() and unCache(). Notice listAll() syncs on "this". unCache only synchronizes on "this" to delete the file form the cache after it has already written to the real backing directory. it was no mistake or "WIP" Next time, unless it's a trivial change (e.g. formatting, docs, ...) please create separate issues for changes that aren't within the scope of the issue you're including it on. Possibly as a required-by if there is a dependency.
          Hide
          rcmuir Robert Muir added a comment -

          fuck that. This is the correct change: since the leniency around directory creation was removed in that very issue, it was the correct place to remove the leniency.

          Show
          rcmuir Robert Muir added a comment - fuck that. This is the correct change: since the leniency around directory creation was removed in that very issue, it was the correct place to remove the leniency.
          Hide
          dsmiley David Smiley added a comment -

          Wow. The F-that part was uncalled for; I wish you could keep your cool and respectively disagree with me. What do you think of my analysis of the bug?

          Show
          dsmiley David Smiley added a comment - Wow. The F-that part was uncalled for; I wish you could keep your cool and respectively disagree with me. What do you think of my analysis of the bug?
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          I've also seen this exception/bug crop up when running chaos monkey tests.

          David, you are correct. LUCENE-5945 caused this bug by adding the exception without additional needed synchronization. It can be fixed by either removing the exception or adding the additional synchronization.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - I've also seen this exception/bug crop up when running chaos monkey tests. David, you are correct. LUCENE-5945 caused this bug by adding the exception without additional needed synchronization. It can be fixed by either removing the exception or adding the additional synchronization.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Removing the current check makes the most sense. It makes less sense to fail this single read-only method (and not fail any others) if we detect something has gone wrong.

          If there is a desire for more sanity checking (and we can figure out a coherent behavior for when something bad is detected) then that can be handled in a new JIRA issue.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Removing the current check makes the most sense. It makes less sense to fail this single read-only method (and not fail any others) if we detect something has gone wrong. If there is a desire for more sanity checking (and we can figure out a coherent behavior for when something bad is detected) then that can be handled in a new JIRA issue.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit c1a70f31a605ac254c4c5d556444659aaa3201e5 in lucene-solr's branch refs/heads/master from Yonik Seeley
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c1a70f3 ]

          LUCENE-7188: remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException

          Show
          jira-bot ASF subversion and git services added a comment - Commit c1a70f31a605ac254c4c5d556444659aaa3201e5 in lucene-solr's branch refs/heads/master from Yonik Seeley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c1a70f3 ] LUCENE-7188 : remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit ace13b5728df97664ae21e617de9e6ae3706657e in lucene-solr's branch refs/heads/branch_6x from Yonik Seeley
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ace13b5 ]

          LUCENE-7188: remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException

          Show
          jira-bot ASF subversion and git services added a comment - Commit ace13b5728df97664ae21e617de9e6ae3706657e in lucene-solr's branch refs/heads/branch_6x from Yonik Seeley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ace13b5 ] LUCENE-7188 : remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit a49b748b58b31af51d06c1d360777d679285e8fd in lucene-solr's branch refs/heads/branch_5_5 from Yonik Seeley
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a49b748 ]

          LUCENE-7188: remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException

          Show
          jira-bot ASF subversion and git services added a comment - Commit a49b748b58b31af51d06c1d360777d679285e8fd in lucene-solr's branch refs/heads/branch_5_5 from Yonik Seeley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a49b748 ] LUCENE-7188 : remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException
          Hide
          dsmiley David Smiley added a comment -

          I think you're right Yonik. At first I was about to disagree to write that we should fix this by having listAll hold both locks, but I now think there's no point to it. We know exactly why listAll can momentarily find a file in both places, and it's okay. It's a race condition of no consequence. The file is still there to return from listAll; we know what to do. There are other race conditions of no consequences too that have comments "// Another thread beat us...".

          listAll can use Collections.addAll like so to replace two for loops:

          Collections.addAll(files, cache.listAll());
          Collections.addAll(files, in.listAll());
          

          I'm unsure why listAll needs any synchronization at all, for that matter. It's an omission that the Directory API says nothing about thread-safety; nevertheless I assume instances should be thread-safe.

          Everything below could be its own JIRA issue:

          Can we remove all synchronization on "this" (not substituting it with anything else either) and change methods to not use/depend on calling cache.fileNameExists()? Using that method as a guard is, I think, what led to synchronizing on "this" in the first place. For example, fileLength could be rewritten to this:

          public long fileLength(String name) throws IOException {
              try {
                return cache.fileLength(name);
              } catch (FileNotFoundException | NoSuchFileException e) {
                return in.fileLength(name);
              }
            }
          

          – and likewise for deleteFile and openInput. Then the synchronized(this) inside unCache can be removed too, leaving none left.

          unCache calls cache.fileNameExists() too but I think it's okay since it merely exits early.

          unCache's use of uncacheLock could probably be changed to be a per-file name lock instead of one shared lock for the directory instance since it only needs to lock per file name it's un-caching. Although I'm not sure it's worth the complexity bothering.

          Show
          dsmiley David Smiley added a comment - I think you're right Yonik. At first I was about to disagree to write that we should fix this by having listAll hold both locks, but I now think there's no point to it. We know exactly why listAll can momentarily find a file in both places, and it's okay. It's a race condition of no consequence. The file is still there to return from listAll; we know what to do. There are other race conditions of no consequences too that have comments "// Another thread beat us..." . listAll can use Collections.addAll like so to replace two for loops: Collections.addAll(files, cache.listAll()); Collections.addAll(files, in.listAll()); I'm unsure why listAll needs any synchronization at all, for that matter. It's an omission that the Directory API says nothing about thread-safety; nevertheless I assume instances should be thread-safe. Everything below could be its own JIRA issue: Can we remove all synchronization on "this" (not substituting it with anything else either) and change methods to not use/depend on calling cache.fileNameExists() ? Using that method as a guard is, I think, what led to synchronizing on "this" in the first place. For example, fileLength could be rewritten to this: public long fileLength( String name) throws IOException { try { return cache.fileLength(name); } catch (FileNotFoundException | NoSuchFileException e) { return in.fileLength(name); } } – and likewise for deleteFile and openInput. Then the synchronized(this) inside unCache can be removed too, leaving none left. unCache calls cache.fileNameExists() too but I think it's okay since it merely exits early. unCache's use of uncacheLock could probably be changed to be a per-file name lock instead of one shared lock for the directory instance since it only needs to lock per file name it's un-caching. Although I'm not sure it's worth the complexity bothering.
          Hide
          hossman Hoss Man added a comment -

          Manually correcting fixVersion per Step #S5 of LUCENE-7271

          Show
          hossman Hoss Man added a comment - Manually correcting fixVersion per Step #S5 of LUCENE-7271
          Hide
          steve_rowe Steve Rowe added a comment -

          Reopening to backport to 6.0.1.

          Show
          steve_rowe Steve Rowe added a comment - Reopening to backport to 6.0.1.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit b31c39812ec0e6017afe20568bb21d44aef2fa78 in lucene-solr's branch refs/heads/branch_6_0 from Yonik Seeley
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b31c398 ]

          LUCENE-7188: remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException

          Show
          jira-bot ASF subversion and git services added a comment - Commit b31c39812ec0e6017afe20568bb21d44aef2fa78 in lucene-solr's branch refs/heads/branch_6_0 from Yonik Seeley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b31c398 ] LUCENE-7188 : remove incorrect sanity check in NRTCachingDirectory.listAll() that throws IllegalStateException
          Hide
          steve_rowe Steve Rowe added a comment -

          Bulk close issues included in the 6.0.1 release.

          Show
          steve_rowe Steve Rowe added a comment - Bulk close issues included in the 6.0.1 release.

            People

            • Assignee:
              yseeley@gmail.com Yonik Seeley
              Reporter:
              mcalice Semion Mc Alice
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development