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 Dittmann Werner <we...@siemens.com> on 2004/10/19 12:57:45 UTC
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/
>
Re: AW: AW: AW: Bug : Threading issue in wss4j subproject (patch incl uded
)
Posted by Er...@inventivedesigners.com.
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