<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 12pt; color: #000000'>Okay. I don't have a problem with the openssl part of things, just didn't want to see effort expended on APR, as it was mentioned in a different e-mail thread.<br><br>Thanks Jason.<br><br>Andy<br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Jason Greene" <jason.greene@redhat.com><br><b>To: </b>"Andrig T. Miller" <anmiller@redhat.com><br><b>Cc: </b>"undertow-dev" <undertow-dev@lists.jboss.org><br><b>Sent: </b>Monday, June 15, 2015 12:01:42 PM<br><b>Subject: </b>Re: [undertow-dev] Question about APR based connector in Undertow<br><br>Oh and I forgot to mention that IMO I think we should prefer contributing optimizations back to the JDK if at all possible, and if not it should be the long term goal.<div class=""><br class=""><div><blockquote class=""><div class="">On Jun 15, 2015, at 12:51 PM, Jason Greene <<a href="mailto:jason.greene@redhat.com" class="" target="_blank">jason.greene@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word;" class=""><div class="">We have no intention to do an APR connector. We have had some occasional discussions about whether or not we will need openssl support. Perhaps that’s where it is coming from?</div><div class=""><br class=""></div><div class="">JFC and Remy had some numbers on JBossWeb that showed poor perf on JSSE vs OpenSSL using APR. It’s somewhat apples vs oranges but looking at the JSSE impl we do see a number of inefficiencies. As an example JSSE seems to do a lot of copying (e.g. anything in a buffer becomes many byte arrays which gets copied again to a buffer). We also see that SHA support on intel is still in a big chunk of java code, and not intrinsic, wheras on openssl its optimized assembler. The new AES GCM ciphers are also known to be slow, but Andrew Haley mentioned that he is in the process of optimizing those. All of this is of course, anecdotal, and until we spend some cycles doing a more apples to apples test I don’t think we can conclude this is a necessary direction.</div><div class=""><br class=""></div><div class="">The other case where this might matter is how we find a way to support HTTP2. HTTP2 requires that we support the ALPN extension to TLS. Unfortunately JSSE has no support for it, and has been rather slow to implement, and it has to come into 9 before there is any possibility of a backport to 8:</div><div class=""><br class=""></div><div class=""><a href="http://openjdk.java.net/jeps/244" class="" target="_blank">http://openjdk.java.net/jeps/244</a></div><div class=""><a href="https://bugs.openjdk.java.net/browse/JDK-8051498" class="" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8051498</a></div><div class=""><br class=""></div><div class="">In the meantime we have been reusing a hack that the Jetty guys are maintaining as a separate project, and it requires using bootclasspath to replace core JSSE classes. These hacks are not z-stream compatible, so any JDK bug fix update can break the hack (and this has already happened about 2-3 times).</div><div class=""><br class=""></div><div class="">So on that perspective we have three options:</div><div class=""><br class=""></div><div class="">1) Red Hat does a Red Hat only hack for IcedTea distributions (not sure if the JDK team would be willing to maintain it or not, would have to ask)</div><div class="">2) Introduce openssl support, which supports ALPN</div><div class="">3) Wait for JSSE, and live with the hack (warning people appropriately)</div><div class=""><br class=""></div><div class="">At this point, I don’t think we can commit to having anything for the WildFly 10 schedule, unless the performance difference really mandates such a thing, and then we might have to shuffle things around. </div><br class=""><div class=""><blockquote class=""><div class="">On Jun 15, 2015, at 12:29 PM, Andrig T. Miller <<a href="mailto:anmiller@redhat.com" class="" target="_blank">anmiller@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-family: arial,helvetica,sans-serif; font-size: 12pt;" class="">I am hearing that some work is being put into an APR based connector for Undertow. I am wondering why we are doing this?<br class=""><br class="">Based on my own testing, and testing the performance team has done with AS 7.x/EAP 6.x/Wildfly, I see no performance reason to do it, and it creates more work for getting product out the door, and maintaining product.<br class=""><br class="">We have found that the APR based connector can exhibit very poor scalability, and consume large amounts of CPU resources when in a network environment that is having problems (TCP resets, dropped and retransmitted packets, etc.).<br class=""><br class="">In this situation, especially where we see these poor network conditions, the APR connector spends a lot of its time managing the connection data structure. That data structure is a ring (doubly linked list with head and tail pointing at each other, which you already know). That ring is sequentially searched for the socket to remove and it locks all access with a mutex before it does this. This causes both a CPU consumption issue, as it sequentially walks the linked list, and a blocking problem. When we first discovered this, I went into the code to see how easy it would be to change it. I don't think this is a simple fix, and since APR is the underpinning of other things, like Apache HTTPD, not a trivial thing to get accepted by the community either. This spurred us to look at the NIO2 based connector, which at the time was unsupported, and it didn't exhibit any of this poor behavior. That's what spurred the effort to move the NIO2 based connector to be fully supported.<br class=""><br class="">In the absence of poor network conditions, the APR connector behaves and performs well, but in the presence of poor network conditions its not good. So, with a viable alternative, which Undertow provides out of the box with its XNIO based architecture, there simple seems no good reason to do with for Undertow.<br class=""><br class="">Thanks.<br class=""><br class="">--<span class="Apple-converted-space"> </span><br class=""><div class=""><span class=""></span>Andrig (Andy) T. Miller<br class="">Global Platform Director, JBoss Middleware<br class="">Red Hat, Inc.<span class=""></span><br class=""></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline ! important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline ! important;" class="">undertow-dev mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><a href="mailto:undertow-dev@lists.jboss.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="" target="_blank">undertow-dev@lists.jboss.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a></div></blockquote></div><br class=""><div class="">
--<br class="">Jason T. Greene<br class="">WildFly Lead / JBoss EAP Platform Architect<br class="">JBoss, a division of Red Hat
</div>
<br class=""></div>_______________________________________________<br class="">undertow-dev mailing list<br class=""><a href="mailto:undertow-dev@lists.jboss.org" class="" target="_blank">undertow-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/undertow-dev</div></blockquote></div><br class=""><div class="">
--<br class="">Jason T. Greene<br class="">WildFly Lead / JBoss EAP Platform Architect<br class="">JBoss, a division of Red Hat
</div>
<br class=""></div></blockquote><br></div></body></html>