Sounds good. It's probably a good idea to replace all calls to hashCode for constructing URI's as well. I don't think it's necessary to do a digest at all, just base-64 a SecureRandom value.
Colm. -----Original Message----- From: Daniel Kulp [mailto:[email protected]] Sent: 19 March 2009 14:17 To: [email protected] Subject: thread safety issue in wss4j.... Just wanted to let the community know that while doing some testing this week, I've found a thread safety issue in wss4j that can make it randomly fail to validate signatures under high load. I'm going to be working on a fix, but I'm at The Server Side Symposium this week so may not get it committed until next week. Basically, the problem stems from the cache of the WSDocInfo objects. The cache uses the hashCode of the owner document as a key. Hash codes aren't guaranteed to be unique so in some cases, (more often on 64bit machines) I'm getting more than one message in flight with the same hash code, but are different. Thus, when it looks up the docinfo, it gets the wrong one and fails. There are a few potential fixes: 1) Base the key on the doc itself, not the hashcode. Hashtable can resolve the duplicate ID's itself. 2) Change the cache to a ThreadLocal. 3) Eliminate it entirely. I'm going to attempt this route. The cache is used in two places. In one case (the case I'm running into), the method calling the method that does the lookup already has the docinfo. Thus, just passing it as an extra parameter removes the need for the cache lookup entirely. I haven't dug into the other one yet. Anyway, just wanted to let everyone know about it so they can plan accordingly. -- Daniel Kulp [email protected] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
