[TS-3645] After TS-3033, some traffic_line commands result in "requested command failed"

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.3.0, 6.0.0
• Fix Version/s: 6.2.0
• Component/s: Management API
• Labels: review

Environment

RHEL 6.x, CentOS 6.x (on x86_64)

• Assignee: James Peach
• Reporter: Dimitry Andric
• Created: 28/May/15 20:26
• Updated: 19/Jul/16 20:17
• Resolved: 27/Jan/16 22:19

Description

I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I noticed was that certain traffic_line commands started printing "requested command failed". For example:

# trafficserver start
Starting Apache Traffic Server:                            [  OK  ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into function call.

Interestingly, even if the --shutdown command gives such an error message, the diags.log file still shows that the server has shut down:

[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE: [ProcessManager::processEventQueue] Shutdown msg received, exiting

and the --status command also finds the same:

# traffic_line  --status
Proxy -- off

Similar for the --startup command: though it gives the same error message, the command seems to have actually worked.

I did some bisecting to find where this was introduced, and ended up at commit 355c165 (TS-3033: fix PROXY_STATE_GET). Before this particular commit, both traffic_line --shutdown and traffic_line --startup work without printing any error; after the commit, they both start printing "requested command failed".

If I look at all the work done in TS-3033, and the particular change in commit 355c165, I would guess that some parts of the code are disagreeing about the number of parameters for the PROXY_STATE_GET message.

Alternatively, there may be some sort of issue in the management API and/or marshalling code, where a PROXY_STATE_GET message with two parameters gets "cut off" in some way, possibly because the server is just shutting down at that point?

Issue Links

• relates to: TS-3033 Reimplement management protocol