Multiple connections from one browser/session
Opening multiple "tabs" in browser to the Wt application which has "enableUpdates(true)" causes first "tab" to freeze and flood the Wt server with POST requests. This can be stopped only by closing both "tabs".
This is not happening without "enableUpdates(true)".
I tested even with basic "feature/broadcast" example.
Tested only with lastest Chrome.
Thanks for any help in advance.
I just tried this and it works as expected (every session has one request every second). I tried with up to 8 sessions and with Wt git and Chromium 24.
So it's certainly not something that goes wrong in general. Perhaps this occurs only with a specific Wt version and/or Chrome version ?
Here is the version number:
"WEnvironment: UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"
Here's full log: http://pastebin.com/Avr7ReWV
Also I am using "wt-3.3.0-rc3" as you can see in the log.
Can you check Wt 3.3.0 final and/or the Wt git version ?
Alright, I'll do that.
Still happens in Wt 3.3.0.
Seems to be problem when having multiple connections from same session. So this doesn't happen when there is URL tracking of session because each connection is different session.
Could you please test this on your side? I'm not sure what my next should be to solve this issue.
Indeed you cannot support multiple windows from one session, and the use of url tracking is mandatory (versus cookies) if you want a user to have multiple sessions in one browser.
This behavior is then not unexpected.
Alright, I understand. Why does it happen though? Where is the "loop" happening? Can't it be fixed? So the other windows with same session would act just as duplicates?
Were there any efforts in this direction?
Just to clarify what I understand by having multiple windows: for example to have several plots showing data from a process controlled from a main window. Benefit from this is to distribute 'plots' over several physical screens.
Thanks a lot!
We did some work on this, but the branch never got to a usable state. It's a nasty feature since it requires a big re-organisation which doesn't go well together with all of the other changes happening on the tree.
The use case you mention is indeed one of the things we want to be able to do (more easily) than is currently possible.