Alright...
I am sorry but you guys completely missed the point.
We are a week into this (good) discussion, everybody tries to impress
everybody and we still are miles away from a single line of code. In a
second we are going to +1/-1 discussions that never end...
All I want is something we can bite on, a bit ambitious and a bit
realistic... All I wanted was SSB failover as client server.
Man this is going to be a long road... Does anyone step up to provide a
simple "stateless bean" clustering, no b2b no nothing, just client server
with failover of the stateless bean.
JMX clustering will be good there:), deployer will be reworked right there..
naming will be investigated, and the failover logic will be coded.
(btw the only point I will make is "smart stubs are good" MAKE IT SIMPLE)
SO STOP SHOOTING FOR THE SKY, SHOOT AT THAT SHORT GOAL
JUST STEP UP... THE KEYBOARD IS RIGHT THERE!!!!!!
You wanna know the reason why? because I know the stuff you are going to
write is going to crap. Believe me it is going to be absolute shite. IT
ALWAYS IS!!!!. Or you think your code don't stink??? even rickard's was
full of poopoos, mine? I won't even mention it, same with Sebastien and
Juha, hiram, oleg, simone (;-) etc etc we ARE ALL THE SAME, the ONLY
DIFFERENCE is that we stepped up!!!! THAT IS THE ONLY REAL THING, you must
understand that your code will go to trash... so don't worry about getting
it right YOU WON'T!!!!!!.
I repeat "Clustering, let's get started", let's beat the mental barrier that
is #1 in my mind ;-)
Please get going, anything anything... please....
marc
__________________________________
strip those feet of lead my friend
raise the curtain, raise the roof,
spirit's on tonight!
--we love our audience 'bauhaus'--
__________________________________
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Tom Cook
|Sent: Monday, March 12, 2001 6:15 PM
|To: JBoss-Dev
|Subject: RE: [jBoss-Dev] CL: Clustering, let's get started
|
|
|On Mon, 12 Mar 2001, Sacha Labourey wrote:
|
|> Hello Tom,
|>
|> > I think that this last point is one which is being lost on some
|> > people. It means that there can be no central controller. Everything
|> > must work in a completely distributed way. I have tried to
|describe how
|> > this might work. For instance, there can not be a 'master' jndi
|> > repository, which is replicated, nor can there be a 'master'
|transaction
|> > manager, message queue... anything. This is why the
|private/public JNDI
|> > tree became necessary, so that some services could retain an
|identity at
|> > each node, while beans are federated across the nodes, and a lookup on
|> > them may return an instance at any node.
|>
|> OK, I see what you mean: difference between a bean and a service i.e.
|> between a cluster-view and a node-view.
|>
|> Consequently, you suggest to have the public tree (cluster-view) being
|> replicated at each node and all the private (i.e. node-view)
|trees, local to
|> each node, being federated under the public tree. Right? (or we
|may as well
|> have the public (cluster) tree federated under each private local tree)
|
|Yes, you are correct.
|
|> > > 2nd, this "where-could-i-find-such-a-bean..." mechanism is
|probably not
|> > > strict enough.
|> >
|> > What do you mean be this? How is it not 'strict' enough?
|>
|> I meant too lazy => not enough optimized. But I may have missed
|your point!
|
|Yes, it is possibly that. But the other option is to keep a replicated
|index of which PK can be found where (!) This is a clear
|memory-performance tradeoff.
|
|> > Having thought this through a little more, what I really meant was that
|> > objects in JNDI should be treated differently depending on whether they
|> > are services or EJBs. A service should have an identity at each node
|> > within the cluster. For a 10-node cluster, there will be 10
|transaction
|> > managers, which are co-operating to provide distributed
|> > transactions. Each one still retains it's own identity. So there is a
|> > transaction manager in each 'private' JNDI, which is not visible to the
|> > client anyway. Then there are beans, which have to exist as one entity
|> > across all the nodes. Do you see what I am saying? There are two
|> > different sorts of clustering happening here. One is that of many
|> > individuals working independantly to provide a service, the
|other is one
|> > corporate body making up a service. The 'public/private'
|thing might be a
|> > bit confusing, it was just a way of implementing this.
|>
|> OK, I agree with need such local vs. global representation.
|>
|> > > > The list of other live nodes would probably be best acheived
|> > by a regular
|> ...
|> > > ...). (in fact, the failure detection mechanism is a basic
|layer of the
|> > > group communication problem)
|> > >
|> > > What do you think?
|> >
|> > I like this group communication thingy, except for that everyone I've
|> > heard explaining it seems to have advocated having a central
|controller,
|> > which gets messy in the case of the controller failing. I
|have tried to
|> > avoid this.
|>
|> ?!? the group communication scheme as generally implemented (like
|> javagroups) is completely redundant. At a particular moment you have some
|> kind of master that sequences the system. But, a completely distributed
|> failure detection subsystem will detect its death (or the death
|of any other
|> node). And if the "controler" dies, a distributed election mechanism
|> automatically takes place. There no single POF. Have I answered
|your concern
|> or am I (again ;) ) missing your point?
|
|No, that is cool. I just find the concept of having a controller, even a
|transitory one, a bit messy. I prefer the 'all are equals' approach,
|rather than the 'first among equals'. But that is for purely aesthetic
|reasons.
|
|Tom
|--
|"If you mess with something for long enough it will break."
| - Schmidt's law of engineering
|
|
