Hi All,
As we discussed and agreed sometime back we will be adding an abstraction
layer to Axis2 to make it possible to transparently plug-in different
clustering implementations. abstraction was named 'ClusterManager' and
the interface that was proposed is given in [1] (with some slight
modifications).
I am hoping to go a step forward my adding this interface to the Axis2 code
base. At initiation Axis2 will load a ClusterManager implementation object
(if configured) and will call the methods of it whenever respective events
occur.
Chamikara
[1] ClusterManager interface
public abstract class ClusterManager {
public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context, String
propertyName, propertyValue);
public abstract void removeProperty (AbstractContext context, String
propertyName);
public abstract void touchProperty (AbstractContext context, String
propertyName);
public abstract void commit ();
}

Chamikara,

I do have half baked impl sitting on my laptop based on a slightly modified
cluster manager.
I will soon check this into a branch and you guys can then start playing
around with it.

Sorry about this taking time, I was so occupied with the Qpid work.

Regarda,

Rajith

2/1/07, Chamikara Jayalath <chamikaramj (AT) gmail (DOT) comwrote:

Hi All,

As we discussed and agreed sometime back we will be adding an abstraction
layer to Axis2 to make it possible to transparently plug-in different
clustering implementations. abstraction was named 'ClusterManager' and
the interface that was proposed is given in [1] (with some slight
modifications).

I am hoping to go a step forward my adding this interface to the Axis2
code base. At initiation Axis2 will load a ClusterManager implementation
object (if configured) and will call the methods of it whenever respective
events occur.

Chamikara
--
[1] ClusterManager interface

public abstract class ClusterManager {

public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context, String
propertyName, propertyValue);
public abstract void removeProperty (AbstractContext context, String
propertyName);
public abstract void touchProperty (AbstractContext context, String
propertyName);
public abstract void commit ();

}
>
>
>

Rajith,

What we are adding here is the interface that we agreed sometime back. So
nothing prevents your implementation from working on top of that.

BTW, what were the modifications that were done to the interface.

Chamikara

2/2/07, Rajith Attapattu <rajith77 (AT) gmail (DOT) comwrote:

Chamikara,

I do have half baked impl sitting on my laptop based on a slightly
modified cluster manager.
I will soon check this into a branch and you guys can then start playing
around with it.

Sorry about this taking time, I was so occupied with the Qpid work.

Regarda,

Rajith

2/1/07, Chamikara Jayalath <chamikaramj (AT) gmail (DOT) comwrote:

Hi All,

As we discussed and agreed sometime back we will be adding an
abstraction layer to Axis2 to make it possible to transparently plug-in
different clustering implementations. abstraction was named
'ClusterManager' and the interface that was proposed is given in [1] (with
some slight modifications).

I am hoping to go a step forward my adding this interface to the Axis2
code base. At initiation Axis2 will load a ClusterManager implementation
object (if configured) and will call the methods of it whenever respective
events occur.

Chamikara
--
[1] ClusterManager interface

public abstract class ClusterManager {

public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context, String
propertyName, propertyValue);
public abstract void removeProperty (AbstractContext context, String
propertyName);
public abstract void touchProperty (AbstractContext context, String
propertyName);
public abstract void commit ();

}
>
>
>
>

Yes the implementation is build on top of the cluster manager.
I changed the method signatures slightly. But it's only a prototype.

I will not check it into the trunk, untill we run a successfull demo and
everybody is comfortable.
I will put that in a branch and then you guys can also make changes.

Regards,

Rajith

2/2/07, Chamikara Jayalath <chamikaramj (AT) gmail (DOT) comwrote:

Rajith,

What we are adding here is the interface that we agreed sometime back. So
nothing prevents your implementation from working on top of that.

BTW, what were the modifications that were done to the interface.

Chamikara
>
>
>
2/2/07, Rajith Attapattu <rajith77 (AT) gmail (DOT) comwrote:

Chamikara,

I do have half baked impl sitting on my laptop based on a slightly
modified cluster manager.
I will soon check this into a branch and you guys can then start playing
around with it.

Sorry about this taking time, I was so occupied with the Qpid work.

Regarda,

Rajith

2/1/07, Chamikara Jayalath < chamikaramj (AT) gmail (DOT) comwrote:

Hi All,

As we discussed and agreed sometime back we will be adding an
abstraction layer to Axis2 to make it possible to transparently plug-in
different clustering implementations. abstraction was named
'ClusterManager' and the interface that was proposed is given in [1] (with
some slight modifications).

