You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Venkat Reddy <vr...@gmail.com> on 2004/10/26 10:43:33 UTC
Re: AW: AW: Bug : Threading issue in wss4j subproject (patch incl ude d )
hi Werner,
I looked further into this and found something interesting. The code
in org.apache.axis.deployment.wsdd. WSDDDeployableItem indicates that
it is possible to change this default singleton behavior by specifying
an attribute (for <handler> tag?) "scope" with a value of "per-access"
or "per-request". But the WSDD reference documentation at
http://ws.apache.org/axis/java/reference.html does not talk about
this.
However, the default behavior when the undocumented "scope" attribute
is not specified, is just what I described in my earlier mail, which
I've observed in my debugger.
Erik, will it be possible for you to try this scope attribute? If it
works, then we may have to revalidate our proposed code changes to
handlers.
Hope this helps.
Venkat
On Tue, 26 Oct 2004 08:34:16 +0200, Dittmann Werner
<we...@siemens.com> wrote:
> Venkat,
>
> thanks for that info. Is this behaviour somewhere documented
> or described in Axis? It should be in _big_ letters though
> because this restriction has a big impact on the design
> and implementation of Axis handlers. As you stated, they
> should be stateless, in other words Axis handlers shall be classes
> that must not have instance variables (only static data). I even
> would go a step further: the Axis handlers could (should?)
> also have static methods only thus preventing them to use
> instance variables. BTW, this is one of the most restrictive
> designs/requirements I've seen since a long time.
>
> I'm glad to hear that you will fix the handler similar to
> Erik's approach, because synchronizing the whole handler
> would really nullify the performance gain of a
> multi-thread/multi-CPU deployment.
>
> If you need any help pls let me now.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: Venkat Reddy [mailto:vreddyp@gmail.com]
> > Gesendet: Donnerstag, 21. Oktober 2004 13:43
> > An: dims@apache.org
> > Cc: Dittmann Werner; Erik_Vanherck@inventivedesigners.com;
> > fx-dev@ws.apache.org
> > Betreff: Re: AW: Bug : Threading issue in wss4j subproject
> > (patch incl uded )
> >
> >
> > As far as i can see, Axis Engine instance is a singleton and
> > consequently the SOAPService instance per QName is also a singleton
> > which results in a singleton instances for Handlers for the given
> > service. There is no pool for handlers.
> >
> > To deal with multi-threaded cases, we can either make handler classes
> > stateless or users can synchronize the code as needed in their
> > derived classes. I will fix the JAX-RPC Handler code in a similar
> > fashion to the fix provided by Erik.
> >
> > -- Venkat
> >
> >
> > On Wed, 20 Oct 2004 20:34:20 -0400, Davanum Srinivas
> > <da...@gmail.com> wrote:
> > > Venkat,
> > >
> > > Can you please ask someone to look into this issue? (on the
> > Axis side)
> > > I checked in Erik's patch. We will need a similar patch in jax-rpc
> > > handler as well.
> > >
> > > thanks,
> > > dims
> > >
> > > On Tue, 19 Oct 2004 16:29:09 +0200, Dittmann Werner
> > > <we...@siemens.com> wrote:
> > > >
> > > > Dims,
> > > >
> > > > did Axis 1.2 change the behaviour when using handlers? I
> > always was under
> > > > the impression that Axis use a new instance (or out of a
> > pool) fot the
> > > > hanlders,
> > > > but not as a singleton, that is one instance for several threads.
> > > >
> > > > If Axis acts this way (using as singleton) we _must_
> > modify the handlers to
> > > > deal with it.
> > > >
> > > > Regards,
> > > > Werner
> > > >
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Erik_Vanherck@inventivedesigners.com
> > > > [mailto:Erik_Vanherck@inventivedesigners.com]
> > > > Gesendet: Dienstag, 19. Oktober 2004 14:33
> > > > An: fx-dev@ws.apache.org; vreddyp@gmail.com
> > > > Betreff: Re: AW: AW: AW: Bug : Threading issue in wss4j
> > subproject (patch
> > > > incl uded )
> > > >
> > > >
> > > > Well, I don't know if it's a strong requirement to be a
> > singleton. What I
> > > > was seeing was that all the nonce and time values we
> > retrieved in our
> > > > handler were the same indicating a replay attack which
> > wasn't the case as
> > > > the clients all send different nonce values with their
> > SOAP requests. So I
> > > > was looking all over the place for something static. For
> > quite some time I
> > > > suspected the WSSecurityEngine since it's a static member of
> > > > WSDoAllReceiver. However it didn't add up since locking
> > did not remove the
> > > > errors, just changed the sequence or made less or more
> > requests fail.
> > > >
> > > > I did not even realise that there our
> > AuthenticationHandler (derived from
> > > > WSDoAllReceive) was being used as a singleton until I
> > started printing out
> > > > the objects and noticed that our handler was always the
> > same instance. Then
> > > > it occurred to me that most likely Axis would create a
> > single instance of
> > > > the handler and reuse it .. which doesn't seem
> > unreasonable. But you mention
> > > > that Axis handlers should be instantiated for each
> > request over and over.
> > > > Then perhaps, this wasn't a bug in WSS4J but in how Axis
> > deals with the
> > > > handler. I'm using Axis 1.2 beta (the original beta, had
> > to much issues with
> > > > the others) and applied some fixes to it as I found that
> > we were using
> > > > something that was broken and already fixed.
> > > >
> > > > ---------
> > > >
> > > > Erik Vanherck - System Programmer & Designer
> > > > Inventive Designers
> > > > Visit http://www.inventivedesigners.com
> > > > Visit http://www.inventivedesigners.com/scriptura for
> > Scriptura information
> > > > !
> > > >
> > > > Phone: +32 - 3 - 8210170
> > > > Fax: +32 - 3 - 8210171
> > > > Email: Erik_Vanherck@inventivedesigners.com
> > > >
> > > > "Computers in the future may weigh no more than 1.5
> > tons." - Popular
> > > > Mechanics, forecasting the relentless march of science, 1949
> > > >
> > > >
> > > >
> > > > Dittmann Werner <we...@siemens.com>
> > > >
> > > > 10/19/2004 12:57 PM
> > > >
> > > > To "'dims@apache.org'" <di...@apache.org>
> > > >
> > > > cc "Erik_Vanherck@inventivedesigners.com"
> > > > <er...@inventivedesigners.com>, fx-dev@ws.apache.org,
> > > > vreddyp@gmail.com
> > > >
> > > > Subject AW: AW: AW: Bug : Threading issue in wss4j
> > subproject (patch incl
> > > > uded )
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dims,
> > > >
> > > > get a strong one - not the usual "american type of hot
> > > > black water" :-).
> > > >
> > > > However, just had a look at the other handlers (Sender,
> > > > and the JAX-RPC). All handlers were designed with
> > > > the Axis mechanism in mind: instantiate a new handler
> > > > object for each request/response. Thus the handlers
> > > > are not safe to be used in the way Erik described
> > > > (as singleton object in a multi-thread environment).
> > > > In particular the "sender" part of the handlers makes heavy
> > > > use of class variables to reduce the number of parameters
> > > > for method calls.
> > > >
> > > > If it is a strong requirement to provide a singleton
> > > > then:
> > > > - identify all request/response variant data, such
> > > > as username, passwords, certs, etc.
> > > >
> > > > - group them in a private (nested?) class
> > > >
> > > > - for each request/response just instantiate
> > > > this private class. No getters/setters necessary
> > > > if its a private, nested class - access directly.
> > > >
> > > > - use this as a communication object between the
> > > > various method, i.e. put it in the method
> > > > parameters. This is similar to the change
> > > > Erik made for the receiver. But at least
> > > > for the sender it is quite some effort because the
> > > > sender has much more variant data.
> > > >
> > > > Doing all this effectively turns the handlers in
> > > > a class that can be used as a singleton.
> > > >
> > > > Regards,
> > > > Werner
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Davanum Srinivas [mailto:davanum@gmail.com]
> > > > > Gesendet: Dienstag, 19. Oktober 2004 12:42
> > > > > An: Dittmann Werner
> > > > > Cc: Erik_Vanherck@inventivedesigners.com;
> > > > > fx-dev@ws.apache.org; vreddyp@gmail.com
> > > > > Betreff: Re: AW: AW: Bug : Threading issue in wss4j
> > > > > subproject (patch included )
> > > > >
> > > > >
> > > > > Too Early, Need Coffee :) :)
> > > > >
> > > > > -- dims
> > > > >
> > > > >
> > > > > On Tue, 19 Oct 2004 12:37:45 +0200, Dittmann Werner
> > > > > <we...@siemens.com> wrote:
> > > > > > Dims,
> > > > > > the patch is included in the orginal mail from Erik.
> > > > > >
> > > > > > Werner
> > > > > >
> > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > Von: Davanum Srinivas [mailto:davanum@gmail.com]
> > > > > > > Gesendet: Dienstag, 19. Oktober 2004 12:36
> > > > > > > An: Dittmann Werner
> > > > > > > Cc: Erik_Vanherck@inventivedesigners.com;
> > > > > > > fx-dev@ws.apache.org; vreddyp@gmail.com
> > > > > > > Betreff: Re: AW: Bug : Threading issue in wss4j subproject
> > > > > > > (patch included)
> > > > > > >
> > > > > > >
> > > > > > > Werner,
> > > > > > >
> > > > > > > Patch is missing :)
> > > > > > >
> > > > > > > -- dims
> > > > > > >
> > > > > > >
> > > > > > > On Tue, 19 Oct 2004 12:29:04 +0200, Dittmann Werner
> > > > > > > <we...@siemens.com> wrote:
> > > > > > > >
> > > > > > > > Erik,
> > > > > > > >
> > > > > > > > thanks for the info. We'll apply the patch for WSS4J.
> > > > > > > >
> > > > > > > > Venkat, I put you on CC because the same problem exists
> > > > > > > > on the new WSS4JHandler, even worse because WSS4JHandler
> > > > > > > > uses even more Class variables, thus it is not
> > thread safe in
> > > > > > > > the sens Erik describes. Do you see any chance to refactor
> > > > > > > > to code to get rid of the class vaiables?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Werner
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > > Von: Erik_Vanherck@inventivedesigners.com
> > > > > > > > [mailto:Erik_Vanherck@inventivedesigners.com]
> > > > > > > > Gesendet: Dienstag, 19. Oktober 2004 12:11
> > > > > > > > An: fx-dev@ws.apache.org
> > > > > > > > Betreff: Bug : Threading issue in wss4j subproject
> > > > > (patch included)
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi there,
> > > > > > > >
> > > > > > > > Since I could not yet find an entry in the apache bug
> > > > > > > database for the wss4j
> > > > > > > > project (probably since you guys haven't formally released
> > > > > > > yet), I'll use
> > > > > > > > the mailinglist. Please forgive me if it's inapropriate.
> > > > > > > >
> > > > > > > > We've been using the wss4j project in combination
> > with axis
> > > > > > > to enable web
> > > > > > > > service security. We hit a multithreading issue which only
> > > > > > > manifests itself
> > > > > > > > on systems with at least 2 physical cpu's and
> > only when the
> > > > > > > webservice is
> > > > > > > > hit with a lot of requests at the same time. The problem
> > > > > > > was located in
> > > > > > > > org.apache.ws.axis.security.WSDoAllReceiver.
> > > > > > > >
> > > > > > > > We extended our own handler from the WSDoAllReceiver and
> > > > > > > registered that in
> > > > > > > > Axis. Our invoke method, called the super.invoke method of
> > > > > > > WSDoAllReceiver
> > > > > > > > and after that retrieved some security
> > information from the
> > > > > > > messagecontext
> > > > > > > > (for instance the Nonce and the createdTime). The
> > > > > > > WSDoAllReceiver.invoke
> > > > > > > > method saved the MessageContext in a class variable. There
> > > > > > > is however only a
> > > > > > > > single instance of the authenticationhandler
> > present in the
> > > > > > > webapp and it is
> > > > > > > > shared by all the webservice calls in Axis. This causes
> > > > > > > several webservice
> > > > > > > > request chains to flow through the same instance of
> > > > > > > WSDoAllReceiver and as a
> > > > > > > > consequence during the executing of the invoke the
> > > > > > > messagecontext may be
> > > > > > > > changed by another thread.
> > > > > > > >
> > > > > > > > I've attached the patch below
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------
> > > > > > > >
> > > > > > > > Erik Vanherck - System Programmer & Designer
> > > > > > > > Inventive Designers
> > > > > > > > Visit http://www.inventivedesigners.com
> > > > > > > > Visit http://www.inventivedesigners.com/scriptura for
> > > > > > > Scriptura information
> > > > > > > > !
> > > > > > > >
> > > > > > > > Phone: +32 - 3 - 8210170
> > > > > > > > Fax: +32 - 3 - 8210171
> > > > > > > > Email: Erik_Vanherck@inventivedesigners.com
> > > > > > > >
> > > > > > > > "Computers in the future may weigh no more than 1.5
> > > > > tons." - Popular
> > > > > > > > Mechanics, forecasting the relentless march of
> > science, 1949
> > > > > > > > ________________________________
> > > > > > > >
> > > > > > > >
> > > > > > > > Inventive Designers' Email Disclaimer:
> > > > > > > > http://www.inventivedesigners.com/email-disclaimer
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > >
> > > > Inventive Designers' Email Disclaimer:
> > > > http://www.inventivedesigners.com/email-disclaimer
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> >
>
Re: AW: AW: Bug : Threading issue in wss4j subproject (patch incl ude d )
Posted by Er...@inventivedesigners.com.
I just tried it and it did not seem to make a difference. Without the
patch, the threading issues persisted. However I have taken a quick look
at the WSDDeployableItem source and it seems that the scope attribute
should indeed function and provide an instance for each request, so It
must not get enabled. I'll try and look into it, but for the moment it's
extremely hetic over here and I'll have to finish some stuff before I
leave on holiday friday. But Venkat may be right, my patch might not be
needed if the scope attribute functions.
---------
Erik Vanherck - System Programmer & Designer
Inventive Designers
Visit http://www.inventivedesigners.com
Visit http://www.inventivedesigners.com/scriptura for Scriptura
information !
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Erik_Vanherck@inventivedesigners.com
"Computers in the future may weigh no more than 1.5 tons." - Popular
Mechanics, forecasting the relentless march of science, 1949
Venkat Reddy <vr...@gmail.com>
10/26/2004 10:43 AM
Please respond to
Venkat Reddy <vr...@gmail.com>
To
Dittmann Werner <we...@siemens.com>
cc
"dims@apache.org" <di...@apache.org>,
"Erik_Vanherck@inventivedesigners.com"
<er...@inventivedesigners.com>, "fx-dev@ws.apache.org"
<fx...@ws.apache.org>
Subject
Re: AW: AW: Bug : Threading issue in wss4j subproject (patch incl ude d )
hi Werner,
I looked further into this and found something interesting. The code
in org.apache.axis.deployment.wsdd. WSDDDeployableItem indicates that
it is possible to change this default singleton behavior by specifying
an attribute (for <handler> tag?) "scope" with a value of "per-access"
or "per-request". But the WSDD reference documentation at
http://ws.apache.org/axis/java/reference.html does not talk about
this.
However, the default behavior when the undocumented "scope" attribute
is not specified, is just what I described in my earlier mail, which
I've observed in my debugger.
Erik, will it be possible for you to try this scope attribute? If it
works, then we may have to revalidate our proposed code changes to
handlers.
Hope this helps.
Venkat
On Tue, 26 Oct 2004 08:34:16 +0200, Dittmann Werner
<we...@siemens.com> wrote:
> Venkat,
>
> thanks for that info. Is this behaviour somewhere documented
> or described in Axis? It should be in _big_ letters though
> because this restriction has a big impact on the design
> and implementation of Axis handlers. As you stated, they
> should be stateless, in other words Axis handlers shall be classes
> that must not have instance variables (only static data). I even
> would go a step further: the Axis handlers could (should?)
> also have static methods only thus preventing them to use
> instance variables. BTW, this is one of the most restrictive
> designs/requirements I've seen since a long time.
>
> I'm glad to hear that you will fix the handler similar to
> Erik's approach, because synchronizing the whole handler
> would really nullify the performance gain of a
> multi-thread/multi-CPU deployment.
>
> If you need any help pls let me now.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: Venkat Reddy [mailto:vreddyp@gmail.com]
> > Gesendet: Donnerstag, 21. Oktober 2004 13:43
> > An: dims@apache.org
> > Cc: Dittmann Werner; Erik_Vanherck@inventivedesigners.com;
> > fx-dev@ws.apache.org
> > Betreff: Re: AW: Bug : Threading issue in wss4j subproject
> > (patch incl uded )
> >
> >
> > As far as i can see, Axis Engine instance is a singleton and
> > consequently the SOAPService instance per QName is also a singleton
> > which results in a singleton instances for Handlers for the given
> > service. There is no pool for handlers.
> >
> > To deal with multi-threaded cases, we can either make handler classes
> > stateless or users can synchronize the code as needed in their
> > derived classes. I will fix the JAX-RPC Handler code in a similar
> > fashion to the fix provided by Erik.
> >
> > -- Venkat
> >
> >
> > On Wed, 20 Oct 2004 20:34:20 -0400, Davanum Srinivas
> > <da...@gmail.com> wrote:
> > > Venkat,
> > >
> > > Can you please ask someone to look into this issue? (on the
> > Axis side)
> > > I checked in Erik's patch. We will need a similar patch in jax-rpc
> > > handler as well.
> > >
> > > thanks,
> > > dims
> > >
> > > On Tue, 19 Oct 2004 16:29:09 +0200, Dittmann Werner
> > > <we...@siemens.com> wrote:
> > > >
> > > > Dims,
> > > >
> > > > did Axis 1.2 change the behaviour when using handlers? I
> > always was under
> > > > the impression that Axis use a new instance (or out of a
> > pool) fot the
> > > > hanlders,
> > > > but not as a singleton, that is one instance for several threads.
> > > >
> > > > If Axis acts this way (using as singleton) we _must_
> > modify the handlers to
> > > > deal with it.
> > > >
> > > > Regards,
> > > > Werner
> > > >
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Erik_Vanherck@inventivedesigners.com
> > > > [mailto:Erik_Vanherck@inventivedesigners.com]
> > > > Gesendet: Dienstag, 19. Oktober 2004 14:33
> > > > An: fx-dev@ws.apache.org; vreddyp@gmail.com
> > > > Betreff: Re: AW: AW: AW: Bug : Threading issue in wss4j
> > subproject (patch
> > > > incl uded )
> > > >
> > > >
> > > > Well, I don't know if it's a strong requirement to be a
> > singleton. What I
> > > > was seeing was that all the nonce and time values we
> > retrieved in our
> > > > handler were the same indicating a replay attack which
> > wasn't the case as
> > > > the clients all send different nonce values with their
> > SOAP requests. So I
> > > > was looking all over the place for something static. For
> > quite some time I
> > > > suspected the WSSecurityEngine since it's a static member of
> > > > WSDoAllReceiver. However it didn't add up since locking
> > did not remove the
> > > > errors, just changed the sequence or made less or more
> > requests fail.
> > > >
> > > > I did not even realise that there our
> > AuthenticationHandler (derived from
> > > > WSDoAllReceive) was being used as a singleton until I
> > started printing out
> > > > the objects and noticed that our handler was always the
> > same instance. Then
> > > > it occurred to me that most likely Axis would create a
> > single instance of
> > > > the handler and reuse it .. which doesn't seem
> > unreasonable. But you mention
> > > > that Axis handlers should be instantiated for each
> > request over and over.
> > > > Then perhaps, this wasn't a bug in WSS4J but in how Axis
> > deals with the
> > > > handler. I'm using Axis 1.2 beta (the original beta, had
> > to much issues with
> > > > the others) and applied some fixes to it as I found that
> > we were using
> > > > something that was broken and already fixed.
> > > >
> > > > ---------
> > > >
> > > > Erik Vanherck - System Programmer & Designer
> > > > Inventive Designers
> > > > Visit http://www.inventivedesigners.com
> > > > Visit http://www.inventivedesigners.com/scriptura for
> > Scriptura information
> > > > !
> > > >
> > > > Phone: +32 - 3 - 8210170
> > > > Fax: +32 - 3 - 8210171
> > > > Email: Erik_Vanherck@inventivedesigners.com
> > > >
> > > > "Computers in the future may weigh no more than 1.5
> > tons." - Popular
> > > > Mechanics, forecasting the relentless march of science, 1949
> > > >
> > > >
> > > >
> > > > Dittmann Werner <we...@siemens.com>
> > > >
> > > > 10/19/2004 12:57 PM
> > > >
> > > > To "'dims@apache.org'" <di...@apache.org>
> > > >
> > > > cc "Erik_Vanherck@inventivedesigners.com"
> > > > <er...@inventivedesigners.com>, fx-dev@ws.apache.org,
> > > > vreddyp@gmail.com
> > > >
> > > > Subject AW: AW: AW: Bug : Threading issue in wss4j
> > subproject (patch incl
> > > > uded )
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dims,
> > > >
> > > > get a strong one - not the usual "american type of hot
> > > > black water" :-).
> > > >
> > > > However, just had a look at the other handlers (Sender,
> > > > and the JAX-RPC). All handlers were designed with
> > > > the Axis mechanism in mind: instantiate a new handler
> > > > object for each request/response. Thus the handlers
> > > > are not safe to be used in the way Erik described
> > > > (as singleton object in a multi-thread environment).
> > > > In particular the "sender" part of the handlers makes heavy
> > > > use of class variables to reduce the number of parameters
> > > > for method calls.
> > > >
> > > > If it is a strong requirement to provide a singleton
> > > > then:
> > > > - identify all request/response variant data, such
> > > > as username, passwords, certs, etc.
> > > >
> > > > - group them in a private (nested?) class
> > > >
> > > > - for each request/response just instantiate
> > > > this private class. No getters/setters necessary
> > > > if its a private, nested class - access directly.
> > > >
> > > > - use this as a communication object between the
> > > > various method, i.e. put it in the method
> > > > parameters. This is similar to the change
> > > > Erik made for the receiver. But at least
> > > > for the sender it is quite some effort because the
> > > > sender has much more variant data.
> > > >
> > > > Doing all this effectively turns the handlers in
> > > > a class that can be used as a singleton.
> > > >
> > > > Regards,
> > > > Werner
> > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Davanum Srinivas [mailto:davanum@gmail.com]
> > > > > Gesendet: Dienstag, 19. Oktober 2004 12:42
> > > > > An: Dittmann Werner
> > > > > Cc: Erik_Vanherck@inventivedesigners.com;
> > > > > fx-dev@ws.apache.org; vreddyp@gmail.com
> > > > > Betreff: Re: AW: AW: Bug : Threading issue in wss4j
> > > > > subproject (patch included )
> > > > >
> > > > >
> > > > > Too Early, Need Coffee :) :)
> > > > >
> > > > > -- dims
> > > > >
> > > > >
> > > > > On Tue, 19 Oct 2004 12:37:45 +0200, Dittmann Werner
> > > > > <we...@siemens.com> wrote:
> > > > > > Dims,
> > > > > > the patch is included in the orginal mail from Erik.
> > > > > >
> > > > > > Werner
> > > > > >
> > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > Von: Davanum Srinivas [mailto:davanum@gmail.com]
> > > > > > > Gesendet: Dienstag, 19. Oktober 2004 12:36
> > > > > > > An: Dittmann Werner
> > > > > > > Cc: Erik_Vanherck@inventivedesigners.com;
> > > > > > > fx-dev@ws.apache.org; vreddyp@gmail.com
> > > > > > > Betreff: Re: AW: Bug : Threading issue in wss4j subproject
> > > > > > > (patch included)
> > > > > > >
> > > > > > >
> > > > > > > Werner,
> > > > > > >
> > > > > > > Patch is missing :)
> > > > > > >
> > > > > > > -- dims
> > > > > > >
> > > > > > >
> > > > > > > On Tue, 19 Oct 2004 12:29:04 +0200, Dittmann Werner
> > > > > > > <we...@siemens.com> wrote:
> > > > > > > >
> > > > > > > > Erik,
> > > > > > > >
> > > > > > > > thanks for the info. We'll apply the patch for WSS4J.
> > > > > > > >
> > > > > > > > Venkat, I put you on CC because the same problem exists
> > > > > > > > on the new WSS4JHandler, even worse because WSS4JHandler
> > > > > > > > uses even more Class variables, thus it is not
> > thread safe in
> > > > > > > > the sens Erik describes. Do you see any chance to refactor
> > > > > > > > to code to get rid of the class vaiables?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Werner
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > > Von: Erik_Vanherck@inventivedesigners.com
> > > > > > > > [mailto:Erik_Vanherck@inventivedesigners.com]
> > > > > > > > Gesendet: Dienstag, 19. Oktober 2004 12:11
> > > > > > > > An: fx-dev@ws.apache.org
> > > > > > > > Betreff: Bug : Threading issue in wss4j subproject
> > > > > (patch included)
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi there,
> > > > > > > >
> > > > > > > > Since I could not yet find an entry in the apache bug
> > > > > > > database for the wss4j
> > > > > > > > project (probably since you guys haven't formally released
> > > > > > > yet), I'll use
> > > > > > > > the mailinglist. Please forgive me if it's inapropriate.
> > > > > > > >
> > > > > > > > We've been using the wss4j project in combination
> > with axis
> > > > > > > to enable web
> > > > > > > > service security. We hit a multithreading issue which only
> > > > > > > manifests itself
> > > > > > > > on systems with at least 2 physical cpu's and
> > only when the
> > > > > > > webservice is
> > > > > > > > hit with a lot of requests at the same time. The problem
> > > > > > > was located in
> > > > > > > > org.apache.ws.axis.security.WSDoAllReceiver.
> > > > > > > >
> > > > > > > > We extended our own handler from the WSDoAllReceiver and
> > > > > > > registered that in
> > > > > > > > Axis. Our invoke method, called the super.invoke method of
> > > > > > > WSDoAllReceiver
> > > > > > > > and after that retrieved some security
> > information from the
> > > > > > > messagecontext
> > > > > > > > (for instance the Nonce and the createdTime). The
> > > > > > > WSDoAllReceiver.invoke
> > > > > > > > method saved the MessageContext in a class variable. There
> > > > > > > is however only a
> > > > > > > > single instance of the authenticationhandler
> > present in the
> > > > > > > webapp and it is
> > > > > > > > shared by all the webservice calls in Axis. This causes
> > > > > > > several webservice
> > > > > > > > request chains to flow through the same instance of
> > > > > > > WSDoAllReceiver and as a
> > > > > > > > consequence during the executing of the invoke the
> > > > > > > messagecontext may be
> > > > > > > > changed by another thread.
> > > > > > > >
> > > > > > > > I've attached the patch below
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------
> > > > > > > >
> > > > > > > > Erik Vanherck - System Programmer & Designer
> > > > > > > > Inventive Designers
> > > > > > > > Visit http://www.inventivedesigners.com
> > > > > > > > Visit http://www.inventivedesigners.com/scriptura for
> > > > > > > Scriptura information
> > > > > > > > !
> > > > > > > >
> > > > > > > > Phone: +32 - 3 - 8210170
> > > > > > > > Fax: +32 - 3 - 8210171
> > > > > > > > Email: Erik_Vanherck@inventivedesigners.com
> > > > > > > >
> > > > > > > > "Computers in the future may weigh no more than 1.5
> > > > > tons." - Popular
> > > > > > > > Mechanics, forecasting the relentless march of
> > science, 1949
> > > > > > > > ________________________________
> > > > > > > >
> > > > > > > >
> > > > > > > > Inventive Designers' Email Disclaimer:
> > > > > > > > http://www.inventivedesigners.com/email-disclaimer
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > >
> > > > Inventive Designers' Email Disclaimer:
> > > > http://www.inventivedesigners.com/email-disclaimer
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> >
>
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer