Barry Oglesby created GEODE-3072:
------------------------------------
Summary: 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
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)