I am hoping to go a step forward my adding this interface to the Axis2
code base. At initiation Axis2 will load a ClusterManager implementation
object (if configured) and will call the methods of it whenever respective
events occur.

Chamikara
--
[1] ClusterManager interface

public abstract class ClusterManager {

public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context, String
propertyName, propertyValue);
public abstract void removeProperty (AbstractContext context,
String propertyName);
public abstract void touchProperty (AbstractContext context,
String propertyName);
public abstract void commit ();

}
>
>
>
>
>

Chamikara,

The code is available under branches/clustering.

Here are the changes I made to ClusterManager interface. course what I
did is just a prototype so feel free to experiment and change things.

public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);

public abstract void updateState (AbstractContext context);

As you can the changes are where I replaced the add/remove/touch property
methods with a single updateState method.
I found it to be very cumbersome/expensive to intercept the property changes
and keep track of them on a per occurence basis.
Instead a single updateState method called at the end of the invocation
provides better alternative to handle the state changes. YMMV.

looking forward to your comments on the prototype.

Regards,

Rajith

2/2/07, Rajith Attapattu <rajith77 (AT) gmail (DOT) comwrote:
Yes the implementation is build on top of the cluster manager.
I changed the method signatures slightly. But it's only a prototype.

I will not check it into the trunk, untill we run a successfull demo and
everybody is comfortable.
I will put that in a branch and then you guys can also make changes.

Regards,

Rajith
>
>
>
2/2/07, Chamikara Jayalath < chamikaramj (AT) gmail (DOT) comwrote:
Rajith,

What we are adding here is the interface that we agreed sometime back.
So nothing prevents your implementation from working on top of that.

BTW, what were the modifications that were done to the interface.

Chamikara
>
>
>
>
>
2/2/07, Rajith Attapattu < rajith77 (AT) gmail (DOT) comwrote:
Chamikara,

I do have half baked impl sitting on my laptop based on a slightly
modified cluster manager.
I will soon check this into a branch and you guys can then start
playing around with it.

Sorry about this taking time, I was so occupied with the Qpid work.

Regarda,

Rajith
>
>
>
2/1/07, Chamikara Jayalath < chamikaramj (AT) gmail (DOT) comwrote:
Hi All,

As we discussed and agreed sometime back we will be adding an
abstraction layer to Axis2 to make it possible to transparently plug-in
different clustering implementations. abstraction was named
'ClusterManager' and the interface that was proposed is given in [1] (with
some slight modifications).

I am hoping to go a step forward my adding this interface to the
Axis2 code base. At initiation Axis2 will load a ClusterManager
implementation object (if configured) and will call the methods of it
whenever respective events occur.

Chamikara
--
[1] ClusterManager interface

public abstract class ClusterManager {

public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context,
String propertyName, propertyValue);
public abstract void removeProperty (AbstractContext context,
String propertyName);
public abstract void touchProperty (AbstractContext context,
String propertyName);
public abstract void commit ();

}
>
>
>
>
>
>
>
>
>

Hi Rajith,

Please find my comments below marked with [SK]

Thanks
Sanjaya

Monday 05 February 2007 20:28, Rajith Attapattu wrote:
Hello Sanjaya,

comments are inline marked with [RA]

Rajith Attapattu
Red Hat.
--
In a distributed scenario having the ability to handle concurrency is very

important. How do you tackle conflicting updates? There should be a way
to rollback/commit. In otherwords the interface should be
transactionable. Also
having the ability to distinguish between read-only vs read/write access
to
the context is an opportunity to apply some optimizations to the actual
implementation.

[RA] This is where locking comes into picture. There are 2 different types
of locking mechanisms, pesimistic locking and optimistic locking.
Most databases use pesimistic locking and is expensive and slow, while
optimistic locking is relatively cheap. Negotiating concurrency issues is
best handled by the underlying infrastructure. Apache Tribes (the impl I
used and is using total ordering) and Richochet (garuntees are lower than
VS) are both low level reliable multicasting infrastructure and have no
support for locking.
WADI from codehaus specializes in locking. But for now we decided sometime
back to go without any locking for the following reasons.

WADI is written for session replication and is difficult to adapt as is to
the context replication scenario we have with out some modifications.
Sanjiva and I debated on this issue for a while and agreed that we live
with the concurrency issues for the time being.
What we can do is to try to utilise WADI to provide locking support for our
implementation as the second step.

