Wt

Hey Dan,

The implementation of calling finalize() has changed between 3.1.8 and 3.1.9, but it still works for me (e.g. adding it to any of the examples works fine), I've only tried with 3.1.10 though.

Could you provide a small test case that shows the wrong behaviour ?

Regards,
koen

I just tried the samples and they work fine, so there is something sick with either my code or my build. I removed practically everything from my app and the problem is still there, so the next step is to do a clean build and make sure everything is linking against the right version of Wt, etc... I won't have a chance to do this until Friday and will report back here after that.

Cheers,

Dan

Hi Koen,

I discovered that sessions are being destroyed (and WApplication::finalize() being called) properly in my Release build but not in my Debug build. I couldn't replicate this behavior in the Wt samples so I assumed that I had a problem with my build environment. To sanitize my build, I rebuilt Wt 3.1.9, carefully copied the libraries into my development environment, checked that I am linking with the right libs, cleaned my build and rebuild everything... but the problem remains.

I can live with this problem for the moment since the Release build works fine, but I'd still like to understand what is causing it. If you have any thoughts about compiler flags or other things that might have some effect like this then I would be happy to try it.

My build environment is Windows 7 64 bit, VS 2008 SP1, building 32bit-win32 application.

Cheers,

Dan

Hey Daniel,

That is indeed kind of strange (I did test with a debug build, on linux, btw).

However I now realize that you may actually be counting on the fact that the finalize() is being called as soon as the user navigates away. However, this cannot be guaranteed since it depends on a "race-condition" in the browser to load a new page versus to do an Ajax call to the application to notify the shut down.

Even if this is different between build versus release, it could be caused by the different JavaScript code (minified versus non-minified), which is in any case not possible to reason about.

In either case, finalize() should properly be called when the session quits regardless if this is because of an active notification, or whether this is because of the timeout.

Regards,
koen

Yeah, you're right that the sessions are cleaned up after a timeout.

One thing I don't understand though. If I understand correctly, the race-condition exists on the browser, so the call back to the server should either happen (and the session be destroyed) or not happen at all. I see cases where I close the browser window and output appears on server console indicating that it received a request from the client (presumably this is the message to end the session) but the session is not cleaned up - is this to be expected?

An example of the server output in my debug build:

127.0.0.1 - - [2011-Jul-24 08:47:19.221000] "POST /?wtd=0NrKmjeupvsyhRzK HTTP/1.1" 200 0
[2011-Jul-24 08:57:00.246000] 5976 [/ f5BHIYyj1ucI58sH] [notice] "Session created (#sessions = 2)" 
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30
127.0.0.1 - - [2011-Jul-24 08:57:00.269000] "GET / HTTP/1.1" 200 3265
127.0.0.1 - - [2011-Jul-24 08:57:00.538000] "GET /?wtd=f5BHIYyj1ucI58sH&request=style HTTP/1.1" 200 50
127.0.0.1 - - [2011-Jul-24 08:57:00.538000] "GET /?wtd=f5BHIYyj1ucI58sH&request=script&rand=536717 HTTP/1.1" 200 94601
127.0.0.1 - - [2011-Jul-24 08:57:00.576000] "GET /favicon.ico HTTP/1.1" 404 85
127.0.0.1 - - [2011-Jul-24 08:57:00.676000] "POST /?wtd=f5BHIYyj1ucI58sH HTTP/1.1" 200 14982
127.0.0.1 - - [2011-Jul-24 08:57:00.751000] "GET /?wtd=f5BHIYyj1ucI58sH&request=resource&resource=octh&rand=73 HTTP/1.1" 200 2605
127.0.0.1 - - [2011-Jul-24 08:57:00.754000] "GET /?wtd=f5BHIYyj1ucI58sH&request=resource&resource=octc&rand=72 HTTP/1.1" 200 3492
127.0.0.1 - - [2011-Jul-24 08:57:00.772000] "GET /?wtd=f5BHIYyj1ucI58sH&request=resource&resource=ocwu&rand=77 HTTP/1.1" 200 2307
127.0.0.1 - - [2011-Jul-24 08:57:00.784000] "GET /?wtd=f5BHIYyj1ucI58sH&request=resource&resource=ocwr&rand=75 HTTP/1.1" 200 2040
*** This is where I closed the browser window ***
127.0.0.1 - - [2011-Jul-24 08:57:01.893000] "POST /?wtd=f5BHIYyj1ucI58sH HTTP/1.1" 200 0
127.0.0.1 - - [2011-Jul-24 08:57:01.893000] "POST /?wtd=f5BHIYyj1ucI58sH HTTP/1.1" 200 35

