[
https://issues.apache.org/jira/browse/GEODE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335733#comment-17335733
]
Barrett Oglesby commented on GEODE-9138:
----------------------------------------
A lot of this change is to determine when and when not to log the message.
There were 3 HA cases where the message was logged validly:
- posDup (for client message retries)
- low bucket redundancy (when a server crashes)
- recoveries in progress (when a server restarts)
The first change was to convert the message from debug to info. What that
change, Lynn ran the parReg/parRegHABridge.bt test to see how many of those
message were logged. This test does a variety of operations while killing and
restarting servers.
There were ~400 of those messages logged per test the first run. These are all
valid duplicates that we don't want to log if we can help it. We really only
want to log this message in steady state (no HA).
The first case I noticed was low bucket redundancy. I also noticed at that same
time sometimes posDup was true; sometimes not. I also realized every message in
this low bucket redundancy state should have been posDup (they were all client
retries). But posDup wasn't set on putAlls and removeAlls. So I made those
changes and added the posDup case.
After that, there were still a handful of messages logged. That was because the
region was being recovered. The messages were logged for a specific bucket
right after it was GIIed, but the region was still in recovery, so I added that
case.
I also ran some rebalance tests, but I didn't see any messages. I'm not 100%
sure there aren't any though.
> Add warning in server logs when data event is ignored as a duplicate
> --------------------------------------------------------------------
>
> Key: GEODE-9138
> URL: https://issues.apache.org/jira/browse/GEODE-9138
> Project: Geode
> Issue Type: Bug
> Components: client/server, logging
> Reporter: Diane Hardman
> Assignee: Barrett Oglesby
> Priority: Major
> Labels: pull-request-available
>
> Under certain rare conditions, a client may send or resend a data event with
> an eventId that causes the server to interpret it as a duplicate event and
> discard it.
> It is currently impossible to trace when this happens without extra logging
> added.
> From Barry:
> No, if the server thinks it has seen the event, it silently eats it. See
> DistributedEventTracker.hasSeenEvent. It has a trace log message but thats it.
> The log message that tracks this behavior in the server needs to be added
> permanently.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
