geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Oglesby (JIRA)" <>
Subject [jira] [Created] (GEODE-3072) Events do not get removed from the client queue when 1.0 clients connect to 1.2 servers
Date Wed, 14 Jun 2017 20:08:00 GMT
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
             Project: Geode
          Issue Type: Bug
          Components: client queues, serialization
            Reporter: Barry Oglesby

The EventID is created in Put65 cmdExecute on the server here:
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(
	at org.apache.geode.internal.cache.EventID.<init>(
	at org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(
	at org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(
	at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(
	at org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
	at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$
new EventID(serverConnection.getEventMemberIDByteArray(), threadId, sequenceId)
This causes a 38 byte membership id to be generated:
ServerConnection on port 61938 Thread 2: XXXX EventID.EventID 3 membershipIDLength=38
ServerConnection on port 61938 Thread 0: XXXX CacheClientNotifier.processDispatchedMessage
The PeriodicAck sends in a 55 byte membership id:
ServerConnection on port 61938 Thread 0: DurableHARegionQueue.setAckedEvents ackedEventsSize=1
  tid=ThreadId[1]; membershipIdLength=55
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:
DurableHARegionQueue.checkEventForRemoval threadId=ThreadId[;
thread 1]; membershipIdLength=38
DurableHARegionQueue.checkEventForRemoval currDurableMapKey=ThreadId[;
thread 1]; membershipIdLength=55

This message was sent by Atlassian JIRA

View raw message