ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <>
Subject [jira] Resolved: (WSS-232) Performance Improvement in WSSConfig
Date Wed, 22 Dec 2010 13:09:02 GMT


Colm O hEigeartaigh resolved WSS-232.

    Resolution: Fixed

This is now fixed in 1.6-SNAPSHOT. Thanks for the patch.


> Performance Improvement in WSSConfig
> ------------------------------------
>                 Key: WSS-232
>                 URL:
>             Project: WSS4J
>          Issue Type: Improvement
>          Components: WSS4J Core
>    Affects Versions: 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.6
>         Environment: Jetty
>            Reporter: Mario Siegenthaler
>            Assignee: Colm O hEigeartaigh
>             Fix For: 1.6
>         Attachments:,
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
> When I profiled one of our webservices that uses SAML I noticed, that about half the
CPU-time per call gets spent inside
> WSSConfig.getProcessor -> Loader.loadClass -> ClassLoader.loadClass
> The application server I was running on is Jetty 6 (might have some impact on the performance
of classloading, since it's done with the Webapp-Classloader).
> When I reviewed the code I noticed that all the actions and processors inside WSSConfig
are held in a Map with ID -> [either classname or instance). All the default processors/actions
are as Strings (classnames). Most of the processors have to be instantated per invocation,
so I couldn't switch from classnames to instances.
> I propose to add a third value-variant  to the maps: Classes. The included patch contains
the changes to WSSConfig. The central parts are inside the static initialization (I added
a helper method to shorten initializer) and in the #getProcessor and #getAction methods (a
third if-instanceof-part). I retained the dynamic lookup of the opensaml classes.
> The patch brings a massive performance enhancement, at least in the jetty-environment
(I didn't test other application server) due to not looking up the classes on every invocation.
The CPU-time of the wss4j library went from ~50% down to 2%.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message