@Test
  public void testBug37500() throws Exception {
    // put 440 bytes , it will go in oplog1
    region.put(KEY1, new byte[420]);

    // put another 440 bytes ,it will go in oplog1
    region.put(KEY2, new byte[420]);

    // put 440 bytes , switching will be caused, it will go in oplog2 (value
    // size increased to 432 as key wont be written to disk for UPDATE)
    region.put(KEY1, new byte[432]);

    // put 440 bytes , it will go in oplog2
    region.put(KEY1, new byte[432]);

    observer.notifyRoller();

    // put 440 bytes , this will try further switching
    region.put(KEY2, new byte[432]);
  }
This test does the following: <br>
1. Create a disk-region with following configurations:
<ul>
<li>dirSize = 2000 bytes
<li>maxOplogSize = 500 bytes
<li>rolling = true
<li>syncMode = true
<li>approx size on disk for operations = 440 bytes
</ul>

<p>
2.Make Roller go into WAIT state via CacheObserverAdapter.beforeGoingToCompact callback

<p>
3.Put 440 bytes , it will go in oplog1

<p>
4.Put another 440 bytes ,it will go in oplog1

<p>
5.Put 440 bytes , switching will be caused, it will go in oplog2, Roller will remained blocked
(step 2)

<p>
6.Put 440 bytes , it will go in oplog2, oplog2 will now be full

<p>
7.Notify the Roller and put 440 bytes , this will try further switching. The put will fail with
exception due to bug 37500. The put thread takes an entry level lock for entry2 ( the one with
KEY2) and tries to write to disk but there is no free space left, so it goes into wait,
expecting Roller to free up the space. The roller, which has now been notified to run, tries to
roll entry2 for which it seeks entry level lock which has been acquired by put-thread. So the
put thread eventually comes out of the wait with DiskAccessException

<p>
Another scenario for this bug is, once the disk space was getting exhausted , the entry
operation threads which had already taken a lock on Entry got stuck trying to seek the Oplog
Lock. The switching thread had acquired the Oplog.lock & was waiting for the roller thread to
free disk space. Since the roller needed to acquire Entry lock to roll, it was unable to do so
because of entry operation threads. This would cause the entry operation threads to get
DiskAccessException after completing the stipulated wait. The Roller was able to free space
only when it has rolled all the relevant entries which could happen only when the entry
operation threads released the entry lock after getting DiskAccessException.
geode-core/src/integrationTest/java/org/apache/geode/internal/cache/DiskAccessExceptionDisablesServerRegressionTest.java