RE: Aegis versus jaxrs
Hi, Same with the JAX-RS JAXB (and JAXB based JSON) provider - contexts are cached and can be reused. If ObjectFactory is available then only a single context will be created. At the moment, either a class name or just a package name can serve as a key in the (two) maps of contexts. May be for Aegis it's possible to have another key type to have a context with a scope which wide enough. Sure, you can do bean-ish properties too. I guess an Aegis provider will have to be an optional one, otherwise it'll 'clash' with the default JAXB one (both will serve media types like application/xml). Thus it will have to be specified as a bean class in the spring config. Perhaps you can support both options - map of properties and bean-ish properties. Cheers, Sergey -Original Message- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: 14 October 2008 01:00 To: dev@cxf.apache.org; Daniel Kulp Subject: Re: Aegis versus jaxrs OK, now we reach the crux of the matter. JAX-RS creates lots of JAXBContexts, where 'normal' CXF manages to share one through an entire service. Am I getting the idea that this is just an inescapable aspect of the architecture? It could get slow. Aegis is just like JAXB. I could create a set of named properties for the corresponding Aegis options, and add a call like you propose for JAXB. But now we're going to have scads of Aegis objects. In either case, is there any way for the app creator to use Spring configuration to set all this stuff up? And are we really thrilled to have it all as (mistake-prone?) name-value pairs, instead of specific bean-ish properties? I've attempted to drag Dan into this discussion so that he can tell me to stop worrying. On Mon, Oct 13, 2008 at 9:26 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Benson Lets add AbstractJAXBProvider.setContextProperties(MapString, Object) and pass those props to the JAXBContext creation calls. If none is explicitly passed from Spring then a default empty Map can be used instead. In fact, I just removed that code in my previous merge as I thought there was no use for it. About Schema : I presume you ask about the one from javax.xml.validation ? I just added it recently to support the optional schema validation... Cheers, Sergey -Original Message- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: 12 October 2008 12:13 To: dev@cxf.apache.org Subject: Re: Aegis versus jaxrs I think I finally have a sensible question by analogy with JAXB. JAXBContext objects have a variety of options and properties. The JAXBDataBinding allows the CXF app to control these items. The user can make their own context and inject it into the data binding, or the user can set various properties of ours that our code uses to tune the context. If I'm reading the JAX-RS code correctly, AbstractJAXBProvider just creates a JAXBContext per package or class and uses it. Any app that wanted to customize it would be required to make their own subclass of AbstractJAXBProvider, or so it seems to me. Am I missing anything? Anyway, I'm going to bang something together. On Fri, Oct 10, 2008 at 12:42 PM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Sergey, I'm not feeling like I'm doing a very good job of explaining myself here. It's probably true that the best way for me to proceed is to code something and with some comments that say: 'Sergey, I'm frustrated HERE.' ... Yea, please do it :-) ! I do hope though that you wouldn't need to get into the details of the actual JAX-RS runtime impl, hopefully you'd be able to craft a basic Aegis support inside the 'shell' of the (Aegis) JAX-RS MessageBodyReader/Writer implementation...If we could say limit the support to pure Aegis (that is without it also supporting JAXB - which is something CXF Aegis can do as far as I understand) then it would be super... Cheers, Sergey --benson On Fri, Oct 10, 2008 at 11:44 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Benson I'm sorry If I'm too slow :-) but I'm still not getting what is it that you're proposing. That said, I believe that may be we should postponse the discussion on how to improve the overall JAX-RS implementation until after it reaches 1.0. In meantime, if we had even a basic JAX-RS Aegis provider such that peopple could start doing Aegis and REST or indeed combining SOAP and REST with the help of Aegis, then it would be cool IMHO Cheers, Sergey I think I'm beginning to get the idea of what I'm trying to complain about. An AegisDatabinding object has input configuration and it has state. As it goes along, it constructs mappings for types. I'm having trouble swallowing a situation in which each individual JAX-RS item does this independently, as opposed to all the of the items in a service sharing a single state. Am I just confused? IONA Technologies PLC (registered in Ireland) Registered Number: 171387
Re: Memory leak in CXF HTTP transport in Solaris ?
I'm honestly no seeing this on my linux box with the latest code. I hit it with about 500K requests to warm up the JIT and stuff, check the heap sizes using jconsole (1.6VM), then hit it with another 1.5 million requests and rechecked the heap sizes and they ended up exactly the same. My suggestion is to try again with a more recent version of CXF at the very least.Also try the latest JDK's. Dan On Monday 13 October 2008 7:14:37 am Anoop Prasad wrote: Dear Bharat, 1. I have tested on three OS Env Win XP Solaris 10 SuSE Linux (on ATCA) 2. Yes, on windows the behavior is not- alarming. Its stable. But solaris and Linux shows a memory Increase, as i have explained in the prev Post. 3. I have used JConsole and rational Purify to monitor the Heap/non-heap/Perm Generations of Memory. prstat utility was used on Solaris to observe the memory claimed by the process.Also pmap 4. i//The memory of the server continously increases from ~90M to ~350M which never comes down. How did you check this?/i At startup prstat gives a value around 80M Resident Memory and total Mem 164M. After the load testing (around 800,000 continuous requests) the value goes very high, ie 325M RSS and 388M Total Memory. At the same time Heap shows negligible increase after GC, as i have shown in the table. One word about the table: Table has the following columns Total Mem as shown in prstat RSS Mem as shown in prstat eg: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 3769 root 207M 124M sleep 590 0:02:09 4.4% java/40 and.. Used Commited Maximum allowed Memory as per JConsole of JDK 5 And the RSS and total mem used for the process never goes down from the high value even after GC (but this is the behavior of process on Solaris ?) 5. This memory Increase happens only in HTTP transport. in JMS its fine, as Hubert observed. 6. I can send the pmap dump and other details, if required. anoopPrasad Two roads diverged in a wood, and I -- I took the one less traveled by, and that has made all the difference! HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China www.huawei.com --- - - This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
Re: JMS 1.0.2 support......
On Saturday 11 October 2008 3:34:52 am Christian Schneider wrote: Hi Dan, sounds reasonable to me. I have added the config element to address and set the default. I think setting useJms11 to false for 2.0.x and 2.1.x probably makes sense for compatibility sake. For 2.2 (trunk), it probably make sense to set the default to true. If the provider is 1.1 capable, we probably should use it, but provide the option for the user to downgrade to 1.0.2 if they need it. Dan Greetings Christian Daniel Kulp schrieb: Christian, The old JMS transport pretty much just used the JMS 1.0.2 API's so it worked with old versions of JMS providers and such. The new stuff seems to default to 1.1 which is causing issues.I see that if you use the new config, it's settable. However, if you use the old wsdl based stuff, it cannot.I'm wondering if it make sense for the line in JMSOldConfigHolder that reads: jmsConfig.setUseJms11(true); should be changed to false to be compatible with the old version? I suppose we could add a optional useJms11 attribute (default to false) on one of the old extensors (address maybe?) to set this so if someone wants to use 1.1, they could, but default behavior is maintained. Thoughts? -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
Re: Memory leak in CXF HTTP transport in Solaris ?
Adding the Link again from the last post: Could you please have a look at the following post and tell me whether it applies to CXF. http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java ~ anoopPrasad anoopPrasad wrote: Dear Dan/Bharat, I have checked Heap,non-Heap, and perm Gen Memory usage of the process through JCOnsole and OptimizeIT. And like Dan observed, its stable, more or less. (Like in the report in the first post) But still the OS (Solaris) reports a Resident Memory increase as well as the swap memory increase. From the pmap report I have observed that after a number of requests a lot of the anonymus [anon] memory blocks are allocates, which is never reclaimed. In the beginning we were also doubting PermGen space and Jetty server. But it turns out that PermGen allocation is fine , no considerable increase(~3M) at all. About Jetty we are still doubtful.Since JMS transport is fine, it has to be either Jetty problem or the way servlets are handled in CXF Code. Could you please have a look at the following post and tell me whether it applies to CXF. http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java If it's in the process memory space, that's probably a bug in either Jetty (nio stuff it does) or in the JDK itself. Nothing we can do about either of those. If we locate the problem, we can try to fix it. Thank you very much. regards anoopPrasad -- View this message in context: http://www.nabble.com/Memory-leak--tp19619011p19979358.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [VOTE] Release CXF 2.0.9
Hi Willem, so that´s fine with me. I think we should start a release note wiki page for 2.0.9 and perhaps also for 2.1.3. Btw. I noticed that there is no release notes page for the latest 2.1.2 release. In apache camel they create the release notes quite early and then collect the information over time. I think that is a quite good idea. Greetings Christian Daniel Kulp schrieb: My vote is staying +1.The chance of anyone hitting it is small as the JMS versions we hit it with internally are no longer supported. There is kind of a discussion as to why we are testing with such old and unsupported versions of JMS. Basically, any JMS provider released anytime even half way recently will be 1.1. In anycase, it's fixed on the branches. We can get new snapshots up quickly and if someone runs into it, point them at those. Dan -- Christian Schneider --- http://www.liquid-reality.de
Re: Aegis versus jaxrs
I haven't been able to come up with a reason why Aegis would ever say no to isWriteable or isReadable, but I'll study some more. On Tue, Oct 14, 2008 at 10:52 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Sounds good. Have a look, say, at BinaryProvider unit test or at one of the atom providers tests, jaxb providers are poorly unit tested at the moment. Other providers tests might have some useful test methods too. The things to unit test is that MessageBodyReader.isReadable and MessageBodyWriter.isWriteable can return true/false as expected, and they can readFrom/writeTo input streams. There's also a quite involved JAXBClientServerBookTest. Let me know please when you're ready to start writing a system test and we'll create an Aegis version of this test (will be mostly copy/paste), but we'll additionally register AegisProvider using Spring so that it can take precedence over the default JAXB provider which handles application/xml... Cheers, Sergey -Original Message- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: 14 October 2008 12:50 To: dev@cxf.apache.org Subject: Re: Aegis versus jaxrs I appreciate the cache. However, the minimum number of contexts is the number of packages! A property that takes a context object would, however, solve all of this for both Aegis and JAXB, so I'm excited. Can you tell me how to make a unit test for my Aegis stuff? On Tue, Oct 14, 2008 at 3:46 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi, Same with the JAX-RS JAXB (and JAXB based JSON) provider - contexts are cached and can be reused. If ObjectFactory is available then only a single context will be created. At the moment, either a class name or just a package name can serve as a key in the (two) maps of contexts. May be for Aegis it's possible to have another key type to have a context with a scope which wide enough. Sure, you can do bean-ish properties too. I guess an Aegis provider will have to be an optional one, otherwise it'll 'clash' with the default JAXB one (both will serve media types like application/xml). Thus it will have to be specified as a bean class in the spring config. Perhaps you can support both options - map of properties and bean-ish properties. Cheers, Sergey -Original Message- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: 14 October 2008 01:00 To: dev@cxf.apache.org; Daniel Kulp Subject: Re: Aegis versus jaxrs OK, now we reach the crux of the matter. JAX-RS creates lots of JAXBContexts, where 'normal' CXF manages to share one through an entire service. Am I getting the idea that this is just an inescapable aspect of the architecture? It could get slow. Aegis is just like JAXB. I could create a set of named properties for the corresponding Aegis options, and add a call like you propose for JAXB. But now we're going to have scads of Aegis objects. In either case, is there any way for the app creator to use Spring configuration to set all this stuff up? And are we really thrilled to have it all as (mistake-prone?) name-value pairs, instead of specific bean-ish properties? I've attempted to drag Dan into this discussion so that he can tell me to stop worrying. On Mon, Oct 13, 2008 at 9:26 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Benson Lets add AbstractJAXBProvider.setContextProperties(MapString, Object) and pass those props to the JAXBContext creation calls. If none is explicitly passed from Spring then a default empty Map can be used instead. In fact, I just removed that code in my previous merge as I thought there was no use for it. About Schema : I presume you ask about the one from javax.xml.validation ? I just added it recently to support the optional schema validation... Cheers, Sergey -Original Message- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: 12 October 2008 12:13 To: dev@cxf.apache.org Subject: Re: Aegis versus jaxrs I think I finally have a sensible question by analogy with JAXB. JAXBContext objects have a variety of options and properties. The JAXBDataBinding allows the CXF app to control these items. The user can make their own context and inject it into the data binding, or the user can set various properties of ours that our code uses to tune the context. If I'm reading the JAX-RS code correctly, AbstractJAXBProvider just creates a JAXBContext per package or class and uses it. Any app that wanted to customize it would be required to make their own subclass of AbstractJAXBProvider, or so it seems to me. Am I missing anything? Anyway, I'm going to bang something together. On Fri, Oct 10, 2008 at 12:42 PM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Sergey, I'm not feeling like I'm doing a very good job of explaining myself here. It's probably true that the best way for me to proceed is to code something and with some comments that say: 'Sergey, I'm frustrated HERE.' ... Yea, please do
