3 Replies Latest reply on Feb 13, 2009 7:45 PM by Greybird-Oracle

    Infinite cycle in SharedEvictor.getNextIN()

      I'm using JE 3.3.62. Breakpoint on the line 235 (SharedEvictor.java), debugger shows the following data.

      initialIndex = 2
      nSubjects = 1
      subject = {com.sleepycat.je.evictor.SharedEvictor$Subject@326}
      ((Subject)subject).env = {com.sleepycat.je.dbi.EnvironmentImpl@343}
      ((Subject)subject).ins = {com.sleepycat.je.dbi.INList@328}
      ((Subject)subject).iter = {com.sleepycat.je.dbi.INList$Iter@330}
      ((Subject)subject).size = 28
      ((Subject)subject).remaining = 280
      subject.ins = {com.sleepycat.je.dbi.INList@328}
      subject.iter = {com.sleepycat.je.dbi.INList$Iter@330}
      smallestSize = 28
      subject.remaining = 280
      rotationIndex = 1

      SharedEvictor .isEvictionAllowed(subject) returns false.

      treeMemoryUsage = {java.util.concurrent.atomic.AtomicLong@435}"511047"
      minTreeMemoryUsage = 512000

      Once it occurred it repeats each time I start my application.
        • 1. Re: Infinite cycle in SharedEvictor.getNextIN()
          Hi Vyacheslav,

          It turns out that this problem was reported earlier, although in a slightly different context:

          Infinite loop in getNextIN()

          In that case, the problem occurred only after an OutOfMemoryError and only when configuring direct NIO (LOG_USE_NIO and LOG_DIRECT_NIO), which is deprecated.

          Do you see any exceptions before the problem occurs?

          We have a fix for this. However, when this was reported earlier we could not find a case where it could occur without a fatal error (such as OutOfMemoryError) preceding it, so we did not apply the fix to the JE 3.3 release. The fact that the problem has occurred for you means that we misjudged the scope of the problem.

          It looks like it can also occur under certain conditions after an environment using the shared cache is closed, and the remaining environments using the shared cache have no evictable nodes, and the cache overflows.

          Please send me email and I'll give you a JE 3.3 jar file with a fix to try. I'm mark.hayes at the obvious (oracle.com).

          • 2. Re: Infinite cycle in SharedEvictor.getNextIN()
            Mark, thanks for the response.

            No, I don't use direct NIO and I didn't see any exceptions before. My application was opening an environment with WriteNoSync = true which was not closed properly. As far as I understand, it tried to open an existing database and doing that it got internally into the infinite cycle. This environment shares cache with another one which is configured by default with WriteNoSync = false.

            Actually, I've already found a workaround, I've set the lruOnly = true, and the application started successfully.

            • 3. Re: Infinite cycle in SharedEvictor.getNextIN()
              Thanks for the information and for being willing to try the fix I sent you.

              I'm afraid that setting lruOnly = true is simply changing the timing of eviction a little bit. The problem is very much timing dependent. If you were to change the cache size slightly, that might also make the problem go away. But I'm afraid it is still there and could occur again.

              For others who may be interested: This occurs when using EnvironmentConfig.setSharedCache(true) and is very timing dependent. We will be putting a fix for it into the next JE 3.3 release.

              1 person found this helpful