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 >> >
