cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: WS-Security concurrency issue with CXF 2.2.12 + WSS4J 1.5.10
Date Wed, 01 Jun 2011 15:57:45 GMT
On Wednesday, June 01, 2011 11:29:22 AM Alessio Soldano wrote:
> OK, here I am with some data.
> I've been able to reproduce the problem locally (had to tune the load
> test application to run on my laptop and still reproduce the problem
> ;-)) and it seems CXF 2.4.1-SNAPSHOT + WSS4J 1.6 is not affected.
> So I had a look at the commits that went in to the 1.5.x fix branch of
> WSS4J and I think I've found the commit that introduces the problem,
> http://svn.apache.org/viewvc?view=revision&revision=947604 . I've not
> enough knowledge of the project (at least atm) to really understand the
> reason, however the binary obtained by building the 947603 revision is
> not showing the concurrency issue below, while 947604 reproduces the
> problem (both versions tested with CXF 2.2.12).
> At first sight the only way I see the WSDocInfo could be used
> concurrently is because of some issues with getting it from the
> WSDocInfoStore... but again, I'm not an expert at all here. Dan, could
> this perhaps be related to the hashing issue you mentioned in the other
> reply? I'm indeed running a 64bit JDK.

No, it's slightly different.  Up until that commit, the EnvelopIdResolver was 
pretty much just used as a singleton.   It didn't have any state and thus a 
singleton was created and reused.   With that commit, it was given state, but 
all the places that used it as a singleton were not updated.   I've created a 
JIRA: 
 https://issues.apache.org/jira/browse/WSS-292

and will be committing a fix soon.  It would be great if you could test a 
snapshot with it.

Dan


> 
> Thanks
> Alessio
> 
> On 06/01/2011 11:47 AM, Alessio Soldano wrote:
> > Hi Colm,
> > yes, I'll try reproducing this locally (the load test is actually run
> > on a bench environment that can't be moved quickly to cxf 2.4.0 /
> > wss4j 1.6) and let you know asap.
> > Thanks
> > Alessio
> > 
> > On 06/01/2011 11:26 AM, Colm O hEigeartaigh wrote:
> >> Hi Alessio,
> >> 
> >> Very interesting, I haven't seen this problem before. It looks like a
> >> problem in WSS4J - I'm not sure how multiple threads are altering the
> >> same WSDocInfo object.
> >> 
> >> Would it be possible to check whether it exists with CXF 2.4.0 and
> >> WSS4J 1.6.0? I want to get a WSS4J 1.6.1 release out asap, so it would
> >> be cool to fix this problem if it's there.
> >> 
> >> Colm.
> >> 
> >> On Wed, Jun 1, 2011 at 9:52 AM, Alessio Soldano<asoldano@redhat.com>
> >> 
> >> wrote:
> >>> Hi,
> >>> we're running some WS-Security load tests with Apache CXF 2.2.12 +
> >>> WSS4J
> >>> 1.5.10 and might have found a concurrency issue.
> >>> We're getting the following exception:
> >>> 
> >>> [runTest(bash)] OUT>    Caused by:
> >>> java.util.ConcurrentModificationException
> >>> [runTest(bash)] OUT>      at
> >>> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372
> >>> )
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> java.util.AbstractList$Itr.next(AbstractList.java:343)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.ws.security.WSDocInfo.getSecurityTokenReference(WSDocInfo.ja
> >>> va:86)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.ws.security.message.EnvelopeIdResolver.engineResolve(Envelop
> >>> eIdResolver.java:114)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.utils.resolver.ResourceResolver.resolve(Unknown
> >>> Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.Reference.getContentsBeforeTransforma
> >>> tion(Unknown
> >>> 
> >>> Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.Reference.dereferenceURIandPerformTra
> >>> nsforms(Unknown
> >>> 
> >>> Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.Reference.calculateDigest(Unknown
> >>> Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.Reference.verify(Unknown Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.Manifest.verifyReferences(Unknown
> >>> Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.SignedInfo.verify(Unknown Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(Unkn
> >>> own
> >>> 
> >>> Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(Unkn
> >>> own
> >>> 
> >>> Source)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(
> >>> SignatureProcessor.java:470)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.ws.security.processor.SignatureProcessor.handleToken(Signatu
> >>> reProcessor.java:114)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurit
> >>> yEngine.java:328)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurit
> >>> yEngine.java:245)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4J
> >>> InInterceptor.java:208)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4J
> >>> InInterceptor.java:78)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>> Chain.java:243)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRes
> >>> ponseInternal(HTTPConduit.java:2408)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRes
> >>> ponse(HTTPConduit.java:2278)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTT
> >>> PConduit.java:2121)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:695)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEnding
> >>> Interceptor.handleMessage(MessageSenderInterceptor.java:62)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>> Chain.java:243)
> >>> 
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> >>> [runTest(bash)] OUT>      at
> >>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> >>> [runTest(bash)] OUT>      ... 9 more
> >>> 
> >>> 
> >>> Interestingly, forcing the use of WSS4J 1.5.8 instead (we discovered
> >>> this by
> >>> accident ;-) ) the problem goes away.
> >>> The application basically builds up a JAXWS client using WS-Security
> >>> (Sign
> >>> only) through programmatically configured WSS4J interceptors:
> >>> http://fpaste.org/pYHM/
> >>> Once the proxy is ready on client side, it's called concurrently using
> >>> multiple threads (performIteration() method in the code).
> >>> Does the problem/exception above ring any bell? I'm going to
> >>> investigate
> >>> this a bit more in any case.
> >>> Thanks
> >>> Alessio

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Mime
View raw message