Hi Deepal,
What kind of notifications do u mean ?
We will need to listen to event changes like context creation, removal and
property updates. But this does not hv to be done in every property get, set
method call if ask the service authors to do something like following (as
Rajith mentioned),
context1.setProperty();
context2.setProperty();
clusterManager.updateState();
We can further improve this by hiding the updateState() call in a flush()
method of the AbstractContext. This way clustering layer become almost
transparent to the user. I.e. they will not hv to do any changes to their
service code to make them clusterable.
Axis2 should recommend service authors to periodically 'flush()' the
contexts which they store their service state in (please suggest a good
name for this method if this sounds bad). This method could be used not just
for clustering but for any other work that has to done to make the contexts
synchronized.
Chamikara
On 2/8/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi All;
I also like if we can do cluster management w.o changing the kernel ,
and in the meantime I do not like to have the notification capability as
well. If you are trying to do so , then we need to notify whenever we
change a property , context changes etc etc.. , so that going to cost us
a lot. Therefore I am -1 on extending the notification stuff.
btw do we have a wiki or smt explaining the stuff you are going to
change in the kernel module , then that will be very helpful for us to
figure out whether we can do those changes or not.
Thanks
Deepal
Davanum Srinivas 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]
>>
>>
>
>
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
