Wt

Sorry,

but I haven't got a time to test with the release candidate (Wt-3.3.0 RC1).

regards,

stoycho

Hey,

This works for me with Wt 3.3.0 ... Could you verify ?

Regards,

koen

Hey,

sorry, but can't. I don't build it jet, but I'll give you a feedback when I can verify it.

regards,

Stoycho

Hi Koen,

it still not work for me even with the latest git.

When I click the restart button the last output I see is from http://redmine.webtoolkit.eu/attachments/1024/serverRestart.cpp#L83 and the server is hanging on until I press F5 in the browser.

I just tested it with wt-3.2.1 and it works as I expect. When I click the 'restart' button after a short delay where the loading indicator is shown the server starts and a new session is loaded.

Could look at this once again, please!

best regards,

Stoycho

Hi,

it could be browser dependent. I cannot recognise any systematic in it, but sometimes it works with Safari (5.1.7), sometimes get stuck and after manual refresh (F5) it works again correctly. With Firefox (16.0.1) I never see the expected behaviour. I really do not have idea what is wrong. Moreover, it seems that sometimes it does not work even with wt-3.2.1.

regards,

Stoycho

Hey,

I'm a bit confused now :) Where can I see how many threads I use. I do not specify any number and a default one has to be used I suppose. I'm using the built-in server and boost 1.46.0.

Regards,

Stoycho

Hey,

If you're not specifying a parameter then you probably use the default (10) too so that cannot be the difference.

Do you use a wt_config.xml file ?

Regards,

koen

Hey,

yes, I do use the wt_config.xml. Why?

regards,

stoycho

Hey Stoycho,

Perhaps a setting in there is what causes the problem (I still cannot reproduce it).

Could you attach it too ?

Regards,

koen

Hey,

1. Start web server

3.3.0
try start the server
10.0.2.80 - - [2013-Apr-09 16:58:40.349948] "POST /?wtd=eHI8wIcaDY30nM1v HTTP/1.1" 200 72
10.0.2.80 - - [2013-Apr-09 16:58:40.380889] "GET /?&wtd=eHI8wIcaDY30nM1v HTTP/1.1" 200 1941
10.0.2.80 - - [2013-Apr-09 16:58:40.431373] "GET /?&wtd=RJlXG9XKN3Dwaam5 HTTP/1.1" 200 1941
10.0.2.80 - - [2013-Apr-09 16:58:40.461339] "GET /?wtd=RJlXG9XKN3Dwaam5&request=style HTTP/1.1" 200 88
10.0.2.80 - - [2013-Apr-09 16:58:40.550618] "GET /?wtd=RJlXG9XKN3Dwaam5&sid=-72178433&htmlHistory=true&deployPath=%2F&request=script&rand=2087555690 HTTP/1.1" 200 34387
10.0.2.80 - - [2013-Apr-09 16:58:40.650366] "POST /?wtd=RJlXG9XKN3Dwaam5 HTTP/1.1" 200 49

2. Click on "restart" button

Return from waitForShutdown
server.stop()

Here hangs it and the loading indicator is shown. After:

3. pressing F5

continue
try start the server
10.0.2.80 - - [2013-Apr-09 17:00:24.904557] "GET /?&wtd=8N2aFX6TIQBahR8r HTTP/1.1" 200 1943
10.0.2.80 - - [2013-Apr-09 17:00:24.923545] "POST /?wtd=8N2aFX6TIQBahR8r HTTP/1.1" 200 72
10.0.2.80 - - [2013-Apr-09 17:00:24.968529] "GET /?&wtd=H82QP4sRxLSY6B3X HTTP/1.1" 200 1942
10.0.2.80 - - [2013-Apr-09 17:00:25.010412] "GET /?wtd=H82QP4sRxLSY6B3X&request=style HTTP/1.1" 200 88
10.0.2.80 - - [2013-Apr-09 17:00:25.097637] "GET /?wtd=H82QP4sRxLSY6B3X&sid=-710642230&htmlHistory=true&deployPath=%2F&request=script&rand=4203343128 HTTP/1.1" 200 34390
10.0.2.80 - - [2013-Apr-09 17:00:25.204582] "POST /?wtd=H82QP4sRxLSY6B3X HTTP/1.1" 200 50

Just let me know how could I provide you better stack traces if these are not accurate enough.

Regards,

Stoycho

Hi,

