views:

314

answers:

2

I'm evaluating Apache CXF for a project so I wrote a small demo application to try a few things out. Following the CXF user's guide, I was able to get my application up and running pretty quickly.

One thing I wanted to test was how well CXF is able to handle a method that returns a large array of primitives. So I defined a method 'float[] getRandFloats(int count)' which simply returns an array of the specified length filled with random numbers. Looking at the WSDL generated by java2wsdl, I see the method correctly indicates a return type of float[]. Inspecting the client side, I also see that I'm (ultimately) receiving a float[].

I noticed as I increase the number of elements in my array, the client performance suffers. I ran a profiler on the client-side and saw that there are Float objects being created for every element in the returned array. It seems this is happening when CXF invokes JAXB during the parsing of the response.

I'm evaluating CXF for use with an application that potentially sends back millions of floating point numbers so this object creation is highly undesirable. In order to use CXF, I'd need to find a way to prevent this object creation from happening. I've scanned through the documentation and mailing list, but haven't come up with a way to work around this.

Has anyone encountered a similar problem using CXF? If so how did you work around this?

A: 

You say the cliernt performance suffers as the umber of elements in the array increases. This sounds reasonable to me - more data, less performance. What were you expecting there? As long as it's a linear degredation, it's behaving OK.

As for the creation of millions of objects, a modern JVM will do this without breaking sweat. I suspect the designers of CXF are well aware of this. Old JVMs had poor GC algorithms, and having millions of objects kicking around did indeed cause a problem, but this is no longer the case, particularly with very short-lived objects like you have here.

So on the one hand, we have a performance degradation caused by lots of data, and the fact that millions of objects are created. However, there's no evidence that the two observations are related.

skaffman
I agree the JVM has improved considerably however, the unnecessary object creation is still not "free". I'd at least like to rule this out as the cause of the performance degradation I've observed.It's possible that CXF wasn't designed for this sort of usage which is perfectly acceptable. I was just hoping to get someone with more knowledge of CXF to weigh in on the topic before I rule out it's use.
Jason Braucht
It's not free, but it's not far off. The JVM will create those new objects the first time they're needed, and then recycle them as needed. If you wantr to rule this out as a cause, then try executing the call multiple times and see if the time taken is the same every time, or if things improve.
skaffman
A: 

This definitely isn't anything CXF can do anything about. It more of a JAXB issue. I believe that internally, JAXB handles all the "maxOccurs != 1" cases as a java collection, not an array. It just converts to the array as the last step of the process if it needs to. Since java collections cannot hold primitives, it would be Float objects stored.

In anycase, this would have to be taken up with the JAXB folks. :-(

Daniel Kulp