cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Ma <>
Subject Re: JAX-WS client performances
Date Wed, 28 Jan 2015 05:45:34 GMT
I reported this issue to Oracle several month ago, and it took a long time
that I received the mail from Oracle support team that they need a
Before I got time to come back to have a look at this again and provided
them code to reproduce this, they already closed as a non-reproducible bug.
I also wrote several emails after that to report this bug still exists in
latest JDK7/8 with some of my analysis, and haven't get their response.

This is another findings I've talked with Oracle: This performance
regression is actually introduced by From changeset, it tries to
read serverSocket's inputStream to know if the connection is still alive.
But it dramatically slows down the things.

Remove setFixLengthStreamMode() is a temporary workaround, and this will
lead client side consumes more memory for the message doesn't reach default
4k size, especially in some concurrent environment. I agreed with Sergey to
enable/disable this mode with system property and wait JDK team finally get
this fixed.

I created a simple test case to verify if this issue still exists in the
latest jdk if you are interested :


On Wed, Jan 28, 2015 at 5:09 AM, Sergey Beryozkin <>

> Hi Dan
> On 27/01/15 18:00, Daniel Kulp wrote:
>> Chatted with Alessio about this on IRC.   It looks like a bug in the JDK
>> introduced in Java7 update 40.  A bug was logged:
>> but then closed a non-reproducible.   Alessio will look into seeing if
>> that can be re-opened.
>> Meanwhile we’ll likely remove the call to setFixedLengthStreamingMode.
>> That will result in an extra byte[] copy of the message, but this is only
>> for smaller messages (hasn’t hit the threshold yet) and thus is fairly
>> quick and is certainly MUCH MUCH faster than the problems we’re seeing with
>> the call to setFixedLengthStreamingMode().
>>  Should we make it optional (system + contextual property) so that people
> can tell the runtime to actually call this method if confirmed it actually
> improves the performance (may be in newer JDK, etc) ?
> Thanks, Sergey
>  Dan
>>  On Jan 27, 2015, at 12:14 PM, Alessio Soldano <>
>>> wrote:
>>> Hi,
>>> my attention has been recently brought to a scenario in which an Apache
>>> CXF client invokes an endpoint operation in a loop and the number of
>>> invocations performed in a given amount of time (say, 2 minutes) is used as
>>> benchmark for measuring WS stack performances. It's actually a very
>>> simplistic scenario, with a plain JAX-WS single thread client sending and
>>> receiving small RPC/Lit SOAP messages [1]. The reason why I've been asked
>>> to have a look is that with default settings the Apache CXF JAX-WS impl
>>> seems to perform *shamefully* bad compared to the Metro (JAX-WS RI)
>>> implementation. I've been blaming the user log configuration, etc but when
>>> I eventually tried on my own I could actually reproduce the bad results.
>>> I've been profiling a bit and found few hot spot area where CXF could
>>> possibly be optimized, but the big issue really seems to be at the
>>> HTTPCounduit / HTTPURLConnection level.
>>> I found that almost all the invocations end up into
>>> calling available() method [2] as
>>> part of the process for re-using cached connections [3]; that goes to the
>>> wire to try reading and takes a lot of time.
>>> When the RI does the equivalent operation, the available() method is not
>>> called [4], resulting in much better performances.
>>> By looking at the JDK code, it looks to me that the problem boils down
>>> to [5]
>>> returning different values, as a consequence of the fixedContentLenght
>>> attribute being set to a value different from -1 when running on CXF only.
>>> As a matter of fact, that is set when HTTPConduit.WrappedOutputStream#thresholdNotReached()
>>> is called, whenever a message is completely written to the outpustream
>>> buffer before the chunking threshold is reached (at least AFAIU). I've
>>> searched through the JAX-WS RI and could not find any place where
>>> setFixedLengthStreamingMode is called on the connection instead.
>>> So, I've performed two quick and dirty tries: the first time I forced
>>> allowChunking = false on the client policy, the second time I commented out
>>> the code in HTTPConduit.WrappedOutputStream#thresholdNotReached(). In
>>> both cases I managed to get performances comparable to what I can get with
>>> the JAX-WS RI.
>>> Now, few questions:
>>> - are we really required to call setFixedLengthStreamingMode as we
>>> currently do? what's the drawback of not calling it?
>>> - should we actually do something for getting decent performances by
>>> default in this scenario? (not sure expecting the user to disable chunking
>>> is that an option...)
>>> As a side note, the relevant part of the JDK HttpClient code changed
>>> between JDK6 and JDK7, so things have not always been as explained above...
>>> Cheers
>>> Alessio
>>> [1]
>>> [2]
>>> [3]
>>> root/jdk/openjdk/7u40-b43/sun/net/www/http/
>>> [4]
>>> [5]
>>> root/jdk/openjdk/7u40-b43/sun/net/www/protocol/http/
>>> --
>>> Alessio Soldano
>>> Web Service Lead, JBoss

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message