I have been reading your discussions on Clustering the past few days
and would like to throw my 2 cents in. To give a little background ,
I'm working for a company that is planning to deploy JBoss and Jetty
for a production system in the coming months. We are porting from
Weblogic to JBoss for monetary reasons. Not having clustering in
JBoss/Jetty was a concern at first, but after further analysis of our
requirements we determined it might be ok not to have clustering. I
have a lot of random comments so, in advance, I apologize if the
following points only apply to the concerns of my company or are
ignorant or stupid in any way :-)
- This is just an opinion, please no flames, but I would rather see the
JBoss developer community focus on the quality of JBoss, the quality of
the release cycle(an actual branching scheme and bug fixes branch), a
clean 2.1 relase, and getting the docs up-to-date rather than new
features like clustering. JBoss is already a very cool product, and I'm
guessing a lot of us can work around the problems that clustering solves.
- Distributed Transaction Processing. If the JBoss developers are
planning not to tackle DTP along with other clustering features I hope
great concern is taken not to break applications that use transactions
within their EJBs. If a JBoss load-balancer is bouncing nested Bean
method calls to many different nodes and you don't have DTP, many
applications may break. A solution for this may be that nested Bean
method calls are "sticky". That is, only the initiating client
request be load-balanced.
- IMHO, clustering EJBs is only half the problem. Servlet/jsp engines
(Jetty/Tomcat/whatever) need to be clusterable as well for a complete
solution and to be competitve against other Enterprise app servers like
WebLogic. (That's the goal isn't, to beat WebLogic?). Don't most apps
that use EJBs also use a servlet engine?
- Also, IMHO, load-balancing is much less important than fail-over and
DTP. As others have said, those of us who are writing Web-Apps are
getting load-balancing from our routers already.
- Our project is most concerned that all the ACID properties of
Transactions are definable and reliable in a clustered or scaled
environment.
Hope these comments are useful.
Best regards,
Bill
marc fleury wrote:
> 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
> |
> |
>
>
>
>
>
