Re: bug in JGStore

Davide Rossi wrote:

> Jules Gosnell wrote:
>
> > the Jetty DSM only replicates the changed attribute - essentially it 
> > replicates any mutating method invocation immediately to all other 
> > copies of the session.
>
>
> ok, but the mutator also checks if the new value is really different 
> from the old one before propagating the attribute to the other members 
> of the cluster?

No - I'm pretty sure that it does not.

It could :

a) compare two objects by memory location and if they were the same 
object, not replicate - but then how would the app indicate, within the 
bounds of the spec, that it had changed something within the object, by 
reference, and wanted replication to occur ? - your scenario. 
Furthermore, the app is able to make this test itself.

b) compare the two objects by value - either using equals() or by 
serialising them into buffers and comparing those. Depending on how 
large/complex the objects were, this could be very expensive and 
completely unecessary 100% of the time, if the application was being 
sensible about its use of setAttribute().

A more flexible DSM - WADI perhaps? - might provide these options, or 
perhaps a development time test that could be disabled in production - 
your thoughts here are welcome.

> Oh, since we're at it: what's the relation (if any) between clusters 
> as defined by JBoss and subclusters as defined by JGStore? We're 
> trying to compare different replication options with J2EE (DSM, SFSBs, 
> etc...) so we have to set up an environment in which all the various 
> clustering options can live happily together.

As I recall. none. JGStore's use of jgroups is orthogonal to JBoss' use 
of the same library. With the benefit of hindsight, I now see that it is 
important that related state in all tiers is partitioned in the same 
way, but without better integrations between the various state-holding 
containers, allowing e.g. an SFSB to be tracked back to and associated 
with e.g. an HttpSession, this is difficult. This is a discussion that I 
have had with David Blevins and other members of the Geronimo/OpenEJB 
effort....

> > > <...>
> > >
> > > > Of course, you can use various levels of checks and caching to 
> > > > mitigate the effect of the above, but I think these are the basic 
> > > > solutions to the problem.
> > > >
> > > > wadi.codehaus.org, my latest attempt to perfect the art of 
> > > > bomb-proof HttpSessions will provide both (1) and (2). The Jetty 
> > > > distributable session manager only provides (2). The best 
> > > > workaround for you is probably just to call s.setAttribute("X", 
> > > > s.getAttribute("X")) every time you know you have changed a session 
> > > > attribute value. This may add to the complexity of your code, but 
> > > > will give you a working solution.
> > > >
> > > > Does that help ?
> > >
> > >
> > >
> > >
> > > Well, I worked around the problem already (the issue was to realize 
> > > what cased the misfunctioning). I'm using session replication for a 
> > > research project. We are evaluating J2EE appservers with respect to 
> > > clustering with session replication at the web and at the ejb tier. 
> > > I'm curious to give wadi a look. For what I got by giving a fast 
> > > look to wadi's web pages it looks like you're using a filter to 
> > > implement a loadbalancer. We did the same here. We had to struggle 
> > > against the tons of bugs in the overbloated commons-httpclient 
> > > before giving up and using an in-house library. Anyway I'm 
> > > definively interested in the project.
> >
> >
> >
> > interesting :-) My request proxying is not as finished as I would 
> > like - perhaps your impl is better ?
>
>
> I don't really think so. It's a very basic one. We don't even support 
> session affinity (ok, this is not that difficult to implement). The 
> relevant part is the monitoring system that tells the loadbalancer 
> filter the node to which an incoming request should be redirected.
is your code open source ?

> > WADI can relocate requests to the node holding their session 
> > (currently disabled in cvs),
>
>
> How do you know which are the nodes that have the copies of the 
> session data associated to an incoming request? I assume you don't 
> want to spread your session data to all the nodes of the cluster (the 
> main limitation of the current JBoss clustering).

This part of WADI is still embryonic. I have implemented a pluggable 
TopologyManager interface. A TopologyManager has a chance, when a node 
joins or leaves a cluster, to reorganise the nodes of that cluster into 
Cells. A Cell contains 1-N Nodes - it is effectively a super-Node. Each 
session will be associated with and replicated to a Cell. Its own host 
Node should not be a member of that Cell.

> This is a kind of multi-host session affinity. mod_jk uses the 
> jvmRoute attribute that is appended to the session cookie, but how can 
> you play with this trick with multiple "affine hosts"?

I don't. The session is only in one place at one time. If, using modjk, 
a request arrives on say node2 with a session id, say of 1234.node1, the 
session 1234 will be sourced from its current location (node1?) or 
reanimated from store or a replicant and migrated to node2, then the 
response has its session cookie updated to reflect the new location - 
i.e. it becomes 1234.node2. I may do a redirect - I can't remember...

> Of course there are possible solutions but it all become harder if you 
> think that the replicas to use for a new session should be chosen with 
> some advanced load balancing strategy.

WADI has a pluggable LoadBalancer integration strategy, but any 
integration is considered an optimisation, it is important that WADI 
should work properly with any lb that supports affinity. We do not have 
the luxury of dictating the lb in places that we are likely to be deployed.

> > or relocate the required session underneath the
>
> > incoming request  - migrating it to where it is needed ... so think of
> > the load-balancing aspect of the filter as a last-ditch attempt to 
> > preserve session affinity when something has gone badly wrong and the 
> > enterprise strength lb above you has got it wrong. This happens when 
> > a node is shutdown and its sessions have to migrate elsewhere etc...
>
>
> In your picture the "enterprise strength lb above" is a component of 
> WADI or what?

no - more likely an expensive h/w lb that company X has payed a lot of 
money for and are not going to want to replace with a ServletFilter !

> > The current Jetty DSM was my second attempt at a decent distributable 
> > session manager. WADI will be my third. I have been talking to the 
> > OpenEJB guys about pushing WADI technology back into another library 
> > which they can share, so that SFSBs can migrate from one node to 
> > another when their host goes down for maintenance, or state needs to 
> > be rebalanced around the cluster.
>
>
> We have a lot of expertise here with SFSB replication. And for what I 
> can tell replication has to be tightly integrated with distributed 
> transactions.

Sounds like we all have a lot in common :-)  We will have to have a beer 
together sometime.


Jules

> > Ultimately I hope that this should form
>
> > the basis of such fn-ality in all relevant clustered Geronimo services.
> >
> > Subscribe to our lists - they are very low traffic. It would be good 
> > to have your input.
>
>
> ok, I'll do that.
>
> Davide.


--
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*    www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php