axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [Axis2] Adding ClusterManager code the the codebase
Date Wed, 07 Feb 2007 17:15:54 GMT
David,

I certainly think it's a resonable limitation. And we should document it
clearly.

But even in the case of HTTP sessions doesn't this problem exist? If a
service author passes the HTTPSession to a different thread, other than the
current thread of control, and a object in the scope of the other thread
later modifies a session attribute (provided that the session is alive) then
this same problem would exist ? am I correct ?
I think the above method is discouraged but people may end up doing it.

One way of solving this problem is to have a configurable option of how
state change is handled.
a) Container managed (in this case we notify a state change when the
MessageReceiver thread returns)
b) Service managed (in this the service author is responsible for calling a
method to trigger the updateState method)

option "b" would work in the case of asynchronous invocations that may not
finish when flowControl is called.
We can have option "a" as default and clearly document this behaviour so
people have the flexibility to choose according to their requirements.

Regards,

Rajith

On 2/7/07, David Illsley <davidillsley@gmail.com> wrote:
>
> If it's that expensive, and given that it probably gets even more
> difficult if one client can easily hit the same service multiple times
> concurrently, would it be a reasonable limitation for the first
> version that the MessageReceivers which return before the business
> logic is complete are not supported?
>
> David
>
> On 07/02/07, Rajith Attapattu <rajith77@gmail.com> wrote:
> > David,
> >
> > Exactly that was my concern.
> > comments inline.
> >
> > On 2/7/07, David Illsley <davidillsley@gmail.com > wrote:
> > > That's a difficult question to answer... flowComplete is called by the
> > > AxisEngine after the MessageReceiver returns from invoke(). So in the
> > > general case, yes, flowComplete will occur after the business logic is
> > > complete.
> > [RA] I currently (in the branch) have choosen do so in the engine just
> below
> > flowComplete() as the replication point for "state update".
> > but as mentioned below it's not sufficient.
> > > If, however, the MessageReceiver does work on a separate thread and
> > > returns beffore the business logic is complete then flowComplete will
> > > occur too early. However, I'd guess you'll struggle with this problem
> > > with any approach.
> > That is true. And the way to tackle is to track and replicate individual
> > setProperty methods as and when they happen.
> > But this is expensive and will have a performance impact :(
> >
> >
> > > David
> > >
> > > On 07/02/07, Rajith Attapattu <rajith77@gmail.com> wrote:
> > > > David and Dims,
> > > >
> > > > Sorry I should have been more clear. What I meant by end of
> invocation
> > is to
> > > > identify when the business logic has finished executing.
> > > > Bcos during the course of web service operation, the web service
> could
> > be
> > > > updating state.
> > > >
> > > > So does flowComplete() get executed after this ??
> > > > I thought (I maybe wrong, please correct me) flowComplete() can get
> > executed
> > > > before "business logic" if finsihed executing.
> > > >
> > > > Regards,
> > > >
> > > > Rajith Attapattu
> > > > Red Hat.
> > > >
> > > >
> > > >
> > > > On 2/7/07, Davanum Srinivas <davanum@gmail.com> wrote:
> > > > > Yep. David beat me to it :)
> > > > >
> > > > > On 2/7/07, David Illsley < davidillsley@gmail.com> wrote:
> > > > > > Can't you use flowComplete() in the In_ONLY case?
> > > > > > David
> > > > > >
> > > > > > On 07/02/07, Rajith Attapattu < rajith77@gmail.com> wrote:
> > > > > > > Deepal,
> > > > > > >
> > > > > > > I tried this approach and failed badly.
> > > > > > > If it is only a IN_ONLY operation it is very difficult
to
> figure
> > out
> > > > when to
> > > > > > > determine if an invocation is over or not.
> > > > > > > For IN_OUT we can have handler in the inflow and outflow,
but
> > > > certainly
> > > > > > > difficult in the above scenario.
> > > > > > >
> > > > > > > rajith
> > > > > > >
> > > > > > > On 2/7/07, Deepal Jayasinghe <deepal@opensource.lk>
wrote:
> > > > > > > > Hi Chamikara ;
> > > > > > > > Do we really need to the listen to the event changes
?
> > > > > > > >
> > > > > > > > As I know whenever a message coming into the system
there
> will
> > be
> > > > many
> > > > > > > > getProperty and setPoropert method calls. That simply
impl
> you
> > that
> > > > > > > > there are a number of context changes for a req. So
you need
> to
> > > > update
> > > > > > > > the replicas irrespective of the message, therefore
you do
> not
> > need
> > > > to
> > > > > > > > listen to specific event . What you can do is , you
can add
> a
> > > > handler
> > > > > > > > (or handlers) to update the replicas when message
coming to
> the
> > > > system
> > > > > > > > and when a message going out from the system.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Deepal
> > > > > > > >
> > > > > > > > > Hi Deepal,
> > > > > > > > >
> > > > > > > > > The problem we had in clustering is having the
listen to
> > specific
> > > > > > > > > events in the Axis2 execution. For example context
> creation,
> > > > context
> > > > > > > > > removal, mep completion. So it is not possible
to do it
> with a
> > > > module
> > > > > > > > > based approach :-(.
> > > > > > > > >
> > > > > > > > > But performance is certainly in our mind.
> > > > > > > > >
> > > > > > > > > Chamikara
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > axis-dev-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > David Illsley - IBM Web Services Development
> > > > > >
> > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > axis-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
> > Developers
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > axis-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > David Illsley - IBM Web Services Development
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Mime
View raw message