[SK] Locking, which comes under pessimistic concurrency control is good for
databases due to the high probability of conflicts. concurrency
work best when there are high number of reads with intermittent writes. But
which way to go depends on what do we expect in the context. We can put some
constrains or let the end user to configure it. But I don't think this is a
good place to over engineer things. We should keep this very simple. I guess
this is similar to the HTTPSession. We don't expect application developers to
use the HTTPSession as their in memory database. Am I right?

Detecting conflicts and rolling back is best decided at the infrastructure
level (for example WADI) rather than at the application level.
The logic for rolling back is complicated and if a rollback occurs we need
to notify the web service client. Currently there is no standard WS way of
doing that.
(Not sure WS-Context has anything regarding this)

We can have dirty reads (cheap) and do locking only for updates. But ymmv.

[SK] From the application developer point of view Axis2 itself is
infrastructure. we should not pull him in to the picture. However
application code which implements a refine requirement can provide some hints
(like whether its K to have dirty reads).

I suggest that this interface should provide some means to do

that too.

[RA] As I said, the application should not be figuring out wether to
rollback or not, the infrastructure should.
so it should be the reverse. there should be a way for the infrastructure
to notify the client about a rollback.

[SK] Agreed. But it will be good to shoot for some thing where there is no
need to rollback.

I think the intention of abstracting the cluster manager to an interface is

to
provide extensibility so that we can have different cluster manager
implementations based on different group communication techniques. But I
think right now the interface has introduced more coupling.

Following is an approach which could reduce coupling and enable more
flexibility and extensibility.

Do we have the ability to register a listener to the Context? What I mean
is
an instance of a class which implements an interface ContextListner. The
ContextListner has one method "notify" which take a parameter of
type "Event". The ClusterManager interface can extend the ContextListner
(BTW, Should ClusterManger be an abstract class?)

[RA} unfortunately your replication points can be outside of the context
heirachy.

[SK] I am sorry, I did not understand this. What else do you want to
replicate. In a cluster what we need is state information to be replicated.
There are two places where usually an application developer maintain state,
the session and the database. I guess with the Axis2 context option he get a
third place. HTTPSession and databases should not be our problem. Let that to
be handled by the infrastructure providers of those two. But yes, we need to
have a story as to how to get end to end state replication working.

For example instead of replicating every add/remove change happening
inside an invocation we can choose to replicate the net result (change in
state) at the end of the invocation. I think this is more efficient. The
decesion to replicate something should not be limited to be taken within
the context heirachy only.

[SK] Yes this is efficient but leads to more conflicts. Why not let the end
user (Application developer) decide that since he knows best the behavior of
his application implementation.

There should be flexibility to call the ClusterManager from anywhere. So a
context listener is not sufficient.

[SK] Well this sounds bit dangerous :-). I am sorry, I don't have enough
context here.

Furthermore your coupling is only reduced to the cluster manager. I also
didn't like the prospect of calling cluster manager from all over the
place, but given the current design of the context heirachy we have no
choice.

[SK] Well this actually could provide a good extension point to even
application developers. In application server implementation of HTTPSession
there is a way to register a listener. I have used it many times to clean up
stale data in the session. But I may be wrong in this context.

The other more cleaner approach that I proposed a while back was to use
Aspects. We can use aspects to capture replication points using load time
weaving in a more non intrusive manner. This way the context code is not
littered with calls to the Cluster manager. I do have experimental version
on my local copy, but it still needs more work.

[SK] Aspect oriented approach work best when there are cross cutting concerns.
I am not sure about the performance implications. I have used it for logging,
tracing, throttling, etc. But certainly worth evaluating.

This way, in a particular node when there is change in the Context the

ClusterManager instance in that node get notify. Then that ClusterManger
instance can mulitcast (reliable mulitcasting) the change to other
ClusterManger instances running in other nodes. Since each ClusterManager
instance has a handler to the Context it can apply the change locally. If
the
reliable multicast is configured to keep the "total order" in message
ordering you don't have to worry about the conflicts due to concurrency.

[RA] This is what happens currently. Context creations are notified
immediatly and state updates are notified at the end of an invocation.
Tribes which is a total odering reliable multicast then does the work.
However this will not prevent concurrency issues completely. Unless we do
pesimistic locking we would still experiance dirty reads and potential
write/write conflicts.

