It appears as though there might be a contention issue if multiple ssl endoints are activated for the first time simultaneously. If I warm up the end points sequentially before running a the parallel test suite the high CPU does not occur.
I am still investigating and will try and prepare a simple test case for further comment Sent from my iPhone On Jan 18, 2011, at 13:23, [email protected] wrote: > Hi, > > I just noticed the 2.3.1 source code for CXFJettySslSocketConnector > has incorrect javadocs > > /** > * This class extends the Jetty SslSocketConnector, which allows > * us to configure it more in tune with the JSSE, using KeyManagers > * and TrustManagers. Also, Jetty version 6.1.3 has a bug where > * the Trust store needs a password. > */ > > Might need to clean that up as obviously you just changed this in > 2.3.0 (I think I saw a jira that stated that the async nio ssl support > for jetty was being introduced in 2.3.0) > > It no longer extends SslSocketConnector > But extends SslSelectChannelConnector > > On Tue, Jan 18, 2011 at 11:31 AM, <[email protected]> wrote: >> Forget my last comment - a misunderstanding. The name of the class >> does not include SelectChannel so I assumed (wrongly) it was the >> non-blocking kind. Jetty itself has two ssl connectors: >> SslSocketConnector >> SslSelectChannelConnector >> >> And by naming the CXF connector CXFJettySslSocketConnector it looks >> like it might be the SslSocketConnector version (the blocking non-nio >> one) >> >> My bad >> >> >> On Tue, Jan 18, 2011 at 11:17 AM, Jason Pell <[email protected]> wrote: >>> I notice that the jetty ssl connector used is the blocking kind not the NIO >>> impl. Any reason for this? The non ssl jetty connector in cxf uses nio >>> >>> Sent from my iPhone >>> >>> On Jan 18, 2011, at 10:04, Jason Pell <[email protected]> wrote: >>> >>>> So this would be an eclipse jetty forum question then... >>>> >>>> Sent from my iPhone >>>> >>>> On Jan 18, 2011, at 9:46, Daniel Kulp <[email protected]> wrote: >>>> >>>>> On Monday 17 January 2011 5:35:39 pm Jason Pell wrote: >>>>>> Cxf 2.3.1 - I am using soapui as client - what's the best way to "warm >>>>>> up" >>>>>> the ssl before running the test suite in soapui? >>>>> >>>>> I don't think you can, really. Maybe run it in soap UI first for a minute >>>>> before actually running the test. Don't really know. >>>>> >>>>> >>>>>> Is a single sslengine created per jetty port or per jaxws service ? >>>>> >>>>> On the server side, it would be per port, I think. It MAY be per >>>>> connection >>>>> on the port (not per service), but I'm not really sure. That's down in >>>>> Jetty >>>>> someplace. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Jan 18, 2011, at 7:11, Daniel Kulp <[email protected]> wrote: >>>>>>> On Sunday 16 January 2011 10:09:56 pm Jason Pell wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> As soon as I enable SSL and execute my soapui test suite I get cpu to >>>>>>>> %95. I have profiled the application and can see that this is caused >>>>>>>> by the >>>>>>>> >>>>>>>> com.sun.net.ssl.internal.ssl.ServerHandshaker.chooseCipherSuite >>>>>>>> (further down in the stack BigInteger is responsible for most of the >>>>>>>> CPU). >>>>>>>> >>>>>>>> I have configured the following server config: >>>>>>>> >>>>>>>> <sec:cipherSuitesFilter> >>>>>>>> >>>>>>>> <sec:include>.*_EXPORT_.*</sec:include> >>>>>>>> <sec:include>.*_EXPORT1024_.*</sec:include> >>>>>>>> <sec:include>.*_WITH_DES_.*</sec:include> >>>>>>>> <sec:include>.*_WITH_NULL_.*</sec:include> >>>>>>>> <sec:include>.*_128_.*</sec:include> >>>>>>>> <sec:exclude>.*_DH_anon_.*</sec:exclude> >>>>>>>> >>>>>>>> </sec:cipherSuitesFilter> >>>>>>>> >>>>>>>> I am using the self signed cert provided in CXF examples, but I am not >>>>>>>> using a trust store on the server side. >>>>>>>> >>>>>>>> Does the SSL setup take a while to warm up in a JVM? Reason I ask is >>>>>>>> I have managed to get acceptable results from the same soapui >>>>>>>> integration test suite after a few of runs (not deterministic, >>>>>>>> sometimes its the second run, sometimes the 5, and really confusing is >>>>>>>> sometimes it can go back to cpu bound even after a few runs). The >>>>>>>> first 1 or 3 runs fail with EOF exceptions and such and then suddenly >>>>>>>> I am back to 22 seconds total for the test suite which is in the >>>>>>>> ballpark. >>>>>>>> >>>>>>>> I am not entirely sure how to go about resolving this because 90% CPU >>>>>>>> on a single CPU machine and 180% (approx) on a dual CPU machine are >>>>>>>> all in the SSL core jre code. >>>>>>> >>>>>>> Setting up an SSL/TLS connection IS extremely cpu intensive and time >>>>>>> consuming. Once setup, it's not bad and is about 80% the speed of a >>>>>>> non- encrypted connection. >>>>>>> >>>>>>> Couple questions: >>>>>>> 1) What version of CXF are you using? There was a bug in some older >>>>>>> versions that prevented keep-alives from working properly so a new >>>>>>> connection had to be established for each request. >>>>>>> >>>>>>> 2) Are you creating a new proxy for each request? If so, don't do that. >>>>>>> Re- use them. Otherwise, a new connection is made per proxy. >>>>> >>>>> -- >>>>> Daniel Kulp >>>>> [email protected] >>>>> http://dankulp.com/blog >>> >>