And the same from a release build:

[2011-Jul-24 09:01:41.062000] 13112 [/ iXgOFzg1r4fVbdjL] [notice] "Session created (#sessions = 1)" 
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30
127.0.0.1 - - [2011-Jul-24 09:01:41.138000] "GET / HTTP/1.1" 200 3265
127.0.0.1 - - [2011-Jul-24 09:01:41.309000] "GET /?wtd=iXgOFzg1r4fVbdjL&request=style HTTP/1.1" 200 50
    The root name: VoterRegistrationRoot
127.0.0.1 - - [2011-Jul-24 09:01:41.416000] "GET /?wtd=iXgOFzg1r4fVbdjL&request=script&rand=406578 HTTP/1.1" 200 94589
127.0.0.1 - - [2011-Jul-24 09:01:41.512000] "GET /favicon.ico HTTP/1.1" 404 85
127.0.0.1 - - [2011-Jul-24 09:01:41.889000] "POST /?wtd=iXgOFzg1r4fVbdjL HTTP/1.1" 200 14830
127.0.0.1 - - [2011-Jul-24 09:01:41.919000] "POST /?wtd=iXgOFzg1r4fVbdjL HTTP/1.1" 200 21
127.0.0.1 - - [2011-Jul-24 09:01:41.926000] "GET /?wtd=iXgOFzg1r4fVbdjL&request=resource&resource=oc53&rand=3 HTTP/1.1" 200 2605
127.0.0.1 - - [2011-Jul-24 09:01:41.927000] "GET /?wtd=iXgOFzg1r4fVbdjL&request=resource&resource=oc4y&rand=2 HTTP/1.1" 200 3492127.
0.0.1 - - [2011-Jul-24 09:01:41.949000] "GET /?wtd=iXgOFzg1r4fVbdjL&request=resource&resource=oc8d&rand=5 HTTP/1.1" 200 2040

127.0.0.1 - - [2011-Jul-24 09:01:41.967000] "GET /?wtd=iXgOFzg1r4fVbdjL&request=resource&resource=oc8g&rand=7 HTTP/1.1" 200 2307
*** This is where I closed the browser window ***
127.0.0.1 - - [2011-Jul-24 09:01:43.009000] "POST /?wtd=iXgOFzg1r4fVbdjL HTTP/1.1" 200 35
[2011-Jul-24 09:01:43.030000] 13112 [/ iXgOFzg1r4fVbdjL] [1notice] "Session destroyed (#sessions = 0)"27.0.0.1 - - [2011-Jul-24 09:0
1:43.023000] "POST /?wtd=iXgOFzg1r4fVbdjL HTTP/1.1" 200 0

You can see that in both cases, two messages were received by the server after closing the browser window but only the release build actually destroyed the session. Interestingly, the messages numbered "35" and "0" are received in different orders in the two builds - is this significant?

Cheers,

Dan

Hey Daniel,

There is indeed something strange about this. I would indeed expect that one of these messages (the one with 0 length response) indicates the window close.
Are you deploying using a reload-is-new-session false, and are you using server push in this application ? That might be a combination that could explain this (bug).

Regards,
koen

Hi Koen,

I don't specify the value of "reload-is-new-session". I'm pretty sure that a page refresh gives a new session - I'm not at work to check that out just now though.

Server-push is used extensively in the application.

Cheers,

Dan

I can confirm that refreshing the page causes a new session to be created. In this case the session is not destroyed, but I also do not see a request from the client prior to the new session being created, so I assume that in this case I am seeing the effect of the race condition noted earlier.

Cheers,

Dan

Hey Daniel,

I still failed to reproduce this. I am testing with 3.1.10 which may be one explanation for this. Would you be able to test using 3.1.10?
Do you have web sockets enabled ?

Regards,
koen

Hi Koen,

I will upgrade to 3.1.10 when I get a chance and test. I am happy to live with this problem at the moment since the release build behaves correctly. I will report back to this thread once I have tested against 3.1.10.

Cheers,

Dan

Sorry this has taken so long. I upgraded to 3.2.0 and am having no problems with session destruction.

Cheers,

Dan