<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Wish List: Session Moratorium</title>
	<atom:link href="http://www.efsavage.com/blog/posts/session_moratorium/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.efsavage.com/blog/posts/session_moratorium/</link>
	<description>Good stuff, updated weekly(ish)</description>
	<pubDate>Wed, 19 Nov 2008 04:42:20 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Yoav Shapira</title>
		<link>http://www.efsavage.com/blog/posts/session_moratorium/#comment-6124</link>
		<dc:creator>Yoav Shapira</dc:creator>
		<pubDate>Tue, 25 Sep 2007 18:55:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.efsavage.com/blog/posts/session_moratorium/#comment-6124</guid>
		<description>httpd's mod_proxy_balancer has session stickiness.  I think nginx has a module to support this as well, but I'm not sure.  Resin's got that LoadBalanceServlet thing (http://www.caucho.com/resin-3.0/config/balance.xtp#resin) which support sticky sessions and is further pretty easy to hack in Java.  There are probably others, too.  I haven't played in this area with hardware load balancers, but maybe some of them offer support for this.

You make a good point about network-level load balancers, none of the above would help there.</description>
		<content:encoded><![CDATA[<p>httpd&#8217;s mod_proxy_balancer has session stickiness.  I think nginx has a module to support this as well, but I&#8217;m not sure.  Resin&#8217;s got that LoadBalanceServlet thing (http://www.caucho.com/resin-3.0/config/balance.xtp#resin) which support sticky sessions and is further pretty easy to hack in Java.  There are probably others, too.  I haven&#8217;t played in this area with hardware load balancers, but maybe some of them offer support for this.</p>
<p>You make a good point about network-level load balancers, none of the above would help there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: esavage</title>
		<link>http://www.efsavage.com/blog/posts/session_moratorium/#comment-6123</link>
		<dc:creator>esavage</dc:creator>
		<pubDate>Tue, 25 Sep 2007 18:12:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.efsavage.com/blog/posts/session_moratorium/#comment-6123</guid>
		<description>Good point.  I guess I was stuck in the mindset that load balancers are "hardware" and they are rarely touched unless your network architecture changes.

However, some sites I've worked with currently and in the past do not have HTTP Load Balancers,  just network-level load balancers, and they rely on the web servers to deal with things like sticky sessions.  In this case I think this flag would be at the connector level.  A 503 would be appropriate, but if the flag was set on the connector/HTTP server, those requests shouldn't happen.

An additional case would be where session (memory) load is more important to balance than network traffic, in which case the container would be the only source of this information.

That said, I think your solution is the preferred one.  My question would be, which load balancers have this feature, with no/minimal hackery?</description>
		<content:encoded><![CDATA[<p>Good point.  I guess I was stuck in the mindset that load balancers are &#8220;hardware&#8221; and they are rarely touched unless your network architecture changes.</p>
<p>However, some sites I&#8217;ve worked with currently and in the past do not have HTTP Load Balancers,  just network-level load balancers, and they rely on the web servers to deal with things like sticky sessions.  In this case I think this flag would be at the connector level.  A 503 would be appropriate, but if the flag was set on the connector/HTTP server, those requests shouldn&#8217;t happen.</p>
<p>An additional case would be where session (memory) load is more important to balance than network traffic, in which case the container would be the only source of this information.</p>
<p>That said, I think your solution is the preferred one.  My question would be, which load balancers have this feature, with no/minimal hackery?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yoav Shapira</title>
		<link>http://www.efsavage.com/blog/posts/session_moratorium/#comment-6121</link>
		<dc:creator>Yoav Shapira</dc:creator>
		<pubDate>Tue, 25 Sep 2007 17:58:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.efsavage.com/blog/posts/session_moratorium/#comment-6121</guid>
		<description>Why do this at the servlet container level instead of the load balancer level?  If you have a load balancer that supports sticky sessions, you take server bank A "off the balancer" when server bank B is ready, and no more new sessions would be created on A, only B.

Given that most of the high-volume sites that would need this feature probably already have a load balancer in front (as implied by having multiple server banks), the load balancer may be able to handle this for you without any servlet-container-specific features.

Hypothetically-speaking, if Tomcat were to have this feature, how would you like it to behave?  Once an admin sets the "no new sessions" flag, all requests that need new sessions return 503?</description>
		<content:encoded><![CDATA[<p>Why do this at the servlet container level instead of the load balancer level?  If you have a load balancer that supports sticky sessions, you take server bank A &#8220;off the balancer&#8221; when server bank B is ready, and no more new sessions would be created on A, only B.</p>
<p>Given that most of the high-volume sites that would need this feature probably already have a load balancer in front (as implied by having multiple server banks), the load balancer may be able to handle this for you without any servlet-container-specific features.</p>
<p>Hypothetically-speaking, if Tomcat were to have this feature, how would you like it to behave?  Once an admin sets the &#8220;no new sessions&#8221; flag, all requests that need new sessions return 503?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