[SK] Well, total ordering to work, you need to maintain total ordering of
events. In otherwords all the events occurred need to be notified. We can
check with some carefull analysis whether causal ordering could work here. In
that way things will be more efficient.

Different group communication implementations are geared towards different QoS
attributes. Application developer should have the flexibility to choose which
one to go with. So we may want to enable different ClusterManger
implementations to come in using different group communication
implementations.

However things can be futher simplify if we can make an assumption of a sticky
session. I think that's some thing you can enforce and then manage simple
complexities like transparent node recovery. With little feedback from the
application developer this could also lead to flexible scalable
implementation.

I am just throwing out ideas so that we can trash out things. I suppose this
is not information overloading :-).

To unsubscribe, e-mail: axis-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: axis-dev-help (AT) ws (DOT) apache.org

What is the cost of this going to be for someone who doesn't want
clustering/this particular approach to clustering? I can't infer much
from the interface -- exactly which respective events are you referring
to?
-Bill

Thu, 2007-02-01 at 23:16 +0530, Chamikara Jayalath wrote:
At initiation Axis2 will load a ClusterManager implementation object
(if configured) and will call the methods of it whenever respective
events occur.

Chamikara

[1] ClusterManager interface

public abstract class ClusterManager {

public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context, String
propertyName, propertyValue);
public abstract void removeProperty (AbstractContext context,
String propertyName);
public abstract void touchProperty (AbstractContext context,
String propertyName);
public abstract void commit ();

}

To unsubscribe, e-mail: axis-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: axis-dev-help (AT) ws (DOT) apache.org

Bill,

If you addd <cluster class="
"you will get
replication.
you can also just plug in any ClusterManager impl and the code will
delegate to your impl.

If that entry is missing the calls to ClusterManager goes to
NullClusterManager which does nothing.
Absolutely no performance implications (other than calling an empty method
:)

Regards,

Rajith Attapattu
Red Hat.

2/6/07, Bill Nagy <nagy (AT) watson (DOT) ibm.comwrote:

What is the cost of this going to be for someone who doesn't want
clustering/this particular approach to clustering? I can't infer much
from the interface -- exactly which respective events are you referring
to?

-Bill
--
Thu, 2007-02-01 at 23:16 +0530, Chamikara Jayalath wrote:
At initiation Axis2 will load a ClusterManager implementation object
(if configured) and will call the methods of it whenever respective
events occur.

Chamikara
--
[1] ClusterManager interface

public abstract class ClusterManager {

public abstract void init (ConfigurationContext context);
public abstract void addContext (AbstractContext context);
public abstract void removeContext (AbstractContext context);
public abstract void addProperty (AbstractContext context, String
propertyName, propertyValue);
public abstract void removeProperty (AbstractContext context,
String propertyName);
public abstract void touchProperty (AbstractContext context,
String propertyName);
public abstract void commit ();

}
>
>
>

To unsubscribe, e-mail: axis-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: axis-dev-help (AT) ws (DOT) apache.org
--

Hello Sanjaya,

Thanks for the reply, comments marked with [RA]

Regards,
Rajith Attapattu
Red Hat.

2/5/07, Sanjaya Karunasena < sanjayak (AT) wso2 (DOT) comwrote:
Hi Rajith,

Please find my comments below marked with [SK]

Thanks
Sanjaya

Monday 05 February 2007 20:28, Rajith Attapattu wrote:
Hello Sanjaya,

comments are inline marked with [RA]

Rajith Attapattu
Red Hat.
--
In a distributed scenario having the ability to handle concurrency is
very

important. How do you tackle conflicting updates? There should be a
way
to rollback/commit. In otherwords the interface should be
transactionable. Also
having the ability to distinguish between read-only vs read/write
access
to
the context is an opportunity to apply some optimizations to the
actual
implementation.

[RA] This is where locking comes into picture. There are 2 different
types
of locking mechanisms, pesimistic locking and optimistic locking.
Most databases use pesimistic locking and is expensive and slow, while
optimistic locking is relatively cheap. Negotiating concurrency issues
is
best handled by the underlying infrastructure. Apache Tribes (the impl I
used and is using total ordering) and Richochet (garuntees are lower
than
VS) are both low level reliable multicasting infrastructure and have no
support for locking.
WADI from codehaus specializes in locking. But for now we decided
sometime
back to go without any locking for the following reasons.

WADI is written for session replication and is difficult to adapt as is
to
the context replication scenario we have with out some modifications.
Sanjiva and I debated on this issue for a while and agreed that we live
with the concurrency issues for the time being.
What we can do is to try to utilise WADI to provide locking support for
our
implementation as the second step.

[SK] Locking, which comes under pessimistic concurrency control is good
for
databases due to the high probability of conflicts. concurrency
work best when there are high number of reads with intermittent writes.
But
which way to go depends on what do we expect in the context. We can put
some
constrains or let the end user to configure it. But I don't think this is
a
good place to over engineer things. We should keep this very simple. I
guess
this is similar to the HTTPSession. We don't expect application developers
to
use the HTTPSession as their in memory database. Am I right?

[RA] Yes, pessimistic locking is expensive and slow. If we really want to do
locking, then we should do optimistic locking (WADI supports this).
But for the first phase I would like to go without locking. Tomcat
clustering is built on Tribes and they have no distributed locking.
As you correctly pointed out the contexts are like the HTTPSession and
shouldn't be abused by the Web Service developer to shove anything and
everything into it and do frequent writes. This should be clearly stated in
documentation.

The expectation is to use some simple state (mostly read only with
intermittent writes), just like a HTTPSession.

However there is a difference btw the HTTPSession case and the context case
that makes things a bit hard. With HTTPSession if we use session affinity
a.k.a sticky sessions then we make sure requests for the same session is
routed to the same node. So even w/o locking we can get rid of the
concurrency issues. The replication happens merely for failover.

But with Axis2 (if HTTP is not used as transport) we cannot do session
afinity. So we might face concurrency issues. Unless we use Synapse as a
Load Balancer that knows the interpret the serviceGroupId as the session
key.

Detecting conflicts and rolling back is best decided at the
infrastructure
level (for example WADI) rather than at the application level.
The logic for rolling back is complicated and if a rollback occurs we
need
to notify the web service client. Currently there is no standard WS way
of
doing that.
(Not sure WS-Context has anything regarding this)

We can have dirty reads (cheap) and do locking only for updates. But
ymmv.

[SK] From the application developer point of view Axis2 itself is
infrastructure. we should not pull him in to the picture.
However
application code which implements a refine requirement can provide some
hints
(like whether its K to have dirty reads).

[RA] The only way to avoid dirty reads completly is to do pessimistic
locking :(
For now lets keep things simple. Later let us try to come up with a way to
layer some locking mechanism on top of the cluster impl.

I suggest that this interface should provide some means to do

that too.

[RA] As I said, the application should not be figuring out wether to
rollback or not, the infrastructure should.
so it should be the reverse. there should be a way for the
infrastructure
to notify the client about a rollback.
--
[SK] Agreed. But it will be good to shoot for some thing where there is no

need to rollback.

I think the intention of abstracting the cluster manager to an interface
is

to
provide extensibility so that we can have different cluster manager
implementations based on different group communication techniques. But
I
think right now the interface has introduced more coupling.

Following is an approach which could reduce coupling and enable more
flexibility and extensibility.

Do we have the ability to register a listener to the Context? What I
mean
is
an instance of a class which implements an interface ContextListner.
The
ContextListner has one method "notify" which take a parameter of
type "Event". The ClusterManager interface can extend the
ContextListner
(BTW, Should ClusterManger be an abstract class?)

[RA} unfortunately your replication points can be outside of the context

heirachy.

[SK] I am sorry, I did not understand this. What else do you want to
replicate. In a cluster what we need is state information to be
replicated.
There are two places where usually an application developer maintain
state,
the session and the database. I guess with the Axis2 context option he get
a
third place. HTTPSession and databases should not be our problem. Let that
to
be handled by the infrastructure providers of those two. But yes, we need
to
have a story as to how to get end to end state replication working.

[RA]Sorry for not being clear. What I meant was the decesion points to
replicate (the exact replication points)
may fall outside of the context heirachy. That's why I think we need the
ClusterManager (atleast for the time being).
For example update state.
We can do this on per updateBasis (we can have a event listener like u said
that creates event for an add/update/remove proeprty),
instead, it's easy to call updateState at the end of the invocation from the
engine or anywhere deem suitable and then figure out the net state change
and then replicate. So we need more flexibility than events.
Does that make sense ?

For example instead of replicating every add/remove change happening
inside an invocation we can choose to replicate the net result (change
in
state) at the end of the invocation. I think this is more
efficient. The
decesion to replicate something should not be limited to be taken within
the context heirachy only.

[SK] Yes this is efficient but leads to more conflicts. Why not let the
end
user (Application developer) decide that since he knows best the behavior
of
his application implementation.
[RA] If you look at HTTPSession, the service author have no way of saying
how or when to replicate.
If the service author calls abuses this privilege then we have a
performance issue on hand.
Also I am not sure how the above way will lead to less conflicts? Can u
explain more?

There should be flexibility to call the ClusterManager from anywhere. So
a
context listener is not sufficient.

[SK] Well this sounds bit dangerous :-). I am sorry, I don't have enough
context here.

