axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley" <davidills...@gmail.com>
Subject Re: [Axis2] Adding ClusterManager code the the codebase
Date Wed, 07 Feb 2007 19:14:41 GMT
Having container and service management sounds totally reasonable and
sounds like it allows the cluster management to be decoupled from the
kernel which I think is probably a good thing.

David


On 07/02/07, Rajith Attapattu <rajith77@gmail.com> wrote:
> David,
>
> >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
>
> It is expensive, but it maybe useful in certain uses cases. As you pointed
> if there is a long running service invocation, then waiting till the end to
> replicate will obviously increase the chances of conflicts when the same
> service gets multiple hits.
>
> So as I mentioned if we provide the ability to choose the replication
> stratergy (Container managed or Service Managed) then the service author can
> make an informed decesion about when to replicate and how often to
> replicate.
> It could be that if they want replication after every property change or
> maybe after a bunch of property changes.
> This gives a lot of flexibility.
>
> // use case 1
> ctx.setProperty("acct_no","A235523");
> clusterManager.updateState();
>
> // use case2
> ctx.setProperty("acct_no","A235523");
> //....... do more stuff
> ctx.setProperty("ref_no","FSDSGSSG");
> clusterManager.updateState ();
>
> Quite often we can't make all the decesions about functionality at design
> time and certainly one size doesn't fit all. So if we can provide a sensible
> default and the ability(responsibility) to override  the default with what
> makes more sense in a given situation we can mitigate some of the risks and
> performance issues in more acceptable manner.
>
> What do you think?
>
>
>
> 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
> >
> >
>
>


-- 
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