[
https://issues.apache.org/jira/browse/GEODE-9387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367514#comment-17367514
]
ASF subversion and git services commented on GEODE-9387:
--------------------------------------------------------
Commit f6b0ef6634ebf9f8fa58e04478fe47307a238167 in geode-native's branch
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=f6b0ef6 ]
GEODE-9387: Ignore version trace in gnmsg (#822)
- makes the tool robust against weird versions of NC
- no longer any need to combine rolled log files to parse messages
> gnmsg: remove version detection and switch regex based on found log entries
> ---------------------------------------------------------------------------
>
> Key: GEODE-9387
> URL: https://issues.apache.org/jira/browse/GEODE-9387
> Project: Geode
> Issue Type: Improvement
> Components: native client
> Reporter: Blake Bender
> Priority: Major
> Labels: pull-request-available
>
> gnmsg currently looks for the log line containing the version of native
> client being used, in order to detect which regex to use to parse message
> traces, among other things. This has several implications:
>
> i. gnmsg cannot parse messages in a "rolled" log file, because only the first
> file contains the version stamp
> ii. the parsing code is very brittle, and routinely breaks when coming across
> a log from a point release we haven't seen logs for, or a developer build
> with an uninitialized version stamp, etc.
>
> What should happen is, where there are possible variants for a given trace,
> gnmsg should check for all variants until it finds a match, then thereafter
> only check for that variant. This should still yield decent performance, but
> also no longer care about the version stamp, allowing us to parse rolled log
> files and be much more robust to the types of logs we can read.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
