GEODE-4375: Fix problem that an exception occurs when transaction from CacheServer via Pool #1363
Conversation
CacheServer via Pool
| LocalRegion region = getRegionByPath(msg.getDM(), | ||
| parentRegionPath != null ? parentRegionPath : regionPath); | ||
| boolean readShadowKey = | ||
| (region != null ? (region.getPoolName() == null) : !msg.getDM().isLoner()); |
There was a problem hiding this comment.
These two lines with their ternaries are so dense with logic, that I wonder if it might be worthwhile to split this out into a private method and break this out more into variables and maybe even a if/else statement instead of the ternary to make this easier to follow.
CacheServer via Pool
|
@pivotal-amurmann Thank you for your review. |
…m CacheServer via Pool (apache#1363)
|
Good work on this PR. For future reference, this is not the correct way to test for backward compatibility. The code in the old client is 1.5 code. Shoving 1.3 into Version.CURRENT is making the client pretend to be a 1.3 client and servers will serialize messages accordingly. A change in handshake serialization on my "develop" branch for 1.5 caused this test to throw an OutOfMemoryError and blew up my pre-checkin run. The correct way to create an old-version client is to use Host.getVM(versionName, vmNumber), as in Then it will actually be running with 1.3 code. https://cwiki.apache.org/confluence/display/GEODE/Writing+Backward-compatibility+DUnit+tests I'm fixing up the test and will make it a parameterized test running against all available old-versions. |
|
@bschuchardt I'm sorry & Thank you for your future reference. |
…m CacheServer via Pool (#1363) Modifying the test for proper backward-compatibility testing
CacheServer via Pool
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop)?Is your initial contribution a single, squashed commit?
Does
gradlew buildrun cleanly?Have you written or updated unit tests to verify your changes?
[ N?A] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.