<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Thank you Bernd for looking into this!</p>
    <br>
    <div class="moz-cite-prefix">On 11/7/17 11:42 PM, Bernd Eckenfels
      wrote:<br>
    </div>
    <blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Exchange Server">
      <!-- converted from text -->
      <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
      <div>
        <div id="x_compose-container" itemscope=""
          itemtype="https://schema.org/EmailMessage"
          style="direction:ltr">
          <span itemprop="creator" itemscope=""
            itemtype="https://schema.org/Organization"><span
              itemprop="name"></span></span>
          <div>
            <div style="direction:ltr">
              <div style="direction:ltr">Hello,</div>
              <div><br>
              </div>
              <div style="direction:ltr">There is already a property to
                set the cache size, would it be enough to re-purpose a
                cache size of 0 to turn it off?</div>
              <div><br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Currently, setting the cache size to 0 means that it is unbounded,
    so that the entries are removed from the cache only when they get
    expired.<br>
    <br>
    <blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
      type="cite">
      <div>
        <div id="x_compose-container" itemscope=""
          itemtype="https://schema.org/EmailMessage"
          style="direction:ltr">
          <div>
            <div style="direction:ltr">
              <div>
              </div>
              <div style="direction:ltr">Are there numbers to show when
                this is actually a problem? Is this only for 100% Cache
                misses?</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    We've seen dumps with lots of threads blocked waiting on the
    Cache.get()/put()/remove().<br>
    This is primarily due to the time spent in the cache cleaning
    routines (see
    sun.security.util.MemoryCache.emptyQueue()/expungeExpiredEntries()),
    which are executed inside the synchronization block.<br>
    This time is linear on the size of cache, but limiting the cache
    size doesn't always help either, as the amount of cleanup work also
    increases with a bounded cache.<br>
    <br>
    Allowing to avoid to use the cache removed this bottleneck and under
    certain conditions the throughput increased from 35 to 120 sessions
    per second.<br>
    <br>
    Please note that the proposed option javax.net.ssl.needCacheSessions
    will be true by default, so the default behavior will not change.<br>
    Only in specific situation, if it is proved that turning off the
    cache will improve performance, this option will be recommended to
    be set to false. <br>
    <br>
    <blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
      type="cite">
      <div>
        <div id="x_compose-container" itemscope=""
          itemtype="https://schema.org/EmailMessage"
          style="direction:ltr">
          <div>
            <div style="direction:ltr">
              <div style="direction:ltr"> Maybe the cache itself needs
                some optimizations?</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Certainly, it would be very good to optimize the cache
    implementation!<br>
    I've made a few attempts, but failed to achieve a significant
    improvement in different scenarios.<br>
    The complication is due to the two requirements: maintaining fixed
    cache capacity and maintaining FIFO order when removing the
    entries.  This makes it hard to use the concurrent data structures
    as is.<br>
    <br>
    Still, I'm totally for the cache optimization in JDK 10, if it is
    possible.<br>
    However, if it is done, it would not be probably backported to the
    earlier releases.<br>
    <br>
    And I'm going to propose to backport the proposed fix with the
    option to turn off the cache, as it will be useful for some
    currently running applications. <br>
    <br>
    With kind regards,<br>
    Ivan<br>
    <br>
    <blockquote
cite="mid:AM4PR08MB1219BF1297421C9FB201758EFF560@AM4PR08MB1219.eurprd08.prod.outlook.com"
      type="cite">
      <div>
        <div id="x_compose-container" itemscope=""
          itemtype="https://schema.org/EmailMessage"
          style="direction:ltr">
          <div>
            <div style="direction:ltr">
              <div style="direction:ltr"> (It is hard to imagine that a
                saved handshake does not compensate for hundreds of gets
                - especially if the current version still would generate
                a cache key)</div>
              <div><br>
              </div>
              <div style="direction:ltr">Gruss</div>
              <div style="direction:ltr">Bernd</div>
            </div>
            <div><br>
            </div>
            <div class="x_acompli_signature">
              <div>Gruss</div>
              <div>Bernd</div>
              <div>-- </div>
              <div><a moz-do-not-send="true" dir="ltr"
                  href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a></div>
            </div>
          </div>
        </div>
        <hr tabindex="-1" style="display:inline-block; width:98%">
        <div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
            color="#000000" face="Calibri, sans-serif"><b>From:</b>
            security-dev <a class="moz-txt-link-rfc2396E" href="mailto:security-dev-bounces@openjdk.java.net"><security-dev-bounces@openjdk.java.net></a>
            on behalf of Ivan Gerasimov
            <a class="moz-txt-link-rfc2396E" href="mailto:ivan.gerasimov@oracle.com"><ivan.gerasimov@oracle.com></a><br>
            <b>Sent:</b> Wednesday, November 8, 2017 3:24:54 AM<br>
            <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a><br>
            <b>Subject:</b> [10] RFR : 8186628 : SSL session cache can
            cause a scalability bottleneck</font>
          <div> </div>
        </div>
      </div>
      <font size="2"><span style="font-size:10pt;">
          <div class="PlainText">Hello everybody!<br>
            <br>
            The class sun.security.ssl.SSLSessionContextImpl maintains
            caches for <br>
            the sessions reuse.<br>
            Access to the cache from threads is serialized.<br>
            It was reported that under heavy load the time of waiting
            for the turn <br>
            to access the synchronized methods outweighs the time of
            creating a new <br>
            session.<br>
            <br>
            It is proposed to introduce a flag that will allow to avoid
            using the <br>
            cache altogether.<br>
            Would you please help review the proposed fix?<br>
            <br>
            BUGURL: <a moz-do-not-send="true"
              href="https://bugs.openjdk.java.net/browse/JDK-8186628">https://bugs.openjdk.java.net/browse/JDK-8186628</a><br>
            WEBREV: <a moz-do-not-send="true"
              href="http://cr.openjdk.java.net/%7Eigerasim/8186628/00/webrev/">http://cr.openjdk.java.net/~igerasim/8186628/00/webrev/</a><br>
            <br>
            -- <br>
            With kind regards,<br>
            Ivan Gerasimov<br>
            <br>
          </div>
        </span></font>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
With kind regards,
Ivan Gerasimov</pre>
  </body>
</html>