Question regarding VersionRequest/VersionResponse messages
Hi community,
I have one question regarding VersionRequest/VersionResponse messages.
Before member sends actual message, it has to first determine the remote
member version. This is done by exchanging
/VersionRequest///VersionResponse/ messages using function
/getServerVersion() /from class /TcpClient.java/. There is part of code
in /getServerVersion()/ for which I'm unsure which case is actually
covering:
https://github.com/apache/geode/blob/854456c81ca7b9545eba252b6fa075318bb33af8/geode-tcp-server/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpClient.java#L289
try {
final Object readObject =objectDeserializer.readObject(versionedIn); if
(!(readObjectinstanceof VersionResponse)) {
throw new IllegalThreadStateException(
"Server version response invalid: This could be the result of trying to
connect a non-SSL-enabled client to an SSL-enabled locator."); }
final VersionResponse response = (VersionResponse) readObject; serverVersion
= response.getVersionOrdinal(); serverVersions.put(address, serverVersion);
return serverVersion; }catch (EOFException ex) {
// old locators will not recognize the version request and will close
the connection }
...
return KnownVersion.OLDEST.ordinal();
The case is when /readObject()/ try to read /VersionResponse/ and then
throws /EOFException/. As you can see, there is comment in catch
statement explaining the case, but I'm not sure that I understand it
correctly. What I assume is that member with old version (less or equal
to /KnownVersion.OLDEST/) of Geode does not support /VersionRequest/
message, and will close connection if receive such message. This will
result with /EOFException/ on remote member that sent /VersionRequest/.
Is this correct understanding? Is this case still valid with the latest
non-deprecated version set to /GFE_81/?
The reason why I'm asking this is because in some cases in kuberentes
cluster, it is possible to get /EOFException/ when remote member is not
yet accessible. In this case member will still try to send message (e.g.
/RemoteLocatorJoinRequest/) thinking that it is old member on the other
side, and that will then result with /ClassCastException/ when reading
response (e.g. /RemoteLocatorJoinResponse/).
BRs,
Jakov
[PROPOSAL] backport GEODE-8761 to support/1.14
GEODE-8761 causes geode to detect threads in a cache server that are stuck processing a client request. This can be very helpful in diagnosing hangs. The changes to make this happen are rather simple and I'd like to backport them to 1.14.
Re: [PROPOSAL] backport GEODE-8761 to support/1.14
+1 This will be very nice to have On 3/9/21, 9:08 AM, "Darrel Schneider" wrote: GEODE-8761 causes geode to detect threads in a cache server that are stuck processing a client request. This can be very helpful in diagnosing hangs. The changes to make this happen are rather simple and I'd like to backport them to 1.14.
Re: [PROPOSAL] backport GEODE-8761 to support/1.14
Sounds good, added to blocker board On 3/9/21, 9:16 AM, "Bruce Schuchardt" wrote: +1 This will be very nice to have On 3/9/21, 9:08 AM, "Darrel Schneider" wrote: GEODE-8761 causes geode to detect threads in a cache server that are stuck processing a client request. This can be very helpful in diagnosing hangs. The changes to make this happen are rather simple and I'd like to backport them to 1.14.
Avoid PowerMockito
I just reviewed a PR that was adding a unit test using PowerMockito. We've had lots of problems with PowerMockito leaving the unit testing JVM corrupted for later tests. Using PowerMockito also discourages us from refactoring product code to have better design and be easier to unit test. So in previous threads here on dev-list, the community decided to axe our usage of PowerMockito. There are lots of Jira tickets about PowerMockito in Geode: https://issues.apache.org/jira/issues/?jql=project%20%3D%20GEODE%20AND%20text%20~%20%22PowerMockito%22 There is one open ticket for removing PowerMockito from Geode: https://issues.apache.org/jira/browse/GEODE-6143 Unfortunately the assignee is no longer active in this community so we need someone or everyone to pitch in. If you find yourself working on an area of code that has a unit test using PowerMockito, please rewrite the test using regular Mockito and refactor the code that it tests so that you can pass all of its dependencies in via the constructor(s). If anyone would like to volunteer to take on GEODE-6143, please feel free to reassign it. I would be happy to help you out. Thanks, Kirk
