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 Davanum Srinivas <da...@gmail.com> on 2004/10/21 02:34:20 UTC
Re: AW: Bug : Threading issue in wss4j subproject (patch incl uded )
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: Bug : Threading issue in wss4j subproject (patch incl uded )
Posted by Venkat Reddy <vr...@gmail.com>.
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/
>