A similar issue happened to me also with wt3.3.0. Calling WServer::stop seem to block in WIOService::stop() when joining the WT threads that don't seem to ever stop.

(using_timer is false in boost::thread, so join() on that thread will wait infinitely for a thread that doesn't stop).

This is the stack trace:

    ntdll.dll!NtWaitForMultipleObjects()  + 0x15 bytes  
    [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] 
    kernel32.dll!WaitForMultipleObjectsEx()  + 0x8e bytes   
    kernel32.dll!WaitForMultipleObjects()  + 0x18 bytes 
>   .dll!boost::this_thread::interruptible_wait(void * handle_to_wait_for=0x0000132c, boost::detail::timeout target_time={...})  Line 454 + 0x34 bytes  C++
    .dll!boost::thread::join()  Line 271 + 0x2f bytes   C++
    .dll!Wt::WIOService::stop()  Line 91    C++
    .dll!Wt::WServer::stop()  Line 221  C++
    .dll!CServer::Stop()  Line 289  C++
    .dll!CController::stopWebServer()  Line 83  C++
    App.exe!Stop Server initiated from GUI button

WServer::Stop() used to work seamlessly with wt_3.2.1. I'm using boost 1.46.1.

Could this be related to this boost::asio fix in boost 1.53.0: https://svn.boost.org/trac/boost/ticket/7552.

Is there a recommended BOOST version for each WT release ?

Thanks!

Is there any thread that has Wt stuff on its stack?

We have no specific recommendation for a boost release, we recommend to use a recent boost version. On the windows install instruction page, a few boost versions are listed where we identified annoying problems (windows specific).

Stoycho seems to be talking about a bug on Linux, you now report this on Windows. The issue is that while shutting down cleanly, we wait for the io_service to become idle (i.e. no asynchronous callbacks scheduled anymore). Any task, timer, ... that is still scheduled will prevent the io_service to shut down. I'm not sure if we can guarantee memleak-free shutdown if we force the io_service to stop. If Wt leaves something on the io_service, it's a bug; if you posted something in Wt's io_service, it's a feature ;-)

Wim.

Yes, for me it happens on windows.

The stack trace is for the main thread. From this thread, some callbacks are posted indeed to WT just before calling WServer::stop() (the callbacks do some internal cleanup after which they update the UI by deleting and hiding displayed widgets and by creating and showing some sort of disconnect page). The 'post' is done with server.post(pApp->sessionId(), boost::bind(&MyWebApplication:m, pApp));

We keep pApp in some internal list because WApplication::instance() returns 0 on non WT thread.

At this point I'm not sure what is happening, but beside the blockage, the disconnect widgets are not shown.

The same code worked well with wt 3.2.1 (meaning that the disconnect page was shown and then the server stops).

So I guess we fall into the second case: it's a feature (?!) what feature ? :)

Should I open a new issue to WT?

Hi WX,

Stack traces of the other threads may reveal if the application is in a deadlock.

It's better to keep a list of session ID's rather than pointers to applications, since otherwise you also have to manage potential race condition between applications being deleted and the possibility to still have a dereference to it from a different thread.

If it consistently doesn't work, it's worth submitting a bug report (test case much appreciated!), especially if it worked with 3.2.1.

BR,

Wim.

I'll try to come up with a test case, but until now I couldn't reproduce the blockage with a small test case.

I could reproduce the situation where the widgets are not shown after a sequence like this:

WServer.post(MyApp::closingroutine)

wait - without this, consistently the disconnect widget is not shown, but this time with wt 3.2.1 also

Wserver.stop().

MyApp::closingroutine - shows a disconnect page/widget. So, maybe my expectations, that the posted callback is executed before WServer::stop ends, are wrong.

In the meantime I used another approach:

• changed the post with getting the Updatelock for the application and calling directly "MyApp::closingroutine".
  Is it possible to end up with other issues with this approach ?

Regarding your statement that "It's better to keep a list of session ID's rather than pointers to applications", is it possible then to lookup the pointer to the application using the session id ? I need it when posting the callback.

We bind when we register the callback to the server (I believe the chat example does this).

You can also post to a static method, which then uses WApplication::instance() (or in short wApp) to forward the call to the appropriate application object.

Or you can post a lambda function that does dynamic_cast<MyApp *>(wApp)->myMethod().

Or maybe keep a reference to both the application pointer and the session id?

