Re: Websockets with tomcat clustering and session replication

2013-12-02 Thread Johan Compagner
The problem is i guess, that you access the http session outside of a
normal http request cycle
So tomcat doesn't notice anything

And also is it not a spec or behavior requirement that you don't hold on
to your http session objects outside of requests?




On 1 December 2013 15:33, Nir A n...@netomedia.com wrote:

 Hi,

 Ive asked here before about how do i get a session replication over
 websockets sessions.
 Mark Thomas  answered me that i should try and link the httpsession with
 the websocket and then i will gain the replication abilities.

 So, I listended and implemented it just like in this url:

 http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint

 So now, I'm able to get the session for each client. and I Do get
 replication! pretty nice!

 Only problem is,  While i'm adding new attributes to the primary session
 (in tomcat#1 for example) , the replicated sessions (in tomcat#2 for
 example) does NOT contain any attribues.
 The session backup is there but no attributes at all.


 My POC web application has one html page with javascript web socket
 send\recieve messages.

 What i did notice that might shade light on whats the problem is the
 following scenario:

 If i press f5 on the browser, the web page is loaded and a new http
 handshake is taking place. when that happens all the attributes do
 replicate!!!

 Is there a way to make the attribute replicate without the need of
 refreshing the page?

 Thanks!




-- 
Johan Compagner
Servoy


Re: Websockets with tomcat clustering and session replication

2013-12-02 Thread Nir A
Can you come up with an alternative ? Or can you think of a way to fool
tomcat in thinking its in a regular cycle?
On Dec 2, 2013 3:16 PM, Johan Compagner jcompag...@servoy.com wrote:

 The problem is i guess, that you access the http session outside of a
 normal http request cycle
 So tomcat doesn't notice anything

 And also is it not a spec or behavior requirement that you don't hold on
 to your http session objects outside of requests?




 On 1 December 2013 15:33, Nir A n...@netomedia.com wrote:

  Hi,
 
  Ive asked here before about how do i get a session replication over
  websockets sessions.
  Mark Thomas  answered me that i should try and link the httpsession with
  the websocket and then i will gain the replication abilities.
 
  So, I listended and implemented it just like in this url:
 
 
 http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint
 
  So now, I'm able to get the session for each client. and I Do get
  replication! pretty nice!
 
  Only problem is,  While i'm adding new attributes to the primary session
  (in tomcat#1 for example) , the replicated sessions (in tomcat#2 for
  example) does NOT contain any attribues.
  The session backup is there but no attributes at all.
 
 
  My POC web application has one html page with javascript web socket
  send\recieve messages.
 
  What i did notice that might shade light on whats the problem is the
  following scenario:
 
  If i press f5 on the browser, the web page is loaded and a new http
  handshake is taking place. when that happens all the attributes do
  replicate!!!
 
  Is there a way to make the attribute replicate without the need of
  refreshing the page?
 
  Thanks!
 



 --
 Johan Compagner
 Servoy



Re: Websockets with tomcat clustering and session replication

2013-12-02 Thread Rossen Stoyanchev
On Sun, Dec 1, 2013 at 4:33 PM, Nir A n...@netomedia.com wrote:

My POC web application has one html page with javascript web socket
 send\recieve messages.

 What i did notice that might shade light on whats the problem is the
 following scenario:

 If i press f5 on the browser, the web page is loaded and a new http
 handshake is taking place. when that happens all the attributes do
 replicate!!!

 Is there a way to make the attribute replicate without the need of
 refreshing the page?


In HTTP you have many requests associated with a session id. With session
replication, each new request could go to a different server and still
access the same HTTP session attributes.

In WebSocket on the other hand there is a single connection the server and
if you lose it, you have to reconnect, which is probably what pressing F5
does for you. Unless I'm missing something, you have to detect when the
WebSocket connection is closed on client side and reconnect.

Rossen


Re: Websockets with tomcat clustering and session replication

2013-12-02 Thread Nir A
Yeah but, I would like to link the websocket session with the http session
of the handshake. and that way i will be able to imitiate the session
replication abilities for websocket.

This mechanism works as intended only problem is the replication not
replicate http session attribute while the websocket connection is
happening (since this is not a regular httpsession \ request cycle) my
question is - can i activate manually some kind of action on the http
session to make it Refresh so the tomcat will replicate it every time i
set new attribute? (I remind you again that pressing f5 will reconnect the
websocket and the attributes are being copied).


Thanks.


On Dec 2, 2013 8:51 PM, Rossen Stoyanchev rstoyanc...@gopivotal.com
wrote:

 On Sun, Dec 1, 2013 at 4:33 PM, Nir A n...@netomedia.com wrote:

 My POC web application has one html page with javascript web socket
  send\recieve messages.
 
  What i did notice that might shade light on whats the problem is the
  following scenario:
 
  If i press f5 on the browser, the web page is loaded and a new http
  handshake is taking place. when that happens all the attributes do
  replicate!!!
 
  Is there a way to make the attribute replicate without the need of
  refreshing the page?
 

 In HTTP you have many requests associated with a session id. With session
 replication, each new request could go to a different server and still
 access the same HTTP session attributes.

 In WebSocket on the other hand there is a single connection the server and
 if you lose it, you have to reconnect, which is probably what pressing F5
 does for you. Unless I'm missing something, you have to detect when the
 WebSocket connection is closed on client side and reconnect.

 Rossen