Hi,
few months ago I was profiling a JAX-WS client applications and
mentioned few performance issues on this list, see [1].
Recently, I've had a chance to get back to that topic and think about a
possible alternative to the way context properties are retrieved from
and stored in the Message; as I previously noticed, the context cache
computation is quite expensive as 7 maps are merged into one, at least
twice for each request-response processing. I asked for the reason such
cache is there (in the past, getContextualProperty used to go and look
for the prop key into the Bus, Service, Endpoint etc.) and Dan explained
that in some scenarios (for instance when using WS-Security) a lot of
props are checked and that resulted in a lot of time spent creating hash
codes for all those lookups, etc. So the need for a unified view of the
props.
Now, I admit I've been looking around for inspiration, especially in the
JAX-WS RI implementation... and found what I think could be an
interesting idea ;-)
Basically, I think we could revisit this contextual property stuff as
follows:
- we keep a list of the known property names
- for all known properties, instead of saving key-value entries in one
of those 7 maps for each message if the prop is specified, we compute a
static index that tells us where/how to get the value for a given
property; so for instance the index would tell us if prop X is a
Message, Bus, Service or Endpoint stored properties, so that we don't
have to go and try each of them till we find the value.
- any other property is dealt with as we currently do
This way by default and in most of the cases, the context cache merged
map (as well as the 7 maps) would be empty, meaning no need for actually
allocating memory and doing any copy. At the same time, we'd not be
slowing down the gets that much, as we'd only be doing an additional get
in the index.
Moreover, perhaps afterwards in a second optimization effort, we could
make this even more optimized by keeping the (most relevant) known
property values in strong typed members of the Message, Bus, Endpoint,
etc. instead of putting them in maps. For such properties, the index
would return an accessor to the actual field/method providing the
property value. The JAX-WS RI does this by parsing classes during
initialization, looking for @Property custom annotations telling a
field/method provides the value for a given property and creating the
proper accessor for it. The accessor uses reflection to read/write the
data using the field/method.
When adding a new known property, we'd have to add it to the list of the
known properties and have it registered in the index (btw, for
documentation sake, it would still be good to have a centralized
collection of supported contextual properties, regardless of this issue).
Any thought / idea?
I could possibly try implementing this in the next future and have it
included on master if it turns out to actually be an effective solution...
Cheers
Alessio
[1]
http://cxf.547215.n5.nabble.com/JAX-WS-client-performances-td5753625.html
--
Alessio Soldano
Web Service Lead, JBoss
