Bug #1884

WServer post and stop - does not push the GUI updates to the client

Added by W X about 10 years ago. Updated about 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



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.


WT6637.7z (2.97 MB) WT6637.7z W X, 04/29/2013 04:10 PM

Updated by W X about 10 years ago

Sorry, forgot to add the test case. So, here it is, attached.


Updated by Wim Dumon about 10 years ago

  • Assignee set to Koen Deforche

Updated by Koen Deforche almost 10 years ago

  • Status changed from New to InProgress

Updated by Koen Deforche almost 10 years ago

  • Status changed from InProgress to Feedback


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.




Updated by W X almost 10 years ago


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).



Updated by W X almost 10 years ago

Note: by "in a simple manner" I mean using what WT offers.


Updated by W X almost 10 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 10 years ago

Did you have the time to find why this used to work with wt 3.2.1 ?


Updated by Koen Deforche almost 10 years ago


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.




Updated by W X almost 10 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.



Updated by Koen Deforche about 8 years ago

  • Status changed from Feedback to InProgress

Also available in: Atom PDF