yes,this is a performance hit. I'm doing some performance improvements to Sandesha2. Will be converting the Invoker and Sender into thread pools.
Thanks for the comments.
Chamikara
On 8/3/06, L YSSELSTEIN <[EMAIL PROTECTED]> wrote:
Hi Chamikara,
Ok. I understand.
As a last question.
I was looking through the InOrderInvoker code and saw a loop with a sleep time of 1 second for each loop. Won't this break performance?
Also, are all sequences of messages processed by this one thread?
Thanks,
Lennard.
----- Original Message -----
From: Chamikara Jayalath < [EMAIL PROTECTED]>
Date: Thursday, August 3, 2006 2:16 pm
Subject: Re: [Axis2] Sandesha2 and Rampart module
> Hi Lennard,
>
> Please see my comments below,
>
>
> On 8/3/06, L YSSELSTEIN <[EMAIL PROTECTED]> wrote:
> >
> > Hi Chamikara,
> >
> > Basically, what we are trying to do is this. When the first
> invocation> passes the security handler, the handler checks the
> user credentials.
> > If the username/password is valid, the userprofile is retrieved
> from Ldap
> > and stored in a context for future reference.
> >
> > From the security handler we cannot store it in the message
> context. The
> > callback interface does not give a handle to the message context.
> >
> > This leaves us with the following questions.
> > How can we store the userprofile in the current messagecontext?
>
>
>
> I guess ruchith will answer this.
>
>
> Also, why does sandesha skip the security phase when resuming a
> message in
> > the InOrderInvoker?
>
>
>
> Sandesha does not skip any phases. It simply does not repeatedly
> send it
> through the same Phase.
>
> If you consider the Application Message when Sandesha2 is not
> engaged it
> will go through following set of phases.
>
> Transport
> Security
> PreDispatch
> Dispatch
> RMPhase
> OperationOutPhase
> RMPhase
> OperationInPhase
>
>
> When RM is present it will go through the usual set of Phases but
> sinceInOrder invocation is enabled message will be paused at the
> RMPhase. So it
> will go through following phases in the first go.
>
> Transport
> Security
> PreDispatch
> Dispatch
> RMPhase
>
>
> Later Sandesha InOrderInvoker thread will resume the message. (this
> guarantees that the messages are invoked in the order of RM Message
> Numbers). So the message will go through the rest of the Phases.
>
> RMPhase
> OperationInPhase
>
>
> Thanks,
> >
> > Lennard.
> >
> > ----- Original Message -----
> > From: Chamikara Jayalath <[EMAIL PROTECTED]>
> > Date: Thursday, August 3, 2006 11:31 am
> > Subject: Re: [Axis2] Sandesha2 and Rampart module
> >
> > > Hi Lennard,
> > >
> > > I'm not fully getting it. What do u mean by a Security Context.
> To my
> > > knwoedge security handler saves all the information to the message
> > > context.
> > > The storage framework should not loose any information when
> saving and
> > > retrieving information. In the in-memory implementation Message
> > > Context is
> > > simply stored in a HashMap and properties and all other
> information> > shouldbe there when the message is resumed.
> > >
> > > R u saying that some of these properties are lost when the
> message is
> > > resumed by the Sandesha2 InOrderInvoker ?
> > >
> > > Chamikara
> > >
> > >
> > > On 8/3/06, L YSSELSTEIN < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Chamikara,
> > > >
> > > > Ok, I understand.
> > > > During debugging I can see the first invocation to be passed
> > > through the
> > > > security phase.
> > > > The problem is that during the security phase the security
> > > handler is
> > > > adding user information to a acegi security context.
> > > > This context only exists during each invocation.
> > > > Because during the second invocation this security handler is
> not> > called,> no user information is available. Because of this
> the soap
> > > call cannot be
> > > > processed correctly.
> > > > Can we add the user information to the storage framework of
> > > sandesha2?>
> > > > Thanks,
> > > >
> > > > Lennard.
> > > >
> > > > ----- Original Message -----
> > > > From: Chamikara Jayalath < [EMAIL PROTECTED]>
> > > > Date: Thursday, August 3, 2006 5:30 am
> > > > Subject: Re: [Axis2] Sandesha2 and Rampart module
> > > >
> > > > > Hi Lennard,
> > > > >
> > > > > There is no way a message could reach the RM Phase without
> going> > > > trough the
> > > > > global phases (this include Transport, Security, Dispatch
> phases).> > > > If you
> > > > > have enable In-Order invocation in Sandesha2 (which is the
> > > > > default), it has
> > > > > following behaviour.
> > > > >
> > > > > Every incoming application will be paused at the RMPhase.
> So in
> > > the> > firstinvocation the messages will go through the Global
> > > Phases and the
> > > > > Application Phases upto the RM Phase. Later Sandesha2 will
> invoke> > > > application message in the order of Message Numbers.
> So if you are
> > > > > monitorning in the second invocation you will only see a
> set of
> > > > > Applicationlevel Phases. But this message must have gone
> through> > > > the Security Phase in
> > > > > its first invocation. Therefore this does not produce a
> > > security hole.
> > > > >
> > > > > Chamikara
> > > > >
> > > > >
> > > > >
> > > > > On 8/2/06, Lennard IJsselstein < [EMAIL PROTECTED]>
> > > wrote:> > >
> > > > > > Hi Ruchith,
> > > > > >
> > > > > > I also expected the phases you mentioned. But when I
> check the
> > > > > > executionChain in the messagecontext while debugging I only
> > > see the
> > > > > > phases I mentioned before. For some reason sandesha2
> alters the
> > > > > phases> of the messages during invocation.
> > > > > >
> > > > > > Before sandesha2 was added the execution chain was as you
> > > described.> > >
> > > > > > Thanks,
> > > > > >
> > > > > > Lennard.
> > > > > > ||
> > > > > > Ruchith Fernando wrote:
> > > > > >
> > > > > > > Hi Lennard,
> > > > > > >
> > > > > > > On 8/2/06, Lennard IJsselstein
> < [EMAIL PROTECTED]>> > > > wrote:> >
> > > > > > >> Hi all,
> > > > > > >>
> > > > > > >> We are currently using both the Sandesha2 and the Rampart
> > > module.> > > >> The problem we are facing now is when we send a
> > > webservice> > call the
> > > > > > >> following happens:
> > > > > > >> - The CreateSequence soapmessage is send to the Axis2
> servlet> > > > and is
> > > > > > >> correctly processed.
> > > > > > >> As expected the following axis2 phases are hit:
> > > > > > >> Transport, Security, RMPhase OperationInPhase
> > > > > > >> - The soapmessage with the actual webservice call is
> send to
> > > > > the Axis2
> > > > > > >> servlet.
> > > > > > >> The following phases are hit:
> > > > > > >> soapmonitorPhase, RMPhase, OperationInPhase.
> > > > > > >> - The TerminateSequence soapmessage is send to the Axis2
> > > > > servlet and is
> > > > > > >> correctly processed.
> > > > > > >> As expected the following axis2 phases are hit:
> > > > > > >> Transport, Security, RMPhase, OperationInPhase
> > > > > > >>
> > > > > > >> Our question is:
> > > > > > >> Why does the 'normal' soapmessage not run through the
> > > > > Security> >> phase?
> > > > > > >
> > > > > > >
> > > > > > > IMHO the request message should go through the following
> > > phases :
> > > > > > > Transport, Security, PreDispatch, Dispatch,
> OperationInPhase> > > > > >
> > > > > > > Transport and Dispatch phases are used to dispatch and
> since> > > > you have
> > > > > > > not mentioned any of these in the phases that the soap
> message> > > > hit I
> > > > > > > wonder how the request reached the OperationInPhase.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Ruchith
> > > > > > >
> > > > > >
> > > > > > ----------------------------------------------------------
> ----
> > > ----
> > > > > ---
> > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: axis-user-
> [EMAIL PROTECTED]> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --------------------------------------------------------------
> ----
> > > ---
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> >
> > ------------------------------------------------------------------
> ---
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
