00455: dcomm get_num_overrun_frames hangs on clients

« 00454 | Issues | 00456 »

Summary: dcomm get_num_overrun_frames hangs on clients

Created: 2012–11–14 18:26

Status: Released

Category: Bug

From: frankie

Version: 2.2

Released_In: 2.3

Description:

using the tcl command to the dcomm plugin "get_num_overrun_frames" hangs when calling on a client until a 10 second timeout occurs. Then it just returns −1.

---

Comments

frankie November 14, 2012, at 07:20 PM: Some of these commands on a client cause a message to be sent to the server and waits for an answer. Something was causing this to hang until it reached the timeout. Since it is easier to request this information from the server directly rather than through a client, and since we have a precedent like this with other commands, I changed this to return −1 when called on a client and to return a valid value when called on a server. This effectively gets rid of the hanging issue when the command is called or when the WCS page requesting this telemetry is called.

---

« 00454 | Issues | 00456 »

Associated Commits

| commit | a0889c5a988f9d94384da920d9458a1ac22ef010 link5 | || | Author: | Frank Graffagnino | | Date: | Wed Nov 14 19:10:29 2012 -0600 | | Message: | [@Issue 00398, 00448, 00455: Added in dcomm read-only mode, fixes for dcomm hanging on tcl command, and updated mobile WCS template These issues were loosely interrelated, so they got committed together. For 00398, the read-only mode was added in via the updated plugins. Now, on the command line to the dcomm plugin you can pass in "-read_only" or "-noread_only" to enable and disable read-only mode. There is a new tcl command to query the state, which is why the WCS xml template and mobile pages were updated to reflect this new telemetry. This lead to issue 00448, since when I added in the connected field to the xml, i forgot to update the mobile pages also to include it. So while I added in the read-only mode to both, I also fixed the mobile pages to have the connected field in the general and dcomm status pages. Issue 00455 got committed at the same time because it is also in the dcomm plugins where I applied the fix. Rather than trying to fix the source of the hang, I changed it to where clients always return −1, as it is easier to query this information from the manager directly. Also, it is probably more effecient since it doesn't have to tunnel the information through a tunnel blocking all communication until an answer returns. @] |

Affected Files:

gui/html/lte_edge_root.xsl        |   3 +++
 gui/html/templates/mobile.tmpl    |   6 ++++++
 gui/html/templates/xml_dcomm.tmpl |   1 +
 plugin_Darwin/dsp_dcomm_tc.so     | Bin 229280 -> 229340 bytes
 plugin_Linux_FC3/dsp_dcomm_tc.so  | Bin 68950 -> 69135 bytes
 plugin_Win32/dsp_dcomm_tc.dll     | Bin 1009518 -> 1009554 bytes
 6 files changed, 10 insertions(+)

| commit | 0ab613db4d12c538a447956cc6c384bad2136f03 link6 | || | Author: | Frank Graffagnino | | Date: | Wed Nov 14 19:17:54 2012 -0600 | | Message: | [@Issue 00455: Fixed issue where tcl command in dcomm was causing a hang Some of these commands on a client cause a message to be sent to the server and waits for an answer. Something was causing this to hang until it reached the timeout. Since it is easier to request this information from the server directly rather than through a client, and since we have a precedent like this with other commands, I changed this to return −1 when called on a client and to return a valid value when called on a server. This effectively gets rid of the hanging issue when the command is called or when the WCS page requesting this telemetry is called. @] |

Affected Files:

src/plugins/dsp_dcomm_tc.c | 9 ++++±---
 1 file changed, 5 insertions(+), 4 deletions(-)