Bug #1884
openWServer post and stop - does not push the GUI updates to the client
0%
Description
Hi,
The documentation for WServer::stop says: "Stops the server. Active application sessions are terminated cleanly, and the HTTP (S) server is shut down."
but, with wt 3.3.0, after posting using WServer::post() to all opened applications and then immediately calling WServer::stop() doesn't send all the GUI updates. (Note: Posted callbacks change the GUI).
This seemed to work with 3.2.1. (well, with the provided test application it proved to work sometimes only).
Have I misinterpreted the documentation regarding the "clean session termination" in the sense that the GUI updates are not guaranteed to be pushed to the client in this sequence?
To reproduce, please use the attached application. There is a howto.txt file that describe the situation and provide details on how to reproduce.
Files
Updated by Koen Deforche almost 11 years ago
- Status changed from New to InProgress
Updated by Koen Deforche almost 11 years ago
- Status changed from InProgress to Feedback
Hey,
Yes, with "clean session termination" we did not imply that. It simply meant that we would delete all sessions and shutdown the web server cleanly, with as main objective to have the ability to cleanup all resources but also to check your application for memory leaks.
I'm not sure why this still worked with Wt 3.2.1 --- what happens is that the application indeed prepares the last requests to be send, but then immediately these write requests are cancelled as the web server shuts down.
Regards,
koen
Updated by W X almost 11 years ago
Hey,
In that case what is the correct sequence in order to ensure that the GUI is updated by the post()-ed action, before the server is stopped. Is it something that the application itself should manage ? I don't know how to control this in a simple manner since post() is asynchronous and stop() can take place at any time (at user request).
Thanks!
Updated by W X almost 11 years ago
Note: by "in a simple manner" I mean using what WT offers.
Updated by W X almost 11 years ago
Do you have any suggestion on how to ensure the GUI is updated before the server stops completely in the situation described ?
Updated by W X almost 11 years ago
Did you have the time to find why this used to work with wt 3.2.1 ?
Updated by Koen Deforche almost 11 years ago
Hey,
I now recall that we changed the order in which we shutdown:
We used to first terminate sessions and then shutdown the web servers, but now we reversed this order.
The problem was that new sessions still could be created until the server was shutdown.
I'll take a look if this can be done differently.
Regards,
Koen
Updated by W X almost 11 years ago
Maybe to set a flag when the server is shutting down and check it whenever an attempt to create a new session is made. Allow or disallow the new session based on that flag ?
I'm looking forward for a fix to this issue.
I'm not sure if it is related to this, but I've noticed that WServer::stop() takes a lot of time with wt-3.3.0 (as opposed to wt-3.2.1) when the server is running HTTPS and there is at least one HTTPS connection present.
Thanks!
Updated by Koen Deforche about 9 years ago
- Status changed from Feedback to InProgress