[
https://issues.apache.org/jira/browse/GEODE-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065488#comment-16065488
]
ASF subversion and git services commented on GEODE-3072:
--------------------------------------------------------
Commit ff6cbf317ab24bb0e582a3eca01c23e7b435ef35 in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ff6cbf3 ]
GEODE-3072: Events do not get removed from the client queue for 1.0 clients
EventID and ThreadIdentifier hold the serialized form of portions of an
InternalDistributedMember identifier. This serialized form changed in
v1.0.0 and was causing .equals and .hashCode for these objects to return
false when they should have returned true owing to additional data being
in the serialized form of the identifier.
This change set modifies the equals and hashCode methods of the classes
to ensure that they return the correct results in the presence of this
additional ID data.
I created a dunit test to reproduce the problem but I think the behavior
of HARegionQueues isn't reliable enough to check in that test. I'm
afraid that it would end up being a "flaky" test that fails periodically.
Instead, I'm relying on a new junit test and the test that Barry already
checked in.
Note: I've also included two other things in this change set.
First, LocalRegion.dumpBackingMap() is a test-hook that should log its
results at "info" level. I used it in debugging this problem.
Second, I've added a new backward-compatibility version so now we have
100 and 110.
> Events do not get removed from the client queue when 1.0 clients connect to
> 1.2 servers
> ---------------------------------------------------------------------------------------
>
> Key: GEODE-3072
> URL: https://issues.apache.org/jira/browse/GEODE-3072
> Project: Geode
> Issue Type: Bug
> Components: client queues, serialization
> Reporter: Barry Oglesby
> Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> The EventID is created in Put65 cmdExecute on the server here:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1329)
> at org.apache.geode.internal.cache.EventID.<init>(EventID.java:242)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:201)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:165)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:780)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:911)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:523)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> like:
> {noformat}
> new EventID(serverConnection.getEventMemberIDByteArray(), threadId,
> sequenceId)
> {noformat}
> This causes a 38 byte membership id to be generated:
> {noformat}
> ServerConnection on port 61938 Thread 2: XXXX EventID.EventID 3
> membershipIDLength=38
> ServerConnection on port 61938 Thread 0: XXXX
> CacheClientNotifier.processDispatchedMessage eidMembershipIdLength=55
> {noformat}
> The PeriodicAck sends in a 55 byte membership id:
> {noformat}
> ServerConnection on port 61938 Thread 0: DurableHARegionQueue.setAckedEvents
> ackedEventsSize=1
> tid=ThreadId[1]; membershipIdLength=55
> {noformat}
> HARegionQueue remove calls HARegionQueue checkEventForRemoval before it
> removes an event from the queue. When the comparison is made in HARegionQueue
> checkEventForRemoval, it returns false every time. Its false because the
> input ThreadIdentifier is not the same as the one in the currDurableMap.
> Their toStrings are the same, but they are not equal because their
> membershipIDs are not equal. This is why the events aren't being removed.
> Here is some debugging that shows the difference:
> {noformat}
> DurableHARegionQueue.checkEventForRemoval
> threadId=ThreadId[192.168.2.4(client-feeder:loner):61201:70bec7a3:client-feeder;
> thread 1]; membershipIdLength=38
> DurableHARegionQueue.checkEventForRemoval
> currDurableMapKey=ThreadId[192.168.2.4(client-feeder:loner):61201:70bec7a3:client-feeder;
> thread 1]; membershipIdLength=55
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
