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]
