[jira] [Commented] (GEODE-10004) Starting server should fail fast when server port and redis port are the same
[
https://issues.apache.org/jira/browse/GEODE-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489982#comment-17489982
]
ASF GitHub Bot commented on GEODE-10004:
pivotal-jbarrett commented on a change in pull request #917:
URL: https://github.com/apache/geode-native/pull/917#discussion_r803341661
##
File path: CMakeLists.txt
##
@@ -61,6 +61,7 @@ set(PRODUCT_BUILDDATE "1970-01-01" CACHE STRING "Product
build date")
set(PRODUCT_SOURCE_REVISION "" CACHE
STRING "Product source SHA")
set(PRODUCT_SOURCE_REPOSITORY "" CACHE STRING "Product source
branch")
set(PRODUCT_BITS "${BUILD_BITS}bit")
+set(GEODE_AUTHEXPIREDEXCEPTION_VERSION "1.15.0-build.546" CACHE STRING "First
build containing AuthenticationExpiredException")
Review comment:
Why not just test for the existence of the exception class or not and
set a "has feature" type flag?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Starting server should fail fast when server port and redis port are the same
> -
>
> Key: GEODE-10004
> URL: https://issues.apache.org/jira/browse/GEODE-10004
> Project: Geode
> Issue Type: Bug
> Components: gfsh, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> When starting a cluster with GFSH with geode-for-redis enabled, starting a
> server fails when the geode-for-redis-port and server-port are set to the
> same port. It fails with the below stacktrace, but does not fail fast. We
> should be able to detect this issue before we reach the point of getting a
> bind exception.
> stacktrace:
> {code:java}
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred
> while starting a Server in /Users/hbales/workspace/geode/itch-proud-alpha on
> hbales-a01.vmware.com[6379]: Failed to create server socket on
> 192.168.0.4[6379]
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:863)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:258)
> Caused by: java.net.BindException: Failed to create server socket on
> 192.168.0.4[6379]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:522)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:573)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:291)
> at
> org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:420)
> at
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:377)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:1039)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:837)
> ... 2 more
> Caused by: java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 10 more
> {code}
> series of GFSH commands that led to this error:
> {code:java}
> > start locator
> > start server --J=-Dgemfire.geode-for-redis-enabled=true
> > --J=-Dgemfire.geode-for-redis-port=6379 --server-port=6379
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
Udo Kohlmeyer created GEODE-10038:
-
Summary: Trying to access the QueryService results in NPE on
server restart from deployed Jar
Key: GEODE-10038
URL: https://issues.apache.org/jira/browse/GEODE-10038
Project: Geode
Issue Type: Bug
Components: functions
Affects Versions: 1.14.3, 1.13.7, 1.12.8, 1.15.0
Reporter: Udo Kohlmeyer
After deploying a jar which contains a Function, restarting the server causes
an NPE.
Using the Function definition of:
{code:java}
public class CustomFunction implements Function {
private GemFireCache cache;
private QueryService queryService;
public CustomFunction() {
this.cache = CacheFactory.getAnyInstance();
this.queryService = cache.getQueryService();
}
{code}
Due to the startup flow
https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
the registration of Functions are initialized from cluster configuration
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
There is a dependency on the `QueryService` to be available at Function
construction time, but given that the services are only initialized
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
the call to the `cache.getQueryService` fails with an NPE
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10038:
--
Labels: (was: needsTriage)
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10038:
--
Labels: needsTriage (was: )
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: needsTriage
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489937#comment-17489937
]
Owen Nichols commented on GEODE-10005:
--
yup, that is exactly the reason why we're still on Jetty 9...
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10005:
-
Parent: GEODE-10003
Issue Type: Sub-task (was: Improvement)
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489918#comment-17489918
]
Udo Kohlmeyer commented on GEODE-10005:
---
[~jblum] currently Apache Geode has a baseline of JDK8, from we've not decided
to move from yet. Given that Jetty 10.x and 11.x has a baseline of JDK11, there
is no way for Apache Geode to use the newer Jetty version until we move the JDK
baseline to at least JDK 11+.
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Priority: Minor (was: Major) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Minor > Labels: needsTriage > > See GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Issue Type: Improvement (was: Bug) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Summary: Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API (was: Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API) > Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, > public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Description: See GEODE-10007. (was: See GEODE-) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-10037: -- Summary: Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API (was: Make o.a.g.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10037: -- Labels: needsTriage (was: ) > Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of > the non-internal, public API > -- > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10037) Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API
John Blum created GEODE-10037: - Summary: Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API Key: GEODE-10037 URL: https://issues.apache.org/jira/browse/GEODE-10037 Project: Geode Issue Type: Bug Affects Versions: 1.14.3 Reporter: John Blum See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489898#comment-17489898
]
John Blum edited comment on GEODE-10036 at 2/10/22, 1:23 AM:
-
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of {{--add-opens}} JVM options are not an
acceptable alternative to proper Java module configuration.
was (Author: jblum):
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of the JVM {{--add-opens}} option is not an
acceptable alternative to proper Java module configuration.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByte
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Priority: Minor (was: Critical)
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Minor
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489898#comment-17489898
]
John Blum edited comment on GEODE-10036 at 2/10/22, 1:22 AM:
-
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
It should be noted that the use of the JVM {{--add-opens}} option is not an
acceptable alternative to proper Java module configuration.
was (Author: jblum):
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.la
[jira] [Commented] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489900#comment-17489900
]
John Blum commented on GEODE-10035:
---
You may wonder why I needed to set this System property at all; GEODE-10036 is
the reason.
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489899#comment-17489899
]
John Blum commented on GEODE-10036:
---
This was related to GEODE-10035.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10036:
--
Priority: Critical (was: Major)
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489898#comment-17489898
]
John Blum commented on GEODE-10036:
---
While it should be technically possible to still run and join Locators in a
cluster by setting the appropriate JVM options (e.g. {{--add-opens
java.base/java.nio=ALL_UNNAMED}}), I was unsuccessful in doing so. I am not
sure why in this case as I was successfully adding open options while running
other Apache Geode processes based on my use cases and scenarios.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10036:
--
Labels: needsTriage (was: )
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
John Blum created GEODE-10036:
-
Summary: Joining Locators in a cluster is not possible on Java 17
Key: GEODE-10036
URL: https://issues.apache.org/jira/browse/GEODE-10036
Project: Geode
Issue Type: Bug
Affects Versions: 1.14.3
Reporter: John Blum
When trying to add multiple _Locators_ to the same cluster, particularly when
"_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
{code:java}
Caused by: org.apache.geode.SystemConnectException: One or more peers generated
exceptions during connection attempt
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
at
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
at
org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
... 44 more
Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
underlying byte buffer
at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
at
org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
at
org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
at
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
at
org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
... 56 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make public
java.lang.Object java.nio.DirectByteBuffer.attachment() accessible: module
java.base does not "opens java.nio" to unnamed module @2e0fa5d3
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at
java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
... 69 more
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Issue Type: Bug (was: Improvement)
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should be created on the
JVM Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
property is not set at all (which results in {{Boolean.getBoolean(..)}}
returning {{false}}), which negated results in the OR'd condition not even
being evaluated!
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should be created on the
JVM Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
>
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Priority: Critical (was: Major)
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should be created on the
JVM Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
Alternatively:
{code:java}
public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers")
&&
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should created on the
> JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useH
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
That is, if either the "{{p2p.nodirectBuffers}}" OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO
NOT USE direct ByteBuffers.
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should created on the
> JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10035:
--
Description:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read (formatted to make it more readable):
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read:
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> The term "{{useHeapBuffers}}" implies that the buffer should created on the
> JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
John Blum created GEODE-10035:
-
Summary: The System property condition to use "direct" ByteBuffers
in P2P is wrong
Key: GEODE-10035
URL: https://issues.apache.org/jira/browse/GEODE-10035
Project: Geode
Issue Type: Improvement
Affects Versions: 1.14.3
Reporter: John Blum
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static)
constant field
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
which is derived from either the "{{p2p.nodirectBuffers"}} OR the
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
logic is incorrect!
It should read:
{code:java}
public static final boolean useDirectBuffers = !(
Boolean.getBoolean("p2p.nodirectBuffers")
||
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
);
{code}
The term "{{useHeapBuffers}}" implies that the buffer should created on the JVM
Heap, and not in main memory as a "direct" ByteBuffer.
Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
"{{true}}" would result in a direct ByteBuffer allocation as can be seen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
rather than what should happen
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10018) Remove tx flag from Redis SetOptions
[
https://issues.apache.org/jira/browse/GEODE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10018:
---
Labels: pull-request-available (was: )
> Remove tx flag from Redis SetOptions
>
>
> Key: GEODE-10018
> URL: https://issues.apache.org/jira/browse/GEODE-10018
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> A recent change ([https://github.com/apache/geode/pull/7321)] consolidated
> the logic for transactional operations, avoiding the need for individual data
> structs and commands to take different code paths to account for delta
> changes vs tx contexts.
>
> The MSET command still contains this older approach which can now be removed.
> Practically, we can remove the {{SetOptions.inTransaction}} field and all
> logic surrounding this flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10018) Remove tx flag from Redis SetOptions
[
https://issues.apache.org/jira/browse/GEODE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-10018:
---
Assignee: Donal Evans
> Remove tx flag from Redis SetOptions
>
>
> Key: GEODE-10018
> URL: https://issues.apache.org/jira/browse/GEODE-10018
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Donal Evans
>Priority: Major
>
> A recent change ([https://github.com/apache/geode/pull/7321)] consolidated
> the logic for transactional operations, avoiding the need for individual data
> structs and commands to take different code paths to account for delta
> changes vs tx contexts.
>
> The MSET command still contains this older approach which can now be removed.
> Practically, we can remove the {{SetOptions.inTransaction}} field and all
> logic surrounding this flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
Wayne created GEODE-10034: - Summary: Organize Geode For Redis Stats By Data Structure Key: GEODE-10034 URL: https://issues.apache.org/jira/browse/GEODE-10034 Project: Geode Issue Type: Improvement Components: redis Reporter: Wayne The Geode for Redis Stats should be organized by Data Structure. For the stats not associated with a data structure, the stats should continue to be exposed under "GeodeForRedisStats". +Acceptance Criteria+ All stats, associated with a command specific to a data structure, should be exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, Lists). All tests should pass. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10033) Disable Geode Redis Stats Above Threshold
Wayne created GEODE-10033: - Summary: Disable Geode Redis Stats Above Threshold Key: GEODE-10033 URL: https://issues.apache.org/jira/browse/GEODE-10033 Project: Geode Issue Type: Improvement Components: redis Reporter: Wayne The current limit for Geode for Redis stats is 254. After we have reached this threshold, stop publishing stats. This is a temporary change until we can reorganize stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10021) Clean up RemoteTrasactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10021: --- Labels: pull-request-available (was: ) > Clean up RemoteTrasactionDUnitTest > -- > > Key: GEODE-10021 > URL: https://issues.apache.org/jira/browse/GEODE-10021 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.16.0 >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > > I have been working on GEODE-9929 and the failing DUnitTest has a lot of > errors. I want to clean up some of the errors where I can use find and > replace, as well as a couple of changes to make it easier for the next person > who works on GEODE-9929. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10026) Implement java deserialization
[ https://issues.apache.org/jira/browse/GEODE-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489818#comment-17489818 ] Mario Salazar de Torres commented on GEODE-10026: - Hi [~echobravo], You've got a good point, and I don't like it either. But the problem is that the current way that exceptions are handled inside the native client is not acceptable at all. Eitherway I'll let rest the exceptions part for now, and come back with some alternatives in the future. BR, Mario. > Implement java deserialization > -- > > Key: GEODE-10026 > URL: https://issues.apache.org/jira/browse/GEODE-10026 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, the native client does not support deserializing Java serialized > objects. > I.E exceptions are sent as Java serialized and also a message is sent, so if > the Java serialized object could be read instead of the exception message, > this would solve several issues while parsing exceptions. > Java (de)serialization is an > [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] > so and has not changed in a while, so adding this would require so little > maintenance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489813#comment-17489813 ] Mario Salazar de Torres edited comment on GEODE-10029 at 2/9/22, 9:07 PM: -- Hi [~echobravo], Sorry, I should have added some context for why I chose to open this ticket as a bug and not a feature. Thing is that we are noticing an issue under the following scenario: # From a native client, I create an object using a PdxSerializable implementation, which has an String field. # After that, we are reading this object from a java client which cache has readPdxSerialized=true and comparing it with a PdxInstance created locally inside the Java client. # As PdxInstanceImpl.equals method uses rawBytes for strings, if the string is serialized using different DSCodes, the comparison will fail, even if the length and content are the same. *Note that* as stated by the ticket description, whenever writing an ASCII string inside the native client it's DSCode will be CacheableString, whenever in the case of the Java client will actually be CacheableASCIIString. That's why there are 3 approaches here: * Modify the native client so whenever writeString is called, the string is parsed and the DSCode is selected depending on wether it contains an UTF-8 string or just an ASCII string, just like Java client is doing right now. * Modify PdxInstanceImpl equals method, so the DSCode is not taken into account whenever comparing string fields. * Both of the above. So I'd say, given this information, it's indeed a bug. If you don't see it that way, I don't have any issue in re-opening it as an improvement. I'll push the PR eitherways. was (Author: gaussianrecurrence): Hi [~echobravo], Sorry, I might have added some context for why I chose to open this ticket as a bug and not a feature. Thing is that we are noticing an issue under the following scenario: # From a native client, I create an object using a PdxSerializable implementation, which has an String field. # After that, we are reading this object from a java client which cache has readPdxSerialized=true and comparing it with a PdxInstance created locally inside the Java client. # As PdxInstanceImpl.equals method uses rawBytes for strings, if the string is serialized using different DSCodes, the comparison will fail, even if the length and content are the same. *Note that* as stated by the ticket description, whenever writing an ASCII string inside the native client it's DSCode will be CacheableString, whenever in the case of the Java client will actually be CacheableASCIIString. That's why there are 3 approaches here: * Modify the native client so whenever writeString is called, the string is parsed and the DSCode is selected depending on wether it contains an UTF-8 string or just an ASCII string, just like Java client is doing right now. * Modify PdxInstanceImpl equals method, so the DSCode is not taken into account whenever comparing string fields. * Both of the above. So I'd say, given this information, it's indeed a bug. If you don't see it that way, I don't have any issue in re-opening it as an improvement. I'll push the PR eitherways. > Strings are not correctly serialized > > > Key: GEODE-10029 > URL: https://issues.apache.org/jira/browse/GEODE-10029 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489813#comment-17489813 ] Mario Salazar de Torres commented on GEODE-10029: - Hi [~echobravo], Sorry, I might have added some context for why I chose to open this ticket as a bug and not a feature. Thing is that we are noticing an issue under the following scenario: # From a native client, I create an object using a PdxSerializable implementation, which has an String field. # After that, we are reading this object from a java client which cache has readPdxSerialized=true and comparing it with a PdxInstance created locally inside the Java client. # As PdxInstanceImpl.equals method uses rawBytes for strings, if the string is serialized using different DSCodes, the comparison will fail, even if the length and content are the same. *Note that* as stated by the ticket description, whenever writing an ASCII string inside the native client it's DSCode will be CacheableString, whenever in the case of the Java client will actually be CacheableASCIIString. That's why there are 3 approaches here: * Modify the native client so whenever writeString is called, the string is parsed and the DSCode is selected depending on wether it contains an UTF-8 string or just an ASCII string, just like Java client is doing right now. * Modify PdxInstanceImpl equals method, so the DSCode is not taken into account whenever comparing string fields. * Both of the above. So I'd say, given this information, it's indeed a bug. If you don't see it that way, I don't have any issue in re-opening it as an improvement. I'll push the PR eitherways. > Strings are not correctly serialized > > > Key: GEODE-10029 > URL: https://issues.apache.org/jira/browse/GEODE-10029 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (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
]
Ernest Burghardt resolved GEODE-9982.
-
Resolution: Won't Fix
not modifying 1.14 and below
> 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
>Assignee: Blake Bender
>Priority: Critical
> Labels: pull-request-available
> 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] [Closed] (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
]
Ernest Burghardt closed GEODE-9982.
---
> 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
>Assignee: Blake Bender
>Priority: Critical
> Labels: pull-request-available
> 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] [Assigned] (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
]
Ernest Burghardt reassigned GEODE-9982:
---
Assignee: Blake Bender
> 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
>Assignee: Blake Bender
>Priority: Critical
> Labels: pull-request-available
> 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] [Assigned] (GEODE-10014) Add support for building nativeclient against older geode releases
[ https://issues.apache.org/jira/browse/GEODE-10014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt reassigned GEODE-10014: Assignee: Michael Martell > Add support for building nativeclient against older geode releases > -- > > Key: GEODE-10014 > URL: https://issues.apache.org/jira/browse/GEODE-10014 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > > Currently, the nativeclient's java test module (javaobject.jar) depends on a > very recent version of geode (1.15.0-build.546 or higher). This ticket is to > add support for building this jar file against older versions of geode which > do not contain the new AuthenticationExpiredException. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10016) Use Thread Name In Log Messages
[ https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-10016. -- Fix Version/s: 1.15.0 Resolution: Fixed > Use Thread Name In Log Messages > --- > > Key: GEODE-10016 > URL: https://issues.apache.org/jira/browse/GEODE-10016 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Minor > Labels: pull-request-available > Fix For: 1.15.0 > > > The native client logging system currently prints the threadId in all log > messages. Since all internally created native client threads are named, we > should print the threadName instead of threadId. This will be extremely > helpful to understanding the flow of messages since there are many background > threads in the native client. > Note: Lots of log messages are running on an application thread which was not > created internally by the native client. Messages running on these threads > should continue to print the threadId. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10016) Use Thread Name In Log Messages
[ https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-10016. > Use Thread Name In Log Messages > --- > > Key: GEODE-10016 > URL: https://issues.apache.org/jira/browse/GEODE-10016 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Minor > Labels: pull-request-available > Fix For: 1.15.0 > > > The native client logging system currently prints the threadId in all log > messages. Since all internally created native client threads are named, we > should print the threadName instead of threadId. This will be extremely > helpful to understanding the flow of messages since there are many background > threads in the native client. > Note: Lots of log messages are running on an application thread which was not > created internally by the native client. Messages running on these threads > should continue to print the threadId. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10026) Implement java deserialization
[ https://issues.apache.org/jira/browse/GEODE-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-10026. -- Resolution: Won't Fix > Implement java deserialization > -- > > Key: GEODE-10026 > URL: https://issues.apache.org/jira/browse/GEODE-10026 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, the native client does not support deserializing Java serialized > objects. > I.E exceptions are sent as Java serialized and also a message is sent, so if > the Java serialized object could be read instead of the exception message, > this would solve several issues while parsing exceptions. > Java (de)serialization is an > [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] > so and has not changed in a while, so adding this would require so little > maintenance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10026) Implement java deserialization
[ https://issues.apache.org/jira/browse/GEODE-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-10026. > Implement java deserialization > -- > > Key: GEODE-10026 > URL: https://issues.apache.org/jira/browse/GEODE-10026 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, the native client does not support deserializing Java serialized > objects. > I.E exceptions are sent as Java serialized and also a message is sent, so if > the Java serialized object could be read instead of the exception message, > this would solve several issues while parsing exceptions. > Java (de)serialization is an > [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] > so and has not changed in a while, so adding this would require so little > maintenance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10026) Implement java deserialization
[ https://issues.apache.org/jira/browse/GEODE-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt reopened GEODE-10026: -- > Implement java deserialization > -- > > Key: GEODE-10026 > URL: https://issues.apache.org/jira/browse/GEODE-10026 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, the native client does not support deserializing Java serialized > objects. > I.E exceptions are sent as Java serialized and also a message is sent, so if > the Java serialized object could be read instead of the exception message, > this would solve several issues while parsing exceptions. > Java (de)serialization is an > [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] > so and has not changed in a while, so adding this would require so little > maintenance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10027) Exception parsing using the Java serialized object
[ https://issues.apache.org/jira/browse/GEODE-10027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-10027. -- Resolution: Won't Fix see related issue > Exception parsing using the Java serialized object > -- > > Key: GEODE-10027 > URL: https://issues.apache.org/jira/browse/GEODE-10027 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, exceptions received in the native client are using just the > exception message to identify the exceptions. > Also there is the problem that the exception chain is lost, only the first > identified exception in the message is thrown. > Also there is the thing that it would be way easier to handle all kind of > exceptions, and also, in the future, could allow to parse custom implemented > exceptions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10027) Exception parsing using the Java serialized object
[ https://issues.apache.org/jira/browse/GEODE-10027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-10027. > Exception parsing using the Java serialized object > -- > > Key: GEODE-10027 > URL: https://issues.apache.org/jira/browse/GEODE-10027 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, exceptions received in the native client are using just the > exception message to identify the exceptions. > Also there is the problem that the exception chain is lost, only the first > identified exception in the message is thrown. > Also there is the thing that it would be way easier to handle all kind of > exceptions, and also, in the future, could allow to parse custom implemented > exceptions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10026) Implement java deserialization
[ https://issues.apache.org/jira/browse/GEODE-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-10026. -- Resolution: Won't Fix deserializing java objects in C++ is a bad idea > Implement java deserialization > -- > > Key: GEODE-10026 > URL: https://issues.apache.org/jira/browse/GEODE-10026 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, the native client does not support deserializing Java serialized > objects. > I.E exceptions are sent as Java serialized and also a message is sent, so if > the Java serialized object could be read instead of the exception message, > this would solve several issues while parsing exceptions. > Java (de)serialization is an > [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] > so and has not changed in a while, so adding this would require so little > maintenance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-10029. > Strings are not correctly serialized > > > Key: GEODE-10029 > URL: https://issues.apache.org/jira/browse/GEODE-10029 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-10029. -- Resolution: Won't Fix this is a feature request > Strings are not correctly serialized > > > Key: GEODE-10029 > URL: https://issues.apache.org/jira/browse/GEODE-10029 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489783#comment-17489783 ] ASF subversion and git services commented on GEODE-9959: Commit 8659e22805479bb6d3927cdf903dfcb71b4fa2b2 in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=8659e22 ] GEODE-9959: Add FQDN in log upon SSL missconfig (#904) - Whenever there is an SSL missoconfiguration while trying to reach a locator, an AuthenticationRequiredException is thrown and a log is written. Currently FQDN of the locator is not logged. - This commit adds the locator FQDN in order to further troubleshoot this kind of scenarios. - Also, in order to ease implementation, toString method was implemented for ServerLocation. > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-9959. - Resolution: Fixed > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-9959. --- > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489781#comment-17489781 ] ASF GitHub Bot commented on GEODE-9959: --- pdxcodemonkey merged pull request #904: URL: https://github.com/apache/geode-native/pull/904 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-10030: Labels: pull-request-available (was: needsTriage pull-request-available) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489769#comment-17489769 ] ASF subversion and git services commented on GEODE-10030: - Commit 0b46698c7a0be115256d0e44d5614afa957ac071 in geode-native's branch refs/heads/support/1.15 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=0b46698 ] GEODE-10030: Remove obsolete cross-reference in geode-native user docs (#921) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-10030: Fix Version/s: 1.15.0 > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-10030: Fix Version/s: 1.12.9 1.13.8 1.14.4 > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489765#comment-17489765 ] ASF subversion and git services commented on GEODE-10030: - Commit af4922d53aad235fbc106bae512db072c21521ee in geode-native's branch refs/heads/support/1.12 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=af4922d ] GEODE-10030: Remove obsolete cross-reference in geode-native user docs (#921) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489764#comment-17489764 ] ASF subversion and git services commented on GEODE-10030: - Commit a57a7080b040f70de8ee9a37a6b5f7341d1d033e in geode-native's branch refs/heads/support/1.13 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=a57a708 ] GEODE-10030: Remove obsolete cross-reference in geode-native user docs (#921) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489763#comment-17489763 ] ASF subversion and git services commented on GEODE-10030: - Commit cd5c0d124bf1951c546ceef38e4cad5a650d4967 in geode-native's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cd5c0d1 ] GEODE-10030: Remove obsolete cross-reference in geode-native user docs (#921) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-10030: Fix Version/s: 1.16.0 > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-10030. -- Resolution: Fixed > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-10030. > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489758#comment-17489758 ] ASF GitHub Bot commented on GEODE-10030: pdxcodemonkey merged pull request #921: URL: https://github.com/apache/geode-native/pull/921 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489757#comment-17489757 ] ASF subversion and git services commented on GEODE-10030: - Commit 6797d4f971c1068b8eee52ab797304f24c9bf0d2 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=6797d4f ] GEODE-10030: Remove obsolete cross-reference in geode-native user docs (#921) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10030: --- Labels: needsTriage pull-request-available (was: needsTriage) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage, pull-request-available > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489750#comment-17489750 ] ASF GitHub Bot commented on GEODE-10030: davebarnes97 opened a new pull request #921: URL: https://github.com/apache/geode-native/pull/921 Simple deletion of a cross-reference from two source files, one for the C++ user guide, one for the .NET user guide. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-10022:
Fix Version/s: 1.15.0
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489738#comment-17489738
]
ASF subversion and git services commented on GEODE-10022:
-
Commit 195ba36c27488534c015ec368d0790715b674e28 in geode's branch
refs/heads/support/1.15 from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=195ba36 ]
GEODE-10022: fix the logging to log the entire stack trace. (#7349)
(cherry picked from commit fbe4e662fd679f718ab57e207b063a0902ed44c8)
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9960) Remove support for strong name signing of assemblies
[ https://issues.apache.org/jira/browse/GEODE-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9960: -- Labels: pull-request-available (was: ) > Remove support for strong name signing of assemblies > > > Key: GEODE-9960 > URL: https://issues.apache.org/jira/browse/GEODE-9960 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > This has historically caused problems in builds and CI pipelines. Microsoft > has recognized that it's not actually solving the problems originally > intended, and has removed any code that uses it from .net 5 and .net core. > We could continue to build with it, but literally nothing would use it, so > let's get rid of another weird vestigial artifact from our Windows support. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9960) Remove support for strong name signing of assemblies
[ https://issues.apache.org/jira/browse/GEODE-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489728#comment-17489728 ] ASF subversion and git services commented on GEODE-9960: Commit 7b88b9e4464249fadbe33c29c1bf989f1d6b6e3b in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=7b88b9e ] GEODE-9960: Remove strong name signing support for .net assemblies (#905) * Remove strong name signing support for .net assemblies - This has caused problems with build pipelines, and is no longer used by .net runtimes - Make internals visible to test DLL > Remove support for strong name signing of assemblies > > > Key: GEODE-9960 > URL: https://issues.apache.org/jira/browse/GEODE-9960 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Priority: Major > > This has historically caused problems in builds and CI pipelines. Microsoft > has recognized that it's not actually solving the problems originally > intended, and has removed any code that uses it from .net 5 and .net core. > We could continue to build with it, but literally nothing would use it, so > let's get rid of another weird vestigial artifact from our Windows support. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9960) Remove support for strong name signing of assemblies
[ https://issues.apache.org/jira/browse/GEODE-9960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489727#comment-17489727 ] ASF GitHub Bot commented on GEODE-9960: --- pdxcodemonkey merged pull request #905: URL: https://github.com/apache/geode-native/pull/905 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove support for strong name signing of assemblies > > > Key: GEODE-9960 > URL: https://issues.apache.org/jira/browse/GEODE-9960 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Priority: Major > > This has historically caused problems in builds and CI pipelines. Microsoft > has recognized that it's not actually solving the problems originally > intended, and has removed any code that uses it from .net 5 and .net core. > We could continue to build with it, but literally nothing would use it, so > let's get rid of another weird vestigial artifact from our Windows support. -- 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:
--
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] [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
]
Alexander Murmann updated GEODE-10031:
--
Labels: needsTriage (was: )
> 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: Major
> 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] [Commented] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489722#comment-17489722
]
ASF subversion and git services commented on GEODE-10022:
-
Commit fbe4e662fd679f718ab57e207b063a0902ed44c8 in geode's branch
refs/heads/develop from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fbe4e66 ]
GEODE-10022: fix the logging to log the entire stack trace. (#7349)
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-10030: --- Assignee: Dave Barnes > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: needsTriage > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10022.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
Dave Barnes created GEODE-10030: --- Summary: Remove obsolete cross-reference in geode-native user docs Key: GEODE-10030 URL: https://issues.apache.org/jira/browse/GEODE-10030 Project: Geode Issue Type: Bug Components: docs Reporter: Dave Barnes The System Properties page contains a cross-reference to the System Statistics page, which no longer exists. Just remove the link from both the .NET and C++ versions of the user guide. It's in the System Archiving Properties table. .NET: https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props C++: https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10030: -- Labels: needsTriage (was: ) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Priority: Major > Labels: needsTriage > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9360) Initial revision of .net core support
[ https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489714#comment-17489714 ] ASF GitHub Bot commented on GEODE-9360: --- pdxcodemonkey commented on pull request #823: URL: https://github.com/apache/geode-native/pull/823#issuecomment-1034043585 No, sorry. There is a ton of work left to get to a full client, and this particular attempt at a first cut may not even make it into the final product. You can build it yourself and use it's (extremely limited) functionality, but it's not up on Nuget and we don't post binaries for geode-native builds. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Initial revision of .net core support > - > > Key: GEODE-9360 > URL: https://issues.apache.org/jira/browse/GEODE-9360 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > As a .net core developer, I would like to be able to access the geode-native > API. To facilitate this, we need to implement a minimal set of C# classes > that use p/invoke to access geode-native via C bindings (GEODE-9358). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10029: -- Labels: needsTriage (was: ) > Strings are not correctly serialized > > > Key: GEODE-10029 > URL: https://issues.apache.org/jira/browse/GEODE-10029 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10029) Strings are not correctly serialized
Mario Salazar de Torres created GEODE-10029: --- Summary: Strings are not correctly serialized Key: GEODE-10029 URL: https://issues.apache.org/jira/browse/GEODE-10029 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* a PdxSerializable implementation with a string field *WHEN* an ASCII string is written *THEN* the string is serialized with the DSCode CacheableString *Additional information.* In the Java client, whenever writing an string, the string is parsed and the DSCode is assigned depending on the string codification. In the native client, it's always set to CacheableString, whenever for example in the case of an ASCII string should be CacheableASCIIString -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9892) Create Infrastructure for Redis Lists
[ https://issues.apache.org/jira/browse/GEODE-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9892: -- Labels: pull-request-available (was: ) > Create Infrastructure for Redis Lists > - > > Key: GEODE-9892 > URL: https://issues.apache.org/jira/browse/GEODE-9892 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > > Create the infrastructure for supporting Redis Lists including: > * Use of the appropriate underlying Java collection > * Implementing the [LPUSH|https://redis.io/commands/lpush] Command > * Implementing the [LRANGE|https://redis.io/commands/lrange] command > +Acceptance Critera+ > The LPUSH and LRANGE commands have been implemented with appropriate unit > testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9360) Initial revision of .net core support
[ https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489678#comment-17489678 ] ASF GitHub Bot commented on GEODE-9360: --- prashant-upadhyay commented on pull request #823: URL: https://github.com/apache/geode-native/pull/823#issuecomment-1033966909 any public package available to use the .net core client of Geode? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Initial revision of .net core support > - > > Key: GEODE-9360 > URL: https://issues.apache.org/jira/browse/GEODE-9360 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > As a .net core developer, I would like to be able to access the geode-native > API. To facilitate this, we need to implement a minimal set of C# classes > that use p/invoke to access geode-native via C bindings (GEODE-9358). -- This message was sent by Atlassian Jira (v8.20.1#820001)
