You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Barry Oglesby (JIRA)" <ji...@apache.org> on 2017/06/14 20:10:00 UTC
[jira] [Commented] (GEODE-3072) Events do not get removed from the
client queue when 1.0 clients connect to 1.2 servers
[ https://issues.apache.org/jira/browse/GEODE-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049604#comment-16049604 ]
Barry Oglesby commented on GEODE-3072:
--------------------------------------
I have a fix for this.
ServerConnection getMembershipId was creating:
{noformat}
HeapDataOutputStream hdos = new HeapDataOutputStream(256, Version.CURRENT);
{noformat}
It should be creating the HeapDataOutputStream with the client version like:
{noformat}
HeapDataOutputStream hdos = new HeapDataOutputStream(256, client.getClientVersion());
{noformat}
With this change, the membershipId byte[]s are equal, and the events are removed from the queue.
> 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
>
> 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)