On Fri March 20 2009 8:37:52 am Colm O hEigeartaigh wrote: > 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.
Actually, this is something where I'd like to take a cue from MS. WCF, for the wsu:Id things, generally starts a count a "_1" and each time a new one is needed, it increments. It's VERY simple to look at and debug cause you end up matching a small number which is much more "natural". It also makes the messages a little smaller. I think the longer forms are just used for the actual security tokens, not the stuff they reference. Dan > > 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]
