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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> wrote:
> > > > > David,
> > > > >
> > > > > Exactly that was my concern.
> > > > > comments inline.
> > > > >
> > > > > On 2/7/07, David Illsley <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED] > wrote:
> > > > > > > > Yep. David beat me to it :)
> > > > > > > >
> > > > > > > > On 2/7/07, David Illsley < [EMAIL PROTECTED]> wrote:
> > > > > > > > > Can't you use flowComplete() in the In_ONLY case?
> > > > > > > > > David
> > > > > > > > >
> > > > > > > > > On 07/02/07, Rajith Attapattu < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>
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:
> > > > > > > > > > [EMAIL PROTECTED]
> > > > > > > > > > > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > David Illsley - IBM Web Services Development
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > [EMAIL PROTECTED]
> > > > > > > > > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web
Services
> > > > > Developers
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > [EMAIL PROTECTED]
> > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > David Illsley - IBM Web Services Development
> > > > > >
> > > > > >
> > > > >
> > >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > > > [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > David Illsley - IBM Web Services Development
> > > >
> > > >
> > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
