[jira] [Resolved] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10381.
---
Resolution: Duplicate
> CI Failure:
> SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
> FAILED
> --
>
> Key: GEODE-10381
> URL: https://issues.apache.org/jira/browse/GEODE-10381
> Project: Geode
> Issue Type: Bug
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [c4f0c1c64be0eb32: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator1
> --bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
> --port=29435 --J=-Dgemfire.jmx-manager-port=29436
> --security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
>
> --locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
> at
> org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vin
[jira] [Resolved] (GEODE-10326) Convert MessageType into an enum
[
https://issues.apache.org/jira/browse/GEODE-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10326.
---
Fix Version/s: 1.16.0
Resolution: Fixed
> Convert MessageType into an enum
>
>
> Key: GEODE-10326
> URL: https://issues.apache.org/jira/browse/GEODE-10326
> Project: Geode
> Issue Type: Improvement
> Components: messaging
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> Currently {{MessageType}} is class with lots of numeric constants,
> effectively and enum without all the compile time checking that comes with
> it. Let's make it an enum for type safety.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10349) Client connects to a new server socket should check its availability
[
https://issues.apache.org/jira/browse/GEODE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545889#comment-17545889
]
Jacob Barrett commented on GEODE-10349:
---
Then lower the connection timeout. DO NOT use {{InetAddress.isReachable()}}.
The method makes a best effort check for availability of the host, not a
listening port on a host. It is likely to report false positives and negatives
depending on the current state of the host or any firewalls between client and
server.
> Client connects to a new server socket should check its availability
> -
>
> Key: GEODE-10349
> URL: https://issues.apache.org/jira/browse/GEODE-10349
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: pull-request-available
>
> When client connects to a new server (or restarted server), it might
> encounter SocketTimeoutException which could take 59 seconds.
> To speed up, the idea is to check if the server address's is reachable with
> smaller timeout.
> If the server's address is not reachable, no need to block waiting for 59
> seconds (DEFAULT_SOCKET_CONNECT_TIMEOUT).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10354) Convert DataPolicy and InterestPolicy to enums
[
https://issues.apache.org/jira/browse/GEODE-10354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-10354:
-
Assignee: Jacob Barrett
> Convert DataPolicy and InterestPolicy to enums
> --
>
> Key: GEODE-10354
> URL: https://issues.apache.org/jira/browse/GEODE-10354
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>
> Both {{DataPolicy}} and {{InterestPolicy}} are enum like classes so make them
> true Java enums.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10354) Convert DataPolicy and InterestPolicy to enums
Jacob Barrett created GEODE-10354:
-
Summary: Convert DataPolicy and InterestPolicy to enums
Key: GEODE-10354
URL: https://issues.apache.org/jira/browse/GEODE-10354
Project: Geode
Issue Type: Improvement
Reporter: Jacob Barrett
Both {{DataPolicy}} and {{InterestPolicy}} are enum like classes so make them
true Java enums.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10326) Covert MessageType into an enum
[
https://issues.apache.org/jira/browse/GEODE-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-10326:
-
Assignee: Jacob Barrett
> Covert MessageType into an enum
> ---
>
> Key: GEODE-10326
> URL: https://issues.apache.org/jira/browse/GEODE-10326
> Project: Geode
> Issue Type: Improvement
> Components: messaging
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>
> Currently {{MessageType}} is class with lots of numeric constants,
> effectively and enum without all the compile time checking that comes with
> it. Let's make it an enum for type safety.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10326) Covert MessageType into an enum
Jacob Barrett created GEODE-10326:
-
Summary: Covert MessageType into an enum
Key: GEODE-10326
URL: https://issues.apache.org/jira/browse/GEODE-10326
Project: Geode
Issue Type: Improvement
Components: messaging
Reporter: Jacob Barrett
Currently {{MessageType}} is class with lots of numeric constants, effectively
and enum without all the compile time checking that comes with it. Let's make
it an enum for type safety.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9787) Cascade deprecation of symbols to dependent symbols in preparation for 2.0. [PERMANENT]
[
https://issues.apache.org/jira/browse/GEODE-9787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9787:
-
Summary: Cascade deprecation of symbols to dependent symbols in preparation
for 2.0. [PERMANENT] (was: Cascade deprecation of symbols to dependent
symbols. [PERMANENT])
> Cascade deprecation of symbols to dependent symbols in preparation for 2.0.
> [PERMANENT]
> ---
>
> Key: GEODE-9787
> URL: https://issues.apache.org/jira/browse/GEODE-9787
> Project: Geode
> Issue Type: Task
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> When deprecated some symbols require that other symbols be modified to match
> types or or other changes. The original versions of these symbols should be
> deprecated in favor of the new. This is a long running ticket to collect all
> those changes.
> For example, when replacing deprecated usage of {{Statistics.getInt()}} with
> {{Statistics.getLong()}} a public API method may need to change to return the
> {{long}} value.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534649#comment-17534649
]
Jacob Barrett commented on GEODE-10297:
---
When creating an {{SSLContext}} in {{SSLUtil}} we use the {{ssl-protocols}}
list to for the {{SSLContext}} instance. It loops over the list and returns the
first request that doesn't result in an exception. In the example case
{{TLSv1.2}} context is found first, which supports {{TLSv1.2}} as its newest
protocol.
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10297:
--
Affects Version/s: 1.14.4
1.13.8
1.12.9
1.15.0
1.16.0
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10297:
--
Labels: blocks-1.15.0 needsTriage (was: needsTriage)
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
Jacob Barrett created GEODE-10297:
-
Summary: SSL protocol ordering can result in loss of newer
protocol support.
Key: GEODE-10297
URL: https://issues.apache.org/jira/browse/GEODE-10297
Project: Geode
Issue Type: Bug
Components: core
Reporter: Jacob Barrett
If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
the {{SSLContext}} used will support at most that weaker protocol.
For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the {{TLSv1.2}}
{{SSLContext}}, which will not support, and silently ignore, the {{TLSv1.3}}
configuration. The effective enabled protocols list will be {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
[ https://issues.apache.org/jira/browse/GEODE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett reassigned GEODE-10296: - Assignee: Jacob Barrett > Parser error in HDR histogram log can result in terminate of JVM > > > Key: GEODE-10296 > URL: https://issues.apache.org/jira/browse/GEODE-10296 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > The HDR histogram parser exits the JVM on parsing errors. This results in > benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
Jacob Barrett created GEODE-10296: - Summary: Parser error in HDR histogram log can result in terminate of JVM Key: GEODE-10296 URL: https://issues.apache.org/jira/browse/GEODE-10296 Project: Geode Issue Type: Bug Components: benchmarks Reporter: Jacob Barrett The HDR histogram parser exits the JVM on parsing errors. This results in benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10259) Update geode-native library protocol to 1.14
[ https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-10259. --- Fix Version/s: 1.15.0 Resolution: Fixed > Update geode-native library protocol to 1.14 > > > Key: GEODE-10259 > URL: https://issues.apache.org/jira/browse/GEODE-10259 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-native library still talks the Geode 1.0.0 protocol, update to at > 1.14. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10217) NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes multiple test failures
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528847#comment-17528847
]
Jacob Barrett commented on GEODE-10217:
---
ByteBuddy was introduced in 3b8f4401bf117f811f455b8723803edfe61b71fe.
> NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes
> multiple test failures
> ---
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
>
> The below stack traces were seen in the unit-test-openjdk8 job in the
> pipeline. In addition to the two failures shown, multiple other failures due
> to {{NoClassDefFoundError}} for {{ThreadLocalRandom}} were also present.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.ja
[jira] [Commented] (GEODE-10217) NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes multiple test failures
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528844#comment-17528844
]
Jacob Barrett commented on GEODE-10217:
---
This happens to others as a result of Mockito inline plugin used for mocking
private classes. We could modify/eliminate the test that was added that needed
this. A new integration test would likely need to be created to replace it
since we can't mock its interactions.
Other projects report similar random issues too:
[https://groups.google.com/g/mockito/c/1nPBIzvOHYs]
[https://github.com/GoogleContainerTools/jib/issues/940]
> NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes
> multiple test failures
> ---
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
>
> The below stack traces were seen in the unit-test-openjdk8 job in the
> pipeline. In addition to the two failures shown, multiple other failures due
> to {{NoClassDefFoundError}} for {{ThreadLocalRandom}} were also present.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGener
[jira] [Resolved] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10066.
---
Resolution: Fixed
Not back porting to older releases. Fix misconfigured locator or update to
Geode 1.15.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.12.10, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.int
[jira] [Resolved] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-9991.
--
Resolution: Fixed
Not back porting to older releases due to complexity of upgrading the patches.
Users should upgrade to Geode 1.15 using the documented steps in this ticket.
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[ https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528322#comment-17528322 ] Jacob Barrett commented on GEODE-9991: -- h1. Geode Upgrade Methods for 1.15.0 h1. Preface Migration steps are only required if ssl-endpoint-identification-enabled=true. All other upgrades are allowed without migration steps. Migration is required due to a bug introduced that causes Geode to ignore the configured ssl-protocols and fall back to the JVM defaults, which can result in the client side being configured with SSLv2Hello and the server to deny it. With this mismatch in protocol configuration the member can fail to establish P2P connections to other members of the cluster. Two new properties are introduced in this version to configure the server and client side of the P2P connections separately, ssl-server-protocols and ssl-client-protocols respectively. h1. Upgrading Geode You can upgrade Geode to 1.15.0, with or without upgrading the JVM, under these conditions. h2. From 1.14.0-1.14.4, 1.13.0-1.13.8, 1.12.1-1.12.9 If ssl-protocols is explicitly set but does not include SSLv2Hello, for example “TLSv1.2,TLSv1.1”, then goto [Upgrade With New Properties|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.modyy795d4pz]. If ssl-protocols explicitly includes SSLv2Hello, for example “TLSv1.2,SSLv2Hello”, then goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. If ssl-protocols is unset or set to “any”, then goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. h2. From 1.12.0, 1.11.0, 1.10.0, 1.9.2, 1.8.0 No special considerations required, goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. h2. From Other Versions These are untested and should not be attempted in production. h1. Upgrading JVM Only If you are upgrading the JVM only, from a Java 1.8 version prior to TLS 1.3 support you may also need to upgrade Geode. TLS 1.3 was backported to different versions of Java 1.8 by various vendors. OpenJDK backport version is 1.8.0_271. Oracle JDK backport version is 1.8.0_261. For other vendors please refer to their documentation. h2. From 1.14.0-1.14.4, 1.13.0-1.13.8, 1.12.1-1.12.9 You cannot upgrade the JVM without upgrading Geode to 1.15.0. This can be done in a single restart. Goto [Upgrade With New Properties|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.modyy795d4pz]. h2. For 1.12.0, 1.12.0, 1.11.0, 1.10.0, 1.9.2, 1.8.0 No special considerations required, goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. h1. Upgrade Without Migration You have nothing to fear, go ahead and upgrade like normal. h1. Upgrade With New Properties Use the new ssl-client-protocols and ssl-server-protocols properties to configure the client and server side of the SSL connection independently. You will need to add SSLv2Hello to the ssl-server-protocols to account for the misconfiguration of the older members in the cluster. # Shutdown member. # Install new Geode. # Optionally install new Java JDK. # Eliminate security property ssl-protocols from the server’s configuration. # Add security property ssl-client-protocols with the explicit value(s) previously defined in ssl-protocols. For example, if ssl-protocols=TLSv1.2 then ssl-client-protocols=TLSv1.2. # Add security property ssl-server-protocols with the explicit value(s) previously defined in ssl-protocols plus “SSLv2Hello”. For example, if ssl-protocols=TLSv1.2 then ssl-server-protocols=TLSv1.2,SSLv2Hello. # Start member. # Verify successful cluster join. # Repeat from step 1 for the next member. Optionally, after the migration is complete you may restore your original ssl-protocols property and restart all your members to eliminate the SSLv2Hello protocol support from the server side sockets. > SSL protocol and cipher preferences are ignored when endpoint verification is > enabled. > -- > > Key: GEODE-9991 > URL: https://issues.apache.org/jira/browse/GEODE-9991 > Project: Geode > Issue Type: Bug > Components: core, security >Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.15.0 > > > When SSL endpoint verif
[jira] [Resolved] (GEODE-10249) Add stats for BufferPoolMXBean
[ https://issues.apache.org/jira/browse/GEODE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-10249. --- Fix Version/s: 1.15.0 Resolution: Fixed > Add stats for BufferPoolMXBean > -- > > Key: GEODE-10249 > URL: https://issues.apache.org/jira/browse/GEODE-10249 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Java provides information on buffer pools used in the JVM via > BufferPoolMXBean. Add the output of these to the basic set of platform stats > to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10259) Update geode-native library protocol to 1.14
Jacob Barrett created GEODE-10259: - Summary: Update geode-native library protocol to 1.14 Key: GEODE-10259 URL: https://issues.apache.org/jira/browse/GEODE-10259 Project: Geode Issue Type: Improvement Reporter: Jacob Barrett The geode-native library still talks the Geode 1.0.0 protocol, update to at 1.14. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
[
https://issues.apache.org/jira/browse/GEODE-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10254.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> NullPointerException in DistributionLocatorID.marshalForClients()
> -
>
> Key: GEODE-10254
> URL: https://issues.apache.org/jira/browse/GEODE-10254
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
> calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
[
https://issues.apache.org/jira/browse/GEODE-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-10254:
-
Assignee: Jacob Barrett
> NullPointerException in DistributionLocatorID.marshalForClients()
> -
>
> Key: GEODE-10254
> URL: https://issues.apache.org/jira/browse/GEODE-10254
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
> calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
[
https://issues.apache.org/jira/browse/GEODE-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10254:
--
Affects Version/s: 1.14.0
1.13.0
1.12.0
> NullPointerException in DistributionLocatorID.marshalForClients()
> -
>
> Key: GEODE-10254
> URL: https://issues.apache.org/jira/browse/GEODE-10254
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
> calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
Jacob Barrett created GEODE-10254:
-
Summary: NullPointerException in
DistributionLocatorID.marshalForClients()
Key: GEODE-10254
URL: https://issues.apache.org/jira/browse/GEODE-10254
Project: Geode
Issue Type: Bug
Affects Versions: 1.15.0
Reporter: Jacob Barrett
When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10249) Add stats for BufferPoolMXBean
[ https://issues.apache.org/jira/browse/GEODE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett reassigned GEODE-10249: - Assignee: Jacob Barrett > Add stats for BufferPoolMXBean > -- > > Key: GEODE-10249 > URL: https://issues.apache.org/jira/browse/GEODE-10249 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > > Java provides information on buffer pools used in the JVM via > BufferPoolMXBean. Add the output of these to the basic set of platform stats > to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10249) Add stats for BufferPoolMXBean
Jacob Barrett created GEODE-10249: - Summary: Add stats for BufferPoolMXBean Key: GEODE-10249 URL: https://issues.apache.org/jira/browse/GEODE-10249 Project: Geode Issue Type: Improvement Reporter: Jacob Barrett Java provides information on buffer pools used in the JVM via BufferPoolMXBean. Add the output of these to the basic set of platform stats to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-8228) CI Failure: SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions
[ https://issues.apache.org/jira/browse/GEODE-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-8228. -- Fix Version/s: 1.15.0 Resolution: Fixed > CI Failure: SerialWANStatsDUnitTest > > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions > --- > > Key: GEODE-8228 > URL: https://issues.apache.org/jira/browse/GEODE-8228 > Project: Geode > Issue Type: Test > Components: ci, wan >Affects Versions: 1.14.0 >Reporter: Ernest Burghardt >Assignee: Jacob Barrett >Priority: Major > Labels: caching-applications, pull-request-available > Fix For: 1.15.0 > > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/247#A] > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-results/distributedTest/1591318846/ > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Test report artifacts from this job are available at: > > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-artifacts/1591318846/distributedtestfiles-OpenJDK8-1.14.0-build.0115.tgz -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10127.
---
Resolution: Fixed
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-8228) CI Failure: SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions
[ https://issues.apache.org/jira/browse/GEODE-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett reassigned GEODE-8228: Assignee: Jacob Barrett > CI Failure: SerialWANStatsDUnitTest > > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions > --- > > Key: GEODE-8228 > URL: https://issues.apache.org/jira/browse/GEODE-8228 > Project: Geode > Issue Type: Test > Components: ci, wan >Affects Versions: 1.14.0 >Reporter: Ernest Burghardt >Assignee: Jacob Barrett >Priority: Major > Labels: caching-applications > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/247#A] > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-results/distributedTest/1591318846/ > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Test report artifacts from this job are available at: > > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-artifacts/1591318846/distributedtestfiles-OpenJDK8-1.14.0-build.0115.tgz -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8228) CI Failure: SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions
[ https://issues.apache.org/jira/browse/GEODE-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-8228: - Affects Version/s: 1.14.0 > CI Failure: SerialWANStatsDUnitTest > > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions > --- > > Key: GEODE-8228 > URL: https://issues.apache.org/jira/browse/GEODE-8228 > Project: Geode > Issue Type: Test > Components: ci, wan >Affects Versions: 1.14.0 >Reporter: Ernest Burghardt >Priority: Major > Labels: caching-applications > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/247#A] > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-results/distributedTest/1591318846/ > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Test report artifacts from this job are available at: > > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-artifacts/1591318846/distributedtestfiles-OpenJDK8-1.14.0-build.0115.tgz -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reopened GEODE-10127:
---
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10127.
---
Resolution: Fixed
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10200) [CI Failure] : SocketCreatorUpgradeTest > upgradingToNewGeodeAndNewJavaWithProtocolsAny[1.14.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10200.
---
Resolution: Cannot Reproduce
Ran 100 times without reproduction.
> [CI Failure] : SocketCreatorUpgradeTest >
> upgradingToNewGeodeAndNewJavaWithProtocolsAny[1.14.0] FAILED
> ---
>
> Key: GEODE-10200
> URL: https://issues.apache.org/jira/browse/GEODE-10200
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
>
> {code:java}
> SocketCreatorUpgradeTest >
> upgradingToNewGeodeAndNewJavaWithProtocolsAny[1.14.0] FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [1fa9fcaebd8c018e: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator2
> --bind-address=heavy-lifter-5c2a1d0b-5930-5788-97d6-3ca24d2f026a.c.apachegeode-ci.internal
> --port=21172 --J=-Dgemfire.jmx-manager-port=21173
> --security-properties-file=/tmp/junit1876902159761664930/junit7901411307157053608.tmp
>
> --locators=heavy-lifter-5c2a1d0b-5930-5788-97d6-3ca24d2f026a.c.apachegeode-ci.internal[21170]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:133)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsAny(SocketCreatorUpgradeTest.java:450)
> {code}
> In the logs we can see that there are a lot SSLv2Hello not supported errors.
> {code:java}
> [warn 2022/03/30 11:49:45.067 UTC locator2
> tid=0x38] SSL handshake exception
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled
> at
> sun.security.ssl.SSLEngineInputRecord.handleUnknownRecord(SSLEngineInputRecord.java:366)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:193)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
> at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:575)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:531)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:398)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:377)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:147)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:436)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1775)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1563)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1500)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748) {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9105) Remove transient allocations of SerializationContextImpl
[ https://issues.apache.org/jira/browse/GEODE-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-9105. -- Resolution: Won't Fix > Remove transient allocations of SerializationContextImpl > > > Key: GEODE-9105 > URL: https://issues.apache.org/jira/browse/GEODE-9105 > Project: Geode > Issue Type: Improvement > Components: serialization >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > > This object is allocated multiple times per execution of pretty much any > operation. The object doesn't vary much between allocations and is mostly a > grouping up stack variables. I believe the intent was to add properties to > this context over time without changing the method signature for > serialization with each release. Given this pattern of use I think it makes > sense to implement a flyweight pattern here. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9991:
-
Labels: blocks-1.15.0 pull-request-available ssl (was: blocks-1.15.0
pull-request-available)
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Labels: blocks-1.15.0 pull-request-available ssl (was: blocks-1.15.0
pull-request-available)
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan
[jira] [Updated] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10127:
--
Fix Version/s: 1.15.0
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10122: -- Labels: blocks-1.15.0 pull-request-available ssl (was: blocks-1.15.0 pull-request-available) > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.13.7, 1.14.3, 1.15.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0
blocks-1.15.0 pull-request-available)
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.inte
[jira] [Updated] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10127:
--
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0
needsTriage pull-request-available)
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10122: -- Labels: blocks-1.15.0 pull-request-available (was: pull-request-available) > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.13.7, 1.14.3, 1.15.0, 1.16.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10127:
--
Labels: blocks-1.15.0 needsTriage (was: needsTriage)
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Labels: blocks-1.15.0 blocks-1.15.0 pull-request-available (was:
blocks-1.15.0 pull-request-available)
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Labels: blocks-1.15.0 pull-request-available (was: pull-request-available)
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan.AbstractGatew
[jira] [Commented] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507720#comment-17507720
]
Jacob Barrett commented on GEODE-10127:
---
The change from toString to marshal results in the loss of
{{hostname-for-clients}} or {{bind-address}} as the name sent remotely. This
change had no tests associated with it. All current tests affected by this bug
don't fail because we don't don't do any multi-homed or split-horizon DNS
testing.
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-10127:
-
Assignee: Jacob Barrett
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10127) Incorrect locator hostname used in remote locator connections
Jacob Barrett created GEODE-10127:
-
Summary: Incorrect locator hostname used in remote locator
connections
Key: GEODE-10127
URL: https://issues.apache.org/jira/browse/GEODE-10127
Project: Geode
Issue Type: Bug
Components: wan
Affects Versions: 1.15.0, 1.16.0
Reporter: Jacob Barrett
When locators in distributed system (DS) B as for locators in DS A they are
sent the local host name and IP address of the locators and not that of the
{{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (GEODE-10113) CI: AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions() FAILED
[ https://issues.apache.org/jira/browse/GEODE-10113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett closed GEODE-10113. - > CI: > AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions() > FAILED > -- > > Key: GEODE-10113 > URL: https://issues.apache.org/jira/browse/GEODE-10113 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > > Task :geode-core:test > AutoConnectionSourceImplTest > queryLocatorsTriesNextLocatorOnSSLExceptions() > FAILED > java.lang.AssertionError: > Expecting actual: > Mock for ServerLocationResponse, hashCode: 186159903 > and actual: > null > to refer to the same object > at > org.apache.geode.cache.client.internal.AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions(AutoConnectionSourceImplTest.java:91) > 7320 tests completed, 1 failed, 11 skipped > It's found in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/187 > It's said to be similar to GEODE-10066 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10113) CI: AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions() FAILED
[ https://issues.apache.org/jira/browse/GEODE-10113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-10113. --- Resolution: Fixed > CI: > AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions() > FAILED > -- > > Key: GEODE-10113 > URL: https://issues.apache.org/jira/browse/GEODE-10113 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > > Task :geode-core:test > AutoConnectionSourceImplTest > queryLocatorsTriesNextLocatorOnSSLExceptions() > FAILED > java.lang.AssertionError: > Expecting actual: > Mock for ServerLocationResponse, hashCode: 186159903 > and actual: > null > to refer to the same object > at > org.apache.geode.cache.client.internal.AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions(AutoConnectionSourceImplTest.java:91) > 7320 tests completed, 1 failed, 11 skipped > It's found in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/187 > It's said to be similar to GEODE-10066 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8217) Geode session replication could leak internal serialized bytes during HttpSessionAttributeListener invocation even when preferDeserializedForm is set to true
[
https://issues.apache.org/jira/browse/GEODE-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-8217:
-
Affects Version/s: 1.14.0
1.13.0
1.12.0
> Geode session replication could leak internal serialized bytes during
> HttpSessionAttributeListener invocation even when preferDeserializedForm is
> set to true
> -
>
> Key: GEODE-8217
> URL: https://issues.apache.org/jira/browse/GEODE-8217
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: caching-applications
> Fix For: 1.12.2, 1.13.3, 1.14.0
>
>
> When preferDeserializedForm is set to true (default value), session object
> should not contain serialized byte in the cache. However, the following
> exception shows that product leaks the serialized bytes.
> {noformat}
> Jun 02, 2020 3:31:58 PM org.apache.catalina.session.StandardSession
> setAttribute
> SEVERE: Session attribute event listener threw exception
> java.lang.ClassCastException: [B cannot be cast to java.lang.String
> at
> org.apache.geode.modules.session.AccessAttributeValueListener.attributeReplaced(AccessAttributeValueListener.java:34)
> at
> org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1482)
> at
> org.apache.geode.modules.session.catalina.DeltaSession.setAttribute(DeltaSession.java:262)
> at
> org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1385)
> at
> org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:137)
> at
> org.apache.geode.modules.session.catalina.DeltaSessionFacade.setAttribute(DeltaSessionFacade.java:49)
> at
> org.apache.geode.modules.session.CommandServlet.doGet(CommandServlet.java:64)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:47)
> at
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:45)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:609)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:810)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623)
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Please note if preferDeserializedForm is set to false, this issue could still
> exist, unless HttpSessionBindingEvent.getValue() is not being accessed by the
> application. Otherwise, user should set preferDeserializ
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Fix Version/s: 1.16.0
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySen
[jira] [Updated] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9991:
-
Fix Version/s: 1.16.0
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0,
> 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17501477#comment-17501477
]
Jacob Barrett commented on GEODE-9991:
--
More changes, specifically documentation of the new properties and upgrade
procedures are forthcoming. Back ports to older releases may also be necessary.
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0,
> 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10082) Duplicate values found in DSCode enums
[ https://issues.apache.org/jira/browse/GEODE-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10082: -- Fix Version/s: 1.16.0 (was: 1.15.0) > Duplicate values found in DSCode enums > -- > > Key: GEODE-10082 > URL: https://issues.apache.org/jira/browse/GEODE-10082 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > The following snippet appears in DSCode.hpp: > ``` > CacheableEnum = 94, > ClientProxyMembershipId = 38, > CacheableUserData = 39, > CacheableUserData2 = 38, > CacheableUserData4 = 37, > PDX = 93, > PDX_ENUM = 94, > InterestResultPolicy = 37, > }; > ``` > `CacheableEnum` is the name of the class that geode-native uses for > `PDX_ENUM`, it should not exist as an enum value. `ClientProxyMembershipId`, > `InternalDistributedMember`, and `InterestResultPolicy` are > `DataSerializableFixedId` values, and belong in that enum rather than DSCode. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-10093. --- Resolution: Fixed > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10093: -- Fix Version/s: 1.12.9 1.13.8 1.14.4 > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10093: -- Fix Version/s: 1.15.0 1.16.0 > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[
https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499694#comment-17499694
]
Jacob Barrett commented on GEODE-10093:
---
Changes made in GEODE-8217 exposed incorrect handling of {{null}} values in
{{DeltaSession.setAttribute}}.
> DeltaSession getAttribute method logs an NPE and returns unserialized value
> when called on attribute with null value
>
>
> Key: GEODE-10093
> URL: https://issues.apache.org/jira/browse/GEODE-10093
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0
>Reporter: Benjamin P Ross
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> Under certain circumstances, a null value can be set for an attribute which
> then throws an NPE when trying to add it to the local map during a
> getAttribute call on the session. Prior to 1.12.2 we were responding to this
> by removing the entry entirely from the local map which is consistent with
> what the base Session class for Catalina does, but starting with 1.12.2
> onward this results in an error message being displayed and the serialized
> value being returned rather than the unserialized value.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10093: -- Affects Version/s: 1.14.0 1.13.3 1.12.2 1.16.0 (was: 1.12.7) (was: 1.13.7) (was: 1.14.3) > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10082) Duplicate values found in DSCode enums
[ https://issues.apache.org/jira/browse/GEODE-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett reassigned GEODE-10082: - Assignee: Jacob Barrett > Duplicate values found in DSCode enums > -- > > Key: GEODE-10082 > URL: https://issues.apache.org/jira/browse/GEODE-10082 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > The following snippet appears in DSCode.hpp: > ``` > CacheableEnum = 94, > ClientProxyMembershipId = 38, > CacheableUserData = 39, > CacheableUserData2 = 38, > CacheableUserData4 = 37, > PDX = 93, > PDX_ENUM = 94, > InterestResultPolicy = 37, > }; > ``` > `CacheableEnum` is the name of the class that geode-native uses for > `PDX_ENUM`, it should not exist as an enum value. `ClientProxyMembershipId`, > `InternalDistributedMember`, and `InterestResultPolicy` are > `DataSerializableFixedId` values, and belong in that enum rather than DSCode. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17497043#comment-17497043
]
Jacob Barrett commented on GEODE-10066:
---
As it relates to tests trying to detect locators without SSL enabled connecting
to locators with SSL connecting the SSL layer will respond to anything that is
not a {{ClientHello}} with an {{Alert}}. The formatting of this {{Alert}}
appears to Geode as serialization of the literal type {{Class}}, byte
value 0x15 (21), followed by unparsed payload bytes. The initial request
attempts to then cast {{Class}} to {{VersionResponse}}. Perhaps there
is a more efficient and accurate way to detect this configuration error.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.Gatewa
[jira] [Commented] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17497027#comment-17497027
]
Jacob Barrett commented on GEODE-10066:
---
Usage of `IllegalThreadStateException` and `IllegalStateException` added in
this enhancement.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.g
[jira] [Commented] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496963#comment-17496963
]
Jacob Barrett commented on GEODE-10066:
---
Changes for this enhancement resulted in the introduction of the unchecked
{{LocatorCancelException}}.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org
[jira] [Commented] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496962#comment-17496962
]
Jacob Barrett commented on GEODE-10066:
---
Changes made for GEODE-1793 introduced the {{IllegalStateException}} but the
original {{LocatorCancelException}} is also unchecked an results in similar
issues.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemotePa
[jira] [Commented] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496959#comment-17496959
]
Jacob Barrett commented on GEODE-10066:
---
Partially corrected in GEODE-7917 but only for the {{EOFException}} condition.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.ca
[jira] [Commented] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496480#comment-17496480
]
Jacob Barrett commented on GEODE-10066:
---
This issue was introduced prior to v1.0.0.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventPr
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Affects Version/s: 1.12.9
1.13.8
1.14.4
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.set
[jira] [Assigned] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-10066:
-
Assignee: Jacob Barrett
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Affects Version/s: 1.15.0
1.16.0
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.Abst
[jira] [Created] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
Jacob Barrett created GEODE-10066:
-
Summary: SSL handshake failures on 1 locator prevents connection
pool from trying other locators
Key: GEODE-10066
URL: https://issues.apache.org/jira/browse/GEODE-10066
Project: Geode
Issue Type: Bug
Components: client/server
Reporter: Jacob Barrett
If an {{SSLException}} is thrown when handshaking with a locator the exception
is wrapped in an {{IllegalStateException}} that is not caught by the connection
pool, the stack is blown, and no connections can be established. If not wrapped
the connection pool will properly try the next locator.
The {{SSLExceptions}} are wrapped in at least {{TcpClient.getServerVersion()}}
but other locations may exist in this path. This method throws {{IOException}}
and the {{SSLExceptions}} extend {{IOExceptions}} so they should not be
wrapped. It probably makes sense to split the concern of socket connection from
determining the server version in {{TcpClient.getServerVersion()}}.
{noformat}
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
No subject alternative names matching IP address 10.2.8.12 found
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
at
org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
at
org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
at
org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
at
org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1081)
Caused by: java.security.cert.CertificateException: No subject alternative
names matching IP address 10.2.8.12 found
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
at
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java
[jira] [Updated] (GEODE-10031) Can't stop embedded locator when SSL endpoint validation is enabled.
[
https://issues.apache.org/jira/browse/GEODE-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10031:
--
Priority: Minor (was: Major)
> Can't stop embedded locator when SSL endpoint validation is enabled.
>
>
> Key: GEODE-10031
> URL: https://issues.apache.org/jira/browse/GEODE-10031
> Project: Geode
> Issue Type: Bug
> Components: jmx, locator, security
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: needsTriage
>
> When {{ssl-endpoint-identifcation-enable=true}} an embedded locator,
> typically used in testing, can't be stopped. The hostname the client side of
> the SSL connection tries to validate is `0.0.0.0`, which of course won't be
> in the certificate SAN tries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10031) Can't stop embedded locator when SSL endpoint validation is enabled.
[
https://issues.apache.org/jira/browse/GEODE-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10031:
--
Component/s: tests
> Can't stop embedded locator when SSL endpoint validation is enabled.
>
>
> Key: GEODE-10031
> URL: https://issues.apache.org/jira/browse/GEODE-10031
> Project: Geode
> Issue Type: Bug
> Components: jmx, locator, security, tests
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: needsTriage
>
> When {{ssl-endpoint-identifcation-enable=true}} an embedded locator,
> typically used in testing, can't be stopped. The hostname the client side of
> the SSL connection tries to validate is `0.0.0.0`, which of course won't be
> in the certificate SAN tries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10031) Can't stop embedded locator when SSL endpoint validation is enabled.
Jacob Barrett created GEODE-10031:
-
Summary: Can't stop embedded locator when SSL endpoint validation
is enabled.
Key: GEODE-10031
URL: https://issues.apache.org/jira/browse/GEODE-10031
Project: Geode
Issue Type: Bug
Components: jmx, locator, security
Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
Reporter: Jacob Barrett
When {{ssl-endpoint-identifcation-enable=true}} an embedded locator, typically
used in testing, can't be stopped. The hostname the client side of the SSL
connection tries to validate is `0.0.0.0`, which of course won't be in the
certificate SAN tries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10015.
---
Resolution: Fixed
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10015:
--
Fix Version/s: 1.15.0
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10015:
--
Fix Version/s: 1.16.0
(was: 1.15.0)
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10015:
--
Fix Version/s: 1.15.0
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488296#comment-17488296
]
Jacob Barrett commented on GEODE-9991:
--
Changes in GEODE-10015 are needed to complete JDK upgrade testing.
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0,
> 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9991:
-
Affects Version/s: 1.12.8
1.12.9
1.13.8
1.14.4
1.16.0
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0,
> 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487386#comment-17487386
]
Jacob Barrett commented on GEODE-10015:
---
RMI defaults to using the local IP address rather than hostname. It has a
System Property, {{java.rmi.server.hostname}}, which allows you to override an
set a specific hostname. We set this property to the value of
{{jmx-manager-hostname-for-clients}}, if it is set. Adjusting the logic such
that when {{jmx-manager-hostname-for-clients}} is not set then we to set
{{java.rmi.server.hostname}} to the {{jmx-manager-bind-address}}, if set, or
the local hostname when SSL is enabled corrects this problem.
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487327#comment-17487327
]
Jacob Barrett commented on GEODE-10015:
---
This issue was introduced in
[55921a4d7b66a51279e71d1a665dc797fcc8ca6f|https://github.com/apache/geode/commit/55921a4d7b66a51279e71d1a665dc797fcc8ca6f].
When {{SocketCreator}} would configuration the SNI entries it used to convert
IP addresses into canonical host names. This was removed to better support
managed environments with strict usage of bind addresses. Restoring this
behavior might introduce other issues in these scenarios.
The IP address seems to be coming the RMI registry. The solution will require
fixing how those entries are created so they use the bind address of the JXM
service.
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10015:
--
Description:
When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
address of the locator in the SNI header rather than the hostname. This results
in a certificate validation failure when the IP is not found in the SAN
entries.
Version 1.14.3 sends the correct hostname in the SNI. Something changed between
1.14.3 and now.
Reproduction:
{noformat}
gfsh -e version --full -e start locator --name=locator2
--bind-address=myhost.example.com --port=20005
--J=-Dgemfire.jmx-manager-port=20007
--security-properties-file=/path/to/security.properties --http-service-port=0
--locators=myhost.example.com[20004]
(1) Executing - version --full
...
Product-Version: 1.16.0-build.0
...
(2) Executing - start locator --name=locator2
--bind-address=myhost.example.com --port=20005
--J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
--http-service-port=0 --locators=myhost.example.com[20004]
...
[fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
connection to /192.168.68.56[20007].
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
No subject alternative names matching IP address 192.168.68.56 found
...
Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
currently online.
...
Unable to auto-connect (Security Manager may be enabled). Please use "connect
--locator=myhost.example.com[20005]" to connect Gfsh to the locator.
SSL configuration required to connect to the Manager.
Failed to connect; unknown cause: error during JRMP connection establishment;
nested exception is:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
{noformat}
Where {{/path/to/security.properties}} contains:
{noformat}
ssl-require-authentication=true
ssl-keystore=/path/to/keystore.jks
ssl-truststore-type=jks
ssl-keystore-password=password
ssl-truststore=/path/to/truststore.jks
ssl-enabled-components=all
ssl-truststore-password=password
ssl-protocols=any
ssl-endpoint-identification-enabled=true
ssl-keystore-type=jks
{noformat}
The certificate used in the key store is singed by a fake CA and contains only
the hostname, {{myhost.example.com}}. The trust store contains the fake CA.
was:
When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
address of the locator in the SNI header rather than the hostname. This results
in a certificate validation failure when the IP is not found in the SAN
entries.
Version 1.14.3 sends the correct hostname in the SNI. Something changed between
1.14.3 and now.
> gfsh sends does not send hostname in SNI header
> ---
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: needsTriage
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> n
[jira] [Created] (GEODE-10015) gfsh sends does not send hostname in SNI header
Jacob Barrett created GEODE-10015:
-
Summary: gfsh sends does not send hostname in SNI header
Key: GEODE-10015
URL: https://issues.apache.org/jira/browse/GEODE-10015
Project: Geode
Issue Type: Bug
Components: gfsh, jmx
Affects Versions: 1.15.0, 1.16.0
Reporter: Jacob Barrett
When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
address of the locator in the SNI header rather than the hostname. This results
in a certificate validation failure when the IP is not found in the SAN
entries.
Version 1.14.3 sends the correct hostname in the SNI. Something changed between
1.14.3 and now.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10015:
--
Priority: Blocker (was: Major)
> gfsh sends does not send hostname in SNI header
> ---
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: needsTriage
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483257#comment-17483257
]
Jacob Barrett commented on GEODE-9991:
--
It looks like some of this overwriting was introduced by GEODE-8419.
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.13.7, 1.14.3, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
Jacob Barrett created GEODE-9991:
Summary: SSL protocol and cipher preferences are ignored when
endpoint verification is enabled.
Key: GEODE-9991
URL: https://issues.apache.org/jira/browse/GEODE-9991
Project: Geode
Issue Type: Bug
Components: core, security
Affects Versions: 1.14.3, 1.13.7, 1.15.0
Reporter: Jacob Barrett
When SSL endpoint verification is enabled the configuration for protocols and
ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
in difficulty upgrade the JDK when the newer JDK may use different defaults for
client and server mode SSL.
Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
with a back port from Java 11. This changed the default server protocols from
{{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols get
reset to the client protocols dropping support for the {{SSLv2Hello}} protocol,
which is the first priority protocol by default in the old JDK.
The result is a failure to handshake with the following exception:
{{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
To reproduce you need to have endpoint validation enabled on your SSL
configuration. Set your protocols to `any`. Start 1st locator with JDK older
than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-9991:
Assignee: Jacob Barrett
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.13.7, 1.14.3, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9982) Native clients older than 1.15 fail to read longer version ordinal from 1.15 servers.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9982:
-
Attachment: GEODE-9982.patch
> Native clients older than 1.15 fail to read longer version ordinal from 1.15
> servers.
> -
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.12.8, 1.13.7, 1.14.0, 1.14.1, 1.14.2, 1.14.3, 1.14.4
>Reporter: Jacob Barrett
>Priority: Critical
> Attachments: GEODE-9982.patch
>
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9982) Native clients older than 1.15 fail to read longer version ordinal from 1.15 servers.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481484#comment-17481484
]
Jacob Barrett commented on GEODE-9982:
--
Unlike the Java clients, which when released, match the server version ordinal,
the native library has not increased it's protocol version since Geode 1.0.0.
This means one could just upgrade to the Geode Native 1.15 client prior to
upgrading the servers to manage upgrades.
> Native clients older than 1.15 fail to read longer version ordinal from 1.15
> servers.
> -
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.12.8, 1.13.7, 1.14.0, 1.14.1, 1.14.2, 1.14.3, 1.14.4
>Reporter: Jacob Barrett
>Priority: Critical
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9982) Native clients older than 1.15 fail to read longer version ordinal from 1.15 servers.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9982:
-
Summary: Native clients older than 1.15 fail to read longer version ordinal
from 1.15 servers. (was: Native clients older than 1.15 fail do decode longer
version ordinal from 1.15 servers.)
> Native clients older than 1.15 fail to read longer version ordinal from 1.15
> servers.
> -
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.12.8, 1.13.7, 1.14.0, 1.14.1, 1.14.2, 1.14.3, 1.14.4
>Reporter: Jacob Barrett
>Priority: Critical
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9982) Native clients older than 1.15 fail do decode longer version ordinal from 1.15 servers.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9982:
-
Summary: Native clients older than 1.15 fail do decode longer version
ordinal from 1.15 servers. (was: Backwards compatibility failure between older
C++ client and newer server.)
> Native clients older than 1.15 fail do decode longer version ordinal from
> 1.15 servers.
> ---
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.12.8, 1.13.7, 1.14.0, 1.14.1, 1.14.2, 1.14.3, 1.14.4
>Reporter: Jacob Barrett
>Priority: Critical
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9982) Backwards compatibility failure between older C++ client and newer server.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9982:
-
Affects Version/s: 1.14.2
1.14.1
1.13.7
1.12.8
1.14.3
1.14.4
(was: 1.15.0)
> Backwards compatibility failure between older C++ client and newer server.
> --
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.12.8, 1.13.7, 1.14.0, 1.14.1, 1.14.2, 1.14.3, 1.14.4
>Reporter: Jacob Barrett
>Priority: Critical
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9982) Backwards compatibility failure between older C++ client and newer server.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9982:
-
Priority: Critical (was: Blocker)
> Backwards compatibility failure between older C++ client and newer server.
> --
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Critical
> Labels: blocks-1.15.0
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9982) Backwards compatibility failure between older C++ client and newer server.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9982:
-
Labels: (was: blocks-1.15.0)
> Backwards compatibility failure between older C++ client and newer server.
> --
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Critical
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9982) Backwards compatibility failure between older C++ client and newer server.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481438#comment-17481438
]
Jacob Barrett commented on GEODE-9982:
--
Since the issue isn't in 1.15 and no change could be made to 1.15 to address
older clients I am going to remove the blocker and adjust the versions affected.
> Backwards compatibility failure between older C++ client and newer server.
> --
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9982) Backwards compatibility failure between older C++ client and newer server.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481436#comment-17481436
]
Jacob Barrett commented on GEODE-9982:
--
The issue was introduced about 4 years ago but only manifests now that the
server's ordinal value is 2 bytes long. The statement to read the short value
was omitted by logging guard embedded in a macro. This patch will need to be
applied to any previous version of Geode Native we want to support server
upgrades beyond 1.14.0. Any version of Geode that has any version ordinal
greater than 127 will result in this short read error.
It is also very interesting that this issue only affected these transaction
tests and not other tests that likely transmit the member id.
> Backwards compatibility failure between older C++ client and newer server.
> --
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9982) Backwards compatibility failure between older C++ client and newer server.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480713#comment-17480713
]
Jacob Barrett commented on GEODE-9982:
--
[~bbender] has tracked the native change in develop where the tests start
working again to PR [#737|https://github.com/apache/geode-native/pull/737].
Before this change the client can't talk to develop/1.15 servers and after the
change it can. This change was part of
[GEODE-8837|https://issues.apache.org/jira/browse/GEODE-8837], which was an
effort to drop support for obsolete versions of the protocol that pre-dated
Geode. It looks like the native client was using an older handshake method that
predated Geode to communicate a Geode version number. Changes in the server to
only support the handshake version expected for the supported versions may have
broken the native client's ability to correctly communicate its version. Oddly
enough operations all except for {{TXCommitMessage}} seem to work for the older
version.
I will investigate what effort is needed for the server to support that older
handshake method so that pre-1.15 versions of native client can work with post
1.15 servers as expected. If we can get this change into the server prior to
1.15's release we should not need to patch older releases of native client to
support newer servers.
> Backwards compatibility failure between older C++ client and newer server.
> --
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Blocker
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9982) Backwards compatibility failure between older C++ client and newer server.
[
https://issues.apache.org/jira/browse/GEODE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480347#comment-17480347
]
Jacob Barrett commented on GEODE-9982:
--
The message it is trying to decode is {{DataSerializableFixedId}} 110, aka
{{TXCommitMessage}}.
> Backwards compatibility failure between older C++ client and newer server.
> --
>
> Key: GEODE-9982
> URL: https://issues.apache.org/jira/browse/GEODE-9982
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Blocker
>
> Geode Native C++ client v1.14.0 fails execution of
> testThinClientTransactionsWithoutSticky against current develop branch
> server. C++ client v1.14.0 does not fail when talking to a v1.14.0 server.
> Current develop branch C++ client does not fail when talking to a develop
> branch server. It appears there may be a protocol incompatibly issue between
> these two versions. More investigations to narrow down the version matrix is
> necessary.
> The following error is logged when the test fails:
> {{Error during send for endpoint 192.168.68.56:18539 due to
> apache::geode::client::IllegalStateException: Unregistered type in
> deserialization}}
> ||Server Versions|1.14.0|1.15.0|
> ||Client Versions||
> |1.14.0|P|F|
> |1.15.0|-|P|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