[RA] Sorry what I meant was the decesion to replicate or points of
replication can be anywhere within the system.
(Not the state, the state is only encapsulated inside the ctx heirachy).

Furthermore your coupling is only reduced to the cluster manager. I also
didn't like the prospect of calling cluster manager from all over the
place, but given the current design of the context heirachy we have no
choice.

[SK] Well this actually could provide a good extension point to even
application developers. In application server implementation of
HTTPSession
there is a way to register a listener. I have used it many times to clean
up
stale data in the session. But I may be wrong in this context.

The other more cleaner approach that I proposed a while back was to use
Aspects. We can use aspects to capture replication points using load
time
weaving in a more non intrusive manner. This way the context code is not
littered with calls to the Cluster manager. I do have experimental
version
on my local copy, but it still needs more work.
--
[SK] Aspect oriented approach work best when there are cross cutting
concerns.
I am not sure about the performance implications. I have used it for
logging,
tracing, throttling, etc. But certainly worth evaluating.
[RA] I don't think it's a big problem with performance, but dims pointed out
other issues where byte code manipulation may create to other non technical
realted issues.
My point cuts are the replication points. AP will allow me to intercept
these points in a non intrusive manner.

This way, in a particular node when there is change in the Context the

ClusterManager instance in that node get notify. Then that
ClusterManger
instance can mulitcast (reliable mulitcasting) the change to other
ClusterManger instances running in other nodes. Since each
ClusterManager
instance has a handler to the Context it can apply the change locally.
If
the
reliable multicast is configured to keep the "total order" in message
ordering you don't have to worry about the conflicts due to
concurrency.

[RA] This is what happens currently. Context creations are notified
immediatly and state updates are notified at the end of an invocation.
Tribes which is a total odering reliable multicast then does the work.
However this will not prevent concurrency issues completely. Unless we
do
pesimistic locking we would still experiance dirty reads and potential
write/write conflicts.
--
[SK] Well, total ordering to work, you need to maintain total ordering of
events. In otherwords all the events occurred need to be notified. We can
check with some carefull analysis whether causal ordering could work here.
In
that way things will be more efficient.

[RA] I made mistake, Phlips confirmed that he hasn't implemented total
ordering. Even JGroups doesn't have it.
There is evs4j from Guglielmo Lichtner which claims total odering. The
others seem to have different levels of garuntees.

Different group communication implementations are geared towards different
QoS
attributes. Application developer should have the flexibility to choose
which
one to go with. So we may want to enable different ClusterManger
implementations to come in using different group communication
implementations.

[RA] It is simple, all you need to do is to add the following to your
axis2.xml
<cluster class="" />

You can put any implementation that implements the ClusterManager interface.

However things can be futher simplify if we can make an assumption of a
sticky
session. I think that's some thing you can enforce and then manage simple
complexities like transparent node recovery. With little feedback from the
application developer this could also lead to flexible scalable
implementation.

[RA] see my above comment on session affinity and why it may not work for
axis2.

I am just throwing out ideas so that we can trash out things. I suppose
this
is not information overloading :-).

[RA] not at all, I really like this conversation.

To unsubscribe, e-mail: axis-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: axis-dev-help (AT) ws (DOT) apache.org
--

Hi All;

I am not sure if this is the best place for this question, but I am
stuck.

I have a Axis2 client which I created from a service's WSDL using the
xmlbeans data binding. I am now trying to connect to the live
service, but the service is behind a proxy server. The proxy server
monitors the HTTP headers, and based on custom field in the header
will route the request to the correct machine. I am trying to add
the HTTP Header information to my code for the client, but I am not
sure how to do this. So far the best I have been able to do is this:

//Set the HTTP Headers
ServiceClient sc = stub._getServiceClient();
options = ();
options.setProperty("myKey", "myValue");
(options);
stub._setServiceClient(sc);

I am hoping somebody may be able to help me here, or at least point
me to some reference that discuss this

Rob