Please see inline:
kedar wrote:
>
>> Another question I need answered
> We will satisfy all your needs :)
I hope not ;)
>> 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.
Define complex ?
>> 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".
That's correct and even though I wasn't able to set the value of session
attribute 'instance-name'
(http:..../st?instance-name=xyz) and therefore see it on the other
instance, the value
of the cookie set by the browser for requests to both instances was the
SAME. I would have thought
that is a security issue, but then what do I know ...
Okay, I take it that your sample works, however the clusterjsp
(sample/quickstart/clusterjsp)
does not. The session ids for the two instances do not match and
needless to say the http
session data does not persist across instances. The app's availability
flag is enabled.
Interestingly enough the browser sends the JSESSIONID cookie value to
the second instance
that it received from the first instance, but the response from the
second instance has a new
value of JSESSIONID. Anyone know why ?
I'll try to deploy my app with the availability enabled flag set to true
(this was missing yesterday).
Is there any other option that I need to keep in mind while trying out
HA/in-memory replication ?
Any documentation on it ?
Thanks much,
Ashish