Looking forward to have this in the next release 2.0.5 or 2.1 :)
On Tue, Mar 4, 2008 at 11:55 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > Willem, > > The issue is that they CAN be modified after that. One popular > modification is to grab the EndpointInfo out of it and change the > address. Other things like adding interceptors to the BindingInfo, > changing properties on the service (like to enable schema validation), > etc... are all modifications that affect the servicemodel. > > Databinding is "less" of an issue, but still one. For example, the > databinding has an "mtomThreshold" and a namespaceMap that can be set > programatically. > > In both of those cases, a modification should only affect the proxy on > which the modification is made. Thus, the servicemodel would need a > full "clone", which may not be easy to do. It's certainly a lot more > code to add. > > That said, I don't think it's a bad idea at all. On the contrary, it's a > good idea. It's just a bit of work. > > Dan > > > On Tuesday 04 March 2008, Willem Jiang wrote: > > Hi Dan, > > > > I think we could cache the ServiceInfo object and DataBinding object > > which will take lots of time to be created and can't be modified after > > that. Any thought? > > > > Willem > > > > Daniel Kulp wrote: > > > On Tuesday 04 March 2008, Christopher Cheng wrote: > > >> I haven't read the codes of Axis, but I have been using it for 2 > > >> years and it doesn't have this problem. > > >> Having an overhead for 5-8 seconds is not an option for a > > >> production system in term of performance > > >> > > >> What you are saying is that all the services must implement > > >> Clonable interface? > > > > > > No, not the services themselves. Just our interal service model > > > stuff that holds all the metadata. Basically, when creating a new > > > service, we need to calculate the metadata. We should cache that > > > if possible. > > > > > > Dan > > > > > >> On Tue, Mar 4, 2008 at 4:48 AM, Daniel Kulp <[EMAIL PROTECTED]> > wrote: > > >>> Christopher, > > >>> > > >>> We cannot just "reuse" the Service model objects as they are > > >>> completely modifiable at runtime. For example, one proxy could be > > >>> reconfigured with new address or have additional interceptors > > >>> added or similar. Those shouldn't affect others. > > >>> > > >>> On option that propably would make sense is to add a fast "clone" > > >>> functionality to the entire service model so we could cache one, > > >>> and then clone it whenever one is really needed. All the > > >>> individual versions could be modified and not affect the original. > > >>> However, doing that would be quite a bit of work as there are a > > >>> LOT of classes that would need to be updated to support that. > > >>> > > >>> Patches towards that end would be great. :-) > > >>> > > >>> Dan > > >>> > > >>> On Monday 03 March 2008, Christopher Cheng wrote: > > >>>> wsdl is indeed cached in WSDLManagerImpl.definitionsMap > > >>>> > > >>>> After reading the codes, I have some questions. My workstation is > > >>>> a PentiumD 3GHz with 1.5GB RAM > > >>>> > > >>>> In the class > > >>>> "org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buil > > >>>>d Serv iceFromWSDL(String url)", > > >>>> "setService(factory.create());" takes 3 seconds > > >>>> "getDataBinding().initialize(getService());" takes 2 seconds > > >>>> > > >>>> These 2 methods are called even in 2nd calls. Can you also cache > > >>>> the services perhaps using jakarta commons-pool? or eh-cache? > > >>>> > > >>>> By the way, I found that the wsdl is put into the definitionMap > > >>>> twice if " WSDLManagerImpl.getDefinition(URL url)" is called. > > >>>> First in "getDefintion(URL url)" at line 147 and second in > > >>>> "loadDefinition(String url)" at line 201. > > >>>> > > >>>> > > >>>> On Mon, Mar 3, 2008 at 4:22 PM, Christopher Cheng < > > >>>> > > >>>> [EMAIL PROTECTED]> wrote: > > >>>>> wsdl is indeed cached in WSDLManagerImpl.definitionsMap > > >>>>> > > >>>>> After reading the codes, I have some questions. My workstation > > >>>>> is a PentiumD 3GHz with 1.5GB RAM > > >>>>> > > >>>>> In the class " > > >>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buil > > >>>>> dSer viceFromWSDL(String url)", > > >>>>> "setService(factory.create());" takes 3 seconds > > >>>>> "getDataBinding().initialize(getService());" takes 2 seconds > > >>>>> > > >>>>> These 2 methods are called even in 2nd calls. Can you also cache > > >>>>> the services perhaps using jakarta commons-pool? or eh-cache? > > >>>>> > > >>>>> By the way, I found that the wsdl is put into the definitionMap > > >>>>> twice if " WSDLManagerImpl.getDefinition(URL url)" is called. > > >>>>> First in "getDefintion(URL url)" at line 147 and second in > > >>>>> "loadDefinition(String url)" at line 201. > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Mon, Mar 3, 2008 at 9:43 AM, Willem Jiang > > >>>>> <[EMAIL PROTECTED]> > > >>>>> > > >>>>> wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I just went through the code, we really cache the WSDL > > >>>>>> definition in CXF. > > >>>>>> Could you send your test case and wsdl file to me ? I may need > > >>>>>> to trace it for more information. > > >>>>>> > > >>>>>> Regards, > > >>>>>> > > >>>>>> Willem > > >>>>>> > > >>>>>> Christopher Cheng wrote: > > >>>>>>> I think the issue is still there. I used a for loop to > > >>>>>>> execute the > > >>>>>> > > >>>>>> same > > >>>>>> > > >>>>>>> call, all takes approximately the same time to create > > >>>>>>> service. I guess > > >>>>>> > > >>>>>> that > > >>>>>> > > >>>>>>> the service itself is not cached. > > >>>>>>> > > >>>>>>> On Sun, Mar 2, 2008 at 11:43 AM, Willem Jiang > > >>>>>>> <[EMAIL PROTECTED]> > > >>>>>>> > > >>>>>>> wrote: > > >>>>>>>> Here is the JIRA[1] which describe the same thing that you > > >>>>>>>> want. I don't know if it was really resolved, could you try > > >>>>>>>> the latest released CXF 2.0.4 for it. > > >>>>>>>> > > >>>>>>>> If the issue is still there, please let me know , I will > > >>>>>>>> put it to my next week todo list. > > >>>>>>>> > > >>>>>>>> [1]https://issues.apache.org/jira/browse/CXF-699 > > >>>>>>>> [2]http://cwiki.apache.org/CXF/download.html > > >>>>>>>> > > >>>>>>>> Willem. > > >>>>>>>> > > >>>>>>>> Christopher Cheng wrote: > > >>>>>>>>> I am migrating from Axis1.2 to CXF 2.0.3 > > >>>>>>>>> > > >>>>>>>>> I understand that it will take a long time to build for > > >>>>>>>>> the first > > >>>>>> > > >>>>>> time. > > >>>>>> > > >>>>>>>> What > > >>>>>>>> > > >>>>>>>>> I am wondering is that why it takes so long for the second > > >>>>>>>>> and third > > >>>>>>>> > > >>>>>>>> time? > > >>>>>>>> > > >>>>>>>>> Is there any caching of services? Axis does not seem to > > >>>>>>>>> have this > > >>>>>> > > >>>>>> issue. > > >>>>>> > > >>>>>>>>> Christopher Cheng wrote: > > >>>>>>>>>> Attached is the log > > >>>>>>>>>> > > >>>>>>>>>> ----- Original Message ----- > > >>>>>>>>>> From: "Willem Jiang" <[EMAIL PROTECTED]> > > >>>>>>>>>> To: <[email protected]> > > >>>>>>>>>> Sent: Saturday, March 01, 2008 8:53 PM > > >>>>>>>>>> Subject: Re: service caching? > > >>>>>>>>>> > > >>>>>>>>>>> Hi > > >>>>>>>>>>> > > >>>>>>>>>>> Could you set the logger level to FINE ? > > >>>>>>>>>>> So we can get more information about the service > > >>>>>>>>>>> publishing. > > >>>>>>>>>>> > > >>>>>>>>>>> Willem. > > >>>>>>>>>>> > > >>>>>>>>>>> Christopher Cheng wrote: > > >>>>>>>>>>>> When I call the service as a client, it takes 5 seconds > > >>>>>>>>>>>> to load. > > >>>>>> > > >>>>>> I am > > >>>>>> > > >>>>>>>>>>>> not > > >>>>>>>>>>>> sure whether it takes 5 seconds to create the service > > >>>>>>>>>>>> or it takes > > >>>>>> > > >>>>>> 5 > > >>>>>> > > >>>>>>>>>>>> seconds > > >>>>>>>>>>>> to look up for ciper filters. I am wondering if the > > >>>>>>>>>>>> services are cached... > > >>>>>>>>>>>> Feb 29, 2008 2:14:42 PM > > >>>>>>>>>>>> org.apache.cxf.service.factory.ReflectionServiceFactory > > >>>>>>>>>>>> Bean buildServiceFromWSDL > > >>>>>>>>>>>> INFO: Creating Service > > >>>>>>>>>>>> {https://webservices.sabre.com/websvc}OTA_HotelAvailSer<https://webservices.sabre.com/websvc%7DOTA_HotelAvailSer> > > >>>>>>>>>>>> vice<https://webservices.sabre.com/websvc%7DOTA_HotelAva > > >>>>>>>>>>>> ilService> > > >>>>>>>>>>>> <https://webservices.sabre.com/websvc%7DOTA_HotelAvailS > > >>>>>>>>>>>> ervic e> > > >>>>>> > > >>>>>> <https://webservices.sabre.com/websvc%7DOTA_HotelAvailService> > > >>>>>> from > > >>> > > >>> WSDL: > > >>>>>>>>>>>> file:/C:/Java/abacus-webconnect-1.14.0.rc1 > > >>>>>>>> > > >>>>>>>> /wsdl/OTA_HotelAvailLLS1.4.1RQ.wsdl > > >>>>>>>> > > >>>>>>>>>>>> Feb 29, 2008 2:14:47 PM > > >>>>>>>>>>>> org.apache.cxf.transport.https.SSLUtils getCiphersuites > > >>>>>>>>>>>> INFO: The cipher suites have not been configured, > > >>>>>>>>>>>> falling back to > > >>>>>>>> > > >>>>>>>> cipher > > >>>>>>>> > > >>>>>>>>>>>> suite filters. > > >>>>>>>>>>>> Feb 29, 2008 2:14:47 PM > > >>>>>>>>>>>> org.apache.cxf.transport.https.SSLUtils > > >>>>>>>>>>>> getCiphersFromList INFO: The cipher suites have been > > >>>>>>>>>>>> set to > > >>>>>> > > >>>>>> SSL_RSA_WITH_RC4_128_MD5, > > >>>>>> > > >>>>>>>>>>>> SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, > > >>>>>>>>>>>> SSL_DHE_RSA_WITH_DES_CBC_SHA, > > >>>>>>>>>>>> SSL_DHE_DSS_WITH_DES_CBC_SHA, > > >>>>>>>>>>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5, > > >>>>>> > > >>>>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, > > >>>>>> > > >>>>>>>>>>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, > > >>>>>>>>>>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, > > >>>>>>>>>>>> SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, > > >>>>>>>>>>>> SSL_DH_anon_WITH_RC4_128_MD5, > > >>>>>>>>>>>> TLS_DH_anon_WITH_AES_128_CBC_SHA, > > >>>>>> > > >>>>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, > > >>>>>> > > >>>>>>>>>>>> SSL_DH_anon_WITH_DES_CBC_SHA, > > >>>>>>>>>>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, > > >>>>>>>>>>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, > > >>>>>>>>>>>> TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, > > >>>>>>>>>>>> TLS_KRB5_EXPORT_WITH_RC4_40_SHA, > > >>>>>>>>>>>> TLS_KRB5_EXPORT_WITH_RC4_40_MD5, > > >>>>>> > > >>>>>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, > > >>>>>> > > >>>>>>>>>>>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. Feb 29, 2008 > > >>>>>>>>>>>> 2:14:48 PM > > >>>>>> > > >>>>>> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallba > > >>>>>> ckon Close > > >>>>>> > > >>>>>>>>>>>> I have put this in my cxf.xml as in > > >>>>>>>>>>>> http://cwiki.apache.org/CXF20DOC/client-http-transport. > > >>>>>>>>>>>> html , but > > >>>>>> > > >>>>>> it > > >>>>>> > > >>>>>>>>>>>> doesn't > > >>>>>>>>>>>> help... <http:conduit name="*.http-conduit"> > > >>>>>>>>>>>> <http:tlsClientParameters > > >>>>>>>>>>>> secureSocketProtocol="SSL"> <sec:cipherSuitesFilter> > > >>>>>>>>>>>> <!-- these filters ensure that a > > >>>>>>>>>>>> ciphersuite with export-suitable or null encryption is > > >>>>>>>>>>>> used, but exclude anonymous Diffie-Hellman key change > > >>>>>> > > >>>>>> as > > >>>>>> > > >>>>>>>>>>>> this is vulnerable to man-in-the-middle > > >>>>>>>>>>>> attacks > > >>>>>> > > >>>>>> --> > > >>>>>> > > >>>>>>>>>>>> <sec:include>.*_EXPORT_.*</sec:include> > > >>>>>>>>>>>> > > >>>>>>>>>>>> <sec:include>.*_EXPORT1024_.*</sec:include> > > >>>>>>>>>>>> <sec:include>.*_WITH_DES_.*</sec:include> > > >>>>>>>>>>>> <sec:include>.*_WITH_NULL_.*</sec:include> > > >>>>>>>>>>>> <sec:exclude>.*_DH_anon_.*</sec:exclude> > > >>>>>>>>>>>> </sec:cipherSuitesFilter> > > >>>>>>>>>>>> </http:tlsClientParameters> > > >>>>>>>>>>>> </http:conduit> > > >>>>>>>>>> > > >>>>>>>>>> http://www.nabble.com/file/p15773252/cxf.log cxf.log > > >>> > > >>> -- > > >>> J. Daniel Kulp > > >>> Principal Engineer, IONA > > >>> [EMAIL PROTECTED] > > >>> http://www.dankulp.com/blog > > > > -- > J. Daniel Kulp > Principal Engineer, IONA > [EMAIL PROTECTED] > http://www.dankulp.com/blog >
