Ashish Sahni wrote:
> 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 ?
Anything that's not simple. Example: a Hashtable<String,String>.
>
>
>
>>> 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 ...
Like I said, this is for demo purpose, the goal of which is to demonstrate
that it works.
>
> 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 ?
Not that I am aware of.
> Any documentation on it ?
>
Look at the GlassFish documentation. If you can't find it, send an e-mail
to Paul Davies.
> Thanks much,
> Ashish
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>