[DISCUSS] batch patch release voting

[Owen Nichols]

Geode's N-2 support policy can lead to "waves" of patch releases.  For example, 
1.12.6, 1.13.5 and 1.14.1 are all likely this month, with many of the same 
fixes in each.

Some open source projects group waves of patch releases into a single 
announcement.  It might be nice to do this for Geode.

For voting, does anyone have any preference whether to still hold three 
separate votes, or would it be ok to vote on a batch of patch releases at once? 
 If so, would 3 days still be enough time for the voting deadline?

Re: Client terminating when trying to connect to an SSL configured locator

[Dan Smith]

I guess the alternative would be for the client to automatically switch to SSL 
if it detected the server was using SSL? It is not currently doing that, as you 
discovered.

That might be a nice feature to have to support upgrading to SSL. At some 
point, it is important for users that want SSL to configure their client to 
only​ use SSL, to prevent downgrade attacks.

I think we would consider a geode change that turns on SSL by default to be a 
breaking change. I can image some users might want to upgrade to using SSL in 
their existing cluster. For clients, I think that could be accomplished by 
running both a SSL and non-SSL enabled locator, for example. I'm not sure if 
it's possible to switch the P2Pmessaging to use SSL with a rollng upgrade right 
now though.

-Dan

From: Mario Salazar de Torres 
Sent: Tuesday, November 30, 2021 10:37 AM
To: dev@geode.apache.org 
Subject: Client terminating when trying to connect to an SSL configured locator

Hi everyone,

During some tests, we've noted that if a client tries to connect to an SSL 
configured locator, and the client does not have SSL configured, it terminates 
due to an unhandled exception.
You can check the behaviour here for geode-native: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fblob%2Fdevelop%2Fcppcache%2Fsrc%2FThinClientLocatorHelper.cpp%23L147&data=04%7C01%7Cdasmith%40vmware.com%7Cb2e7a8ffc506463d51e008d9b4306e5d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637738942373842079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q%2F18j0f3GtCXUS5jtI8fZbdjUFn7ouRwRd%2BnAKFA9QY%3D&reserved=0
And here for the Java client: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-tcp-server%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Fdistributed%2Finternal%2Ftcpserver%2FTcpClient.java%23L278&data=04%7C01%7Cdasmith%40vmware.com%7Cb2e7a8ffc506463d51e008d9b4306e5d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637738942373852076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZkixzNe4sGUzIQOz%2FNc1gdYBI%2B6F%2FFeG2HsPf3ZaYVU%3D&reserved=0

And here is the question. Do you know if there is any reason behind it?
Also, do you happen to know if there is any upgrade case in which SSL is 
enabled on the newer version? Because I am guessing this kind of upgrade might 
be problematic, right?

Thanks!
Mario

Re: Question related to orphaned .drf files in disk-store

[Dan Smith]

Interesting. It does look like that pendingKrfTags structure is wasting memory.

I think that retained heap of 20 gigabytes might include your entire cache, 
because those objects have references back to the Cache object. However with 6K 
oplogs each having an empty map with 4K elements that does add up.

-Dan

From: Jakov Varenina 
Sent: Tuesday, November 30, 2021 5:53 AM
To: dev@geode.apache.org 
Subject: Re: Question related to orphaned .drf files in disk-store


Hi Dan and all,


Just to provide you the additional picture that better represents the severity 
of the problem with pendingKrfsTag. So when after you check the second picture 
in below mail, then please come back and check this one also. Here you can see 
that the pendingKerfTags is empty and has capacity of 9,192 allocated in memory.


[cid:part1.34321273.4B069259@est.tech]


Sorry for any inconvenience.

BRs/Jakov


On 30. 11. 2021. 09:32, Jakov Varenina wrote:

Hi Dan,


Thank you for your answer!


We have identify memory leak in Oplog objects that are representing orphaned 
.drf files in heap memory. In below screenshoot you can see that 7680 
onlyDrfOplogs consume more than 18 GB of heap which doesn't seem correct.


[cid:part2.37771ED9.3D154D16@est.tech]


In below picture you can see that the drfOnlyPlog.Oplog.regionMap.pendingKrfTgs 
structure is responsible for more then 95% of drfOnlyOplogs heap memory.



[cid:part3.CBE3F691.1279916D@est.tech]


The pendingKrfTags structure is actually empty (although it consumes memory 
because it was used previously and the size of the HashMap was not reduced) and 
not used by the onlyDrfOplogs objects. Additionally, the regionMap.liveEntries 
linked list has just one element (fake disk entry OlogDiskEntry indicating that 
it is empty) and it is also not used. You can find more details why 
pedingKrfTags sturcture remianed in memory for Oplog object representing 
orphaned .drf file and possible solution in the following ticket and the PR:


https://issues.apache.org/jira/browse/GEODE-9854

https://github.com/apache/geode/pull/7145


BRs/Jakov



On 24. 11. 2021. 23:12, Dan Smith wrote:
The .drf file contains destroy records for entries in any older oplog. So even 
if the corresponding .crf file has been deleted, the .drf file with the same 
number still needs to be retained until the older .crf files are all deleted.

7680 does seem like a lot of oplogs. That data structure is just references to 
the files themselves, I don't think we are keeping the contents of the .drf 
files in memory, except during recovery time.

-Dan

From: Jakov Varenina 
Sent: Wednesday, November 24, 2021 11:13 AM
To: dev@geode.apache.org 

Subject: Question related to orphaned .drf files in disk-store

Hi devs,

We have noticed that disk-store folder can contain orphaned .drf files (only 
.drf file without accompanying .crf and .krf file with the same id). Also, we 
have noticed that these "orphaned" .drf are stored in heap (drfOnlyOplogs hash 
map with size 7680 in below picture):

[cid:part1.46E308C2.37688A13@est.tech]

Could you please tell us why do geode after compaction sometimes only keep .drf 
and deletes the .crf and .krf files? Why do geode need those orphaned .drf 
files?

BRs/Jakov