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 >
