From: Greg W. <gr...@mo...> - 2003-11-16 11:30:23
|
Dieter, Thanks for spotting this race. But I don't think the solution is to put another sync in, as that would cost considerable performance on such a central class. I think the fix is to use the existing sync during addition of a new FieldInfo to check that it is not already in the cache. While this smacks of double check sync issue, I don't believe it is. It does not stop two FieldInfos from being created, it only makes sure that one of them is added to the cache. Also, it is probably worth adding all the soap headers to the HttpField cache during static initialization to avoid this situation completely. Do you have a good listing of the headers that SOAP uses? regards PS. I'll check in a fix for this shortly, but I'm not sure I can fully test in on my single CPU box.... but I'll do some contrived passing of the initial unsynchronized cache lookup. die...@in... wrote: > > Hi all, > > I seem to have encountered a problem with Jetty (4.2.14). > We are using Axis for our webservice. But we always got a > 'Client.NoSOAPAction' error, when sending 2 (or more) requests to the > service at the same time. > After a long search, it seems as if jetty has a threading problem in > HttpFields in the method add(LineInput). > This method is accessed twice at the same time (the two requests that > come in at the same time). Because the jetty server just started, no > header field info is available yet. The method checks if the header > field (SOAPAction in this case) is already in the list, but it is not, > so it adds it. So it is added twice to the list instead of only once. > When I add a 'synchronized(__info)' around the check and add stuff, it > seems to work fine. > I'm absolutely no expert in jetty code (this is the first time I've seen > it), so I could be terribly wrong. > > Sincerely > > Dieter Wachters > |