From: kedar <Kedar.Mhaswade_at_Sun.COM>
Date: Fri, 06 Apr 2007 00:28:21 -0700

> Another question I need answered
We will satisfy all your needs :)
> since I can't actually verify this now -
> For the application session data to be replicated across instances,
> does the data (stored
> in HttpSession) have to be 'instanceof Serializable' ?
>
I would think so. I hope that you are not storing complex
data structures in the session though.
> More questions inline:
>
> Yes, I'll hold off on this for now.
>
>
>>>
>> Consider that you have two instances "foo" and "bar" in
>> a cluster.
>>
>> If the intent is just to "test" that session is preserved,
>>
>> - deploy an application by setting availability-enabled=true on it.
>> - change the session attributes by "physically" contacting "foo".
>> - change the session attribute.
>> - stop instance "foo".
>> - actually contact "bar" and see if you can see the change.
> How do I change the session attribute by 'contacting' the instance ?
> Replication of application session is data
> is keyed off of cookies, right ? So I need to manipulate http requests
> to the application, right ?
> First request http://foo:1234/myapp/does-not-work (this request
> modifies session )
> Second request http://bar:4567/myapp/does-not-work( now this request
> will have a different session identifier
> sent from the browser since its a different URL), right ?
> I'll need to go looking for cookies in the request for foo and somehow
> set it in the requests to bar !
>
I don't think you have to do any of this, since the availability is
turned on
for the application on the *entire cluster* and browser will send the
right JSESSIONID
cookie that it received in the first response. For the *demo* purpose,
you'll
have to call both the instances at least twice.

Here is a ready recipe that I have just tested on GlassFish build. Promise
me that you'll create a nice demo out of it :)
- save the attached war file: st.war somewhere, note that this web-app
  is "distributable".
- create a cluster profile domain using "ant -f setup-cluster.xml"
- asadmin start-domain
- asadmin create-node-agent na1
- asadmin start-node-agent na1
- asadmin create-cluster c1
- asadmin create-instance --cluster c1 --nodeagent na1 i1
- asadmin create-instance --cluster c1 --nodeagent na1 i2
- [NOW instances are in the cluster c1 and the in-memory replication is
all set].
- asadmin start-cluster c1
- asadmin deploy --target c1 --availabilityenabled=true st.war
- wait for a few minutes ...
- http://localhost:38080/TestSession/st
- http://localhost:38080/TestSession/st --- you will see that the
instance name
  from the VM and session match at this point.
- asadmin stop-instance i1
- now contact the second instance to see if the session is persisted.
- http://localhost:38081/TestSession/st
- http://localhost:38081/TestSession/st --- note that now, this page
will show
  that instance name from VM and session don't match, because from VM it
will
  always be "i2" (since this is i2) and from session it will be ("i1"),
since
  the servlet when running in i1, set a session attribute named
"instance-name"
  to "i1".

The whole point is that session was persisted.

Give it a try by using your own domain, node-agent, cluster, instance names.
Let me know what happens.

I will send you the source code if you are interested. It is a very
rudimentary
servlet that demonstrates this.

Regards,
Kedar