UpdateLocks are quite dangerous wrt deadlocks, make sure that you don't hold any other related lock (including other session locks, like the one for an event you're currently handling) when you use them. post() avoids this mess.

BR,

Wim.

I moved this discussion to http://redmine.webtoolkit.eu/boards/2/topics/6637 to avoid polluting the initial issue.

Wrt to comment [#21], I didn't say it is a deadlock. It looks to me more like and indefinite wait for the worker threads to finish (this is why I thought it might be related to boost issue: https://svn.boost.org/trac/boost/ticket/7552). The worker threads stack seem to show them polling on IO completion ports.

Thanks for recommendations on using the wApp pointer. In my application we store both the sessionId and the wApp pointer in a map indexed by sessionId(), so I guess we should be safe (?).

If I use a static callback I should get the same wApp that was used when post() was called (with a call to WApplication::instance()), because the callback is called on a Wt thread, right? (that seems more appealing then storing the app pointers).

Wrt to holding the UpdateLock, I don't get any other locks directly while using the UpdateLock (well, unless Wt does it internally, which is out of my control).

Hey Koen,

it works for me at least w.r.t. http://redmine.webtoolkit.eu/issues/1708#note-17. Here is the output of the use-case:

3.3.2
try start the server
10.0.2.80 - - [2014-Feb-26 16:26:35.001342] "GET /?wtd=nByIPvecDoWr1ch4 HTTP/1.1" 200 2088
10.0.2.80 - - [2014-Feb-26 16:26:35.009657] "POST /?wtd=nByIPvecDoWr1ch4 HTTP/1.1" 200 72
10.0.2.80 - - [2014-Feb-26 16:26:35.039774] "GET /?wtd=GJetRcDlhnDR4dC1 HTTP/1.1" 200 2088
10.0.2.80 - - [2014-Feb-26 16:26:35.078957] "GET /?wtd=GJetRcDlhnDR4dC1&request=style HTTP/1.1" 200 88
10.0.2.80 - - [2014-Feb-26 16:26:35.082643] "GET /resources/themes/default/wt.css HTTP/1.1" 404 85
10.0.2.80 - - [2014-Feb-26 16:26:35.085732] "GET /resources/moz-transitions.css HTTP/1.1" 200 5405
10.0.2.80 - - [2014-Feb-26 16:26:35.149432] "GET /?wtd=GJetRcDlhnDR4dC1&sid=-2128662183&tz=60&htmlHistory=true&deployPath=%2F&request=script&rand=3233340224 HTTP/1.1" 200 34914
10.0.2.80 - - [2014-Feb-26 16:26:35.229145] "POST /?wtd=GJetRcDlhnDR4dC1 HTTP/1.1" 200 51
10.0.2.80 - - [2014-Feb-26 16:26:38.395269] "POST /?wtd=GJetRcDlhnDR4dC1 HTTP/1.1" 200 51
Return from waitForShutdown
server.stop()
continue
try start the server
10.0.2.80 - - [2014-Feb-26 16:26:44.273275] "GET /?wtd=GJetRcDlhnDR4dC1 HTTP/1.1" 200 2090
10.0.2.80 - - [2014-Feb-26 16:26:44.282975] "POST /?wtd=GJetRcDlhnDR4dC1 HTTP/1.1" 200 72
10.0.2.80 - - [2014-Feb-26 16:26:44.332651] "GET /?wtd=5OqFhafeKh7aHWXi HTTP/1.1" 200 2089
10.0.2.80 - - [2014-Feb-26 16:26:44.368124] "GET /?wtd=5OqFhafeKh7aHWXi&request=style HTTP/1.1" 200 88
10.0.2.80 - - [2014-Feb-26 16:26:44.379907] "GET /resources/themes/default/wt.css HTTP/1.1" 404 85
10.0.2.80 - - [2014-Feb-26 16:26:44.380875] "GET /resources/moz-transitions.css HTTP/1.1" 200 5405
10.0.2.80 - - [2014-Feb-26 16:26:44.442281] "GET /?wtd=5OqFhafeKh7aHWXi&sid=520071826&tz=60&htmlHistory=true&deployPath=%2F&request=script&rand=504284216 HTTP/1.1" 200 34914
10.0.2.80 - - [2014-Feb-26 16:26:44.525397] "POST /?wtd=5OqFhafeKh7aHWXi HTTP/1.1" 200 49

Regards,

Stoycho