cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <>
Subject Different approach for saving context properties
Date Sun, 19 Apr 2015 21:55:13 GMT
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 
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 
- 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...


Alessio Soldano
Web Service Lead, JBoss

View raw message