Silvio127 / gwt-comet

Automatically exported from code.google.com/p/gwt-comet
0 stars 0 forks source link

Multiple connections to one session #3

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
At the moment only one connection to one session is supported in the
framework. I.e. CometSession has only one CometResponse associated with it.
It should be possible to have multiple CometResponse's to one CometSession.
In this way you can open multiple windows to you application using the same
session.

Original issue reported on code.google.com by PierreHa...@gmail.com on 15 Mar 2010 at 2:32

GoogleCodeExporter commented 9 years ago
This is currently in the RoadMap under "support for sharing a comet connection 
across
multiple browser windows/tabs"

I prefer the idea of sharing a connection rather than having multiple 
connections
which adds more load on the server and consumes more resources on both the 
client and
server.

Original comment by rich...@zschech.net on 15 Mar 2010 at 10:40

GoogleCodeExporter commented 9 years ago
It would be nice to share the connection, but I think it would be good to have a
fallback to multiple connections, because we have tried inter-window 
communication
here at our company and it does not work so well on all browsers because of 
security
constraints.

Original comment by PierreHa...@gmail.com on 16 Mar 2010 at 8:09

GoogleCodeExporter commented 9 years ago
Yes, this would be a very welcome feature. some kind of fan-in mechanism for 
pushing
data to all browser windows sharing the same session, maybe as a configuration
property. however, im not sure how would comet detect that a second or third..
browser window has been started. and besides, every browser has a different 
handling
for it. the IE for ex. starts a complete new session whereas firefox does not.

Original comment by marcelo....@gmx.de on 26 Mar 2010 at 3:27

GoogleCodeExporter commented 9 years ago
In my opinion it's a "must have" feature.

Original comment by nordlig....@gmail.com on 17 Aug 2010 at 11:28

GoogleCodeExporter commented 9 years ago
Is it possible to not store the session id in a cookie but keep it on the 
client somehow? If I'm not mistaken, that would resolve this issue completely.

One session for each window would take care of this, no? But I'm not entirely 
sure how this would work in Java.

Original comment by daedel...@gmail.com on 17 Aug 2010 at 8:58

GoogleCodeExporter commented 9 years ago
Yes it is possible to detect the different pages/clients by not using a session 
cookie but the problem remains that having multiple connections consumes more 
resources on both the client and server. Also browsers can have a limit to the 
number of connections.

Original comment by rich...@zschech.net on 18 Aug 2010 at 6:53

GoogleCodeExporter commented 9 years ago
If I'm not mistaken, the amount of multiple connections is limited per open 
window, not in total.

Could you explain how I could achieve having a seperate session for every open 
window? I'm not entirely sure how sessions work in GWT, and I must admit I'm a 
bit of a java noob :)

Original comment by daedel...@gmail.com on 18 Aug 2010 at 9:29

GoogleCodeExporter commented 9 years ago
For what I've seen the setting and retrieving the session cookie is deep in the 
code.  Is there any way to override that behavior?  If not, I'm willing to 
create patch but the sources that I've download reference missing libraries.

Original comment by mvid...@gmail.com on 20 Aug 2010 at 8:47

GoogleCodeExporter commented 9 years ago
We are beginning an application that would absolutely need this feature. As a 
brief background we have to support a multiple-windowed environment where each 
window needs access to a comet message stream - it can be an 'uber' stream 
which is filtered on the client or an individual stream per window. In any case 
I know that this issue has been accepted, can you give us an update on when we 
might be able to expect this feature? Is there something we can do to help in 
terms of development? We would be happy to take a look at writing the patch 
ourselves if you could give us some pointers on where to get started.

Thanks,
Adam

Original comment by adamben...@gmail.com on 8 Nov 2010 at 5:45

GoogleCodeExporter commented 9 years ago
Any news on the multiple connections per session issue? I would be glad to help!

Original comment by j.posth...@gmail.com on 30 Jan 2011 at 3:07

GoogleCodeExporter commented 9 years ago
I also would love to have this capability, or to be able to create multiple 
CometSessions (each with their own CometResponse).  If you could point me to 
where the problem for this lies I know that I and some others would be happy to 
offer help on this.

btw - Thanks for the wonderful work you've done thus far for gwt-comet.  Really 
great work!

Original comment by BNovaBry...@gmail.com on 30 Mar 2011 at 7:35

GoogleCodeExporter commented 9 years ago
In atmosphere-gwt I made this possible by not relying on a session that is 
tightly coupled to the comet mechanism (in fact I took out all support for 
sessions) this means you are free to implement your own session logic and the 
comet code uses a connection identifier to communicate back and forth even if 
you have multiple windows/connections open in one session. Atmosphere has a 
mechanism through which you can cache broadcasted messages so you can make sure 
your client will receive them. This is what is currently done by the sessions 
in gwt-comet.
The next improvement we want to make is to multiplex one connection through 
multiple windows.
So with gwt-comet I think it will also work if you do not rely on the 
CometSessions. Of course you would miss some features of CometSessions.

Original comment by Rinchen....@gmail.com on 4 Apr 2011 at 7:45

GoogleCodeExporter commented 9 years ago
Hello I would also love to have this capability for my application.

Original comment by jcdeanto...@gmail.com on 18 Nov 2011 at 11:33

GoogleCodeExporter commented 9 years ago
Still a huge problem.

open a second tab in the web browser spawning a comet connection and and the 
servlet's doComet() / cometTerminated() on the server are called in rapid 
succession (several times per second), hammering the server and making the web 
browser unresponsive.

Seems difficult to fix without rewriting CometSession to not rely on 
HttpSession.

Original comment by pujos.mi...@gmail.com on 8 Aug 2012 at 12:11