[jira] [Commented] (GEODE-9324) Remove ACE_Task references
[ https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492684#comment-17492684 ] ASF GitHub Bot commented on GEODE-9324: --- gaussianrecurrence commented on pull request #812: URL: https://github.com/apache/geode-native/pull/812#issuecomment-1040433402 Hi @pdxcodemonkey, among others interested I think this is ready to continue reviewing. Will be glad to hear any feedback :) -- 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 ACE_Task references > -- > > Key: GEODE-9324 > URL: https://issues.apache.org/jira/browse/GEODE-9324 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Task > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9261) Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest validateRegionVersionVectorsConsistency
[
https://issues.apache.org/jira/browse/GEODE-9261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Melchior reassigned GEODE-9261:
-
Assignee: Joris Melchior
> Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest
> validateRegionVersionVectorsConsistency
> ---
>
> Key: GEODE-9261
> URL: https://issues.apache.org/jira/browse/GEODE-9261
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Kirk Lund
>Assignee: Joris Melchior
>Priority: Major
> Labels: GeodeOperationAPI
>
> The validateRegionVersionVectorsConsistency method should be fixed to fetch
> rvv2Members from rvv2 instead of rvv1. Unfortunately, the validation breaks
> if this change is made. The test needs to be fixed and the underlying problem
> needs to be identified and fixed before GEODE-7665 can be merged to develop.
> {noformat}
> /**
>* Asserts that the RegionVersionVectors for both buckets are consistent.
>*
>* @param bucketId Id of the bucket to compare.
>* @param bucketDump1 First bucketDump.
>* @param bucketDump2 Second bucketDump.
>*/
> private void validateRegionVersionVectorsConsistency(int bucketId,
> BucketDump bucketDump1,
> BucketDump bucketDump2) {
> RegionVersionVector rvv1 = bucketDump1.getRvv();
> RegionVersionVector rvv2 = bucketDump2.getRvv();
> Map, RegionVersionHolder> rvv2Members =
> new HashMap<>(rvv1.getMemberToVersion()); // TODO: getting
> rvv2Members from rvv1 is wrong
> Map, RegionVersionHolder> rvv1Members =
> new HashMap<>(rvv1.getMemberToVersion());
> {noformat}
--
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&focusedCommentId=17492698#comment-17492698
]
ASF GitHub Bot commented on GEODE-10004:
mmartell merged pull request #917:
URL: https://github.com/apache/geode-native/pull/917
--
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&focusedCommentId=17492700#comment-17492700
]
ASF subversion and git services commented on GEODE-10004:
-
Commit 64e728ee8dc5972fcb4c6ac648bf8209af6944fa in geode-native's branch
refs/heads/develop from Michael Martell
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=64e728e ]
GEODE-10004: support older geode versions (#917)
* Check for class existence instead of version.
> 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-9261) Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest validateRegionVersionVectorsConsistency
[
https://issues.apache.org/jira/browse/GEODE-9261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492705#comment-17492705
]
Joris Melchior commented on GEODE-9261:
---
It appears that this DUnit test no longer exists. [~klund] can you confirm if
this issue is still something that needs to be fixed?
> Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest
> validateRegionVersionVectorsConsistency
> ---
>
> Key: GEODE-9261
> URL: https://issues.apache.org/jira/browse/GEODE-9261
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Kirk Lund
>Assignee: Joris Melchior
>Priority: Major
> Labels: GeodeOperationAPI
>
> The validateRegionVersionVectorsConsistency method should be fixed to fetch
> rvv2Members from rvv2 instead of rvv1. Unfortunately, the validation breaks
> if this change is made. The test needs to be fixed and the underlying problem
> needs to be identified and fixed before GEODE-7665 can be merged to develop.
> {noformat}
> /**
>* Asserts that the RegionVersionVectors for both buckets are consistent.
>*
>* @param bucketId Id of the bucket to compare.
>* @param bucketDump1 First bucketDump.
>* @param bucketDump2 Second bucketDump.
>*/
> private void validateRegionVersionVectorsConsistency(int bucketId,
> BucketDump bucketDump1,
> BucketDump bucketDump2) {
> RegionVersionVector rvv1 = bucketDump1.getRvv();
> RegionVersionVector rvv2 = bucketDump2.getRvv();
> Map, RegionVersionHolder> rvv2Members =
> new HashMap<>(rvv1.getMemberToVersion()); // TODO: getting
> rvv2Members from rvv1 is wrong
> Map, RegionVersionHolder> rvv1Members =
> new HashMap<>(rvv1.getMemberToVersion());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492729#comment-17492729
]
ASF GitHub Bot commented on GEODE-9268:
---
pdxcodemonkey commented on pull request #806:
URL: https://github.com/apache/geode-native/pull/806#issuecomment-1040519470
@gaussianrecurrence Thanks for picking this back up. I have resolved a few
of the comments that you replied to and don't need code changes. Let's clean
up the last few and get this merged!
--
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
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9324) Remove ACE_Task references
[ https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492732#comment-17492732 ] ASF GitHub Bot commented on GEODE-9324: --- pdxcodemonkey commented on pull request #812: URL: https://github.com/apache/geode-native/pull/812#issuecomment-1040523650 > Hi @pdxcodemonkey, among others interested I think this is ready to continue reviewing. Will be glad to hear any feedback :) Do you wish to address any of the variable names as mentioned, or no? If no just indicate here, and I'll approve/merge as is. -- 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 ACE_Task references > -- > > Key: GEODE-9324 > URL: https://issues.apache.org/jira/browse/GEODE-9324 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Task > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9324) Remove ACE_Task references
[ https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492733#comment-17492733 ] ASF GitHub Bot commented on GEODE-9324: --- gaussianrecurrence commented on pull request #812: URL: https://github.com/apache/geode-native/pull/812#issuecomment-1040530307 > > Hi @pdxcodemonkey, among others interested I think this is ready to continue reviewing. Will be glad to hear any feedback :) > > Do you wish to address any of the variable names as mentioned, or no? If no just indicate here, and I'll approve/merge as is. TBH I thought I addressed them all on revision 1. However, even If there are more naming comments to be addressed, I'd say it's best to get this merged, since this PR has been long standing. And, also, I don't think it's worth to invest too much effort on the old ITs, just maintenance until we get the equivalent new ITs. -- 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 ACE_Task references > -- > > Key: GEODE-9324 > URL: https://issues.apache.org/jira/browse/GEODE-9324 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Task > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9980) Startup of Locator or Server should fail fast if geode.enableGlobalSerialFilter is enabled but fails configuration
[
https://issues.apache.org/jira/browse/GEODE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492776#comment-17492776
]
ASF subversion and git services commented on GEODE-9980:
Commit ce57e9fd2b8b644cadc469209e12e4fbd281e0d9 in geode's branch
refs/heads/WIP-GEODE-9892 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce57e9f ]
GEODE-9980: Improve error handling of serial filters (#7299)
Improves the error handling of serial filter configuration and
filtering. The API throws a runtime exception wrapping any thrown
exceptions.
When geode.enableGlobalSerialFilter is FALSE:
* Startup succeeds without throwing any exceptions even if an older
version of Java throws "java.lang.ClassNotFoundException
sun.misc.ObjectInputFilter".
When geode.enableGlobalSerialFilter is TRUE:
* Startup fails by throwing an exception when configuration of serial
filter fails for any reason.
Renames ObjectInputFilter to avoid confusion with the Java interface of
the same name.
Fixes a bug found in ReflectiveFacadeGlobalSerialFilterTest which
resulted in configuring a non-mocked process-wide serial filter that
polluted the JVM for all later tests.
Fixes other minor details in LocatorLauncher, InternalDataSerializer
and various related tests.
> Startup of Locator or Server should fail fast if
> geode.enableGlobalSerialFilter is enabled but fails configuration
> --
>
> Key: GEODE-9980
> URL: https://issues.apache.org/jira/browse/GEODE-9980
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>
> The following error conditions need better handling which includes handling
> of all errors consistently and cause the startup of a Locator or Server to
> fail if it's unable to honor the setting of
> {{-Dgeode.enableGlobalSerialFilter=true}} for any reason. Currently, if
> {{-Dgeode.enableGlobalSerialFilter=true}} is specified but Geode is unable to
> create a global serial filter, then it will will log a warning and continue
> running. A user may easily miss that log statement and believe that the JVM
> is running with a properly configured serialization filter.
> 1) The user is trying to secure the JVM very thoroughly and accidentally
> specifies both {{-Djdk.serialFilter}} and
> {{-Dgeode.enableGlobalSerialFilter}}.
> 2) The user runs some non-Geode code in the same JVM that invokes
> {{ObjectInputFilter.Config.setFilter(...)}} directly.
> 3) The user is using a version of Java 8 prior to 8u121 (the release that
> first added {{sun.misc.ObjectInputFilter}}) and specifies
> {{-Dgeode.enableGlobalSerialFilter=true}}. Also, the same behavior occurs if
> they do NOT specify enabling that property.
> 4) {{LocatorLauncher}} or {{ServerLauncher}} is started in a JVM that has
> already created at least one {{ObjectInputStream}} which will cause
> {{ObjectInputFilter.Config.setFilter(...)}} to fail.
> 5) {{LocatorLauncher}} or {{ServerLauncher}} is started in a Java 8 JVM that
> is not based on OpenJDK (ie {{sun.misc.ObjectInputFilter}} does not exist).
> 6) {{LocatorLauncher}} or {{ServerLauncher}} is started in an unforeseen
> environment that causes invocation of
> {{ObjectInputFilter.Config.setFilter(...)}} via Java Reflection to throw
> {{IllegalAccessException}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492775#comment-17492775 ] ASF subversion and git services commented on GEODE-10009: - Commit 551d7d78548f10218146b074df9b0c4adc0940f7 in geode's branch refs/heads/WIP-GEODE-9892 from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=551d7d7 ] GEODE-10009: Invoked internalClose with keepAlive true (#7332) > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10032) Redis Command Registry Needs to Include Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492783#comment-17492783 ] ASF subversion and git services commented on GEODE-10032: - Commit fc3f991c1988bfe45933103abd55b603331a2ec8 in geode's branch refs/heads/WIP-GEODE-9892 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fc3f991 ] GEODE-10032: Add Category to RedisCommandType (#7354) - This adds a single category (or type) to each command in order to identify the type of data structure it applies too. This is initially being done in order to allow Geode statistics to be finer grained in how the Radish-specific stats are grouped. - The category is derived from Redis' ACL Categories. In Redis these categories also include the command's flags (and possibly additional values). This implementation only specifies the category as it relates to the command's data type. For example, in Redis the `GET` command has categories `@read`, `@fast` and `@string`. In Geode, the category would only be `@string`. This may well change in the future if ACLs are implemented. > Redis Command Registry Needs to Include Data Structure > -- > > Key: GEODE-10032 > URL: https://issues.apache.org/jira/browse/GEODE-10032 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Not all Redis commands are associated with a data structure. For the > commands that are, we need to know which data structure that command is > associated with. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9892) Create Infrastructure for Redis Lists
[ https://issues.apache.org/jira/browse/GEODE-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492784#comment-17492784 ] ASF subversion and git services commented on GEODE-9892: Commit 5bb3d3a6a286d48e5eeb33c0a6f1ebf3dc64263a in geode's branch refs/heads/WIP-GEODE-9892 from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5bb3d3a ] GEODE-9892: Add initial support for RedisLists - implements LPUSH, LPOP, LLEN > 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-9845) CI failure: Multiple tests in OutOfMemoryDUnitTest failed with ConnectException
[
https://issues.apache.org/jira/browse/GEODE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492779#comment-17492779
]
ASF subversion and git services commented on GEODE-9845:
Commit 21215d8ec0f236b01ccbc661a049fa53b01950cc in geode's branch
refs/heads/WIP-GEODE-9892 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=21215d8 ]
GEODE-9845: Refactor OutOfMemoryDUnitTest (#7338)
- Start servers using gfsh to allow setting
XX:CMSInitiatingOccupancyFraction and other VM memory/GC settings
- Add GEODE_HOME setting to geode-for-redis:distributedTest and
repeatDistributedTest in build.gradle to support starting servers
using GfshCommandRule
- Add test coverage for commands being allowed again after recovering
from critical
- Add test that non-critical member does not allow write operations if
there is a critical member in the cluster
> CI failure: Multiple tests in OutOfMemoryDUnitTest failed with
> ConnectException
> ---
>
> Key: GEODE-9845
> URL: https://issues.apache.org/jira/browse/GEODE-9845
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
> Attachments: PXL_20220114_205141950.MP.jpg,
> PXL_20220114_205147440.jpg, PXL_20220114_205152268.jpg,
> PXL_20220114_205156514.jpg
>
>
> 4 tests in OutOfMemoryDUnitTest failed with `java.net.ConnectException:
> Connection refused`.
> {noformat}
> OutOfMemoryDUnitTest > shouldAllowDeleteOperations_afterThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting throwable message:
> "No more cluster attempts left."
> to contain:
> "OOM command not allowed"
> but did not.
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more
> cluster attempts left.
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:156)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.set(JedisCluster.java:293)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.setRedisKeyAndValue(OutOfMemoryDUnitTest.java:228)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$addMultipleKeys$5(OutOfMemoryDUnitTest.java:212)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:62)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:877)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeys(OutOfMemoryDUnitTest.java:210)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillMemory(OutOfMemoryDUnitTest.java:201)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowDeleteOperations_afterThresholdReached(OutOfMemoryDUnitTest.java:166)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:29
[jira] [Commented] (GEODE-10021) Clean up RemoteTrasactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492780#comment-17492780 ] ASF subversion and git services commented on GEODE-10021: - Commit 9fa1c1b3afd1193bb4072501c0ff23008da8625e in geode's branch refs/heads/WIP-GEODE-9892 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 > 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-10018) Remove tx flag from Redis SetOptions
[
https://issues.apache.org/jira/browse/GEODE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492778#comment-17492778
]
ASF subversion and git services commented on GEODE-10018:
-
Commit 8825d95ea64d154d4349e1e74f75bc34833a4702 in geode's branch
refs/heads/WIP-GEODE-9892 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8825d95 ]
GEODE-10018: Remove redundant TX flag from SetOptions (#7352)
Authored-by: 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
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> 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] [Commented] (GEODE-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492781#comment-17492781 ] ASF subversion and git services commented on GEODE-9929: Commit 9fa1c1b3afd1193bb4072501c0ff23008da8625e in geode's branch refs/heads/WIP-GEODE-9892 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-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&focusedCommentId=17492782#comment-17492782
]
ASF subversion and git services commented on GEODE-9990:
Commit a98197b5d0a3a2547e0581e475dcabaa82e6e92f in geode's branch
refs/heads/WIP-GEODE-9892 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
> org.apache.
[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=17492777#comment-17492777
]
ASF subversion and git services commented on GEODE-10022:
-
Commit fbe4e662fd679f718ab57e207b063a0902ed44c8 in geode's branch
refs/heads/WIP-GEODE-9892 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.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-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
[ https://issues.apache.org/jira/browse/GEODE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492798#comment-17492798 ] ASF subversion and git services commented on GEODE-10042: - Commit 592dd652c263c2f043c6f6a11c5fd7f8a61c84a6 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=592dd65 ] GEODE-10042: do not make ClientUserAuths null when we are not unregister client yet. (#7357) * make cleanUserAuths synchronized to avoid NPE * This also pass down client termination reason when we clean up client threads. * since we introduced a lock object for clientUserAuths, revert some old code to not to catch NPE but use the lock * synchronize all clientUserAuths updates. > ServerConnection would make the ClientUserAuths null when there are still > client using that connection > -- > > Key: GEODE-10042 > URL: https://issues.apache.org/jira/browse/GEODE-10042 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.3 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In `handleTermination` method, when we calculate there are still client > threads using this connection, we should not cleanup clientUserAuth (this is > done correctly), but we make the clientUserAuth null regardless, this would > result in NPE sent down to the client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
[ https://issues.apache.org/jira/browse/GEODE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10042. - Fix Version/s: 1.15.0 Resolution: Fixed > ServerConnection would make the ClientUserAuths null when there are still > client using that connection > -- > > Key: GEODE-10042 > URL: https://issues.apache.org/jira/browse/GEODE-10042 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.3 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > In `handleTermination` method, when we calculate there are still client > threads using this connection, we should not cleanup clientUserAuth (this is > done correctly), but we make the clientUserAuth null regardless, this would > result in NPE sent down to the client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
[ https://issues.apache.org/jira/browse/GEODE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492806#comment-17492806 ] ASF subversion and git services commented on GEODE-10042: - Commit 5a656ce402280c377f72f9baf23e422dea528afd in geode's branch refs/heads/support/1.15 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5a656ce ] GEODE-10042: do not make ClientUserAuths null when we are not unregister client yet. (#7357) * make cleanUserAuths synchronized to avoid NPE * This also pass down client termination reason when we clean up client threads. * since we introduced a lock object for clientUserAuths, revert some old code to not to catch NPE but use the lock * synchronize all clientUserAuths updates. (cherry picked from commit 592dd652c263c2f043c6f6a11c5fd7f8a61c84a6) > ServerConnection would make the ClientUserAuths null when there are still > client using that connection > -- > > Key: GEODE-10042 > URL: https://issues.apache.org/jira/browse/GEODE-10042 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.3 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In `handleTermination` method, when we calculate there are still client > threads using this connection, we should not cleanup clientUserAuth (this is > done correctly), but we make the clientUserAuth null regardless, this would > result in NPE sent down to the client. -- 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&focusedCommentId=17492812#comment-17492812
]
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_r806084212
##
File path: cmake/FindGeode.cmake
##
@@ -73,7 +73,8 @@ 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 "${CMAKE_MATCH_1}")
+ set(Geode_VERSION_FULL ${var})
Review comment:
Unless I'm mistaken, nothing in this change depends on Geode_VERSION any
more, so there should be no changes necessary in this file. Please remove, we
don't want to accidentally introduce any new ways to break the build.
--
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&focusedCommentId=17492820#comment-17492820
]
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_r806070730
##
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:
Removed.
##
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:
No longer need to define the variable. Switched to searching for the
Java class.
##
File path: cmake/FindGeode.cmake
##
@@ -73,7 +73,8 @@ 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 "${CMAKE_MATCH_1}")
+ set(Geode_VERSION_FULL ${var})
Review comment:
Good catch!
--
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=-Dgemfir
[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=17492827#comment-17492827
]
ASF GitHub Bot commented on GEODE-10004:
mmartell merged pull request #917:
URL: https://github.com/apache/geode-native/pull/917
--
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-9324) Remove ACE_Task references
[ https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492830#comment-17492830 ] ASF GitHub Bot commented on GEODE-9324: --- pdxcodemonkey commented on pull request #812: URL: https://github.com/apache/geode-native/pull/812#issuecomment-1040523650 > Hi @pdxcodemonkey, among others interested I think this is ready to continue reviewing. Will be glad to hear any feedback :) Do you wish to address any of the variable names as mentioned, or no? If no just indicate here, and I'll approve/merge as is. -- 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 ACE_Task references > -- > > Key: GEODE-9324 > URL: https://issues.apache.org/jira/browse/GEODE-9324 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Task > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492838#comment-17492838
]
ASF GitHub Bot commented on GEODE-9268:
---
pdxcodemonkey commented on pull request #806:
URL: https://github.com/apache/geode-native/pull/806#issuecomment-1040519470
@gaussianrecurrence Thanks for picking this back up. I have resolved a few
of the comments that you replied to and don't need code changes. Let's clean
up the last few and get this merged!
--
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
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9324) Remove ACE_Task references
[ https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492841#comment-17492841 ] ASF GitHub Bot commented on GEODE-9324: --- gaussianrecurrence commented on pull request #812: URL: https://github.com/apache/geode-native/pull/812#issuecomment-1040433402 -- 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 ACE_Task references > -- > > Key: GEODE-9324 > URL: https://issues.apache.org/jira/browse/GEODE-9324 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Task > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10053) Prevent reading property files every time SSL config is created
[ https://issues.apache.org/jira/browse/GEODE-10053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10053: --- Labels: needsTriage pull-request-available (was: needsTriage) > Prevent reading property files every time SSL config is created > --- > > Key: GEODE-10053 > URL: https://issues.apache.org/jira/browse/GEODE-10053 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > > Situation: > 1. Currently, when we create a new SSL config, we read the properties stored > in the LocatorLauncher class. > 2. Using these properties, the DistributionConfigImpl is created which is > used to create the SSLConfig > > Problem: > # While creating the DistributionConfig from properties, it reads the > properties file and security files and creates a new class everytime. > # This is a bit inefficient as the DistributedConfigImpl is already stored > in the InternalLocator. > > Solution: > Use InternalLocator's DistributedConfigurationImpl. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10002: -- Summary: Remove from documentation obligation for parallel gateway sender to share disk store with region (was: Document recommendation but not obligation for parallel gateway sender to share disk store with region) > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > Even though it is true that "parallel gateway sender queues must be colocated > with their regions to operate correctly", having different disk stores for > the region and for the parallel gateway sender queues does not prevent them > from being colocated and therefore to operate correctly. > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10002: -- Description: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is proposed to change the statement from an obligation to a recommendation giving the reasons for it or completely removing the obligation. was: As a result of GEODE-7997, it was documented that "the persisted data from a parallel gateway sender must go to the same disk store as used by the region, because parallel gateway sender queues must be colocated with their regions to operate correctly.". Even though it is true that "parallel gateway sender queues must be colocated with their regions to operate correctly", having different disk stores for the region and for the parallel gateway sender queues does not prevent them from being colocated and therefore to operate correctly. As stated in the Activity in the original ticket by Dan Smith, "The only issue with separating the data into two separate disk stores is that manually deleting the files for just one of the disk stores could cause a hang on startup looking for the missing disk store. We recommend keeping all of the colocated data together." Given that the current statement in the documentation adds a non compatible change to previous versions and also that the given restriction prevents from the independent management of the disk used by the region and by the parallel gateway sender queues it is proposed to change the statement from an obligation to a recommendation giving the reasons for it. > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it or completely > removing the obligation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492868#comment-17492868 ] ASF subversion and git services commented on GEODE-10002: - Commit 0f0edbe0004ca5498bbe5382c353d4f1da396258 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f0edbe ] GEODE-10002: Remove in documentation obligation for parallel … (#7345) * GEODE-10002: Document recommendation but not obligation for parallel gateway sender to share disk store with region * GEODE-10002: Remove also the recommendation. > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it or completely > removing the obligation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-10002. --- Fix Version/s: 1.16.0 Resolution: Fixed > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it or completely > removing the obligation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9981) use more portable approach to getting crypto algorithm oid
[
https://issues.apache.org/jira/browse/GEODE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9981:
--
Labels: pull-request-available (was: )
> use more portable approach to getting crypto algorithm oid
> --
>
> Key: GEODE-9981
> URL: https://issues.apache.org/jira/browse/GEODE-9981
> Project: Geode
> Issue Type: Sub-task
>Reporter: Owen Nichols
>Priority: Major
> Labels: pull-request-available
>
> instead of:
> `new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid)`
> this works with more jdk versions:
> AlgorithmId.get("MD5withRSA");
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10046) bump dependencies in 1.16
[ https://issues.apache.org/jira/browse/GEODE-10046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10046: --- Labels: pull-request-available (was: ) > 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 > Labels: pull-request-available > > 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] [Commented] (GEODE-9981) use more portable approach to getting crypto algorithm oid
[
https://issues.apache.org/jira/browse/GEODE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492871#comment-17492871
]
ASF subversion and git services commented on GEODE-9981:
Commit 9eeeb2d810904c19d286c53ab59bebdd8ba0f84f in geode's branch
refs/heads/develop from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9eeeb2d ]
GEODE-9981: Use API to get crypto oid (#7298)
* use more portable approach to getting crypto algorithm oid. this works in
both JDK17 and earlier versions, unlike the previous approach which broke in
JDK17
> use more portable approach to getting crypto algorithm oid
> --
>
> Key: GEODE-9981
> URL: https://issues.apache.org/jira/browse/GEODE-9981
> Project: Geode
> Issue Type: Sub-task
>Reporter: Owen Nichols
>Priority: Major
> Labels: pull-request-available
>
> instead of:
> `new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid)`
> this works with more jdk versions:
> AlgorithmId.get("MD5withRSA");
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10046) bump dependencies in 1.16
[ https://issues.apache.org/jira/browse/GEODE-10046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492872#comment-17492872 ] ASF subversion and git services commented on GEODE-10046: - Commit 5d69a616d2516b0f401bfbb4394e484bf2c3a284 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5d69a61 ] GEODE-10046: bump dependencies (#7360) * Bump ben-manes versions from 0.39.0 to 0.42.0 * Bump palantir docker from 0.28.0 to 0.32.0 * Bump fastutil from 8.5.6 to 8.5.8 * Bump java-jq from 1.2.0 to 1.3.0 * Bump jproc from 2.6.2 to 2.8.0 * Bump json-path from 2.6.0 to 2.7.0 * Bump lettuce-core from 6.1.5.RELEASE to 6.1.6.RELEASE * Bump micrometer-core from 1.8.1 to 1.8.2 * Bump mysql-connector-java from 8.0.26 to 8.0.28 * Bump nebula.lint from 17.1.1 to 17.6.1 * Bump netty from 4.1.72.Final to 4.1.74.Final * Bump pmd from 6.41.0 to 6.42.0 * Bump spotless from 5.14.3 to 6.2.2 * Bump spring from 5.3.14 to 5.3.15 * Bump spring-boot-starter from 2.6.2 to 2.6.3 * Bump spring-hateoas from 1.4.0 to 1.4.1 * Bump tomcat from 9.0.56 to 9.0.58 > 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 > Labels: pull-request-available > > 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] [Resolved] (GEODE-9981) use more portable approach to getting crypto algorithm oid
[
https://issues.apache.org/jira/browse/GEODE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols resolved GEODE-9981.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> use more portable approach to getting crypto algorithm oid
> --
>
> Key: GEODE-9981
> URL: https://issues.apache.org/jira/browse/GEODE-9981
> Project: Geode
> Issue Type: Sub-task
>Reporter: Owen Nichols
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> instead of:
> `new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid)`
> this works with more jdk versions:
> AlgorithmId.get("MD5withRSA");
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9910) Failure to auto-reconnect upon network partition
[ https://issues.apache.org/jira/browse/GEODE-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9910: - Labels: blocks-1.15.0 (was: ) > Failure to auto-reconnect upon network partition > > > Key: GEODE-9910 > URL: https://issues.apache.org/jira/browse/GEODE-9910 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.0 >Reporter: Surya Mudundi >Priority: Major > Labels: blocks-1.15.0 > > Two node cluster with embedded locators failed to auto-reconnect when node-1 > experienced network outage for couple of minutes and when node-1 recovered > from the outage, node-2 failed to auto-reconnect. > node-2 tried to re-connect to node-1 as: > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #1. > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #2. > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #3. > Finally reported below error after 3 attempts as: > INFO > [org.apache.geode.logging.internal.LoggingProviderLoader]-[ReconnectThread] > [] Using org.apache.geode.logging.internal.SimpleLoggingProvider for service > org.apache.geode.logging.internal.spi.LoggingProvider > INFO [org.apache.geode.internal.InternalDataSerializer]-[ReconnectThread] [] > initializing InternalDataSerializer with 0 services > INFO > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] performing a quorum check to see if location services can be started early > INFO > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Quorum check passed - allowing location services to start early > WARN > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Exception occurred while trying to connect the system during reconnect > java.lang.IllegalStateException: A locator can not be created because one > already exists in this JVM. > at > org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:298) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:273) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSystem.java:916) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:768) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2605) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2424) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1275) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2326) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1187) > ~[geode-membership-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$forceDisconnect$0(GMSMembership.java:1811) > ~[geode-membership-1.14.0.jar:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (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 resolved GEODE-10046. -- Fix Version/s: 1.16.0 Resolution: Fixed This ticket will be reused for additional bumps ~monthly until we are close to cutting support/1.16 > 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 > Labels: pull-request-available > Fix For: 1.16.0 > > > 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-9981) use more portable approach to getting crypto algorithm oid
[
https://issues.apache.org/jira/browse/GEODE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9981:
Fix Version/s: 1.16.0
(was: 1.15.0)
> use more portable approach to getting crypto algorithm oid
> --
>
> Key: GEODE-9981
> URL: https://issues.apache.org/jira/browse/GEODE-9981
> Project: Geode
> Issue Type: Sub-task
>Reporter: Owen Nichols
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> instead of:
> `new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid)`
> this works with more jdk versions:
> AlgorithmId.get("MD5withRSA");
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
[ https://issues.apache.org/jira/browse/GEODE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10042: - Fix Version/s: 1.16.0 > ServerConnection would make the ClientUserAuths null when there are still > client using that connection > -- > > Key: GEODE-10042 > URL: https://issues.apache.org/jira/browse/GEODE-10042 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.3 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > In `handleTermination` method, when we calculate there are still client > threads using this connection, we should not cleanup clientUserAuth (this is > done correctly), but we make the clientUserAuth null regardless, this would > result in NPE sent down to the client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10019) add jira id to release-related commits
[ https://issues.apache.org/jira/browse/GEODE-10019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10019. -- Fix Version/s: 1.16.0 Resolution: Fixed > add jira id to release-related commits > -- > > Key: GEODE-10019 > URL: https://issues.apache.org/jira/browse/GEODE-10019 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > problem: commits generated during release process fail to adhere to Geode > commit-message standards: they do not include a Jira ticket. > > solution: add a required -j parameter to all release scripts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10019) add jira id to release-related commits
[ https://issues.apache.org/jira/browse/GEODE-10019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492874#comment-17492874 ] ASF subversion and git services commented on GEODE-10019: - Commit f20888e64283c61bbf4a8cac671642622595f237 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f20888e ] GEODE-10019: Obey rules on release commits (#7341) * prefix all release-related commits with a JIRA ticket number to comply with Geode commit message standards * provide commit message details for release-related commits * change release-related commit summaries to imperative style * change release-related commit messages to be under 30 characters * update benchmark baselines now correctly overrides any previous overrides * exclude stale data from update finder script > add jira id to release-related commits > -- > > Key: GEODE-10019 > URL: https://issues.apache.org/jira/browse/GEODE-10019 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > problem: commits generated during release process fail to adhere to Geode > commit-message standards: they do not include a Jira ticket. > > solution: add a required -j parameter to all release scripts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9710) Clean up PRColocationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-9710. Fix Version/s: 1.16.0 Resolution: Fixed > Clean up PRColocationDUnitTestHelper > > > Key: GEODE-9710 > URL: https://issues.apache.org/jira/browse/GEODE-9710 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17492908#comment-17492908
]
ASF subversion and git services commented on GEODE-10047:
-
Commit cd0b52e02bb4aeef7b35a2c5015cb7333481232e in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cd0b52e ]
GEODE-10047: Fix expiration interval log (#7359)
- Change naming of passive expiration to active expiration throughout
the geode-for-redis module so as to be consistent with Redis' language
- Replace hard-coded expiration interval of 1 second with a reference to
the configured expiration interval in log message in
PassiveExpirationManager (now named ActiveExpirationManager)
Authored-by: 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: 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] [Commented] (GEODE-10040) Fix intermittent clicache test failures
[ https://issues.apache.org/jira/browse/GEODE-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492910#comment-17492910 ] ASF subversion and git services commented on GEODE-10040: - Commit 642dbfd613bd08e944c51cae44acb7af005bc52d in geode-native's branch refs/heads/GEODE-10040-increase-gfsh-wait-timeout from Mike Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=642dbfd ] GEODE-10040: Increase MaxWaitMillis to 5min > Fix intermittent clicache test failures > --- > > Key: GEODE-10040 > URL: https://issues.apache.org/jira/browse/GEODE-10040 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > > Occassionaly we see timeouts in the CI when running the legacy clicache > tests. These appear to mostly be timeouts waiting for gfsh commands to > complete. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (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 resolved GEODE-10047.
-
Fix Version/s: 1.15.0
1.16.0
Resolution: Fixed
> 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
> Fix For: 1.15.0, 1.16.0
>
>
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=17492915#comment-17492915
]
ASF subversion and git services commented on GEODE-10047:
-
Commit 9f4f66ed9ed0f8fdba432c6df92184ee5adcc7eb in geode's branch
refs/heads/support/1.15 from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9f4f66e ]
GEODE-10047: Fix expiration interval log (#7359)
- Change naming of passive expiration to active expiration throughout
the geode-for-redis module so as to be consistent with Redis' language
- Replace hard-coded expiration interval of 1 second with a reference to
the configured expiration interval in log message in
PassiveExpirationManager (now named ActiveExpirationManager)
Authored-by: Donal Evans
(cherry picked from commit cd0b52e02bb4aeef7b35a2c5015cb7333481232e)
> 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
> Fix For: 1.15.0, 1.16.0
>
>
> 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-10040) Fix intermittent clicache test failures
[ https://issues.apache.org/jira/browse/GEODE-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10040: --- Labels: pull-request-available (was: ) > Fix intermittent clicache test failures > --- > > Key: GEODE-10040 > URL: https://issues.apache.org/jira/browse/GEODE-10040 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > Occassionaly we see timeouts in the CI when running the legacy clicache > tests. These appear to mostly be timeouts waiting for gfsh commands to > complete. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10040) Fix intermittent clicache test failures
[ https://issues.apache.org/jira/browse/GEODE-10040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492918#comment-17492918 ] ASF GitHub Bot commented on GEODE-10040: mmartell opened a new pull request #924: URL: https://github.com/apache/geode-native/pull/924 Occassionaly we see timeouts in the CI when running the legacy clicache tests. These appear to mostly be timeouts waiting for gfsh commands to complete. The error message varies depending on what branch you're on: - develop: "ExecuteGfsh: Timeout, killing 4604" - 10.2.7: "Timed out waiting for Java cacheserver to stop" -- 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 > Fix intermittent clicache test failures > --- > > Key: GEODE-10040 > URL: https://issues.apache.org/jira/browse/GEODE-10040 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > > Occassionaly we see timeouts in the CI when running the legacy clicache > tests. These appear to mostly be timeouts waiting for gfsh commands to > complete. -- This message was sent by Atlassian Jira (v8.20.1#820001)
