You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wadi-commits@incubator.apache.org by bd...@apache.org on 2005/12/14 23:36:16 UTC
svn commit: r356933 [29/35] - in /incubator/wadi/trunk: ./ etc/ modules/
modules/assembly/ modules/assembly/src/ modules/assembly/src/bin/
modules/assembly/src/conf/ modules/assembly/src/main/
modules/assembly/src/main/assembly/ modules/core/ modules/c...
Added: incubator/wadi/trunk/wadi-site/src/old_docs/JK, Session Replication_Clustering, SSL and failover in Tomcat 5.eml
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/JK%2C%20Session%20Replication_Clustering%2C%20SSL%20and%20failover%20in%20Tomcat%205.eml?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/JK, Session Replication_Clustering, SSL and failover in Tomcat 5.eml (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/JK, Session Replication_Clustering, SSL and failover in Tomcat 5.eml Wed Dec 14 15:32:56 2005
@@ -0,0 +1,711 @@
+Return-Path: <to...@jakarta.apache.org>
+Delivered-To: jules@mortbay.com
+Received: (qmail 17720 invoked by alias); 27 Jan 2005 15:37:09 -0000
+Delivered-To: alias-cdn-jules@coredevelopers.net
+Received: (qmail 17715 invoked from network); 27 Jan 2005 15:37:09 -0000
+Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
+ by jetty3.inetu.net with SMTP; 27 Jan 2005 15:37:05 -0000
+Received-SPF: pass (jetty3.inetu.net: domain of tomcat-user-return-120258-jules=coredevelopers.net@jakarta.apache.org designates 209.237.227.199 as permitted sender) receiver=jetty3.inetu.net; client_ip=209.237.227.199; envelope-from=tomcat-user-return-120258-jules=coredevelopers.net@jakarta.apache.org;
+Received: (qmail 79259 invoked by uid 500); 27 Jan 2005 15:36:50 -0000
+Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
+Precedence: bulk
+List-Unsubscribe: <ma...@jakarta.apache.org>
+List-Subscribe: <ma...@jakarta.apache.org>
+List-Help: <ma...@jakarta.apache.org>
+List-Post: <ma...@jakarta.apache.org>
+List-Id: "Tomcat Users List" <tomcat-user.jakarta.apache.org>
+Reply-To: "Tomcat Users List" <to...@jakarta.apache.org>
+Delivered-To: mailing list tomcat-user@jakarta.apache.org
+Received: (qmail 79244 invoked by uid 99); 27 Jan 2005 15:36:49 -0000
+X-ASF-Spam-Status: No, hits=0.4 required=10.0
+ tests=DNS_FROM_RFC_ABUSE
+X-Spam-Check-By: apache.org
+Received-SPF: pass (hermes.apache.org: local policy)
+Received: from mpls-qmqp-04.inet.qwest.net (HELO mpls-qmqp-04.inet.qwest.net) (63.231.195.115)
+ by apache.org (qpsmtpd/0.28) with SMTP; Thu, 27 Jan 2005 07:36:47 -0800
+Received: (qmail 92486 invoked by uid 0); 27 Jan 2005 15:36:34 -0000
+Received: from mpls-pop-08.inet.qwest.net (63.231.195.8)
+ by mpls-qmqp-04.inet.qwest.net with QMQP; 27 Jan 2005 15:36:34 -0000
+Received: from vdsl-130-13-0-2.phnx.qwest.net (HELO redfish) (130.13.0.2)
+ by mpls-pop-08.inet.qwest.net with SMTP; 27 Jan 2005 15:36:33 -0000
+Date: Thu, 27 Jan 2005 08:37:25 -0700
+Message-ID: <DK...@qwest.net>
+From: "Richard Mixon (qwest)" <rn...@qwest.net>
+To: "Tomcat Users List" <to...@jakarta.apache.org>
+Cc: devlists@hanik.com
+Subject: RE: JK, Session Replication/Clustering, SSL and failover in Tomcat 5
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset="iso-8859-1"
+Content-Transfer-Encoding: 7bit
+X-Priority: 3 (Normal)
+X-MSMail-Priority: Normal
+X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
+X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
+In-Reply-To: <07...@Corp.LaQuinta.com>
+Importance: Normal
+X-Virus-Checked: Checked
+X-Qmail-Scrubber-Version: 1.02
+X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on jetty3.inetu.net
+X-Spam-Level:
+X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
+ version=2.63
+
+Filip,
+
+Thank you - that appears to be what I need. Unfortunately the only
+documentation I can find is at:
+ http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/
+apache/catalina/cluster/session/JvmRouteBinderValve.html
+
+BEGIN-QUOTE
+Valve to handle Tomcat jvmRoute takeover using mod_jk module after node
+failure. After a node crashed the next request going to other cluster
+node. Now the answering from apache is slower ( make some error
+handshaking. Very bad with apache at my windows.). We rewrite now the
+cookie jsessionid information to the backup cluster node. After the next
+response all client request goes direct to the backup node. The change
+sessionid send also to all other cluster nodes. Well, now the session
+stickyness work directly to the backup node and traffic don't go back
+too restarted cluster nodes! At all cluster node you must configure the
+JvmRouteSessionIDBinderListener with
+JvmRouteSessionIDBinderListenerLifecycle Add this Valve to your
+clustered application or setup it to context default
+conf/enginename/hostname/context.xml.default for all host application
+
+ <Context>
+ <Valve
+className="org.apache.catalina.cluster.session.JvmRouteBinderValve" />
+ </Context>
+
+
+END-QUOTE
+
+I put the valve statement in my conf/context.xml. But this does not seem
+to be enough.
+
+But where can I find information on configuring the
+"JvmRouteSessionIDBinderListener with
+JvmRouteSessionIDBinderListenerLifecycle"?
+
+Thank you - Richard Mixon
+
+-----Original Message-----
+From: Filip Hanik - Dev [mailto:devlists@hanik.com]
+Sent: Thursday, January 27, 2005 7:29 AM
+To: Tomcat Users List
+Cc: rnmixon@qwest.net
+Subject: Re: JK, Session Replication/Clustering, SSL and failover in
+Tomcat 5
+
+
+yes, There is code that takes care of that scenario, I believe it was
+peter who coded it.
+There is a valve called JvmRouteBinderValve that peter wrote, that you
+enable for your context.
+It will rewrite the session id for, and broadbast it to the cluster.
+
+Filip
+
+----- Original Message -----
+From: "Richard Mixon (qwest)" <rn...@qwest.net>
+To: "Tomcat Users List" <to...@jakarta.apache.org>
+Sent: Wednesday, January 26, 2005 6:44 PM
+Subject: RE: JK, Session Replication/Clustering, SSL and failover in
+Tomcat 5
+
+
+Filip,
+
+Pen does not really help me out.
+
+My problem is JK I am pretty sure. It is appending ".srv1" to the
+session. When srv1 is stopped, it detects this on the next request and
+routes the request to srv2. However I notice in the JK output that it
+now has ".srv2" appended to the session, which of course does not exist,
+and I get prompted to re-logon.
+
+Below is the debug output from JK showing the failover attempt.
+
+Any other suggestion?
+
+Thank you - Richard
+
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+map_uri_to_worker::jk_uri_worker_map.c (700): Attempting to map URI
+'/stars/gridAction.do' from 1 maps
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+map_uri_to_worker::jk_uri_worker_map.c (718): Attempting to map context
+URI '/stars/*'
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+map_uri_to_worker::jk_uri_worker_map.c (755): Found a context match
+loadbalancer -> /stars/
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug] jk_handler::mod_jk.c
+(1715): Into handler jakarta-servlet worker=loadbalancer r->proxyreq=0
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+wc_get_worker_for_name::jk_worker.c (92): found a worker loadbalancer
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug] init_ws_service::mod_jk.c
+(479): agsp=443 agsn=redfishsoftware.swamp.home
+hostn=redfishsoftware.swamp.home shostn=redfishsoftware.swamp.home
+cbsport=0 sport=0 claport=443
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug] service::jk_lb_worker.c
+(465): service sticky_session=1
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+get_most_suitable_worker::jk_lb_worker.c (372): total sessionid is
+EE9EF7748256B50E03C48A3F3735DE59.srv1.
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+get_most_suitable_worker::jk_lb_worker.c (383): searching worker for
+partial sessionid EE9EF7748256B50E03C48A3F3735DE59.srv1.
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (275): searching for sticky worker
+(srv1)
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (282): found candidate worker srv1
+(0) for match with sticky (srv1)
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (290): found candidate worker srv1
+(0) with previous load 100 in search with sticky (srv1)
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (343): found worker srv1 with new
+load 100 in search with sticky (srv1)
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+ajp_get_endpoint::jk_ajp_common.c (2016): time elapsed since last
+request = 76 seconds
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug] service::jk_lb_worker.c
+(482): service worker=srv1 jvm_route=srv1 rc=1
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+ajp_marshal_into_msgb::jk_ajp_common.c (551): ajp marshaling done
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+ajp_service::jk_ajp_common.c (1594): processing with 3 retries
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=611 max=8192
+[Wed Jan 26 17:15:57 2005] [6040:2256] [error]
+ajp_connection_tcp_send_message::jk_ajp_common.c (902): sendfull
+returned -3 with errno=54
+[Wed Jan 26 17:15:57 2005] [6040:2256] [error]
+ajp_send_request::jk_ajp_common.c (1158): Error sending request try
+another pooled connection
+[Wed Jan 26 17:15:57 2005] [6040:2256] [debug]
+jk_open_socket::jk_connect.c (159): try to connect socket = 700 to
+127.0.0.1:8009
+[Wed Jan 26 17:15:58 2005] [6040:2256] [debug]
+jk_open_socket::jk_connect.c (177): after connect ret = -1
+[Wed Jan 26 17:15:58 2005] [6040:2256] [info]
+jk_open_socket::jk_connect.c (183): connect() failed errno = 61
+[Wed Jan 26 17:15:58 2005] [6040:2256] [info]
+ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to
+tomcat. Tomcat is probably not started or is listening on the wrong
+host/port (127.0.0.1:8009). Failed errno = 61
+[Wed Jan 26 17:15:58 2005] [6040:2256] [info]
+ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat
+process.
+[Wed Jan 26 17:15:58 2005] [6040:2256] [info]
+ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed,
+recoverable operation attempt=0
+[Wed Jan 26 17:15:58 2005] [6040:2256] [debug]
+jk_open_socket::jk_connect.c (159): try to connect socket = 700 to
+127.0.0.1:8009
+[Wed Jan 26 17:15:59 2005] [6040:2256] [debug]
+jk_open_socket::jk_connect.c (177): after connect ret = -1
+[Wed Jan 26 17:15:59 2005] [6040:2256] [info]
+jk_open_socket::jk_connect.c (183): connect() failed errno = 61
+[Wed Jan 26 17:15:59 2005] [6040:2256] [info]
+ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to
+tomcat. Tomcat is probably not started or is listening on the wrong
+host/port (127.0.0.1:8009). Failed errno = 61
+[Wed Jan 26 17:15:59 2005] [6040:2256] [info]
+ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat
+process.
+[Wed Jan 26 17:15:59 2005] [6040:2256] [info]
+ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed,
+recoverable operation attempt=1
+[Wed Jan 26 17:15:59 2005] [6040:2256] [debug]
+jk_open_socket::jk_connect.c (159): try to connect socket = 700 to
+127.0.0.1:8009
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+jk_open_socket::jk_connect.c (177): after connect ret = -1
+[Wed Jan 26 17:16:00 2005] [6040:2256] [info]
+jk_open_socket::jk_connect.c (183): connect() failed errno = 61
+[Wed Jan 26 17:16:00 2005] [6040:2256] [info]
+ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to
+tomcat. Tomcat is probably not started or is listening on the wrong
+host/port (127.0.0.1:8009). Failed errno = 61
+[Wed Jan 26 17:16:00 2005] [6040:2256] [info]
+ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat
+process.
+[Wed Jan 26 17:16:00 2005] [6040:2256] [info]
+ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed,
+recoverable operation attempt=2
+[Wed Jan 26 17:16:00 2005] [6040:2256] [error]
+ajp_service::jk_ajp_common.c (1673): Error connecting to tomcat. Tomcat
+is probably not started or is listening on the wrong port. worker=srv1
+failed errno = 61
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ajp_done::jk_ajp_common.c
+(1955): done with connection -1 for worker srv1
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] service::jk_lb_worker.c
+(522): recoverable error... will try to recover on other host
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_most_suitable_worker::jk_lb_worker.c (372): total sessionid is
+EE9EF7748256B50E03C48A3F3735DE59.srv1.
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_most_suitable_worker::jk_lb_worker.c (383): searching worker for
+partial sessionid EE9EF7748256B50E03C48A3F3735DE59.srv1.
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (275): searching for sticky worker
+(srv1)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (282): found candidate worker srv1
+(0) for match with sticky (srv1)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (290): found candidate worker srv1
+(0) with previous load 100 in search with sticky (srv1)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (300): worker candidate srv1 (0) is
+in error state - will not yet recover (0 < 60)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (350): found no sticky (srv1) worker
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_most_suitable_worker::jk_lb_worker.c (403): found domain unknown in
+route srv1
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (275): searching for sticky domain
+worker (unknown)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (282): found candidate worker srv1
+(0) for match with sticky domain (unknown)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (290): found candidate worker srv1
+(0) with previous load 100 in search with sticky domain (unknown)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (300): worker candidate srv1 (0) is
+in error state - will not yet recover (0 < 60)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (282): found candidate worker srv2
+(1) for match with sticky domain (unknown)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (290): found candidate worker srv2
+(1) with previous load 100 in search with sticky domain (unknown)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (314): new maximal worker srv2 (1)
+with previous load 200 in search with sticky domain (unknown)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+get_suitable_worker::jk_lb_worker.c (343): found worker srv2 with new
+load 100 in search with sticky domain (unknown)
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_get_endpoint::jk_ajp_common.c (2016): time elapsed since last
+request = 29 seconds
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] service::jk_lb_worker.c
+(482): service worker=srv2 jvm_route=srv2 rc=1
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_marshal_into_msgb::jk_ajp_common.c (551): ajp marshaling done
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_service::jk_ajp_common.c (1594): processing with 3 retries
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=611 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_send_request::jk_ajp_common.c (1199): request body to send 64587 -
+request body to resend 0
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=8192 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=3 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=8192 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=3 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=8192 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=3 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=8192 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=3 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=8192 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=3 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=8192 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=3 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=8192 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=3 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_send_message::jk_ajp_common.c (883): sending to ajp13
+pos=4 len=7291 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=141 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_unmarshal_response::jk_ajp_common.c (606): status = 200
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_unmarshal_response::jk_ajp_common.c (613): Number of headers is = 2
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_unmarshal_response::jk_ajp_common.c (669): Header[0] [Set-Cookie] =
+[JSESSIONID=9FF5A5ED4466F1EE906856287DF2EF8F.srv2; Path=/stars; Secure]
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_unmarshal_response::jk_ajp_common.c (669): Header[1] [Content-Type]
+= [text/html;charset=ISO-8859-1]
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=25 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ws_write::mod_jk.c (376):
+writing 21 (21) out of 21
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=6585 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ws_write::mod_jk.c (376):
+writing 4096 (4096) out of 6581
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ws_write::mod_jk.c (376):
+writing 2485 (2485) out of 2485
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=161 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ws_write::mod_jk.c (376):
+writing 157 (157) out of 157
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=5887 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ws_write::mod_jk.c (376):
+writing 4096 (4096) out of 5883
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ws_write::mod_jk.c (376):
+writing 1787 (1787) out of 1787
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug]
+ajp_connection_tcp_get_message::jk_ajp_common.c (1007): received from
+ajp13 pos=0 len=2 max=8192
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] ajp_done::jk_ajp_common.c
+(1942): recycling connection cache slot=0
+[Wed Jan 26 17:16:00 2005] [6040:2256] [debug] jk_handler::mod_jk.c
+(1860): Service finished with status=200 for worker=loadbalancer
+[Wed Jan 26 17:16:00 2005] [6040:4016] [debug]
+map_uri_to_worker::jk_uri_worker_map.c (700): Attempting to map URI
+'/styles/messages.css' from 1 maps
+[Wed Jan 26 17:16:00 2005] [6040:4016] [debug]
+map_uri_to_worker::jk_uri_worker_map.c (718): Attempting to map context
+URI '/stars/*'
+[Wed Jan 26 17:16:00 2005] [6040:4016] [debug]
+map_uri_to_worker::jk_uri_worker_map.c (700): Attempting to map URI
+'/styles/messages.css' from 1 maps
+[Wed Jan 26 17:16:00 2005] [6040:4016] [debug]
+map_uri_to_worker::jk_uri_worker_map.c (718): Attempting to map context
+URI '/stars/*'
+
+
+
+
+-----Original Message-----
+From: Filip Hanik - Dev [mailto:devlists@hanik.com]
+Sent: Wednesday, January 26, 2005 4:10 PM
+To: Tomcat Users List
+Subject: Re: JK, Session Replication/Clustering, SSL and failover in
+Tomcat 5
+
+
+try with a regular tcp loadbalancer like pen (http://siag.nu/) first,
+otherwise you are debugging a whole stack at once.
+
+so use pen, and your two tomcats, try failover and go from there.
+also, enable debugging for your logging, and a lot more will be spit out
+in the logs
+
+Filip
+
+----- Original Message -----
+From: "Richard Mixon (qwest)" <rn...@qwest.net>
+To: <to...@jakarta.apache.org>
+Sent: Wednesday, January 26, 2005 4:37 PM
+Subject: JK, Session Replication/Clustering, SSL and failover in Tomcat
+5
+
+
+I am trying to get JK 1.2.8 (within Apache 2.0.52 SSL build) to fail
+over to my remaining Tomcat 5.5.7 instance when the first instance is
+brought down (e.g. for maintenance or due to an actual failure).
+
+The application uses container managed authentication (CMA) and
+obviously sessions.
+
+I have two questions/problems. Thanks so much for any ideas/help you can
+provide.
+
+1) If I set sticky_session=True then the loadbalancer worker distributes
+requests among the two workers just fine. If I shut down one Tomcat
+instance, it redirects me to the second - but I am prompted to login
+again. This makes me think that session replication is not occurring.
+How can I check that session replication is happening (is there a log
+settings)?
+
+I thought it must be at first as I was getting the following in my
+tomcat logs:
+
+>From srv1:
+
+INFO main org.apache.coyote.http11.Http11Protocol - Initializing Coyote
+HTTP/1.1 on http-8080
+ INFO main org.apache.catalina.startup.Catalina - Initialization
+processed in 875 ms
+ INFO main org.apache.catalina.core.StandardService - Starting service
+Catalina
+ INFO main org.apache.catalina.core.StandardEngine - Starting Servlet
+Engine: Apache Tomcat/5.5.7
+ INFO main org.apache.catalina.core.StandardHost - XML validation
+disabled
+ INFO main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Cluster is
+about to start
+ INFO main org.apache.catalina.cluster.mcast.McastService - Sleeping for
+2000 secs to establish cluster membership
+ INFO main org.apache.catalina.cluster.deploy.FarmWarDeployer - Cluster
+FarmWarDeployer started.
+ INFO main org.apache.coyote.http11.Http11Protocol - Starting Coyote
+HTTP/1.1 on http-8080
+ INFO main org.apache.jk.common.ChannelSocket - JK2: ajp13 listening on
+/0.0.0.0:8009
+ INFO main org.apache.jk.server.JkMain - Jk running ID=0 time=0/31
+config=null
+ INFO main org.apache.catalina.storeconfig.StoreLoader - Find registry
+server-registry.xml at classpath resource
+ INFO main org.apache.catalina.startup.Catalina - Server startup in 6016
+ms
+ INFO Cluster-MembershipReceiver
+org.apache.catalina.cluster.tcp.SimpleTcpCluster - Replication member
+added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.140:
+4002,192.168.1.140,4002, alive=16]
+
+>From srv2:
+
+INFO main org.apache.coyote.http11.Http11Protocol - Initializing Coyote
+HTTP/1.1 on http-9080
+ INFO main org.apache.catalina.startup.Catalina - Initialization
+processed in 1250 ms
+ INFO main org.apache.catalina.core.StandardService - Starting service
+Catalina
+ INFO main org.apache.catalina.core.StandardEngine - Starting Servlet
+Engine: Apache Tomcat/5.5.7
+ INFO main org.apache.catalina.core.StandardHost - XML validation
+disabled
+ INFO main org.apache.catalina.cluster.tcp.SimpleTcpCluster - Cluster is
+about to start
+ INFO main org.apache.catalina.cluster.mcast.McastService - Sleeping for
+2000 secs to establish cluster membership
+ INFO Cluster-MembershipReceiver
+org.apache.catalina.cluster.tcp.SimpleTcpCluster - Replication member
+added:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.140:
+4001,192.168.1.140,4001, alive=5578]
+ INFO main org.apache.catalina.cluster.deploy.FarmWarDeployer - Cluster
+FarmWarDeployer started.
+ INFO main org.apache.coyote.http11.Http11Protocol - Starting Coyote
+HTTP/1.1 on http-9080
+ INFO main org.apache.jk.common.ChannelSocket - JK2: ajp13 listening on
+/0.0.0.0:9009
+ INFO main org.apache.jk.server.JkMain - Jk running ID=0 time=0/31
+config=null
+ INFO main org.apache.catalina.storeconfig.StoreLoader - Find registry
+server-registry.xml at classpath resource
+ INFO main org.apache.catalina.startup.Catalina - Server startup in 6313
+ms
+
+
+2) If I set sticky_session=False I am unable to login, failing with an
+HTTP Status 408. Here's the sequence:
+ a) Issue a request to a protected resource that will trigger
+form-based authentication (CMA). JK worker loadbalancer sends this
+request to the first worker, "srv1".
+ b) After I fill in the authentication/login form I press submit. Now
+JK worker loadbalancer send this request to worker "srv2" and I end up
+with this error respons: HTTP Status 408 - The time allowed for the
+login process has been exceeded...
+
+Here are my configuration files (or pieces):
+
+FILE: piece form httpd.conf
+<IfModule mod_jk.c>
+
+ JkWorkersFile conf/workers.properties
+
+ JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
+ JkLogFile logs/mod_jk.log
+
+ # Log level to be used by mod_jk: debug, info, warn error or trace
+ JkLogLevel debug
+
+ JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
+ JkExtractSSL on
+ JkHTTPSIndicator HTTPS
+ JkSESSIONIndicator SSL_SESSION_ID
+ JkCIPHERIndicator SSL_CIPHER
+ JkCERTSIndicator SSL_CLIENT_CERT
+
+</IfModule>
+
+FILE: workers.properties
+# workers.properties -
+#
+workers.tomcat_home=c:/jakarta-tomcat-5.5.7
+workers.java_home=C:/jdk1.5.0_01
+ps=/
+
+#
+# Define one worker for each tomcat instance, plus one
+# to handle the load balancing.
+#
+worker.list=loadbalancer
+
+worker.srv1.port=8009
+worker.srv1.host=localhost
+worker.srv1.type=ajp13
+worker.srv1.lbfactor=100
+worker.srv1.sticky_session=False
+worker.srv1.local_worker=0
+
+worker.srv2.port=9009
+worker.srv2.host=localhost
+worker.srv2.type=ajp13
+worker.srv2.lbfactor=100
+worker.srv2.sticky_session=False
+worker.srv2.local_worker=0
+
+worker.loadbalancer.type=lb
+worker.loadbalancer.sticky_session=False
+worker.loadbalancer.balanced_workers=srv1,srv2
+worker.loadbalancer.local_worker_only=1
+
+FILE: piece from server.xml on "srv1"
+(note: I do not want automated deployment so I watchEnabled="false", I
+do not want farm deployment to occur)
+
+ <Cluster
+className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"
+ managerClassName="org.apache.catalina.cluster.session.D
+eltaManager"
+ expireSessionsOnShutdown="true"
+ useDirtyFlag="true"
+ notifyListenersOnReplication="true">
+
+ <Membership
+ className="org.apache.catalina.cluster.mcast.McastServic
+e"
+ mcastAddr="228.0.0.4"
+ mcastPort="45564"
+ mcastFrequency="500"
+ mcastDropTime="3000"/>
+
+ <Receiver
+ className="org.apache.catalina.cluster.tcp.ReplicationLi
+stener"
+ tcpListenAddress="auto"
+ tcpListenPort="4001"
+ tcpSelectorTimeout="100"
+ tcpThreadCount="6"/>
+
+ <Sender
+ className="org.apache.catalina.cluster.tcp.ReplicationTr
+ansmitter"
+ replicationMode="pooled"
+ ackTimeout="15000"/>
+
+ <Valve
+className="org.apache.catalina.cluster.tcp.ReplicationValve"
+ filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.ht
+ml;.*\.css;.*\.txt;"/>
+
+ <Deployer
+className="org.apache.catalina.cluster.deploy.FarmWarDeployer"
+ tempDir="c:/jakarta-tomcat-5.5.7/temp"
+ deployDir="c:/jakarta-tomcat-5.5.7/webapps"
+ watchDir="c:/jakarta-tomcat-5.5.7-deployer/build/w
+ebapp"
+ watchEnabled="false"/>
+ </Cluster>
+
+FILE: piece from server.xml on "srv2"
+ <Cluster
+className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"
+ managerClassName="org.apache.catalina.cluster.session.D
+eltaManager"
+ expireSessionsOnShutdown="true"
+ useDirtyFlag="true"
+ notifyListenersOnReplication="true">
+
+ <Membership
+ className="org.apache.catalina.cluster.mcast.McastServic
+e"
+ mcastAddr="228.0.0.4"
+ mcastPort="45564"
+ mcastFrequency="500"
+ mcastDropTime="3000"/>
+
+ <Receiver
+ className="org.apache.catalina.cluster.tcp.ReplicationLi
+stener"
+ tcpListenAddress="auto"
+ tcpListenPort="4002"
+ tcpSelectorTimeout="100"
+ tcpThreadCount="6"/>
+
+ <Sender
+ className="org.apache.catalina.cluster.tcp.ReplicationTr
+ansmitter"
+ replicationMode="pooled"
+ ackTimeout="15000"/>
+
+ <Valve
+className="org.apache.catalina.cluster.tcp.ReplicationValve"
+ filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.ht
+ml;.*\.css;.*\.txt;"/>
+
+ <Deployer
+className="org.apache.catalina.cluster.deploy.FarmWarDeployer"
+ tempDir="c:/jakarta-tomcat-5.5.7b/temp"
+ deployDir="c:/jakarta-tomcat-5.5.7b/webapps"
+ watchDir="c:/jakarta-tomcat-5.5.7-deployer/build/w
+ebapp"
+ watchEnabled="false"/>
+ </Cluster>
+
+Thanks again - Richard
+
+
+---------------------------------------------------------------------
+To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
+For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
+
+---------------------------------------------------------------------
+To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
+For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
+
+
+
+
+---------------------------------------------------------------------
+To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
+For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
+
+---------------------------------------------------------------------
+To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
+For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
+
+
+
+
+---------------------------------------------------------------------
+To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
+For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Added: incubator/wadi/trunk/wadi-site/src/old_docs/MetaDataMigrationProtocol.odg
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/MetaDataMigrationProtocol.odg?rev=356933&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/wadi/trunk/wadi-site/src/old_docs/MetaDataMigrationProtocol.odg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/wadi/trunk/wadi-site/src/old_docs/NOTES.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/NOTES.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/NOTES.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/NOTES.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,530 @@
+
+Philosophy
+----------
+
+as little work as possible is done on request thread.
+
+session destruction/migration is only done when we know that no
+relevant application threads are running.
+
+no session can be timed-out whilst a relevant application thread is in
+the container.
+
+invalidation is done by simply marking a session to be dealt with by
+the housekeeper.
+
+contention on the id:session map will be severe so we must keep it's
+use to a minimum.
+
+
+
+migrate - move persistant rep to 'shared' area
+replicate - store persistant rep to shared 'disaster-recovery' area
+whole session - replicate whole session to replication area
+delta - replicate delta to shared area
+
+per-attribute - delta might be add/remove/change attribute
+
+per-session - serialise session into byte[] and diff (optional
+compression) - may get better performance doing this on per-attribute
+basis...
+
+a background thread should go around periodically merging diffs into
+whole session sized storage...
+
+would analogue of isModified flag be of any use - an isModified
+attribute ? - On a per-attrbute basis, this is simply an agreement to
+call set/remove when a change occurs...
+
+
+Migration vs Replication
+
+Migration
+
+JVM -> Store -> JVM
+
+Replication
+
+JVM -> JVM & Store -> JVM & Store
+
+we need 2 stores : 1 for migration and 1 for replication
+
+do they need to cooperate ?
+
+I replicate a session, then evict it. Do I simply throw away the
+reference because I know it is already replicated ? or do I remove all
+replicants and migrate it onto e.g. disc.
+
+Replication:
+
+Object Identity:
+ All sessions
+ single session
+ single attribute
+Safety:
+ Immediate (attribute-based)
+ Request
+ RequestGroup
+Packaging
+ Delta
+ Whole
+
+Migration:
+Object Identity:
+ single session
+ all sessions
+Safety:
+ some factorisable of RequestGroup
+Packaging
+ whole (could we use deltas?)
+
+
+Combinations:
+
+ ObjectIdentity | Safety | Packaging | ???
+
+
+Ideas for Geronimo:
+
+every MBean has an election policy default value is EveryNode -
+i.e. Homogeneous other values are e.g. - OneNodeOnly, RoundRobin
+etc,NumInstances(2)=any 2 nodes, etc... OneNodeOnly=NumInstances(1)...
+
+
+
+
+See FileMigrationPolicy
+
+request enters filter with id
+id table is checked
+
+if session present try for Rlock and req proceeds
+
+if session not present take Wlock and try to activate - when
+activated, release Wlock, take Rlock and proceed.
+
+so when you look up a session, if it isn't in the main table check a
+secondary one, for sessions being activated/located etc.
+
+if we locate and proxy, do we cache the location - not at first.
+
+when search in local store fails take a W lock and try to activate.
+
+If another request comes in before activation is complete, it will
+fall through to secondary table and block before continuing.
+
+If a location enquiry comes in, we can search first the local map and
+then the activation map before responding.
+
+If we don't respond within a given time frame the other container will
+assume the session no longer exists.
+
+
+It would be useful for the session housekeeper to have a garbage
+collection policy. The default policy would simply remove invalid
+sessions. Alternative policies might e.g. move them to an analysis
+area where another program might look at them and figure out why the
+user lost interest in the web site etc...
+
+It looks like, in order to support routing info a la modjk, we will
+need another interceptor to add/remove it from the session id, as and
+when required...
+
+
+
+
+Where to put lock
+
+only facade is looked up by id via impl - so no impl, no facade
+facade API should ONLY be that of HttpSession
+lock needs to exist before and after impl
+
+so:
+
+we need impl placeholders, with no data, just a lock, which can be
+placed into map as and when needed, and turn into a session, cease to
+be one as and when also. - nasty, but much more efficient. - how do we
+do it ?
+
+transit table shared by node2node and node2store migrations
+
+work on
+WADI, Jetty, Tomcat, Resin integrations
+Geronimo/Jetty/Tomcat
+Clustering/JCluster-replacement
+
+High level clustering/election abstractions...
+
+
+distributed gc election protocol broken
+
+
+We can use the Wrapper class to spot when references to stateful
+sessions are migrated to store or elsewhere in the cluster and somehow
+coordinate the same movement for ejb tier state. Ultimately, this may
+not be such a good idea as it will result in cache misses but...
+
+
+If node clocks aren't synched FileMigrationPolicy gcs files at wrong times - ouch !
+
+
+Replication.
+
+Every node holds open a connection to every one of it's buddies,
+each connection has a logical queue
+updates are put onto queues
+queue may be sync/async
+queue may know how to ellyde deltas/complete-sessions
+session should know how to write itself into an internal byte[]
+connection will use NIO to copy this byte[] across connection
+same byte[] should be shared by all queues
+
+if a session is migrated (from storage of another node) to a node it
+will arrive as such a byte[], which can be immediately replicated to
+necessary buddies by being put on their queues, etc.
+
+
+
+A common pattern (IOC)
+
+interface LifeCycle {
+
+public void start();
+public void stop();
+public boolean isRunning();
+}
+
+class Bean implements LifeCycle {
+...
+
+public void setFoo(Type foo){...}
+public void setBar(Type foo){...}
+public void setBaz(Type foo){...}
+
+...
+}
+
+public Type method() {
+
+Bean b=new Bean();
+b.setFoo(x);
+b.setBar(y);
+b.setBaz(z);
+b.start();
+...
+b.stop();
+}
+
+I would like:
+
+an xdoclet tag to identify attributes that can only be set when !isRunning();
+an aspect which will check an assertion on any setter identified in this way.
+the same thing with attributes in 1.5
+
+----------------------------------------
+
+replication.
+
+in case of the loss (planned or catastrophic) of a node, all sessions
+which it hosts must be rehosted immediately or possibly initially
+reconstituted from backup and passivated into shared store...
+
+this revisits the migrate to disc or vm issue?
+
+----------------------------------------
+
+location
+
+the result of a location query should return whether the host node is
+bleeding sessions, if so the session should be migrated off it.
+
+
+----------------------------------------
+
+PROBLEM.
+
+What happens if a request thread arrives whilst we are
+migrating/(passivating) a session?
+
+It waits to acquire an app/read-lock
+We finish and it acquires lock
+It continues into the container and asks for the session.
+It is now too late to proxy it elsewhere, so we will have to migrate the session in underneath it.
+NO GOOD !
+
+before we release the container/write-lock, we need to somehow
+interrupt all the waiting threads and force them to try to look up the
+session again. They will find it is not there and have to consider
+alternatives such as redirection, proxying and migration/activation.
+
+----------------------------------------
+
+shutting down
+
+We could evict all sessions to shared store, whence to be loaded by other nodes.
+
+We could divide sessions equally across cluster and migrate
+concurrently to all nodes.
+
+Bear in mind how this situation will be affected if every
+node/basket/session has a pair of buddies...
+
+----------------------------------------
+
+Refactoring
+
+The location query should really return a client side proxy for the
+session-manager/bucket containing the session in question. That it is
+still contained should be ascertained during the resulting two-way
+conversation.
+
+So maybe the return packet should just contain a serialised proxy ?,
+or simply a string from which we can construct said proxy on the other
+side ?
+
+advantages to string - no serialversionuid, smaller...
+
+----------------------------------------
+
+Servlets & Filters may be marked as 'stateless' - i.e. no session
+interaction.
+
+Non-container code running in a stateless component may not read/write
+the session. Attempts to do so will be met with an Exception. How do
+we handle container code ? setLastAccessedTime will/won't be called ?
+If called - does nothing.
+
+With this optimisation in place, we can avoid locking the session
+table (hopefully) and certainly any unecessary replication or
+contention when serving static resources from e.g. the DefaultServlet
+etc.
+
+----------------------------------------
+
+inbound/outbound lock tables....
+
+refactoring local/activating lock tables....
+
+should be replaced with local/inbound/outbound.
+
+whilst sessions are being migrated into a container (from store or
+another node) they take an inbound lock, whilst bein migrated out of a
+container (to store or another container) they take an outbound lock.
+
+I think we probably need the same arrangement in stores.
+
+Try (but maybe too slow...) :
+
+requests should :
+
+take read lock on outbound table for session id - now no-one can move their session off node
+take read lock on local table for session id - now no-one can garbage collect their session
+check if session is local
+if so is it outbound (wait for outbound lock, then check local again - maybe migration failed)
+if not take inbound readlock
+is session inbound wait
+else release inbound readlock, take inbound writelock and insert locked inbound lock
+try to load session
+release all locks
+
+maybe we don't need the outbound table - the w lock in the session
+would be locked - we wait for it and then try local map again - phew !
+
+----------------------------------------
+
+do we really need to load a session back off disc and activate all
+it's attributes before destroying it?
+
+the attributes were passivated as we saved it - do they need to be
+activated when they are timed out ?
+
+
+----------------------------------------
+
+redirect/cookie/Jetty problem.
+
+If I get hold of the session cookie, rewrite its routing info and
+redirect back to the lb, then browser receives:
+
+Cookie: JSESSIONID=C82EA2883D12C57D1B1F47BE85E8FF71.web0; JSESSIONID=C82EA2883D12C57D1B1F47BE85E8FF71.web1
+
+see headers.txt, instead of just one cookie - it looks like Jetty adds
+the web1 cookie after I have added the web0 one - why ?
+
+Then the browser, firebird, figures out the path for each of them differently !
+
+the first gets /wadi/jsp, the second /wadi... ?
+
+when I logged their paths in Jetty, both were 'null'
+
+----------------------------------------=
+
+eviction lock need not take any locks on first pass
+migration could remove session from table then reinsert on fail
+
+Commands could be nested into two-sided conversations.
+A whole conversation could be sent from one node then progressively unpacked and as passed backwards and forwards
+each command has a commit and rollback method.
+
+----------------------------------------=
+
+
+two types of affinity ?
+
+(1) memory-based
+
+lb actually remembers where last request for a given session was
+processed and sends subsequent requests for same session to same
+place.
+
+with this type of lb we cannot redirect a request to another node via
+its routing info - see (2), but we could proxy it. However this should
+only be done in emergencies as the lb will still think that the
+session was available on the node that it sent the request to and will
+continue to route relevent requests since we it is awkward to relocate
+requests with this lb we shouldhere. Therefore we should choose
+policies that will relocate the session instead, knowing that the lb
+will remember where it last saw it.
+
+NB - memory is state and a tier of these lbs will need to replicate
+such state to each other.
+
+(2) routing-based
+
+lb holds no memory/state, but this is encoded as routing info on the
+end if the session cookie/param. This is advantageous since no state
+needs to be replicated across lb tier, but adds extra complexity in
+web tier, since if a session relocates its session cookie must be
+adjusted.
+
+If we understand how the routing info is encoded then we can use
+request relocation (cheaper than session relocation). This means that
+we can actually relocate sessions to where we want them, rather than
+where the lb expects them, then relocate initial requests to
+them. Subsequent requests will thenceforth be delivered to correct new
+location.
+
+
+node shutdown...
+
+we should avoid writing to long term store if we can, since it is a
+single point of contention and failure.
+
+under a routing-based lb, a node should share out its active sessions
+between remaining nodes up to their capacity, then write remaining
+sessions into long term storage. The lb will have no idea where to
+deliver requests for these sessions, since the node encoded in the
+routing info is inactive, so it will drop them anywhere on the
+cluster. The node receiving the request will relocate it to the
+sessions new owner. worst case scenario cost for a sbsequent incoming
+request will be: either a single request relocation, or a single
+session disc-node migration.
+
+under a memory-based lb a node has a choice :-(
+
+a) do as for a routing-based lb.
+
+worst case scenario cost will be: either one node/store-node session relocation
+
+or migrate all sessions to store where WCSC becomes one store-node session relocation
+
+so if we want to avoid use of store it looks as if both lb strategies
+should share their sessions out with remaining nodes. At least some
+requests will fall on correct node and if they fall on wrong node cost
+will be same or less than load from store.
+
+There is another way an lb can implement stickiness - by intrusive
+cookie that records where last successful request went, this can be
+considered to be the same as routing-based affinity except that the
+routing info is encoded in its own cookie - WADI should consider how
+to do this.
+
+in summary:
+
+- node is shutting down
+- takes exclusive lock on session map
+- multicasts to all other nodes enquiring about location and capacity
+- share out active sessions between answering nodes up to their
+capacity (all nodes should answer as this will be quicker than waiting
+for a timeout - we have to wait anyway if we don't know how many nodes
+there are)
+- release lock or shutdown whilst still holding it - browsers will
+reissue unanswered requests.
+
+issues.
+
+node A shuts down passing node B sessions that fill it to capacity
+node A puts remaining sessions in store
+node B receives a request that requires that it load one of As sessions from store
+but it has no capacity...
+
+it can temporarily override max-size
+it can forcibly evict another session to make space
+
+it can look for another that has space and proxy the request to it -
+but will end up being a long-term go-between in this conversation -
+not a good idea.
+
+----------------------------------------
+
+does identity need to live in a session ?
+
+does validity need to live in a session - is an invalid session simply
+not one that doesn't exist?
+
+----------------------------------------
+
+now that facade is set in HttpSessionImpl.readObject ensure that it is
+not being done unecessarily elsewhere.
+
+----------------------------------------
+
+we need a good joinpoint to hang session creation and destruction
+related aspects from - how about a session commission/decommission
+method pair.
+
+----------------------------------------
+
+wad-web.xml is written (currently) in Jetty-ese, because I anticipate
+the internal APIs changing frequently for a while and Jetty-ese is
+more flexible in this respectthan Digester. I understand that this
+ties the Tomcat integration to Jetty code. Too bad :-) its probably
+only a temporary situation.
+
+----------------------------------------
+
+The PassivationStrategy should probably live inside the EvictionPolicy
+? Their naming convention should be rationalised.
+
+-----------------------------------------
+
+wadi-web.xml needs FAQ-ing
+
+-----------------------------------------
+
+What happens when Jetty or Tomcat are run via JMX :-)
+
+-----------------------------------------
+
+for Tomcat (maybe Jetty as well)
+
+
+if get() comes in from above filter, we know it is request thread and maybe first time
+filter will wrap request and put aspect around get so that it arrives with ref to req object in threadlocal
+req obj will have field for current session
+
+req objects session methods will be aspected to keep this up to date
+
+so any session fetch/create/invalidate will update relevant request
+obj.
+
+on leaving through filter current session will be picked out of request wrapper and unlocked...
+
+
+
+In Jetty, we may not need to wrap request as every get/create will have req passed as param...
+
+what about invalidate ?, how do we ensure that req is kept up to date...
+invalidation goes through manager which must notify relevant request wrappers ?
+
+-----------------------------------------
Added: incubator/wadi/trunk/wadi-site/src/old_docs/NOTES2.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/NOTES2.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/NOTES2.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/NOTES2.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,421 @@
+
+discuss session events with distributed sessions
+session counting and monitoring
+etc..
+
+discuss :
+ static/stateless
+ dynamic/stateless - how to optimise...
+ dynamic/stateful
+
+
+BucketingStrategy needs :
+
+bucket list management
+session id -> bucket mapping
+bucket -> replicant mapping
+
+Node can use this to get a list of buckets, allocate one two each
+session and decide which buckets it is responsible for backing up.
+
+Node leaving/joining events should cause changes in
+bucket->replicant-mapping as nodes take the place of leaving nodes, or
+balance state between themselves...
+
+----------------------------------------
+
+two locking models :
+
+Memory - fine granularity, fast-access - lock owned by Context
+Other - configurable granularity, slower access - lock owned by external component (Collapser)
+
+----------------------------------------
+
+
+lookup is done through a tiered series of caches (hopefully jcaches).
+
+e.g.
+
+memory
+local [disc]
+shared [cluster]
+shared [db]
+
+As you cross from local to shared you MUST go through a barrier in
+which you negotiate ownership, with the rest of the cluster, of the
+resource, should you recover it successfully. This will prevent any
+contention for the same resource in e.g. a shared disc, db or
+misunderstandings about ownership occurring within the cluster. It
+also means that the code for this negotiation need only be written
+once at the cluster-level, rather than for every shared medium.
+
+
+----------------------------------------
+
+
+http-request or session-search message arrives at node where session is not present.
+
+It creates dummy session of said id, locks it exclusively, attaches timestamp and waits on it (with timeout)
+
+Node sends session-search-message to all other nodes, including timestamp of arrival of http-request, or brought by message.
+
+When subsequent http-request or session-search-message arrives on node where exclusive lock has already been taken:
+
+it compares tstamp with exclusive lock, if same age or older it gives up. if younger it waits.
+
+
+when request message arrives at node holding session - first come
+first served - session is granted to first thread to achieve lock.
+
+
+when thread gains lock, if session is valid, it may migrate it back
+whence it came. if it is invalid a message will give up (it will be
+more recent and may have missed session on this node, but shoud win it
+on a another). if it is a request, it will start the whole process again..
+
+Write a test to ensure tha this algorithm is bombproof.
+
+
+----------------------------------------
+
+
+Implement transparent e/in-viction - i.e. session stub is maintained
+in-vm, only data is evicted to LOCAL disk.
+
+CONs;
+
+- more data will be held in memory
+
+PROs:
+
+- no need to check disc - we will know immediately if we own a session
+- simpler code, sessions can be decorated with evictability
+
+- if a session is migrated, it will be loaded by its owner and the
+transferred - only the owner will have access to the copy on disc,
+therefore this disc can now be LOCAL.
+
+CONs:
+
+- if a node dies (without replication) all its sessions (not just
+active ones) will be lost.
+
+PROs:
+
+- when a node is asked for a session that it does not have, it only
+has to check the cluster - no more race conditions across NFS.
+
+
+----------------------------------------
+
+Latest plan is :
+
+Node n1 receives a request for a session s
+
+it checks local cache for s
+it checks eviction cache for s
+it checks recently-died (if it's there it gives up)
+it checks recently-migrating
+ if mentioned
+ if mentioned request is older than this request continue
+ else (mentioned request is younger than this one - this one may have been e.g. proxied) give up on migration and relocate request to mentioned node
+
+it takes a timestamp t1
+it sends a message to cluster saying - 'I needed s at t1'
+
+
+node n2 receives message 'I needed s at t1' from n1
+it checks local cache for s and
+either
+ finds it
+ it takes a W-lock on s
+ when it has the lock
+
+ if session is still valid:
+ it checks s.lastAccessedTime() t2
+ if t1>t2, it migrates s to n1
+ if t2>=t1 it messages n1 saying 'relocate your request for s at t1 to n2'
+ else
+ it messages n1 saying 're your request for s at t1 - I had s but now it has gone'
+
+ doesn't find it
+ puts an entry in the searches table 'n1 at t1 looking for s' for x seconds
+
+n1 either :
+
+receives the migrated session and processes the request
+
+or
+
+receives message 'relocate your request for s at t1 to n2' and does so
+
+or
+
+receives message 're your request for s at t1 - I had s but now it has gone'
+
+or waits until timeout then decides that
+
+
+need a recently-migrating and a recently-died indexed and sorted sets
+of fixed size, things cease to become 'recent' when they fall of the
+end...
+
+
+
+
+Greg
+
+cannot redirect a a post
+issues with adding metadata (original request time etc) to a redirection/proxy -
+can we arrange a lb-wc redirection protocol instead of client-lb-wc - is it quicker to proxy ?
+authorisation etc..
+
+----------------------------------------
+
+
+names:
+
+Jetty has :
+
+Handler
+
+Tomcat has :
+
+Processor
+
+Web Spec has :
+
+Contexts
+
+
+
+Handler - Jetty has them
+Context[ualiser] - WebSpec has them
+Processor - Tomcat has them
+
+Realizer
+Renderer
+
+Session/Store
+Combiner/Session
+
+Executor ?
+Runner ?
+Actualiser
+Concretise
+Reify ?
+
+
+
+
+We can now serialise out a session with e.g. gzip, then load it back
+in, promote it up through the ranks and emmigrate it to another node,
+where we will sonn be able to demote it back down the ranks to
+e.g. LocalDisc - all without demarshalling it into its constituent
+objects and firing any listeners at all.
+
+
+
+Depending on how I implement replication, it may be the case that
+immediately after calling setAttribute(key, val), where val is an
+ActivationListener, the container will call willPassivate() on it,
+serialise it and send the result off-node, leaving the val in your
+hand deactivated.. It won't be reactivated, unless, (a) I do that
+immediately, or (b) you call getAttribute(name).
+
+If the container does (a), this implies that the val ref in your hand
+is valid to change - which it is not, since it now has nothing to do
+with the session, which has effectively taken a copy... - or...
+
+
+If you do (b), this will deserialise and activate the attribute,
+returning it ...
+
+I think we should go with (a)....
+
+----------------------------------------
+
+
+how about a way of applying for a W lock:
+
+if any R locks exist, you wait
+
+if another W lock is in place, you exit immediately - there is no
+point in hanging around, the session will be shipped off node or
+destroyed...
+
+----------------------------------------
+
+Open Source Load Balancers:
+
+1. http://siag.nu/pen/ (works on both windows and unix, you may need cygwin)
+2. http://balance.sourceforge.net (unix only)
+3. Apache mod_jk/mod_jk2 with load balancing
+
+pound
+jetty balancer
+
+----------------------------------------
+
+Bibliography:
+
+http://www.theserverside.com/articles/article.tss?l=Tomcat
+http://www.onjava.com/lpt/a/4649
+http://www.onjava.com/lpt/a/4702
+
+----------------------------------------
+
+Jetty LB - API:
+
+
+add vhost/host:port/context[/subcontext] (html -> node1, gif-> node2)
+remove ""
+setWeight
+
+----------------------------------------
+
+Logging Policy
+
+WADI logs information at the following levels :
+
+ERROR -
+
+something has really gone wrong - i.e. a session could not be served
+for some reason or another. The impact on WADI is functional and will
+impact correctness of service.
+
+WARN -
+
+something unexpected or sub-optimal has occurred. The impact will be
+in terms of performance rather than correctness. This level is useful
+for understanding a little more about what is going on inside WADI.
+
+INFO -
+
+general information about WADIs workings is logged at this level.
+
+DEBUG -
+
+this level is used to log session lifecycle - creation, destruction,
+peer-to-peer and peer-to-store migration etc...
+
+TRACE -
+
+exhaustive detail about WADI's inner workings ?
+
+
+----------------------------------------
+
+QUESTIONS about Spec - to be resolved
+
+
+when notifying an HttpSessionAttributeListener.attributeReplaced(HttpSessionBindingEvent event) - should event.value be the new or oldValue (I am using new)
+should AttributeListeners be notified before or after BindingListeners ?
+
+
+----------------------------------------
+
+SERIALISATION
+
+We need to combine a number of features to allow session serialisation to be necessarily flexible.
+
+Object Identity Scope:
+----------------------
+
+Whole Session :
+ preserves object identity across whole session
+ any change to session marks whole session as dirty
+ when serialised, smallest unit stored/replicated is whole session
+ if any part of the session is needed in object form, whole session must be deserialised
+
+Part Session (Attribute) :
+ preserves object identity across a single attribute. Refs to the same object from more than one attribute may diverge
+ individual attributes may be marked as dirty
+ when serialised, dirty attributes are reserialised. Clean ones may use the result of a previous serialisation
+ smallest unit stored/replicated is attribute
+ if any part of the session is needed in object form, only that part need be deserialised
+
+
+When is a [part of a] session dirty:
+------------------------------------
+
+Explicit :
+ write access to an attribute has occurred
+
+Implicit :
+ read or write access to an attribute has occurred
+
+
+Distributable:
+-------------
+
+A session may be serialised (i.e. migrated to store or peer)
+
+
+Replicable:
+------------
+
+A session should maintain an off-node backup when 'at risk'
+
+
+When should a [part of a] session be replicated:
+------------------------------------------------
+
+ Immediately - as soon as the access marking the [part of the] session
+ dirty is complete. This is tricky if we are in Implicit mode, because
+ we are implying that references may be taken and used to modify
+ attribute contents... - Consider
+
+ End of Request group - as soon as the last overlapping stateful
+ request accessing a session completes, changes will be flushed off
+ node.
+
+ Needs more thought...
+
+OTHER THOUGHTS :
+
+Session should be divided into [application-]data and
+[container-]meta-data. Container changes can be considered 'explicit'
+since we control how access occurs.
+
+Upon expiry of a session in store, we need to try to avoid
+deserialising as much of it as we can :
+
+HttpSessionListeners :
+ - registered with Manager
+ - require session reference in the sessionDestroyed notification - but may not actually access session...
+
+HttpSessionAttributeListeners :
+- registered with Manager
+- require session, key and value references in their attributeRemoved notification - but may not actually access them...
+
+HttpSessionActivationListeners :
+- registered as attributes
+- internal rep of serialised session needs to be aware of their presence
+- will require the deserialisation of relevant attributes, so that they can be called
+
+HttpSessionBindingListeners
+- registered as attributes
+- internal rep of serialised session needs to be aware of their presence
+- will require the deserialisation of relevant attributes, so that they can be called
+
+If none of the above are present, a serialised session can be discarded without deserialising - a big win !
+
+
+Attributes Dirtier Replicater
+none - -
+Attr Ex none
+Attr Im none
+Sess Ex none
+Sess Im none
+Attr Ex Imm [probably OK - think about it]
+Attr Ex Req
+Attr Im Imm [probably OK - think about it]
+Attr Im Req
+Sess Ex Imm [probably OK - think about it]
+Sess Ex Req
+Sess Im Imm [probably OK - think about it]
+Sess Im Req
+
+----------------------------------------
+
Added: incubator/wadi/trunk/wadi-site/src/old_docs/NewDataMigrationProtocol.odg
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/NewDataMigrationProtocol.odg?rev=356933&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/wadi/trunk/wadi-site/src/old_docs/NewDataMigrationProtocol.odg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/wadi/trunk/wadi-site/src/old_docs/NewMetaDataMigrationProtocol.odg
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/NewMetaDataMigrationProtocol.odg?rev=356933&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/wadi/trunk/wadi-site/src/old_docs/NewMetaDataMigrationProtocol.odg
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/wadi/trunk/wadi-site/src/old_docs/PROBLEMS.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/PROBLEMS.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/PROBLEMS.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/PROBLEMS.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,127 @@
+WADI 1
+
+2004/10/08 16:41:47:074 BST [WARN] wadi - -/wadi/jsp/render.jsp: <java.lang.NullPointerException>java.lang.NullPointerException
+ at org.codehaus.wadi.Filter.doFilter(Filter.java:164)
+ at org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:511)
+ at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:463)
+ at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:525)
+ at org.mortbay.http.HttpContext.handle(HttpContext.java:1457)
+ at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514)
+ at org.mortbay.http.HttpContext.handle(HttpContext.java:1409)
+ at org.mortbay.http.HttpServer.service(HttpServer.java:889)
+ at org.mortbay.http.HttpConnection.service(HttpConnection.java:831)
+ at org.mortbay.http.ajp.AJP13Connection.handleNext(AJP13Connection.java:287)
+ at org.mortbay.http.HttpConnection.handle(HttpConnection.java:848)
+ at org.mortbay.http.ajp.AJP13Listener.handleConnection(AJP13Listener.java:212)
+ at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:325)
+ at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520)
+
+2004/10/08 16:41:48:868 BST [WARN] Filter - -88F945EB24909A6D6CEAB2E440F7D563: local session emmigrated before it could be locked into container
+
+----------------------------------------
+WADI 2
+----------------------------------------
+
+1). node0 sends out a request (R) for a session's immigration
+2). node1 receives R and sends the session back
+3). node0 acknowledges and migration commits
+4). node2 [in]directly acquires the same session from node1
+5). node2 receives R sometime later and sends the same session to node0
+6). node0 does not acknowledge - it no longer requires the session
+7). node2 times out and issues a warning :-(
+
+at (6), node0 could send a non-acknowledgement, explaining what has
+happened and preventing the warning...
+
+
+2005/04/21 06:25:58:389 BST [WARN] MessageDispatcher - -no response to request within timeout (500 millis): 03A5A3A0B6A8874D483C767F1DBACB7E
+2005/04/21 06:25:58:389 BST [WARN] ImmigrateRelocationStrategy$ImmigrationImmoter - -no ack received for session immigration: 03A5A3A0B6A8874D483C767F1DBACB7E-19107-TemporaryTopic-{TD{ID:smilodon-36744-1114014573474-6:0}TD}ID:smilodon-36744-1114014573474-12:0
+2005/04/21 06:25:58:389 BST [WARN] Utils - -motion failed: 03A5A3A0B6A8874D483C767F1DBACB7E : memory -> emigration (504 millis)
+
+
+----------------------------------------
+
+not sure about this one :
+
+2005/04/20 17:56:57:627 BST [WARN] ImmigrateRelocationStrategy - -problem handling immigration request: FB1F0D58D581BE642D8E27CAF3D54F7C <EDU.oswego.cs.dl.util.concurrent.BrokenBarrierException>EDU.oswego.cs.dl.util.concurrent.BrokenBarrierException
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.doRendezvous(Unknown Source)
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.attemptRendezvous(Unknown Source)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher.exchangeMessages(MessageDispatcher.java:238)
+ at org.codehaus.wadi.sandbox.impl.ImmigrateRelocationStrategy$ImmigrationImmoter.prepare(ImmigrateRelocationStrategy.java:246)
+ at org.codehaus.wadi.sandbox.impl.Utils.mote(Utils.java:62)
+ at org.codehaus.wadi.sandbox.impl.AbstractChainedContextualiser.promote(AbstractChainedContextualiser.java:74)
+ at org.codehaus.wadi.sandbox.impl.MemoryContextualiser.handle(MemoryContextualiser.java:81)
+ at org.codehaus.wadi.sandbox.impl.AbstractChainedContextualiser.contextualise(AbstractChainedContextualiser.java:68)
+ at org.codehaus.wadi.sandbox.impl.ImmigrateRelocationStrategy.onMessage(ImmigrateRelocationStrategy.java:201)
+ at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
+ at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
+ at java.lang.reflect.Method.invoke(Method.java:324)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$TargetDispatcher.dispatch(MessageDispatcher.java:86)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$DispatchThread.run(MessageDispatcher.java:187)
+
+2005/04/20 17:56:59:827 BST [WARN] MessageDispatcher - -no response to request within timeout (500 millis): FB1F0D58D581BE642D8E27CAF3D54F7C
+
+----------------------------------------
+
+an activemq issue - probably resolved when lifecycle is introduced...
+
+2005/04/21 06:27:03:684 BST [INFO] Server - -Shutdown hook complete
+java.lang.NullPointerException
+ at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:202)
+ at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:186)
+ at org.codehaus.activemq.util.SerializationHelper$ObjectInputStreamExt.resolveClass(SerializationHelper.java:101)
+ at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
+ at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
+ at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
+ at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
+ at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
+ at org.codehaus.activemq.util.SerializationHelper.readObject(SerializationHelper.java:74)
+ at org.codehaus.activemq.message.ActiveMQObjectMessage.readBody(ActiveMQObjectMessage.java:208)
+ at org.codehaus.activemq.message.ActiveMQMessage.buildBodyFromBytes(ActiveMQMessage.java:2284)
+ at org.codehaus.activemq.message.ActiveMQObjectMessage.getObject(ActiveMQObjectMessage.java:161)
+ at org.codehaus.activemq.message.ActiveMQObjectMessage.toString(ActiveMQObjectMessage.java:219)
+ at java.lang.String.valueOf(String.java:2131)
+ at java.lang.StringBuffer.append(StringBuffer.java:370)
+ at org.codehaus.activemq.ActiveMQMessageConsumer.processMessage(ActiveMQMessageConsumer.java:448)
+ at org.codehaus.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:112)
+ at org.codehaus.activemq.ActiveMQSessionExecutor.run(ActiveMQSessionExecutor.java:97)
+ at java.lang.Thread.run(Thread.java:534)
+
+
+----------------------------------------
+
+2005/04/21 12:16:09:624 BST [WARN] MessageDispatcher - -rendez-vous timed out: 114875DB7B8B1F7117BB8BC19B60AB19-3734-TemporaryTopic-{TD{ID:smilodon-42112-1114079651086-7:0}TD}ID:smilodon-42112-1114079651086-19:0 <EDU.oswego.cs.dl.util.concurrent.TimeoutException>EDU.oswego.cs.dl.util.concurrent.TimeoutException
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.doRendezvous(Unknown Source)
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.attemptRendezvous(Unknown Source)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$RendezVousDispatcher.dispatch(MessageDispatcher.java:140)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$DispatchThread.run(MessageDispatcher.java:189)
+
+2005/04/21 12:16:04:942 BST [WARN] MessageDispatcher - -rendez-vous timed out: 114875DB7B8B1F7117BB8BC19B60AB19-3722-TemporaryTopic-{TD{ID:smilodon-42118-1114079653597-6:0}TD}ID:smilodon-42118-1114079653597-23:0 <EDU.oswego.cs.dl.util.concurrent.TimeoutException>EDU.oswego.cs.dl.util.concurrent.TimeoutException
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.doRendezvous(Unknown Source)
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.attemptRendezvous(Unknown Source)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$RendezVousDispatcher.dispatch(MessageDispatcher.java:140)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$DispatchThread.run(MessageDispatcher.java:189)
+
+2005/04/21 12:16:07:045 BST [WARN] MessageDispatcher - -rendez-vous timed out: 114875DB7B8B1F7117BB8BC19B60AB19-3727-TemporaryTopic-{TD{ID:smilodon-42136-1114079661576-6:0}TD}ID:smilodon-42136-1114079661576-16:0 <EDU.oswego.cs.dl.util.concurrent.TimeoutException>EDU.oswego.cs.dl.util.concurrent.TimeoutException
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.doRendezvous(Unknown Source)
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.attemptRendezvous(Unknown Source)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$RendezVousDispatcher.dispatch(MessageDispatcher.java:140)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$DispatchThread.run(MessageDispatcher.java:189)
+
+2005/04/21 12:16:12:328 BST [WARN] MessageDispatcher - -rendez-vous timed out: 114875DB7B8B1F7117BB8BC19B60AB19-3726-TemporaryTopic-{TD{ID:smilodon-42148-1114079675407-6:0}TD}ID:smilodon-42148-1114079675407-41:0 <EDU.oswego.cs.dl.util.concurrent.TimeoutException>EDU.oswego.cs.dl.util.concurrent.TimeoutException
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.doRendezvous(Unknown Source)
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.attemptRendezvous(Unknown Source)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$RendezVousDispatcher.dispatch(MessageDispatcher.java:140)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$DispatchThread.run(MessageDispatcher.java:189)
+
+2005/04/21 12:16:03:557 BST [WARN] MessageDispatcher - -rendez-vous timed out: 114875DB7B8B1F7117BB8BC19B60AB19-3723-TemporaryTopic-{TD{ID:smilodon-42162-1114079680144-10:0}TD}ID:smilodon-42162-1114079680144-47:0 <EDU.oswego.cs.dl.util.concurrent.TimeoutException>EDU.oswego.cs.dl.util.concurrent.TimeoutException
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.doRendezvous(Unknown Source)
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.attemptRendezvous(Unknown Source)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$RendezVousDispatcher.dispatch(MessageDispatcher.java:140)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$DispatchThread.run(MessageDispatcher.java:189)
+
+2005/04/21 12:16:02:771 BST [WARN] MessageDispatcher - -rendez-vous timed out: 114875DB7B8B1F7117BB8BC19B60AB19-3714-TemporaryTopic-{TD{ID:smilodon-42179-1114079684252-7:0}TD}ID:smilodon-42179-1114079684252-18:0 <EDU.oswego.cs.dl.util.concurrent.TimeoutException>EDU.oswego.cs.dl.util.concurrent.TimeoutException
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.doRendezvous(Unknown Source)
+ at EDU.oswego.cs.dl.util.concurrent.Rendezvous.attemptRendezvous(Unknown Source)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$RendezVousDispatcher.dispatch(MessageDispatcher.java:140)
+ at org.codehaus.wadi.sandbox.impl.MessageDispatcher$DispatchThread.run(MessageDispatcher.java:189)
Added: incubator/wadi/trunk/wadi-site/src/old_docs/Portlets.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/Portlets.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/Portlets.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/Portlets.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,29 @@
+
+looks like portlet spec unifies session namespace inter-app and
+cross-cluster.
+
+if app-a/node-a invalidates session xxx, app-b/node-b must find out
+and invalidate corresponding sesion...
+
+sessions are store by key: <context>-<sessionid>-<bucketid> so
+sessions in the same xcd-space will be in the same bucket, so will try
+to colocate.
+
+bucket must also be responsible for buliding another index for
+xcd-enabled sessions (or should it be part of the same index ?:
+
+<sessionid>: {[<context>, ,location>], ...}
+
+so that, on invalidation of an xcd-enabled session, all other 'views'
+on this session can also be invalidated...
+
+
+maybe index should be a map of maps :
+
+<sessionid>-<bucketid> : <context> : <location>
+
+non-xcd enabled sessions could use a v.efficient SingletonMap wrapper
+that just held a single <context>:<location> entry.
+
+what about ejbs ?
+
Added: incubator/wadi/trunk/wadi-site/src/old_docs/REPLICATION.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/REPLICATION.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/REPLICATION.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/REPLICATION.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,110 @@
+
+A Proposal for a replication tier for WADI.
+-------------------------------------------
+
+When to replicate:
+------------------
+
+(1). After each mutative session method invocation (except
+setLastAccessedTime()).
+
+Modifiers:
+ mode=sync/async
+ safe-distance=local-queue/network/remote-queue/remote-invocation
+ granularity=invocation
+
+Features:
+ most immediate point at which change can be notified.
+ no batching - many small changes will be replicated
+ highest cost/highest accuracy
+ object identity is per-attribute
+
+Problems:
+ assumes that objects being passed in and out of session are not being written by other app threads (can we make this assumption?)
+
+
+(2). At end of each request.
+
+Modifiers:
+ mode=ditto
+ safe-distance=ditto
+ granularity=batched-invocation, whole-session, diff?
+
+Features:
+ object identity will be either per-attribute (batched-invocation) or per-session (whole-session/diff?)
+ a reasonable point at which to backup
+
+Problems:
+
+ to maintain consistent semantics we would have to break spec and
+ serialise requests - this could be done by taking a write-lock for
+ period of request instead of a read-lock. It may be possible to avoid
+ the need for request serialisation if mode=batched-invocation by only
+ replicating changes that have happened on this request thread,
+ however session mutations performed by app-spawned threads will need
+ to be taken into account.
+
+(3). At end of request group.
+
+ mode=ditto
+ safe-distance=ditto
+ granularity=batched-invocation, whole-session, diff?
+
+Features:
+ object identity will be either per-attribute (batched-invocation) or per-session (whole-session/diff?)
+ a consistant point at which to backup
+
+Problems:
+
+ this may be a little too infrequest for some users, but is a pretty
+ good compromise. Each request attempt(-1)-s to get a write lock at
+ the end of its request, overlapping this with releasing its
+ read-lock. REPLICATION_PRIORITY should become top priority. If if
+ gets it the we know that there are no other readers and we can
+ replicate.
+
+
+
+Having decided when, what (granularity) and with what level of safety
+(mode/safe-distance) to replicate. We can now see how aspects, filter
+and manager might interact to send replication messages encapsulating
+session change.
+
+To whom to replicate?
+---------------------
+
+Each node needs to hold a model of every other node in the
+cluster. Each node will contain a list of attributes. Some of these
+will be deploy-time - e.g. ip-address, subnet, power-supply, room,
+building etc. Some of them will be dynamic e.g. free-mem,
+no-of-sessions-carried, no-of-rthreads-free etc...
+
+These attributes need to be user define/calculable and updated at a
+configurable interval.
+
+The user defines a stack of weightings factors that are combined into
+a single factor that is used as a Comparator to resort the set of
+nodes ach time an update comes in.
+
+The node uses this sorted list of nodes to decide which nodes to use
+as buddies for the next session created.
+
+The list is filtered so that work is distributed over a number of high
+value nodes rather than only the highest - to avoid storming single
+high-weighted nodes to death.
+
+The session may have to carry a serialisable reference to its buddy
+group, so that, no matter where it travels it knows to whom to
+replicate.
+
+If a session tries to migrate onto a peer holding its buddy, it should
+be possible to sync them then promote the buddy to primary and demote
+the primary to buddy.
+
+A buddygroup will be a cluster managed resource. If a buddy is lost it
+will be replaced with another. - this needs more thought - perhaps we
+need buckets here, otherwise we will get session aggregation when
+nodes fail and some nodes will end up
+
+sessions will listen to buddygroups. if a buddy is lost from the group
+they get an event and choose a replacement.
Added: incubator/wadi/trunk/wadi-site/src/old_docs/TODO
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/TODO?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/TODO (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/TODO Wed Dec 14 15:32:56 2005
@@ -0,0 +1,70 @@
+rename DIndex -> GIndex
+refactor request/response structure
+switch off bucket regeneration and harden rebucketing
+think of a better name than bucket
+switch on bucket regeneration and harden
+run concurrent requests through and harden
+
+DefaultCluster creates StateServiceImpl in its ctor
+StateServiceImpl sets up Timer in its ctor
+if DefaultCluster.start is not called in time, Timer will go off before start() is called and distribute Nodes distributed State...
+FIX
+
+synchronised transferBucketRequest stub
+xs
+
+deregister listeners
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+GroundWork
+-----------
+
+take a bart from Powell -> Berkley - get off at MacArthur
+10 mins... across the bay
+call cellphone.
+
+9:00-ish
+
+
+
+
+ACTIVECLUSTER:
+--------------
+
+pluggable election policy
+sync coordinator handover
+StateService does not start until Node starts
+Coordinator correctly elected
+
+
+WADI
+----
+
+deregister listeners at correct time...
+node shuts down whilst no coordinator available ? - if you are no longer coordinator when message arrives - forward it
+if you do not get a reply from the coordinator - wait and try again...
+
+DO NOT QUIT whilst involved in a sync message exchange
+
+
+
+SHOULD NOT TAKE ON ANY BUCKETS UNTIL SHUTDOWN HOOK IS INSTALLED ????
+or do we just treat this as a catastrophic failure.. ?
+
+Jetty does not add hook until all Servers are started...
Added: incubator/wadi/trunk/wadi-site/src/old_docs/TOODOO
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/TOODOO?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/TOODOO (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/TOODOO Wed Dec 14 15:32:56 2005
@@ -0,0 +1,6 @@
+
+
+It ooks as if tomcat/HttpSessionImpls are getting facades of the wrong
+type... it's getting a shared one instead of a tomcat one:-(
+
+
Added: incubator/wadi/trunk/wadi-site/src/old_docs/UPGRADES.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/UPGRADES.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/UPGRADES.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/UPGRADES.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,4 @@
+
+tomcat-5.5 - Manager interface haslost methods mentioning DefaultContext and the DefaultContext class...
+
+jetty-6 - SessionManager has changed package and added an initialise() method
Added: incubator/wadi/trunk/wadi-site/src/old_docs/WADI.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/WADI.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/WADI.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/WADI.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,66 @@
+ protected SortedMap _sortedWaitingWriters=new SyncSortedMap(new TreeMap(new Comparator()
+ {
+ public int
+ compare(Object o1, Object o2)
+ {
+ return ((Thread)o2).getPriority()-((Thread)o1).getPriority();
+ }
+ }),
+ new Mutex())
+
+synchronized (this){...;this.wait();...} becomes synchronized(lock){...;lock.wait();...}
+
+you must synchronize on lock to wake up a thread - this ensures that:
+
+1. the thread is actually wait()-ing
+2. you own the monitor
+
+_writerQueue is synched separately...
+
+a thread can release() and try to notify() a waiting thread - if the
+thread is not yet waiting the notify will wait.
+
+put in an assert to check that the thread is not already in the writer
+list...
+
+
+1, wait, loop(try(2)catch(3,next-writer, next-reader))
+
+end-wait,..., next-reader-or-writer
+
+
+inline endWrite() and maybe signalNextWriter() (notifyNextWriter())
+
+
+maybe have a look at Doug's src for 1.5
+
+
+explain why this lock is so important
+
+
+How about keeping a final array of MAX_THREAD objects and queueing
+each writer thread against the corresponding priority object and
+incrementing a counter. The Object would contain a counter and
+synchronised incr/decr/getCount() methods.
+
+contending threads would be split MAX-MIN_THREAD ways - more efficient
+than normal lock !!
+
+wait()-ing and notify()-ing an object would only involve synching on
+the lock object...
+
+
+FEATURE TABLE
+--------------
+
+Impl Persistant? Evicting? Replicating? Whole/Delta? 1->all/n | author - shared-store?
+--------------------------------|-----------|---------|------------|------------|-----
+WADI | | | NYI | | | jules
+JETTY DSM | | | Y | D | | jules
+JETTY DSM/JBoss | | | | | | jules
+TC4/JBoss | | | | | | ??
+TC5 PersistentManager | Y | Y | | | | Kief - use store as backup
+TC5 DeltaManager | | | | | | filip,craig,jean-francois
+TC5 SimpleTcpReplicationManager | | | | | | filip, bela
+???? | | | Y | | | rob block
+
Added: incubator/wadi/trunk/wadi-site/src/old_docs/abstract.txt
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/abstract.txt?rev=356933&view=auto
==============================================================================
--- incubator/wadi/trunk/wadi-site/src/old_docs/abstract.txt (added)
+++ incubator/wadi/trunk/wadi-site/src/old_docs/abstract.txt Wed Dec 14 15:32:56 2005
@@ -0,0 +1,70 @@
+
+Abstract:
+
+Highly Available State in the Apache Geronimo Web-Tier.
+-------------------------------------------------------
+
+High availability and scalability are becoming an increasing business
+requirement for the modern enterprise.
+
+This talk will look at the challenge of maintaining the high
+availibility of state in an open source web cluster.
+
+We will survey current open source solutions to these problems, with
+specific reference and comparison to Geronimo (geronimo.apache.org),
+Apache's J2EE Application Server project and WADI (wadi.codehaus.org),
+its web clustering component.
+
+We will discuss in detail issues such as HttpSession affinity,
+bleeding, what it means to be a 'distributed' web application, the
+semantics of the HttpSession event model in a 'distributed'
+deployment, the semantics of object reference within a 'distributed'
+HttpSession, session passivation, activation, eviction, migration and
+replication (a number of strategies) and finally self-organising and
+self-healing clusters.
+
+
+Attendees
+---------
+
+To derive maximum benefit from this BOF, the attendee should have a
+good grasp of what an HttpSession is, what it looks like and what it
+is used for. Knowledge about HttpRequest/Response and the use of
+Cookies / URL parameters to mark session identity will also be
+helpful.
+
+
+Summary
+---------
+
+The BOF will use slides and demonstrations to illustrate the issues
+surrounding maintaining the high availibility of web state within a
+J2EE cluster.
+
+The goal of the session is that attendees will leave with a thorough
+understanding of the issues surrounding clustering a stateful
+web-application, and a strong grasp of the technologies available to
+them within the open source arena.
+
+Bio:
+----
+Jules Gosnell is a Core Developers Network partner, founding Apache
+Geronimo committer and PMC member. He has been writing open source for
+a number of years and using it for a long time previous to
+that. Further years of experience working for financial institutions
+in the J2EE arena have given him a solid grasp of exactly what he
+needs from a J2EE Application Server and his work in and around
+Geronimo is an effort to attain that goal....
+
+
+Address:
+--------
+
+2, Tannery Cottages
+Tannery Lane
+Bramley
+Surrey
+GU5 0AB
+U.K.
+
++1483-898348
Added: incubator/wadi/trunk/wadi-site/src/old_docs/combinations.gnumeric
URL: http://svn.apache.org/viewcvs/incubator/wadi/trunk/wadi-site/src/old_docs/combinations.gnumeric?rev=356933&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/wadi/trunk/wadi-site/src/old_docs/combinations.gnumeric
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream