[SERVER-28196] Legacy query and getMore should appear in a consistent format across currentOp, profiler and logs Created: 06/Mar/17 Updated: 06/Dec/17 Resolved: 07/Mar/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.5 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bernard Gorman | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Minor Change | ||||||||
| Backport Requested: |
v3.4
|
||||||||
| Sprint: | Query 2017-03-27 | ||||||||
| Participants: | |||||||||
| Description |
|
The following inconsistencies exist in how legacy query/getMore are represented in diagnostic output: In currentOp:
In the profiler:
In the logs:
Upconversion and display of legacy queries and getMores should be consistent across currentOp/profiler/logs, and in the case of getMores the original operation should be shown in the originatingCommand field. |
| Comments |
| Comment by David Storch [ 10/Oct/17 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi steve.renaker, the originatingCommand field associated with a getMore displays the command which caused the cursor to be opened, typically a find or aggregate command. It contains all of the command parameters, such as the pipeline for aggregate or the filter and sort for find. Both find and aggregate also accept a comment parameter. This does not affect the execution of the command, but instead is a place where applications can put a descriptive string that will appear in the logs and in profiler entries. The comment can help operators trace from the logs/profiler back to the behavior of their application. The originatingCommand field in getMore is also particularly useful for tracing a getMore log line or profiler entry back to the application. Hopefully that was helpful, but let me know if I can clarify further. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Steve Renaker (Inactive) [ 09/Oct/17 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
david.storch can you tell me a bit more about the originatingCommand.comment field? What is its purpose? Thanks for any help. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Storch [ 07/Mar/17 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The following summarizes, with examples, the behavior changes made under this ticket in commit 3cba97198638. Logs Legacy find operations are now logged in an upconverted format, appearing as find commands. Before this change:
After:
Similarly, legacy OP_GET_MORE operations are now upconverted such that their log format resembles that of the getMore command. This also includes inclusion of the full originatingCommand field, which displays the operation which generated the cursor on which the getMore is acting. Before:
After:
Profiler Profiler entries for legacy getMore now contain the originatingCommand. The originatingCommand is displayed in an upconverted format if the cursor was generated by a legacy OP_QUERY find.
currentOp Legacy getMore operations are now upconverted to appear as getMore commands in db.currentOp() output. Furthermore, the originatingCommand is now reported, in an upconverted format if the originating command was in fact a legacy OP_QUERY.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 07/Mar/17 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'gormanb', u'name': u'Bernard Gorman', u'email': u'bernard.gorman@gmail.com'}Message: Closes #1139 Signed-off-by: David Storch <david.storch@10gen.com> |