Oliver:
No, there is no single point of failure. The way it works is thus:
Each tomcat instance in a cluster (defined by a single multicast
address/port):
- Shall keep a copy of all sessions that it owns (created).
- May be configured to be a session repository (or not).
Session repositories keep copies of all sessions created
by all members of the cluster.
- Shall automatically discover the other instances at startup time.
(instances that were started earlier and discovered, shall be
notified of newly started instances).
- during startup of a new 'repository', will request that it be sent
copies of all known Sessions (from an arbitrary known repository).
- Shall copy all new / updated sessions to all other known 'repositories'
after the completion of a web request.
- Shall 'lock' each owned session object while it is in use.
- Shall retrieve and lock a requested session from the 'owner' if the
current
Tomcat is not the owner of the session.
- If the owner (tomcat) has been brought down in an orderly fashion, it will
transfer ownership of all of it's owned sessions to arbitrary
repositories
in the cluster (during it's shutdown sequence).
- If the owner (tomcat) has crashed, the 1st Tomcat (repository) to receive
a request
for a session that was owned by the downed tomcat will become the new
owner
of that session.
So,
- There is no single point of failure.
- Server/session affinity, is not required, but will provide performance
benefits.
- New instances may be brought on-line, and will automatically become a part
of the cluster.
- Existing instances may be brought down with no impact on users (other than
a one-time performance hit).
- Existing instances may crash with *limited* deleterious side-effects.
- There must be at least two 'repository' instances in order to support the
fail-over scenarios. However, the number of 'repository' instances should
be limited to as small a number as is necessary to meet your fail-over
needs.
- This feature will only be present (and consume bandwidth) if it has been
configured. Other load balancing solutions that don't require fail-over
protection, such as the Tomcat 3.x / Apache solution can be implemented
without concern for this.
----- Original Message -----
From: "Lauer, Oliver" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>; "'Tom
Drake'" <[EMAIL PROTECTED]>
Sent: Monday, December 17, 2001 9:25 AM
Subject: AW: Configuring Multiple Tomcat JVMs with Apache - Load Balancing
| Tom,
|
| Will the repository be a single point of failure then ?
| Oliver
|
| > AXA eSolutions GmbH
| > AXA Konzern AG Germany
| > Oliver Lauer
| > Web Architect
| > Wörthstraße 34
| > D-50668 Köln
| > Germany
| > Tel.: +49 221 148 31277
| > Fax: +49 221 148 43963
| > Mobil: +49 179 59 064 59
| > e-Mail: [EMAIL PROTECTED]
| > _____________________________
| >
|
|
| -----Ursprüngliche Nachricht-----
| Von: Tom Drake [mailto:[EMAIL PROTECTED]]
| Gesendet: Montag, 17. Dezember 2001 18:26
| An: Tomcat Developers List
| Betreff: Re: Configuring Multiple Tomcat JVMs with Apache - Load
| Balancing
|
|
| Keep in mind that with distributed sessions (coming soon to a tomcat near
| you), affinity
| is no longer 'required' in order to function. This provides the added
| benefit of fail-over.
|
| Affinity is still desirable for performance reasons. However, the if the
| Tomcat instance
| that created the session is brought down, the user needn't be affected.
| Apache
| should notice this and route subsequent requests (for the affected
sessions)
| to another
| TC instance in the cluster. The other TC instances will either already
have
| a copy of
| the session or can retrieve it from a 'repository'.
|
| Tom
|
| ----- Original Message -----
| From: <[EMAIL PROTECTED]>
| To: "Tomcat Developers List" <[EMAIL PROTECTED]>
| Sent: Monday, December 17, 2001 9:07 AM
| Subject: RE: Configuring Multiple Tomcat JVMs with Apache - Load Balancing
|
|
| | On Mon, 17 Dec 2001, GOMEZ Henri wrote:
| |
| | > >couldn't the connector be solely
| | > >responsible for
| | > >this? the connector could add a cookie to the response, then read
this
| | > >cookie on subsequent requests, and then you wouldn't have to
| | > >add stuff to
| | > >servlet containers to handle this. or, i could be totally off base
:)
| | >
| | > Could we add another cookie in http reply ? Spec compliant ?
| | > What to be used when you have to use URL encoded instead since
| | > cookies are not available ?
| |
| | It'll not work. URL rewriting is the issue - the session id ( i.e. what
| | will be sent on the next request ) will end up inside html pages, where
| | mod_jk can't 'rewrite' it. And adding a cookie will fail if no cookies
| | are available ( again where url rewriting will be used ).
| |
| | The session id that a servlet sees must have the vmroute in it.
| |
| |
| | Costin
| |
| |
| | --
| | To unsubscribe, e-mail:
| <mailto:[EMAIL PROTECTED]>
| | For additional commands, e-mail:
| <mailto:[EMAIL PROTECTED]>
| |
| |
| |
|
|
| --
| To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
| For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
|
|
| --------------------------------------------------------------------------
----
| Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene
Information nicht rechtsverbindlich. Eine rechtsverbindliche Bestaetigung
reichen wir Ihnen gerne auf Anforderung in schriftlicher Form nach. Beachten
Sie bitte, dass jede Form der unautorisierten Nutzung, Veroeffentlichung,
Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail nicht gestattet
ist.Diese Nachricht ist ausschliesslich fuer den bezeichneten Adressaten
oder dessen Vertreter bestimmt. Sollten Sie nicht der vorgesehene Adressat
dieser E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich mit dem
Absender der E-Mail in Verbindung zu setzen.
| ----------------------------
| For legal and security reasons the information provided in this e-mail is
not legally binding. Upon request we would be pleased to provide you with a
legally binding confirmation in written form. Any form of unauthorised use,
publication, reproduction, copying or disclosure of the content of this
e-mail is not permitted. This message is exclusively for the person
addressed or their representative. If you are not the intended recipient of
this message and its contents, please notify the sender immediately.
|
|
============================================================================
==
|
|
|
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
