Hi,

Thanks for the reply. I am sure this informed others as much as it did me. I
also read up on that multi-cast thing. Very ingenious..I thought it was some
special way Orion did things. ;)

> Again, I'd like to point out that the list is meant for the Orion
> community, not
> for the Orion team. It's a rather high volume list and we don't
> require the team
> members to read every mail on the list, so it's not the most
> efficient way to
> reach us. This time you're in luck though :)

Hahah..I know Karl. I posted it here in hopes others would respond as well.
It was targeted towards you and Magnus mostly because you would be aware of
the questions more than anyone else, but I figured others might have the
answers by now as well. There was another Orion user that has been awaiting
these answers as well to release their site on Orion for production. So I
believe it was a good decision for me to post it here. That person, along
with others may now have a place to find some of those answers about
clustering. AT least in more detail than the docs give. :)

> No, just that it has to be unique within the cluster. The cluster needs an
> identifier for every participant, but you don't have to supply
> this id yourself.
> If you don't it will be set automatically for you based on the
> ip-number of the
> host. You only need to set it if you do funky stuff.

Ok..so in server.xml, I can just use <cluster /> I don't have to set the id.
That's kewl.

> Ok, the keyword about the cluster tag is "multicast". If you look
> in the docs on
> the meaning of host, you will note that it says the "multicast
> host/ip". This
> means that it's not a normal TCP/IP host but a specific multicast channel.
> Messages sent on the multicast IP:s are broadcasted to the
> network rather than
> sent to a specific computer. Check out the API docs for
> java.net.MulticastSocket
> to learn more about multicast ip:s
> (http://java.sun.com/j2se/1.3/docs/api/java/net/MulticastSocket.ht
> ml), it's
> pretty nice reading if you don't know how multicast works.
>
> The valid multicast IP:s range from 224.0.0.0 (this one should not be used
> though, reserved) to 239.255.255.255, inclusive. These have
> nothing to do with
> the IP numbers your LAN is using since they are multicast-specific.

>From my understanding, no LAN would ever use ip addresses in this range
then..right? Nor would any IP address on the internet?

> We are working on compiling a list of "certified" load balancers
> that integrate
> well with Orion and we might write something ourselves that is
> provided with
> Orion. However, right now it can be complex to set this up unless
> you know a
> fair deal about clustering-software, and this is what we will
> write about in the
> clustering document. As you can see it's a rather complex story,
> and that's why
> it's taking some time to produce it.
>
> However, I'm just preparing a shorter text for how to set up
> simple clustering
> and it will hopefully be ready no later than monday.

AWESOME explanation. I do understand what you mean. My only question with
what you said is, if I do have a cookie-aware load-balancer (we are getting
an arrow-point that has something like 7 levels of load-balancing..what ever
that means. ;), will Orion properly cluster each island, so that if one goes
down, the other two still have the "identical" http session data (state) of
every client on that island? This is the one problem I am having...when I
set up Orion in a cluster, I see the http session objects on the machine I
browse to, and the other one has the same session key values, but the
objects show something like @babd0... So the objects don't appear to exist,
or it looks like the second machine is "pointing" to the first or something.
The only other explanation is that alot of our classes are not Serializable,
and I am wondering..do I have to serialize every one of my classes since any
of our classes me be descendant or used by objects stored in the http
session..thus our entire class structure needs to be serialized? Do let me
know if you can if the reason why the objects don't show up on the second
clustered server is because its probably not a serializable object.


> I'll get back on this later.
>
> >
> > Fourth, I have not tested the cluster with a load-balance, but
> I have two
> > servers running, clustered. Each has their own ip address. I hit one ip
> > address and see the site show up. In the console app of BOTH
> servers in the
> > cluster, I see the same session id show up under the app (if
> anyone reading
> > this doesn't know what I mean by console app..run orion with java -jar
> > orion.jar console2.
>
> I assume you mean java -jar orion.jar -console or java -jar
> orionconsole.jar

No..console2 is what i run. Magnus told me about this. I just tried -console
and it doesn't work. -console2 works. Never tired orionconsole.jar.

> > ..it creates a new session over there. So what I am
> > wondering is, if I shut down one server, when the client hits the ip
> > (load-balancer) does that client still have an active session?
> Is the data
> > saved on both servers?
>
> Yes, that's the whole point of the session state replication.

I think I repeated myself 4 times with the same question. Thanks for the
patience to answer it..4 times. ;)

Question on what you said above...if I cluster two servers, lets call them A
and B, and on computer A I web in to server A. It creates the session on
both A and B (servers). Now, I shut down server A, but with computer A I web
in to the ip of server B. Will I still have an active session at that time?
I assume it should work because computer A browser would send the same
cookie to server B as it did server A. I recall someone saying the sessions
are stored based on the cookie which has the clients ip address in it. That
is why I can't go to computer B and expect a session created from a
different user (computer/ip) to be accessible by me on this computer.


> Yes, the document that's hopefully due on monday will show how to
> do this using
> free software.

Kewl.

Thanks very much for the reply. You have reassured me, and probably the
other guy that was wondering how this worked too. Hopefully others will find
it useful, and that documentation will be nice. I take it it will be on the
site?



Reply via email to