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 22:08:25 GMT
>From the recent discussion, I believe the container managed version
could manage without any kernel changes. It's the service managed
version which might need the ClusterManager interface in kernel as the
service code would have to have at least an interface to drive. It
can't (I think) simply live in the module because that isn't in the
classpath for services, either at development or run-time.

David

On 07/02/07, Davanum Srinivas <davanum@gmail.com> wrote:
> I don't see any clustering code in Geronimo kernel or tomcat kernel or
> anywhere else (HTTPD?) Guess, i will have to read thru all the emails
> again :) will get back after that.
>
> thanks,
> dims
>
> On 2/7/07, Rajith Attapattu <rajith77@gmail.com> wrote:
> > Dims,
> >
> > The cluster manager interface (proposal bought by chamikara and chathura)
> > seem to be the only agreeable solution that came out of the whole
> > disscussion. I am not saying that there is no other way and certainly open
> > for suggestions :)
> >
> > The problem with notifications is, that replication decesions can be taken
> > out side of the ctx heirachy.
> > For example from the engine (after flowComplete()) or by the service author
> > (check the previous 4 emails in the thread).
> > Therefore notifications is not sufficient.
> >
> > So ClusterManager interface seems to be the only way we can do an
> > abstraction with the minimum impact on the code.
> > It's only a single interface added to the kernal :)
> >
> > Dims what are the reason you think it should not be in the kernal ??
> >
> > Regards,
> >
> > Rajith
> >
> >
> > On 2/7/07, Davanum Srinivas < davanum@gmail.com> wrote:
> > > If only we can figure out a way *not* to define the cluster manager
> > > interface in kernel...i'd be happier. can't we extend the
> > > notifications stuff that we are doing now?
> > >
> > > -- dims
> > >
> > > On 2/7/07, David Illsley <davidillsley@gmail.com > wrote:
> > > > 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
> > > >
> > > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> >
> >
>
>
> --
> 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


Mime
View raw message