Frontend network control sends two responses after 'play program'

[Gregory Moyer <moyerg@…>]

My patch for #9725 overlooked the fact that the 'play program' command was relying on empty responses not being sent to the client.

In the processPlay method in networkcontrol.cpp for a 'play program' command, the result string is cleared when the NETWORK_CONTROL event to actually trigger playback is sent. Before the patch, when this function returned with an empty result, no message would have been sent back to the client and the client would still be waiting at this point. Once the playback request is received, networkcontrol.cpp will see a NETWORK_CONTROL RESPONSE event in the function customEvent and that will trigger the "OK" response to the client. This is the only place I found in which the result is cleared while a response is expected via an event later.

Now, after the fix from #9725, the empty response sends a prompt back to the user immediately and a short time later when the RESPONSE event is received, a second message of "OK" with another prompt is sent to the user. Therefore, in a netcat session, the user seems something like the attached nc-broken.log output.

My approach to correct this involves setting the response to a null QString (as QString defines null using the no-arg constructor) rather than an empty string when no response should be sent. Instead of checking for an empty string, the if check that was removed in #9725 is now verifying that the response is not null. This allows for both scenarios where an empty message can be returned to the user (such as when a 'query recordings' command is issued and no recordings exist), but an immediate response can also be stopped to allow for a delayed response triggered via other means, such as an event in the case of a 'play program' request.

This patch also changes the default response to 'query recordings' to a an empty string instead of a null string to comply with the above.

[Raymond Wagner]

Thank you for tracking this down and producing another patch, but I'm going to go a different direction in fixing this one. Rather than add special handling for commands that respond asynchronously, I'm going to enforce everything operate synchronously, such that there will always be a response to send back to the client.

[Github]

Make "play program" network control call synchronous.

This moves the response from "play program" while inside the playbackbox into the handling thread, rather than a separate asynchronous result. This may result in some concurrency issues as the entire network control server is locked until that thread to that client responds. Due to the already very coarse locking, it should not be significantly noticeable.

Fixes #9922

Branch: master Changeset: 731949d69f2d9c6e993f57cf60a277413a94872d

[Github]

Adjust timeouts for frontend control socket

Increases timeout for startup of recording playback from 2 seconds to 10 seconds. Move all such timeouts to FE_SHORT_TO and FE_LONG_TO, of 2 and 10 seconds respectively.

Refs #9922

Branch: master Changeset: 691d1368f373327685b8ea24015afd85e9d65a1e