[jira] [Commented] (GEODE-9403) Dockerfile uses an unreliable key server
[ https://issues.apache.org/jira/browse/GEODE-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372291#comment-17372291 ] ASF subversion and git services commented on GEODE-9403: Commit b037f2f498c74ae88c408e9977235f33d6d4e77d in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b037f2f ] GEODE-9403: use a better keyserver in Dockerfile (#6648) * sks-keyservers is going away, so use a better one * also patch this change into support branches upon their next release > Dockerfile uses an unreliable key server > > > Key: GEODE-9403 > URL: https://issues.apache.org/jira/browse/GEODE-9403 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > This line in docker/Dockerfile stopped working for me: > `gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GEODE_GPG";` > I found that changing it to this works: > `gpg --keyserver [keyserver.ubuntu.com|http://keyserver.ubuntu.com/] > --recv-keys "$GEODE_GPG";` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9386) google-windows-geode-builder image doesn't properly delete geode directory after dependency caching
[ https://issues.apache.org/jira/browse/GEODE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9386: Fix Version/s: 1.12.4 > google-windows-geode-builder image doesn't properly delete geode directory > after dependency caching > --- > > Key: GEODE-9386 > URL: https://issues.apache.org/jira/browse/GEODE-9386 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.4, 1.13.4, 1.14.0, 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9386) google-windows-geode-builder image doesn't properly delete geode directory after dependency caching
[ https://issues.apache.org/jira/browse/GEODE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372273#comment-17372273 ] ASF subversion and git services commented on GEODE-9386: Commit 7f28bf6fa7302ffa9a6a9b3126e01566803b86d8 in geode's branch refs/heads/support/1.12 from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7f28bf6 ] [GEODE-9386] Fix windows builder cleanup (#6630) * Do './gradlew.bat clean' before C:/geode. (cherry picked from commit ecaf313a6747cf0c465b5cd5852a2304b753919c) (cherry picked from commit 63a0fe7148124912522cd4d1e3f2984993b0aea6) (cherry picked from commit 0cd41073d0a5e40e5eea98a4d7ee534307b474aa) > google-windows-geode-builder image doesn't properly delete geode directory > after dependency caching > --- > > Key: GEODE-9386 > URL: https://issues.apache.org/jira/browse/GEODE-9386 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Minor > Labels: pull-request-available > Fix For: 1.13.4, 1.14.0, 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[ https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7891: - Priority: Major (was: Minor) > User Guide refers to non-valid GemFire Properties > - > > Key: GEODE-7891 > URL: https://issues.apache.org/jira/browse/GEODE-7891 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: John Blum >Priority: Major > > The following properties in [GemFire > Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html] > are *NOT* valid (distributed system/config properties) according to the > [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java] > and > [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java] > classes! > Properties include: > {code:java} > "geode.disallow-internal-messages-without-credentials" > "tombstone-gc-threshold" > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[ https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7891: - Priority: Minor (was: Major) > User Guide refers to non-valid GemFire Properties > - > > Key: GEODE-7891 > URL: https://issues.apache.org/jira/browse/GEODE-7891 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: John Blum >Priority: Minor > > The following properties in [GemFire > Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html] > are *NOT* valid (distributed system/config properties) according to the > [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java] > and > [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java] > classes! > Properties include: > {code:java} > "geode.disallow-internal-messages-without-credentials" > "tombstone-gc-threshold" > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[ https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8256: - Priority: Blocker (was: Critical) > The Jackson ObjectMapper used by a PdxInstance does not properly handle Java > 8 Types > > > Key: GEODE-8256 > URL: https://issues.apache.org/jira/browse/GEODE-8256 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.9.2, 1.10.0, 1.11.0, 1.12.0 >Reporter: John Blum >Priority: Blocker > Labels: JSON-PDX > > The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see > [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is > not properly configured. > Specifically, it cannot handle *Java 8* types since these types are not > included in Jackson 2, by default, primarily because Jackson 2 is based on > Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle > Java 8 types, when configured properly with extension modules. > To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the > {{PdxInstance}} implementation, violates the _Open/Closed_ software design > principle, so there is literally no way to modify (i.e. override/extend) the > configuration of the {{ObjectMapper}} as required by the application. > See > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618] > for a test case demonstrating the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9405) Build fails on rhel-8 release
[ https://issues.apache.org/jira/browse/GEODE-9405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372187#comment-17372187 ] ASF GitHub Bot commented on GEODE-9405: --- mmartell commented on pull request #826: URL: https://github.com/apache/geode-native/pull/826#issuecomment-871690085 Converting to Draft for now. All but one of the files that fail to compile on rhel-8 due to strncpy warnings are disabled tests that use a bogus getXmlPath() function. This function not only uses an unsafe strncpy(), but uses an incorrect path to the Xml folder. Looks like this is an artifact of moving the Xml folder in native client 10, but not fixing up all the tests to use the new path. Rather than just fix the compile problem for tests that we never run, I think it is worth investigating whether we can reenable all these tests by using the correct path. Of course we will also fix the compile problem that's causing the build failure on rhel-8. The list of tests that experience this issue includes: testThinClientSecurityAuthentication.cpp (broken) testThinClientSecurityAuthenticationSetAuthInitialize.cpp testThinClientSecurityAuthorization.cpp (broken) testThinClientSecurityAuthorizationMU.cpp (broken) testThinClientSecurityCQAuthorizationMU.cpp (flaky) testThinClientSecurityDurableCQAuthorizationMU.cpp (broken) testThinClientWriterException.cpp (broken) ThinClientSecurityHelper.hpp (not a test) -- 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 > Build fails on rhel-8 release > - > > Key: GEODE-9405 > URL: https://issues.apache.org/jira/browse/GEODE-9405 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > Looks like a recent gcc compiler change on rhel-8 is causing build failures > in the CI. > Looks to be related to unsafe use of strncpy in a few of our legacy C++ tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[ https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372176#comment-17372176 ] ASF subversion and git services commented on GEODE-8971: Commit 9aa758f0c24a7bcaa0c4b2b76c64b6efbb2ddffc in geode's branch refs/heads/GEODE-9375-Implement-ZRANGE-Radish-command from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9aa758f ] Revert "GEODE-8971: Add grace period when stopping gateway sender with group-… (#6052)" (#6634) This reverts commit 841fa06c7b34916c09df920b7029974a78255cd0. The reason is that this commit creates problems with ongoing put operations during the grace period (very long response times) and also, if operations rate is high, it could prevent that the gateway sender is stopped. Put operations can be very slow during the grace period because they need to traverse the gateway sender queue to find events with the same transactionId. If the queue size is big and events are evicted to disk, the time to process a request can be unacceptably long. At the same time, this can provoke that the gateway sender is never stopped because it is blocked trying to get a write lock and the lock is held by ongoing operations for a long time. > Batches with incomplete transactions when stopping the gateway sender > - > > Key: GEODE-8971 > URL: https://issues.apache.org/jira/browse/GEODE-8971 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When the gateway sender is stopped there is a high probability that batches > with incomplete transactions are sent even if group-transaction-events is > enabled. > The reason is that once the stop command reaches the gateway sender, it > immediately stops queueing events, and this could happen in the middle of > receiving events for the same transaction. If this is the case, some events > for the transaction may have reached the queue right before the stop command > was received and the rest of events for that transaction would not make it to > the queue (they would be dropped) because they arrived right after the stop > command was received at the gateway sender. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9407) RegionDestroyedException while executing GetMemberInformationFunction
[ https://issues.apache.org/jira/browse/GEODE-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9407: -- Labels: pull-request-available (was: ) > RegionDestroyedException while executing GetMemberInformationFunction > - > > Key: GEODE-9407 > URL: https://issues.apache.org/jira/browse/GEODE-9407 > Project: Geode > Issue Type: Bug > Components: gfsh, management >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Minor > Labels: pull-request-available > > GetMemberInformationFunction is used by the gfsh "describe member" command, > the management REST API "/members" endpoint, and is also used internally > within Geode. If this function is invoked while concurrently destroying a > region, it may throw RegionDestroyedException while trying to gather > information about the destroyed region's subregions. > > This bug manifests as a nasty error message in the logs of the member where > the function was being executed (shown below). This confuses Geode > users/developers/operators because it looks like a problem with the system > while instead it's actually expected behavior. GetMemberInformationFunction > should probably catch RegionDestroyedException and remove the destroyed > region from the set of region names in ManagementUtils.getAllRegionNames. > > {code:java} > [error 2021/06/29 23:01:38.640 GMT system-test-gemfire-server-0 Execution Processor3> tid=0x94] Unable to gather runtime information on this > member. > org.apache.geode.cache.RegionDestroyedException: Partitioned Region @79f60edb > [path='/region'; dataPolicy=PARTITION; prId=37; isDestroyed=true; > isClosed=false; retryTimeout=360; serialNumber=4309; partition > attributes=PartitionAttributes@1299510666[redundantCopies=2;localMaxMemory=594;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null]; > on VM system-test-gemfire-server-0(system-test-gemfire-server-0:1):41000] > at > org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7342) > at > org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2757) > at > org.apache.geode.internal.cache.LocalRegion.subregions(LocalRegion.java:1908) > at > org.apache.geode.management.internal.util.ManagementUtils.getAllRegionNames(ManagementUtils.java:167) > at > org.apache.geode.management.internal.functions.GetMemberInformationFunction.getMemberInformation(GetMemberInformationFunction.java:131) > at > org.apache.geode.management.internal.configuration.realizers.MemberRealizer.get(MemberRealizer.java:52) > at > org.apache.geode.management.internal.configuration.realizers.MemberRealizer.get(MemberRealizer.java:35) > at > org.apache.geode.management.internal.functions.CacheRealizationFunction.executeGet(CacheRealizationFunction.java:136) > at > org.apache.geode.management.internal.functions.CacheRealizationFunction.execute(CacheRealizationFunction.java:92) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.base/java.lang.Thread.run(Thread.java:829){code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9407) RegionDestroyedException while executing GetMemberInformationFunction
[ https://issues.apache.org/jira/browse/GEODE-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-9407: Assignee: Aaron Lindsey > RegionDestroyedException while executing GetMemberInformationFunction > - > > Key: GEODE-9407 > URL: https://issues.apache.org/jira/browse/GEODE-9407 > Project: Geode > Issue Type: Bug > Components: gfsh, management >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Minor > > GetMemberInformationFunction is used by the gfsh "describe member" command, > the management REST API "/members" endpoint, and is also used internally > within Geode. If this function is invoked while concurrently destroying a > region, it may throw RegionDestroyedException while trying to gather > information about the destroyed region's subregions. > > This bug manifests as a nasty error message in the logs of the member where > the function was being executed (shown below). This confuses Geode > users/developers/operators because it looks like a problem with the system > while instead it's actually expected behavior. GetMemberInformationFunction > should probably catch RegionDestroyedException and remove the destroyed > region from the set of region names in ManagementUtils.getAllRegionNames. > > {code:java} > [error 2021/06/29 23:01:38.640 GMT system-test-gemfire-server-0 Execution Processor3> tid=0x94] Unable to gather runtime information on this > member. > org.apache.geode.cache.RegionDestroyedException: Partitioned Region @79f60edb > [path='/region'; dataPolicy=PARTITION; prId=37; isDestroyed=true; > isClosed=false; retryTimeout=360; serialNumber=4309; partition > attributes=PartitionAttributes@1299510666[redundantCopies=2;localMaxMemory=594;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null]; > on VM system-test-gemfire-server-0(system-test-gemfire-server-0:1):41000] > at > org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7342) > at > org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2757) > at > org.apache.geode.internal.cache.LocalRegion.subregions(LocalRegion.java:1908) > at > org.apache.geode.management.internal.util.ManagementUtils.getAllRegionNames(ManagementUtils.java:167) > at > org.apache.geode.management.internal.functions.GetMemberInformationFunction.getMemberInformation(GetMemberInformationFunction.java:131) > at > org.apache.geode.management.internal.configuration.realizers.MemberRealizer.get(MemberRealizer.java:52) > at > org.apache.geode.management.internal.configuration.realizers.MemberRealizer.get(MemberRealizer.java:35) > at > org.apache.geode.management.internal.functions.CacheRealizationFunction.executeGet(CacheRealizationFunction.java:136) > at > org.apache.geode.management.internal.functions.CacheRealizationFunction.execute(CacheRealizationFunction.java:92) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.base/java.lang.Thread.run(Thread.java:829){code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9205) Implement NUMPAT Subcommand
[ https://issues.apache.org/jira/browse/GEODE-9205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372010#comment-17372010 ] ASF subversion and git services commented on GEODE-9205: Commit 0ea005d5d7d1deb5ebe9639b34b0294af577b51d in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0ea005d ] GEODE-9205: Implement Radish PUBSUB NUMPAT subcommand (#6642) > Implement NUMPAT Subcommand > --- > > Key: GEODE-9205 > URL: https://issues.apache.org/jira/browse/GEODE-9205 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [NUMPAT|https://redis.io/commands/pubsub#codepubsub-numpatcode] > subcommand. > > +Acceptance Criteria+ > The NUMPAT subcommand has been implemented and unit tests have been developed > that assert that the command correctly returns the number of subscriptions to > patterns (that are performed using the > [PSUBSCRIBE|https://redis.io/commands/psubscribe] command). Note that this is > not just the count of clients subscribed to patterns but the total number of > patterns all the clients are subscribed to. > h5. Return value > [Integer reply|https://redis.io/topics/protocol#integer-reply]: the number of > patterns all the clients are subscribed to. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9405) Build fails on rhel-8 release
[ https://issues.apache.org/jira/browse/GEODE-9405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372003#comment-17372003 ] ASF GitHub Bot commented on GEODE-9405: --- mmartell commented on a change in pull request #826: URL: https://github.com/apache/geode-native/pull/826#discussion_r661476785 ## File path: cppcache/integration-test/CMakeLists.txt ## @@ -205,7 +205,7 @@ set_tests_properties( testThinClientPoolAttrTest testThinClientPoolLocator testThinClientPoolRedundancy -testThinClientSecurityAuthentication +#testThinClientSecurityAuthentication Review comment: Actually forgot to uncomment this. I was trying to see if fixing getXmlPath() would fix this test. It doesn't, so I'll disable this test again. -- 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 > Build fails on rhel-8 release > - > > Key: GEODE-9405 > URL: https://issues.apache.org/jira/browse/GEODE-9405 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > Looks like a recent gcc compiler change on rhel-8 is causing build failures > in the CI. > Looks to be related to unsafe use of strncpy in a few of our legacy C++ tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9408) Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true
[ https://issues.apache.org/jira/browse/GEODE-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9408: -- Labels: pull-request-available (was: ) > Avoid duplicate events sent by Serial Gateway Sender when > group-transaction-events is true > -- > > Key: GEODE-9408 > URL: https://issues.apache.org/jira/browse/GEODE-9408 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When group-transaction-events is set to true for a serial gateway sender, it > is possible that events that were retrieved from the queue to be added to a > batch in order to complete a transaction are later sent again in another > batch due to a bug in the removal logic of events when the ack for a batch is > received from the receiver. > This situation has been seen when several clients are sending transactions to > a Geode cluster when the events for the transactions sent by the clients are > mixed in the gateway sender queue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9408) Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true
[ https://issues.apache.org/jira/browse/GEODE-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-9408: Assignee: Alberto Gomez > Avoid duplicate events sent by Serial Gateway Sender when > group-transaction-events is true > -- > > Key: GEODE-9408 > URL: https://issues.apache.org/jira/browse/GEODE-9408 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > When group-transaction-events is set to true for a serial gateway sender, it > is possible that events that were retrieved from the queue to be added to a > batch in order to complete a transaction are later sent again in another > batch due to a bug in the removal logic of events when the ack for a batch is > received from the receiver. > This situation has been seen when several clients are sending transactions to > a Geode cluster when the events for the transactions sent by the clients are > mixed in the gateway sender queue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9408) Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true
Alberto Gomez created GEODE-9408: Summary: Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true Key: GEODE-9408 URL: https://issues.apache.org/jira/browse/GEODE-9408 Project: Geode Issue Type: Bug Components: wan Reporter: Alberto Gomez When group-transaction-events is set to true for a serial gateway sender, it is possible that events that were retrieved from the queue to be added to a batch in order to complete a transaction are later sent again in another batch due to a bug in the removal logic of events when the ack for a batch is received from the receiver. This situation has been seen when several clients are sending transactions to a Geode cluster when the events for the transactions sent by the clients are mixed in the gateway sender queue. -- This message was sent by Atlassian Jira (v8.3.4#803005)