You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Johan Compagner <jc...@servoy.com> on 2017/05/30 10:09:58 UTC
parallel deployment and websockets
Hi,
if i read this:
http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment
then i see it will go to the "old" version of a war based on session
information
i guess this is jsessionid?
So a refresh in the browser or another request with the jsessionid will go
to the version it started with i guess?
But now i have websockets, if i connect to ##1 first and i have the end
point there
Then i add a ##2 version of the context
then i guess a new user that opens a websocket will go to ##2
but if the existing user does a refresh in the browser then it will also
suddenly go to ##2 i guess?
(we have session info over the websocket url like a jsessionid... but that
will not map in the other later version of the context i guess)
--
Johan Compagner
Servoy
Re: parallel deployment and websockets
Posted by Johan Compagner <jc...@servoy.com>.
On 31 May 2017 at 10:11, Mark Thomas <ma...@apache.org> wrote:
>
> >>
> >>
> > would a feature request be accepted for this that there can be a cookie
> set
> > where that "load balancer" would also look at?
> > and that cookie always make sure that it goes to the context it started
> > from as long as that context is there?
>
> Maybe.
>
> What is the use case? Why can't a new WebSocket connection be created to
> the new version of the web application?
>
because it looses then state.
Like i said below, our application is a statefull application but we use
websocket what was previously ajax request to push back and forward changes
to server and client
(so a data change on the server is pushed right away to the client)
We have our own session tracking over the websocket url:
wss://domain/websocketendpoint/sessionuuidparam
the first time that sessionuuidparam is null but then we push that value to
the client and store it in the session storage (so that tab in the browser)
and if we do a refresh or a reconnect then we send that session uuid to the
server and the server will connect that new websocket endpoint to our
"session" object
So a new context would not find that session object because i guess that is
a fully new classloader/application deploy...
so we lost the session.
In the ajax version this would not happen because that is all pure async
http request to the server with a http session object..
>
> > Because it is quite annoying that it is tied to a jsessionid of a
> > HttpSession that should then be created and kept alive for the whole
> > websocket session..
> >
> > i can do something like this:
> >
> > https://stackoverflow.com/questions/17936440/accessing-httpsession-from-
> httpservletrequest-in-a-web-socket-serverendpoint
> >
> > but isn't that kind of doing something that shouldn't be done? Like
> keeping
> > a reference to a http session?
> >
> > Even if i do the above then still i need to "touch" the session on every
> > websocket request to keep it alive
> > Or set the max idle time out to -1 so it never by itself invalidates()
> > And then when i know the websocket session is really gone i will call
> > invalidate() on it myself..
>
> If you are invalidating the HTTP session once the WebSocket connection
> closes, why keep the session alive in the first place?
>
No we wouldn't close it on the websocket connection close, but on the
timeout of the Session object that is behind that connection
And if before the time out happens a new websocket connection is coming in
(with the above url) then we quickly re attach the session object to that
new endpoint and it will go on
only after a while if there is no new websocket being setup, we invalidate
the session object (and then we could also invalidate the http session that
we stored)
So in the end this is just kind of the same as http sessions in tomcat...
but then real session support over multiply request for websockets
And we don't use a cookie but purely have the id always in the url because
this way multiply tabs in the browser are always independent of each other.
So it would be nice if tomcat would have versioning support for websockets
under the hood...
Like a setting that we could turn on and then when an upgrade happens
tomcat auto sends a cookie which it reuses to connect to the right context
version
johan
Re: parallel deployment and websockets
Posted by Mark Thomas <ma...@apache.org>.
On 31/05/17 08:38, Johan Compagner wrote:
>>
>>
>> It depends. If the URL in the HTTP UPGRADE request includes the session
>> ID, and that session ID is still valid in ##1, then the WebSocket
>> request will be handled by ##1.
>>
>> Mark
>>
>>
> would a feature request be accepted for this that there can be a cookie set
> where that "load balancer" would also look at?
> and that cookie always make sure that it goes to the context it started
> from as long as that context is there?
Maybe.
What is the use case? Why can't a new WebSocket connection be created to
the new version of the web application?
> Because it is quite annoying that it is tied to a jsessionid of a
> HttpSession that should then be created and kept alive for the whole
> websocket session..
>
> i can do something like this:
>
> https://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint
>
> but isn't that kind of doing something that shouldn't be done? Like keeping
> a reference to a http session?
>
> Even if i do the above then still i need to "touch" the session on every
> websocket request to keep it alive
> Or set the max idle time out to -1 so it never by itself invalidates()
> And then when i know the websocket session is really gone i will call
> invalidate() on it myself..
If you are invalidating the HTTP session once the WebSocket connection
closes, why keep the session alive in the first place?
Mark
>
> But this is all quite cumbersome
>
> We just have state there is no way around it, but the communication between
> server and client is after the first startup completely over websocket
> (just like ajax before)>
> For example it would be nice if tomcat did this just under the hood. if
> tomcat upgrades a http request to a websocket then it will also just push a
> small cookie on it to know which context version it was on...
>
> johan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: parallel deployment and websockets
Posted by Johan Compagner <jc...@servoy.com>.
>
>
> It depends. If the URL in the HTTP UPGRADE request includes the session
> ID, and that session ID is still valid in ##1, then the WebSocket
> request will be handled by ##1.
>
> Mark
>
>
would a feature request be accepted for this that there can be a cookie set
where that "load balancer" would also look at?
and that cookie always make sure that it goes to the context it started
from as long as that context is there?
Because it is quite annoying that it is tied to a jsessionid of a
HttpSession that should then be created and kept alive for the whole
websocket session..
i can do something like this:
https://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint
but isn't that kind of doing something that shouldn't be done? Like keeping
a reference to a http session?
Even if i do the above then still i need to "touch" the session on every
websocket request to keep it alive
Or set the max idle time out to -1 so it never by itself invalidates()
And then when i know the websocket session is really gone i will call
invalidate() on it myself..
But this is all quite cumbersome
We just have state there is no way around it, but the communication between
server and client is after the first startup completely over websocket
(just like ajax before)
For example it would be nice if tomcat did this just under the hood. if
tomcat upgrades a http request to a websocket then it will also just push a
small cookie on it to know which context version it was on...
johan
Re: parallel deployment and websockets
Posted by Ludovic Pénet <l....@senat.fr>.
In a similar situation, I do the following :
* go full stateless, use no session ;
* configure WS client to frequently reconnect
* use atmosphere with an internal JMS backend, such as ActiveMQ, to share data transparently between parallely deployed versions.
With Atmosphere, you avoid losing messages on reconnections.
Hope this helps.
Ludovic
Le 30 mai 2017 12:40:45 GMT+02:00, Johan Compagner <jc...@servoy.com> a écrit :
>>
>> > But now i have websockets, if i connect to ##1 first and i have the
>end
>> > point there
>> > Then i add a ##2 version of the context
>> > then i guess a new user that opens a websocket will go to ##2
>> > but if the existing user does a refresh in the browser then it will
>also
>> > suddenly go to ##2 i guess?
>>
>> It depends. If the URL in the HTTP UPGRADE request includes the
>session
>> ID, and that session ID is still valid in ##1, then the WebSocket
>> request will be handled by ##1.
>>
>
>
>ah so for this to work we need to force a http session to be created?
>so the cookie is set and the http session is there?
>problem is a bit that all communication is then going through the
>websocket
>so the session could even just timeout, because we don't hit it anymore
>
>i do see when creating a websocket, request.getSession(false) is called
>(multiply times by the way, a lot goes wrong when you have a breakpoint
>on
>that method, but thats another story)
>but it isn't when it is just alive. So do i need to call something
>every
>time on the incomming() call in the endpoint to keep the http session
>alive..
>
>johan
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Re: parallel deployment and websockets
Posted by Johan Compagner <jc...@servoy.com>.
>
> > But now i have websockets, if i connect to ##1 first and i have the end
> > point there
> > Then i add a ##2 version of the context
> > then i guess a new user that opens a websocket will go to ##2
> > but if the existing user does a refresh in the browser then it will also
> > suddenly go to ##2 i guess?
>
> It depends. If the URL in the HTTP UPGRADE request includes the session
> ID, and that session ID is still valid in ##1, then the WebSocket
> request will be handled by ##1.
>
ah so for this to work we need to force a http session to be created?
so the cookie is set and the http session is there?
problem is a bit that all communication is then going through the websocket
so the session could even just timeout, because we don't hit it anymore
i do see when creating a websocket, request.getSession(false) is called
(multiply times by the way, a lot goes wrong when you have a breakpoint on
that method, but thats another story)
but it isn't when it is just alive. So do i need to call something every
time on the incomming() call in the endpoint to keep the http session
alive..
johan
Re: parallel deployment and websockets
Posted by Mark Thomas <ma...@apache.org>.
On 30/05/17 11:09, Johan Compagner wrote:
> Hi,
>
> if i read this:
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment
>
> then i see it will go to the "old" version of a war based on session
> information
> i guess this is jsessionid?
>
> So a refresh in the browser or another request with the jsessionid will go
> to the version it started with i guess?
>
> But now i have websockets, if i connect to ##1 first and i have the end
> point there
> Then i add a ##2 version of the context
> then i guess a new user that opens a websocket will go to ##2
> but if the existing user does a refresh in the browser then it will also
> suddenly go to ##2 i guess?
It depends. If the URL in the HTTP UPGRADE request includes the session
ID, and that session ID is still valid in ##1, then the WebSocket
request will be handled by ##1.
Mark
>
> (we have session info over the websocket url like a jsessionid... but that
> will not map in the other later version of the context i guess)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org