<?xml version="1.0" encoding="UTF-8"?>











<rss version="2.0" xmlns:jf="http://www.jivesoftware.com/xmlns/jiveforums/rss">



<channel>
    <title>Support Forums: Message List - Monitoring Session Replication in J2EE Clusters</title>
    <link>http://www.theserverside.com</link>
    <description>Most recent forum messages</description>
    <language>en</language>
    
        <generator>Jive Forums Silver 5.5.30 (www.jivesoftware.com)</generator>
    
    <pubDate>Mon, 20 May 2013 01:14:02 -0400</pubDate>


    <item>

        <title>Replication Protocol</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[I know this is an old post, but I saw some comments on session replication using multicast. Although it is true that WebLogic clusters use multicast for certain replication capabilities (such as JNDI replication), in-memory session replication uses a...]]></description>
        

        <pubDate>Thu, 04 Dec 2008 00:39:16 -0500</pubDate>

        

        <jf:creationDate>Thu, 04 Dec 2008 00:39:16 -0500</jf:creationDate>
        <jf:modificationDate>Thu, 04 Dec 2008 00:39:16 -0500</jf:modificationDate>
        <jf:date>Dec 4, 2008</jf:date>
        <jf:author>Mark Lindros</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Re: What is a reasonable HTTPSession size?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[Agreed. Keeping an HttpSession size down can be quite hard sometimes.

A useful monitoring utility for this (and many other things too!) is <a href="http://messadmin.sourceforge.net">MessAdmin</a>. Check it out!]]></description>
        

        <pubDate>Fri, 23 Mar 2007 10:18:23 -0400</pubDate>

        

        <jf:creationDate>Fri, 23 Mar 2007 10:18:23 -0400</jf:creationDate>
        <jf:modificationDate>Fri, 23 Mar 2007 10:18:23 -0400</jf:modificationDate>
        <jf:date>Mar 23, 2007</jf:date>
        <jf:author>Cédrik LIME</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>What is a reasonable HTTPSession size?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[You should try to keep session sizes down to 2-4KB range, but that is extremely hard if you are doing anything complex.<br><br>Typical apps are probably in the 50KB range, from what I've seen.<br><br>500KB and even 1MB+ are not that unusual, but for many...]]></description>
        

        <pubDate>Sun, 01 Jan 2006 00:43:36 -0500</pubDate>

        

        <jf:creationDate>Sun, 01 Jan 2006 00:43:36 -0500</jf:creationDate>
        <jf:modificationDate>Sun, 01 Jan 2006 00:43:36 -0500</jf:modificationDate>
        <jf:date>Jan 1, 2006</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>1</jf:replyCount>
    </item>


    <item>

        <title>What is a reasonable HTTPSession size?</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[What kind of HTTPSession sizes are people working with ?<br>You can qualify your answers with specific scenarios/techniques etc.<br><br>Our session size is 2 Meg and I thought that was outrageously large.(Weblogic 8.1 session affinity turned on)<br>I...]]></description>
        

        <pubDate>Wed, 28 Dec 2005 15:26:36 -0500</pubDate>

        

        <jf:creationDate>Wed, 28 Dec 2005 15:26:36 -0500</jf:creationDate>
        <jf:modificationDate>Wed, 28 Dec 2005 15:26:36 -0500</jf:modificationDate>
        <jf:date>Dec 28, 2005</jf:date>
        <jf:author>Parag Teredesai</jf:author>
        <jf:replyCount>2</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote>Cache control headers in the HTTP response ... allow to tell a browser that a particular page is dynamic and should not be cached. Most browsers work by the rules, it is only the Firefox which thinks too smart about itself and caches...]]></description>
        

        <pubDate>Fri, 17 Sep 2004 11:26:49 -0400</pubDate>

        

        <jf:creationDate>Fri, 17 Sep 2004 11:26:49 -0400</jf:creationDate>
        <jf:modificationDate>Fri, 17 Sep 2004 11:26:49 -0400</jf:modificationDate>
        <jf:date>Sep 17, 2004</jf:date>
        <jf:author>Michael Jouravlev</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote>As for 1 meg of session data: You are right, I would not put it in the web page. On the other hand, if you have 1 meg of session data in the first place, something seems to be fairly wrong, in most application scenarios. Not because there is...]]></description>
        

        <pubDate>Fri, 17 Sep 2004 11:07:18 -0400</pubDate>

        

        <jf:creationDate>Fri, 17 Sep 2004 11:07:18 -0400</jf:creationDate>
        <jf:modificationDate>Fri, 17 Sep 2004 11:07:18 -0400</jf:modificationDate>
        <jf:date>Sep 17, 2004</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote><blockquote>Ugly URLs for GET method* Necessity to keep strict page order* URL cannot be modified by a user; a user cannot select page of his choice* Back button would not work, because prior URL does not have newer session data (oh, I...]]></description>
        

        <pubDate>Tue, 14 Sep 2004 12:05:08 -0400</pubDate>

        

        <jf:creationDate>Tue, 14 Sep 2004 12:05:08 -0400</jf:creationDate>
        <jf:modificationDate>Tue, 14 Sep 2004 12:05:08 -0400</jf:modificationDate>
        <jf:date>Sep 14, 2004</jf:date>
        <jf:author>Michael Jouravlev</jf:author>
        <jf:replyCount>1</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote>Ugly URLs for GET method* Necessity to keep strict page order* URL cannot be modified by a user; a user cannot select page of his choice* Back button would not work, because prior URL does not have newer session data (oh, I forgot, you...]]></description>
        

        <pubDate>Tue, 14 Sep 2004 06:01:44 -0400</pubDate>

        

        <jf:creationDate>Tue, 14 Sep 2004 06:01:44 -0400</jf:creationDate>
        <jf:modificationDate>Tue, 14 Sep 2004 06:01:44 -0400</jf:modificationDate>
        <jf:date>Sep 14, 2004</jf:date>
        <jf:author>Karl Banke</jf:author>
        <jf:replyCount>3</jf:replyCount>
    </item>


    <item>

        <title>Not just marketing</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[Cameron, this is the right point - not the app server vendors should decide what is good and what is bad design - the customers should. (But the vendors should give some hints on that) And customers have to live with there developers...<br><br>I've...]]></description>
        

        <pubDate>Tue, 14 Sep 2004 01:56:53 -0400</pubDate>

        

        <jf:creationDate>Tue, 14 Sep 2004 01:56:53 -0400</jf:creationDate>
        <jf:modificationDate>Tue, 14 Sep 2004 01:56:53 -0400</jf:modificationDate>
        <jf:date>Sep 14, 2004</jf:date>
        <jf:author>Mirko Novakovic</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote>Right, but even non-NFS local mounts (EXT2, even FATx) will work fine, because it's just &quot;overflow&quot; for the memory on that particular cluster node.  However, with NFS you could do some even more interesting things...]]></description>
        

        <pubDate>Mon, 13 Sep 2004 15:24:48 -0400</pubDate>

        

        <jf:creationDate>Mon, 13 Sep 2004 15:24:48 -0400</jf:creationDate>
        <jf:modificationDate>Mon, 13 Sep 2004 15:24:48 -0400</jf:modificationDate>
        <jf:date>Sep 13, 2004</jf:date>
        <jf:author>Brian Miller</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote><blockquote>...rolling them out to a DB or just to a local disk (which is much faster and less expensive and more scalable than a database.)</blockquote>Totally.  NFS is the best cluster fabric I know:  pervasive, free, simple, fast, and with...]]></description>
        

        <pubDate>Mon, 13 Sep 2004 14:51:52 -0400</pubDate>

        

        <jf:creationDate>Mon, 13 Sep 2004 14:51:52 -0400</jf:creationDate>
        <jf:modificationDate>Mon, 13 Sep 2004 14:51:52 -0400</jf:modificationDate>
        <jf:date>Sep 13, 2004</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>1</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote>...rolling them out to a DB or just to a local disk (which is much faster and less expensive and more scalable than a database.)</blockquote>Totally.  NFS is the best cluster fabric I know:  pervasive, free, simple, fast, and with very useful...]]></description>
        

        <pubDate>Mon, 13 Sep 2004 14:27:15 -0400</pubDate>

        

        <jf:creationDate>Mon, 13 Sep 2004 14:27:15 -0400</jf:creationDate>
        <jf:modificationDate>Mon, 13 Sep 2004 14:27:15 -0400</jf:modificationDate>
        <jf:date>Sep 13, 2004</jf:date>
        <jf:author>Brian Miller</jf:author>
        <jf:replyCount>2</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote><blockquote>Saving data to a database (like I suggest in the article) will scale and guaranty no data loss much better than any in-memory mechanism.</blockquote>What you might gain is transactional atomicity, but that is about...]]></description>
        

        <pubDate>Mon, 13 Sep 2004 14:13:42 -0400</pubDate>

        

        <jf:creationDate>Mon, 13 Sep 2004 14:13:42 -0400</jf:creationDate>
        <jf:modificationDate>Mon, 13 Sep 2004 14:13:42 -0400</jf:modificationDate>
        <jf:date>Sep 13, 2004</jf:date>
        <jf:author>Michael Jouravlev</jf:author>
        <jf:replyCount>4</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote>do you know which app-servers do asynchronous in-memory replication and which do not? As far as I know WebLogic replicates session states just between two server instances (primary and secondary server), i.e. point-to-point. But I do not know...]]></description>
        

        <pubDate>Mon, 13 Sep 2004 13:08:00 -0400</pubDate>

        

        <jf:creationDate>Mon, 13 Sep 2004 13:08:00 -0400</jf:creationDate>
        <jf:modificationDate>Mon, 13 Sep 2004 13:08:00 -0400</jf:modificationDate>
        <jf:date>Sep 13, 2004</jf:date>
        <jf:author>Cameron Purdy</jf:author>
        <jf:replyCount>0</jf:replyCount>
    </item>


    <item>

        <title>Nice but theory</title>
        <link>http://www.theserverside.com/discussions/thread.tss?thread_id=28626</link>

        

        
            <description><![CDATA[<blockquote>To minimize the potential for data loss, the session update should be synchronous, and should be processed by the time the request processing completes.It is relatively common for application servers to asynchronously update the session data...]]></description>
        

        <pubDate>Mon, 13 Sep 2004 11:46:54 -0400</pubDate>

        

        <jf:creationDate>Mon, 13 Sep 2004 11:46:54 -0400</jf:creationDate>
        <jf:modificationDate>Mon, 13 Sep 2004 11:46:54 -0400</jf:modificationDate>
        <jf:date>Sep 13, 2004</jf:date>
        <jf:author>Dirk Ludwig</jf:author>
        <jf:replyCount>1</jf:replyCount>
    </item>



</channel>
</rss>

