[jira] [Updated] (GEODE-10049) Redis tests should include the entire error response message rather than just the error type
[
https://issues.apache.org/jira/browse/GEODE-10049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10049:
---
Labels: pull-request-available (was: )
> Redis tests should include the entire error response message rather than just
> the error type
>
>
> Key: GEODE-10049
> URL: https://issues.apache.org/jira/browse/GEODE-10049
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> Currently many tests look for substrings of error messages, rather than the
> error message as a whole. This has in the past led to cases where the Geode
> for Redis Module's error messages have not precisely matched those of native
> Redis.
> For example, if the test is:
> {code:java}
> assertThatThrownBy(
> () -> jedis.hsetnx(string_key, field, "something else"))
> .isInstanceOf(JedisDataException.class)
> .hasMessageContaining("WRONGTYPE");{code}
> instead we should probably look for the full error message that native Redis
> puts out:
> {code:java}
> .hasMessage("WRONGTYPE Operation against a key holding the wrong kind of
> value"){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10051) Create Configuration for Keyspace Notifications
Wayne created GEODE-10051: - Summary: Create Configuration for Keyspace Notifications Key: GEODE-10051 URL: https://issues.apache.org/jira/browse/GEODE-10051 Project: Geode Issue Type: New Feature Components: redis Reporter: Wayne [Keyspace Notifications|https://redis.io/topics/notifications#configuration] require a common infrastructure for configuration. +Acceptance Criteria+ The infrastructure for Keyspace Notifications has been created along with the appropriate unit testing and documentation updates. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket
[
https://issues.apache.org/jira/browse/GEODE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491215#comment-17491215
]
ASF subversion and git services commented on GEODE-9990:
Commit a98197b5d0a3a2547e0581e475dcabaa82e6e92f in geode's branch
refs/heads/develop from Joris Melchior
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a98197b ]
GEODE-9990: turn DiskAccessException into CacheClosedException (#7334)
* GEODE-9990: turn DiskAccessException into CacheClosedException
- when DiskInitFile is in closed state and DiskStoreImpl is closed or
closing
- catch DiskAccessException in PRHARedundancyProvider and turn into
CacheClosedException if cache closing is in progress
- change CreateBucketMessage to handle DiskAccessException as cause of
ReplyException
> Geode should handle certain DiskAccessException due to CacheClosedException
> when creating bucket
>
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Joris Melchior
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>
> This exception is thrown to the node that tries to create the bucket to
> prevent it trying to create the bucket to next available server and fail the
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The
> disk store is closed
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
>
[jira] [Updated] (GEODE-10047) Warning message in geode-for-redis PassiveExpirationManager is inaccurate
[
https://issues.apache.org/jira/browse/GEODE-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10047:
--
Labels: blocks-1.15.0 pull-request-available (was: needsTriage
pull-request-available)
> Warning message in geode-for-redis PassiveExpirationManager is inaccurate
> -
>
> Key: GEODE-10047
> URL: https://issues.apache.org/jira/browse/GEODE-10047
> Project: Geode
> Issue Type: Bug
> Components: logging, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> If an exception is encountered during the {{doDataExpiration()}} method in
> {{{}PassiveExpirationManager{}}}, the following message is logged:
> {code:java}
> logger.warn("Passive expiration failed. Will try again in 1 second.",
> ex);{code}
> However, the passive expiration interval in geode-for-redis defaults to 180
> seconds and can be configured by the user to other values. The log message
> should reflect the configured value for passive expiration interval.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10039: -- Labels: blocks-1.15.0 (was: needsTriage) > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Priority: Major > Labels: blocks-1.15.0 > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10050) Implement BLPOP
Wayne created GEODE-10050: - Summary: Implement BLPOP Key: GEODE-10050 URL: https://issues.apache.org/jira/browse/GEODE-10050 Project: Geode Issue Type: New Feature Components: redis Reporter: Wayne Implement the [BLPOP|https://redis.io/commands/blpop] Command. +Acceptance Criteria+ The BLPOP command has been. implemented, per specifications, along with all associated unit, acceptance, and system testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[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=17491173#comment-17491173
]
ASF GitHub Bot commented on GEODE-10004:
mmartell commented on a change in pull request #917:
URL: https://github.com/apache/geode-native/pull/917#discussion_r805041305
##
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" CACHE STRING "First build
containing AuthenticationExpiredException")
Review comment:
Seems reasonable to put it in the cmake config file for the project it
applies to.
--
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] [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=17491172#comment-17491172
]
ASF GitHub Bot commented on GEODE-10004:
pdxcodemonkey commented on a change in pull request #917:
URL: https://github.com/apache/geode-native/pull/917#discussion_r805041043
##
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" CACHE STRING "First build
containing AuthenticationExpiredException")
Review comment:
See Martell's comment - this is a string variable because there may be
different version(s) to test against, depending on which product is being built.
--
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] [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=17491171#comment-17491171
]
ASF GitHub Bot commented on GEODE-10004:
mmartell commented on a change in pull request #917:
URL: https://github.com/apache/geode-native/pull/917#discussion_r805040012
##
File path: tests/javaobject/CMakeLists.txt
##
@@ -22,6 +22,11 @@ include(UseJava)
file(GLOB_RECURSE SOURCES "*.java")
+# Check for versions of GEODE that don't support AuthenticationExpiredException
+if (${Geode_VERSION} VERSION_LESS ${GEODE_AUTHEXPIREDEXCEPTION_VERSION})
Review comment:
It needs to be a variable that we can override on the cmake config
command line, for closed source builds:
cmake ... -DGEODE_AUTHEXPIREDEXCEPTION_VERSION=9.15.0
--
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] [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=17491169#comment-17491169
]
ASF GitHub Bot commented on GEODE-10004:
mmartell commented on a change in pull request #917:
URL: https://github.com/apache/geode-native/pull/917#discussion_r805034612
##
File path: cmake/FindGeode.cmake
##
@@ -73,7 +73,7 @@ if(Geode_gfsh_EXECUTABLE)
# TODO error checking
else()
if(var MATCHES "([0-9]+\\.[0-9]+\\.[0-9]+)")
- set(Geode_VERSION "${CMAKE_MATCH_1}")
+ set(Geode_VERSION ${var})
Review comment:
Good catch! No longer need the build number since we're just comparing
with first 3 parts.
--
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-10049) Redis tests should include the entire error response message rather than just the error type
Donal Evans created GEODE-10049:
---
Summary: Redis tests should include the entire error response
message rather than just the error type
Key: GEODE-10049
URL: https://issues.apache.org/jira/browse/GEODE-10049
Project: Geode
Issue Type: Test
Components: redis
Affects Versions: 1.16.0
Reporter: Donal Evans
Currently many tests look for substrings of error messages, rather than the
error message as a whole. This has in the past led to cases where the Geode for
Redis Module's error messages have not precisely matched those of native Redis.
For example, if the test is:
{code:java}
assertThatThrownBy(
() -> jedis.hsetnx(string_key, field, "something else"))
.isInstanceOf(JedisDataException.class)
.hasMessageContaining("WRONGTYPE");{code}
instead we should probably look for the full error message that native Redis
puts out:
{code:java}
.hasMessage("WRONGTYPE Operation against a key holding the wrong kind of
value"){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10049) Redis tests should include the entire error response message rather than just the error type
[
https://issues.apache.org/jira/browse/GEODE-10049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-10049:
---
Assignee: Donal Evans
> Redis tests should include the entire error response message rather than just
> the error type
>
>
> Key: GEODE-10049
> URL: https://issues.apache.org/jira/browse/GEODE-10049
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Currently many tests look for substrings of error messages, rather than the
> error message as a whole. This has in the past led to cases where the Geode
> for Redis Module's error messages have not precisely matched those of native
> Redis.
> For example, if the test is:
> {code:java}
> assertThatThrownBy(
> () -> jedis.hsetnx(string_key, field, "something else"))
> .isInstanceOf(JedisDataException.class)
> .hasMessageContaining("WRONGTYPE");{code}
> instead we should probably look for the full error message that native Redis
> puts out:
> {code:java}
> .hasMessage("WRONGTYPE Operation against a key holding the wrong kind of
> value"){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-8649) Update Redis INFO command to support more fields
[
https://issues.apache.org/jira/browse/GEODE-8649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-8649.
Resolution: Duplicate
All the listed stat fields were added in GEODE-8663
> Update Redis INFO command to support more fields
>
>
> Key: GEODE-8649
> URL: https://issues.apache.org/jira/browse/GEODE-8649
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Priority: Major
>
> Various monitoring software suites use the Redis INFO command to gather data
> about a running Redis instance. Adding the following fields will allow at
> least Datadog's Redis Dashboard to function with Geode Redis:
>
> * {{instantaneous_ops_per_sec}}
> * {{keyspace_hits}} and {{keyspace_misses}}
> * {{evicted_keys}}
> * {{mem_fragmentation_ratio}})
> * {{blocked_clients}})
> * {{used_memory}}
> * {{connected_slaves}}
> * {{rejected_connections}}
> * {{connected_clients}}
> * {{keys}}
> * {{rdb_changes_since_last_save}} and {{rdb_last_save_time}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10033) Disable Geode Redis Stats Above Threshold
[ https://issues.apache.org/jira/browse/GEODE-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne resolved GEODE-10033. --- Resolution: Won't Fix We decided that this issue was unnecessary. > 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 >Priority: Major > > 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] [Created] (GEODE-10048) Create Common Infrastructure for Blocking Commands and Keyspace Event Notifications
Wayne created GEODE-10048: - Summary: Create Common Infrastructure for Blocking Commands and Keyspace Event Notifications Key: GEODE-10048 URL: https://issues.apache.org/jira/browse/GEODE-10048 Project: Geode Issue Type: New Feature Components: redis Reporter: Wayne Create the common infrastructure that will be used for implementing both Redis blocking commands and Keyspace Event Notifications. +Acceptance Criteria+ The common infrastructure has been implemented along with appropriate unit testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8554) CI Failure: JMXMBeanReconnectDUnitTest.locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns
[
https://issues.apache.org/jira/browse/GEODE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491153#comment-17491153
]
Geode Integration commented on GEODE-8554:
--
Seen in [distributed-test-openjdk8
#152|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/152]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0052/test-results/distributedTest/1644532915/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0052/test-artifacts/1644532915/distributedtestfiles-openjdk8-1.16.0-build.0052.tgz].
> CI Failure:
> JMXMBeanReconnectDUnitTest.locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns
>
>
> Key: GEODE-8554
> URL: https://issues.apache.org/jira/browse/GEODE-8554
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Jianxia Chen
>Assignee: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.JMXMBeanReconnectDUnitTest$$Lambda$355/858468979.call
> in VM -1 running on Host 7a5c340f5c23 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:472)
> at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.setUp(JMXMBeanReconnectDUnitTest.java:191)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest [GemFire mbeans on
> locator2]
> Expecting HashSet:
> <[GemFire:type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
> GemFire:type=Member,member=server1,
> GemFire:service=Manager,type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator2,
> GemFire:type=Member,member=locator2,
> GemFire:service=Region,name=/region1,type=Member,member=server1,
> GemFire:service=FileUploader,type=Distributed,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
> GemFire:service=Manager,type=Member,member=locator2,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=System,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=Region,name=/region1,type=Distributed]>
> to contain:
> <[GemFire:type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=Manager,type=Member,member=locator1,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> but could not find the following element(s):
>
> <[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.lambda$setUp$515fd116$3(JMXMBeanReconnectDUnitTest.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at
>
[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=17491134#comment-17491134
]
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_r804977432
##
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" CACHE STRING "First build
containing AuthenticationExpiredException")
Review comment:
Why is this a cache variable and why in the root project. This should
just be a string literal in the javaobject project.
##
File path: cmake/FindGeode.cmake
##
@@ -73,7 +73,7 @@ if(Geode_gfsh_EXECUTABLE)
# TODO error checking
else()
if(var MATCHES "([0-9]+\\.[0-9]+\\.[0-9]+)")
- set(Geode_VERSION "${CMAKE_MATCH_1}")
+ set(Geode_VERSION ${var})
Review comment:
I agree, the group 1 has all the parts we care about in the version.
##
File path: tests/javaobject/CMakeLists.txt
##
@@ -22,6 +22,11 @@ include(UseJava)
file(GLOB_RECURSE SOURCES "*.java")
+# Check for versions of GEODE that don't support AuthenticationExpiredException
+if (${Geode_VERSION} VERSION_LESS ${GEODE_AUTHEXPIREDEXCEPTION_VERSION})
Review comment:
Use version literal, `"1.15.0"`, here.
--
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
[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=17491115#comment-17491115
]
ASF GitHub Bot commented on GEODE-10004:
pdxcodemonkey commented on a change in pull request #917:
URL: https://github.com/apache/geode-native/pull/917#discussion_r804954533
##
File path: cmake/FindGeode.cmake
##
@@ -73,7 +73,7 @@ if(Geode_gfsh_EXECUTABLE)
# TODO error checking
else()
if(var MATCHES "([0-9]+\\.[0-9]+\\.[0-9]+)")
- set(Geode_VERSION "${CMAKE_MATCH_1}")
+ set(Geode_VERSION ${var})
Review comment:
What is this all about? I don't understand why we need a change in the
Geode find module...
--
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] [Assigned] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-10015:
-
Assignee: Jacob Barrett
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10043) TransactionCleaningTest.txWithStoppedServer is sporiously failing
[ https://issues.apache.org/jira/browse/GEODE-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491106#comment-17491106 ] ASF GitHub Bot commented on GEODE-10043: pdxcodemonkey merged pull request #923: URL: https://github.com/apache/geode-native/pull/923 -- 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 > TransactionCleaningTest.txWithStoppedServer is sporiously failing > - > > Key: GEODE-10043 > URL: https://issues.apache.org/jira/browse/GEODE-10043 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > This new-IT is failing from time to time due to concurrent modification > exception. > Here there are some executions in which can be seen the failure: > - > [https://concourse.apachegeode-ci.info/builds/25709909|https://concourse.apachegeode-ci.info/builds/25709909] > - > [https://concourse.apachegeode-ci.info/builds/26267825|https://concourse.apachegeode-ci.info/builds/26267825] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10043) TransactionCleaningTest.txWithStoppedServer is sporiously failing
[ https://issues.apache.org/jira/browse/GEODE-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10043: --- Labels: needsTriage pull-request-available (was: needsTriage) > TransactionCleaningTest.txWithStoppedServer is sporiously failing > - > > Key: GEODE-10043 > URL: https://issues.apache.org/jira/browse/GEODE-10043 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > This new-IT is failing from time to time due to concurrent modification > exception. > Here there are some executions in which can be seen the failure: > - > [https://concourse.apachegeode-ci.info/builds/25709909|https://concourse.apachegeode-ci.info/builds/25709909] > - > [https://concourse.apachegeode-ci.info/builds/26267825|https://concourse.apachegeode-ci.info/builds/26267825] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9322) Solve potential race condition in TransactionCleaningTest
[ https://issues.apache.org/jira/browse/GEODE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491105#comment-17491105 ] ASF subversion and git services commented on GEODE-9322: Commit cd38c21282c7a11a6329428d0da41020bd9f6294 in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cd38c21 ] GEODE-100043: Solve TransactionCleaningTest errors (#923) - From time to time this test was failing with the error "Concurrent modification in the cache". Thing is this test was not intended to check concurrent modifications. - In GEODE-9322 this test was modified to avoid a race-condition whenever restarting the server. To do so, it was needed to enable notification subscription and change the region shortcut to CACHE_PROXY. In doing so, concurrent checks are also enabled, and due to some strange race-condition this is occasionally leading to the exception. - Concurrency checks were disabled for the region to avoid the race-condition to happen at all > Solve potential race condition in TransactionCleaningTest > - > > Key: GEODE-9322 > URL: https://issues.apache.org/jira/browse/GEODE-9322 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > A possible race condition was detected in this new IT. > Given there is no check for servers start/stop, it might happen that the test > proceeds before the server is actually stopped/started. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10021) Clean up RemoteTrasactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales resolved GEODE-10021. Fix Version/s: 1.16.0 Resolution: Fixed > 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 > Fix For: 1.16.0 > > > 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-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491095#comment-17491095 ] ASF subversion and git services commented on GEODE-9929: Commit 9fa1c1b3afd1193bb4072501c0ff23008da8625e in geode's branch refs/heads/develop from Hale Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9fa1c1b ] GEODE-10021: Clean up RemoteTransactionDUnitTest (#7339) Clean up RemoteTransactionDUnitTest for the next time this failure occurs. While trying to reproduce the failure described by GEODE-9929 I did some clean up so I would be able to get more useful information out of the failures. I cleaned up a lot of warnings, mostly using IntelliJ's tools. I cleaned up: - assertNull - assertTrue - assertFalse - fail - WaitCriterion - added where required to get rid of warnings - removed unnecessary throws of Exceptions on methods that don't throw - in assertions switched the actual and expected to be the correct direction - getGemfireCache (deprecated) -> getCache > testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest > > > Key: GEODE-9929 > URL: https://issues.apache.org/jira/browse/GEODE-9929 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: Kristen >Priority: Major > > org.apache.geode.internal.cache.RemoteTransactionDUnitTest > > testTXCreationAndCleanupAtCommit FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0 > running on Host 9acb6806d25d with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:473) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565) > Caused by: > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:87) > at org.junit.Assert.assertTrue(Assert.java:42) > at org.junit.Assert.assertNotNull(Assert.java:713) > at org.junit.Assert.assertNotNull(Assert.java:723) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595) > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1 > running on Host 9acb6806d25d with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:473) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121) > at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182) > Caused by: > java.lang.AssertionError: Event never occurred after 3 ms: > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144) > at > org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149) > 8838 tests completed, 1 failed, 458 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10021) Clean up RemoteTrasactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491094#comment-17491094 ] ASF subversion and git services commented on GEODE-10021: - Commit 9fa1c1b3afd1193bb4072501c0ff23008da8625e in geode's branch refs/heads/develop from Hale Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9fa1c1b ] GEODE-10021: Clean up RemoteTransactionDUnitTest (#7339) Clean up RemoteTransactionDUnitTest for the next time this failure occurs. While trying to reproduce the failure described by GEODE-9929 I did some clean up so I would be able to get more useful information out of the failures. I cleaned up a lot of warnings, mostly using IntelliJ's tools. I cleaned up: - assertNull - assertTrue - assertFalse - fail - WaitCriterion - added where required to get rid of warnings - removed unnecessary throws of Exceptions on methods that don't throw - in assertions switched the actual and expected to be the correct direction - getGemfireCache (deprecated) -> getCache > 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] [Updated] (GEODE-10047) Warning message in geode-for-redis PassiveExpirationManager is inaccurate
[
https://issues.apache.org/jira/browse/GEODE-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10047:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> Warning message in geode-for-redis PassiveExpirationManager is inaccurate
> -
>
> Key: GEODE-10047
> URL: https://issues.apache.org/jira/browse/GEODE-10047
> Project: Geode
> Issue Type: Bug
> Components: logging, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If an exception is encountered during the {{doDataExpiration()}} method in
> {{{}PassiveExpirationManager{}}}, the following message is logged:
> {code:java}
> logger.warn("Passive expiration failed. Will try again in 1 second.",
> ex);{code}
> However, the passive expiration interval in geode-for-redis defaults to 180
> seconds and can be configured by the user to other values. The log message
> should reflect the configured value for passive expiration interval.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10047) Warning message in geode-for-redis PassiveExpirationManager is inaccurate
[
https://issues.apache.org/jira/browse/GEODE-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-10047:
---
Assignee: Donal Evans
> Warning message in geode-for-redis PassiveExpirationManager is inaccurate
> -
>
> Key: GEODE-10047
> URL: https://issues.apache.org/jira/browse/GEODE-10047
> Project: Geode
> Issue Type: Bug
> Components: logging, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> If an exception is encountered during the {{doDataExpiration()}} method in
> {{{}PassiveExpirationManager{}}}, the following message is logged:
> {code:java}
> logger.warn("Passive expiration failed. Will try again in 1 second.",
> ex);{code}
> However, the passive expiration interval in geode-for-redis defaults to 180
> seconds and can be configured by the user to other values. The log message
> should reflect the configured value for passive expiration interval.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10047) Warning message in geode-for-redis PassiveExpirationManager is inaccurate
[
https://issues.apache.org/jira/browse/GEODE-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10047:
--
Labels: needsTriage (was: )
> Warning message in geode-for-redis PassiveExpirationManager is inaccurate
> -
>
> Key: GEODE-10047
> URL: https://issues.apache.org/jira/browse/GEODE-10047
> Project: Geode
> Issue Type: Bug
> Components: logging, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> If an exception is encountered during the {{doDataExpiration()}} method in
> {{{}PassiveExpirationManager{}}}, the following message is logged:
> {code:java}
> logger.warn("Passive expiration failed. Will try again in 1 second.",
> ex);{code}
> However, the passive expiration interval in geode-for-redis defaults to 180
> seconds and can be configured by the user to other values. The log message
> should reflect the configured value for passive expiration interval.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10047) Warning message in geode-for-redis PassiveExpirationManager is inaccurate
Donal Evans created GEODE-10047:
---
Summary: Warning message in geode-for-redis
PassiveExpirationManager is inaccurate
Key: GEODE-10047
URL: https://issues.apache.org/jira/browse/GEODE-10047
Project: Geode
Issue Type: Bug
Components: logging, redis
Affects Versions: 1.15.0, 1.16.0
Reporter: Donal Evans
If an exception is encountered during the {{doDataExpiration()}} method in
{{{}PassiveExpirationManager{}}}, the following message is logged:
{code:java}
logger.warn("Passive expiration failed. Will try again in 1 second.",
ex);{code}
However, the passive expiration interval in geode-for-redis defaults to 180
seconds and can be configured by the user to other values. The log message
should reflect the configured value for passive expiration interval.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10046) bump dependencies in 1.16
[ https://issues.apache.org/jira/browse/GEODE-10046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-10046: Assignee: Owen Nichols > bump dependencies in 1.16 > - > > Key: GEODE-10046 > URL: https://issues.apache.org/jira/browse/GEODE-10046 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > until support/1.16 is cut, periodically check for and switch to latest > version of 3rd-party dependencies. this will extend the shelf-life of > eventual Geode 1.16 release and hopefully reduce bugs and cve exposure, or at > least give a smaller delta if there is later a cve found that we need to > patch for -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10046) bump dependencies in 1.16
Owen Nichols created GEODE-10046: Summary: bump dependencies in 1.16 Key: GEODE-10046 URL: https://issues.apache.org/jira/browse/GEODE-10046 Project: Geode Issue Type: Improvement Components: build Reporter: Owen Nichols until support/1.16 is cut, periodically check for and switch to latest version of 3rd-party dependencies. this will extend the shelf-life of eventual Geode 1.16 release and hopefully reduce bugs and cve exposure, or at least give a smaller delta if there is later a cve found that we need to patch for -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Blocker (was: Major)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[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=17491075#comment-17491075
]
John Blum commented on GEODE-10035:
---
The workaround is to simply and only use the {{p2p.nodirectBuffers}} (set to
{{true}}) GemFire property.
> 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] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Component/s: core
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Labels: Micrometer (was: )
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491074#comment-17491074
]
John Blum edited comment on GEODE-10045 at 2/11/22, 5:52 PM:
-
Related: https://github.com/spring-projects/spring-data-geode/issues/572
And: https://github.com/spring-projects/spring-data-geode/issues/571
was (Author: jblum):
Related: https://github.com/spring-projects/spring-data-geode/issues/572
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491074#comment-17491074
]
John Blum commented on GEODE-10045:
---
Related: https://github.com/spring-projects/spring-data-geode/issues/572
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Summary: Upgrade to Micrometer 2.0 (was: Upgrade Apache Geode to
Micrometer 2.0)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10045) Upgrade Apache Geode to Micrometer 2.0
John Blum created GEODE-10045:
-
Summary: Upgrade Apache Geode to Micrometer 2.0
Key: GEODE-10045
URL: https://issues.apache.org/jira/browse/GEODE-10045
Project: Geode
Issue Type: Improvement
Affects Versions: 1.14.3
Reporter: John Blum
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0
and the rest of the Spring portfolio, 1 of the new and major topics is
Observability (Monitoring with Metrics, Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10044) Allow for FunctionAttributes to be updated
[ https://issues.apache.org/jira/browse/GEODE-10044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-10044: Priority: Minor (was: Major) > Allow for FunctionAttributes to be updated > --- > > Key: GEODE-10044 > URL: https://issues.apache.org/jira/browse/GEODE-10044 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Minor > > *AS A* geode-native contributor > *I WANT TO* to reset function attributes on-the-fly whenever a function > attributes mismatch is detected on the client > *SO THAT* FunctionAttributes can be changed during an upgrade scenario > > *Additional information.* Currently there is no exception being thrown from > the server whenever a function attributes missmatch is detected. Instead, a > function execution error is send to the client. So it remains to be tackled > how the mismatch is going to be detected on the client side. > *Also, for additional context,* this feature is designed in order to fulfill > the following upgrade scenario: > # A server function called ExampleFunction is deployed inside a cluster. > This server function is defined with isHA=false > # Function is executed several times from the client. > # After some time, a new version of ExampleFunction jar is deployed. The new > version of the server function is defined with isHA=true > # After updating the server function, executions for this function inside > the client should fail at most once, and after that, execute smoothly with > the new function attributes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10044) Allow for FunctionAttributes to be updated
Mario Salazar de Torres created GEODE-10044: --- Summary: Allow for FunctionAttributes to be updated Key: GEODE-10044 URL: https://issues.apache.org/jira/browse/GEODE-10044 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *AS A* geode-native contributor *I WANT TO* to reset function attributes on-the-fly whenever a function attributes mismatch is detected on the client *SO THAT* FunctionAttributes can be changed during an upgrade scenario *Additional information.* Currently there is no exception being thrown from the server whenever a function attributes missmatch is detected. Instead, a function execution error is send to the client. So it remains to be tackled how the mismatch is going to be detected on the client side. *Also, for additional context,* this feature is designed in order to fulfill the following upgrade scenario: # A server function called ExampleFunction is deployed inside a cluster. This server function is defined with isHA=false # Function is executed several times from the client. # After some time, a new version of ExampleFunction jar is deployed. The new version of the server function is defined with isHA=true # After updating the server function, executions for this function inside the client should fail at most once, and after that, execute smoothly with the new function attributes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
