On Monday 17 January 2011 9:23:11 pm [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
Thanks. I updated the javadocs. Dan > > 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 -- Daniel Kulp [email protected] http://dankulp.com/blog
