GNOME Bugzilla – Bug 727488
There is a race when disconnecting POST channel in tunneled mode
Last modified: 2014-04-08 14:28:41 UTC
Right now there is a race when disconnecting POST channel in tunneled mode and sometimes it is not possible to create new POST connection afterwards. After tunnel setup the first client owns the POST and the GET connections and the second client will be freed. But before it is freed its RTSP Watch will get dispatched and call the closed() callback. From closed() the server tries to remove the tunnelid from the hash table with the pending tunnels. And that is a problem if the POST was already disconnected and the tunnel marked as pending. I think that the client which got the POST connection should never touch the hash table with the pending tunnels. It is a responsibility of the client owning the tunnel to do that.
Created attachment 273462 [details] [review] client: remove watch of the second client after http tunnel setup This is just one way to solve the problem, not sure if that's the perfect way though.
Created attachment 273516 [details] [review] client: support for POST before GET when setting up a tunnel I am attaching this new patch to this same bugzilla ticket since it is kind of related to the above fix.
commit 132f77751d72b9942de25aee4071ba27b9829d28 Author: Ognyan Tonchev <ognyan@axis.com> Date: Wed Apr 2 12:03:32 2014 +0200 client: remove watch of the second client after http tunnel setup The second client will be freed after the HTTP tunnel has been set up. Make sure it's RTSP watch is never dispatched again. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727488
commit 0493a63a652bec39b2db56c2c0c4c4779091c6f5 Author: Ognyan Tonchev <ognyan@axis.com> Date: Thu Apr 3 12:19:51 2014 +0200 client: support for POST before GET when setting up a tunnel