[jira] [Assigned] (GEODE-9472) Improve Test Stability of VerifyNoLeakedThreads
[ https://issues.apache.org/jira/browse/GEODE-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9472: Assignee: Michael Martell > Improve Test Stability of VerifyNoLeakedThreads > --- > > Key: GEODE-9472 > URL: https://issues.apache.org/jira/browse/GEODE-9472 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This test fails occasionally in the CI due to the heuristic being a little > too stringent for such a dynamic environment. Just need to broaden the > acceptable range for the ratio process threads before and after a cache > operation and cache close. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9511) Allow Default WindowsSDK in ACE cmake build
[
https://issues.apache.org/jira/browse/GEODE-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9511:
Assignee: Michael Martell
> Allow Default WindowsSDK in ACE cmake build
> ---
>
> Key: GEODE-9511
> URL: https://issues.apache.org/jira/browse/GEODE-9511
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Major
> Labels: pull-request-available
>
> The cmake configuration file for ACE currently uses the CMAKE_SYSTEM_VERSION
> variable to set the WindowsTargetPlatformVersion for ACE's build system
> (called MPC):
> set ( _CONFIGURE_COMMAND ${MPC} -static ${MPC_FLAGS}
> -name_modifier "*_${MPC_TYPE}_static"
> -value_template MultiProcessorCompilation=true
> -value_template WindowsTargetPlatformVersion=${CMAKE_SYSTEM_VERSION} set (
> _CONFIGURE_COMMAND ${MPC} -static ${MPC_FLAGS}
> -name_modifier "*_${MPC_TYPE}_static"
> -value_template MultiProcessorCompilation=true
> -value_template WindowsTargetPlatformVersion=${CMAKE_SYSTEM_VERSION}
>
> This requires the user to pass in a proper value for CMAKE_SYSTEM_VERSION on
> the cmake config line:
> cmake -DCMAKE_SYSTEM_VERSION=10.0.19041.0
> due to an apparent error in the default value of this variable which leaves
> off the last part (i.e., .0 above).
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9501) Support Latest Microsoft Platform Toolset and Compilers for C++
[ https://issues.apache.org/jira/browse/GEODE-9501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9501: Assignee: Blake Bender > Support Latest Microsoft Platform Toolset and Compilers for C++ > --- > > Key: GEODE-9501 > URL: https://issues.apache.org/jira/browse/GEODE-9501 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Martell >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > Currently, the Windows build of geode-native uses Platform Toolset v141. This > ticket is to build using the default Platform Toolset and compiler which is > v142. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9509) CI Failure: RedisPartitionResolverDUnitTest fails with suspect strings
[
https://issues.apache.org/jira/browse/GEODE-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9509:
Assignee: Dan Smith
> CI Failure: RedisPartitionResolverDUnitTest fails with suspect strings
> --
>
> Key: GEODE-9509
> URL: https://issues.apache.org/jira/browse/GEODE-9509
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Dan Smith
>Priority: Major
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.cluster.RedisPartitionResolverDUnitTest >
> classMethod FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 713
> [fatal 2021/08/14 18:02:15.696 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 777
> [fatal 2021/08/14 18:02:28.025 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 785
> [fatal 2021/08/14 18:02:28.028 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 793
> [fatal 2021/08/14 18:02:28.064 UTC tid=57]
> Exception in processing request from 10.0.0.113
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Hit occurrence limit of 5 for this string.
> Further reporting of this type of error will be suppressed.
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
> at
>
[jira] [Assigned] (GEODE-9524) Make name of directory agree with library name for C bindings
[ https://issues.apache.org/jira/browse/GEODE-9524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9524: Assignee: Blake Bender > Make name of directory agree with library name for C bindings > - > > Key: GEODE-9524 > URL: https://issues.apache.org/jira/browse/GEODE-9524 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Path uses c_bindings with a '_', but the library is c-bindings with a "-". > Switch to "-" everywhere for consistency. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9522: Assignee: Xiaojian Zhou > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9518) Implement ZUNIONSTORE Command
[ https://issues.apache.org/jira/browse/GEODE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9518: Assignee: Jens Deppe > Implement ZUNIONSTORE Command > - > > Key: GEODE-9518 > URL: https://issues.apache.org/jira/browse/GEODE-9518 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [ZUNIONSTORE|https://redis.io/commands/zunionstore] Command, > with all options, and associated tests. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9549) Enable .net core tests in CI
[ https://issues.apache.org/jira/browse/GEODE-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9549: Assignee: Blake Bender > Enable .net core tests in CI > > > Key: GEODE-9549 > URL: https://issues.apache.org/jira/browse/GEODE-9549 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > The .net core build and tests are integrated into the CI, but test running is > currently disabled due to a few issues. These need to be cleaned up, and > tests enabled in CI. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9542: Assignee: Jens Deppe > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > When the ssl-require-authentication Geode property is set to true, we should > validate the Redis client's certificate against the configured ssl-truststore > to ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the Geode property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9559) Demacroize clicache
[ https://issues.apache.org/jira/browse/GEODE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9559: Assignee: Michael Martell > Demacroize clicache > > > Key: GEODE-9559 > URL: https://issues.apache.org/jira/browse/GEODE-9559 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > > Macros in C++ complicate debug efforts and code maintenance and are generally > considered old school ([https://stroustrup.com/icsm-2012-demacro.pdf).] This > PR is to remove all the complicated macros in the .NET Framework client, e.g. > the clicache module. > In addition to improving the maintainability of the clicache module, removing > the macros will greatly assist the creation of the .NET Core client. [dotPeek > |http://jetbrains.com/decompiler/] is proving to be a valuable tool in the > .NET Core project, but is currently limited by the extensive use of macros in > the clicache code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9550) Native Client user guide: warn against floating point values in keys
[ https://issues.apache.org/jira/browse/GEODE-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9550: Assignee: Dave Barnes > Native Client user guide: warn against floating point values in keys > > > Key: GEODE-9550 > URL: https://issues.apache.org/jira/browse/GEODE-9550 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Affects Versions: 1.13.4 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.4, 1.13.4, 1.14.0, 1.15.0 > > > Request from a community member: > You should NEVER use a floating point value as a key, or key component, but > for some reason we allow it. > Since this can't be prevented in code, warn against this practice in the docs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9553) Review and eliminate all remaining usage of sprintf, snprintf, etc
[
https://issues.apache.org/jira/browse/GEODE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9553:
Assignee: Blake Bender
> Review and eliminate all remaining usage of sprintf, snprintf, etc
> --
>
> Key: GEODE-9553
> URL: https://issues.apache.org/jira/browse/GEODE-9553
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> From time to time, we will pick up a new version of a compiler on one or
> another platform we build on, and get new complaints about potential buffer
> overflows or other assorted badness around persistent use of sprintf. See
> the following pull request, e.g.:
> https://github.com/apache/geode-native/pull/861
> Fixing these when they come up is good as far as it goes, but we're really
> just applying band-aids to the problem. *All* use of sprintf is bad,
> snprintf only slightly less so. Someone needs to just go through the code
> and rewrite all instances in modern C++ using std::string, std::stringstream,
> etc.
> At a glance, here is the list of remaining files containing calls to sprintf:
> {code}
> c:\Users\bblake\src\geode-native>findstr /sm sprintf *.cpp
> cppcache\integration\test\ThinClientConflation.cpp
> cppcache\integration-test\fw_dunit.cpp
> cppcache\integration-test\testCacheless.cpp
> cppcache\integration-test\testOverflowPutGetSqLite.cpp
> cppcache\integration-test\testRegionMap.cpp
> cppcache\integration-test\testSerialization.cpp
> cppcache\integration-test\testThinClientBigValue.cpp
> cppcache\integration-test\testThinClientCacheablesLimits.cpp
> cppcache\integration-test\testThinClientCacheableStringArray.cpp
> cppcache\integration-test\testThinClientConflation.cpp
> cppcache\integration-test\testThinClientCq.cpp
> cppcache\integration-test\testThinClientCqDurable.cpp
> cppcache\integration-test\testThinClientCqFailover.cpp
> cppcache\integration-test\testThinClientCqHAFailover.cpp
> cppcache\integration-test\testThinClientCqIR.cpp
> cppcache\integration-test\testThinClientDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientGetInterests.cpp
> cppcache\integration-test\testThinClientHADistOps.cpp
> cppcache\integration-test\testThinClientHAEventIDMap.cpp
> cppcache\integration-test\testThinClientHAFailover.cpp
> cppcache\integration-test\testThinClientHAFailoverRegex.cpp
> cppcache\integration-test\testThinClientHAMixedRedundancy.cpp
> cppcache\integration-test\testThinClientHAPeriodicAck.cpp
> cppcache\integration-test\testThinClientHeapLRU.cpp
> cppcache\integration-test\testThinClientInterest1_Bug1001.cpp
> cppcache\integration-test\testThinClientInterestNotify.cpp
> cppcache\integration-test\testThinClientIntResPolKeysInv.cpp
> cppcache\integration-test\testThinClientListenerCallbackArgTest.cpp
> cppcache\integration-test\testThinClientLRUExpiration.cpp
> cppcache\integration-test\testThinClientMultiDS.cpp
> cppcache\integration-test\testThinClientNotificationWithDeltaWithoutcache.cpp
> cppcache\integration-test\testThinClientPdxDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientPdxInstance.cpp
> cppcache\integration-test\testThinClientPoolAttrTest.cpp
> cppcache\integration-test\testThinClientPoolExecuteFunctionThrowsException.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunction.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunctionPrSHOP.cpp
> cppcache\integration-test\testThinClientPoolRedundancy.cpp
> cppcache\integration-test\testThinClientPRPutAllFailover.cpp
> cppcache\integration-test\testThinClientRemoteQueryRS.cpp
> cppcache\integration-test\testThinClientRemoteQuerySS.cpp
> cppcache\integration-test\testThinClientRemoteRegionQuery.cpp
> cppcache\integration-test\testThinClientRemoveOps.cpp
> cppcache\integration-test\testThinClientSecurityPostAuthorization.cpp
> cppcache\integration-test\testXmlCacheCreationWithPools.cpp
> cppcache\integration-test\testXmlCacheInitialization.cpp
> tests\cpp\security\PkcsCredentialGenerator.cpp
> tests\cpp\security\XmlAuthzCredentialGenerator.cpp
> tests\cpp\testobject\BatchObject.cpp
> tests\cpp\testobject\DeltaPSTObject.cpp
> tests\cpp\testobject\DeltaTestImpl.cpp
> tests\cpp\testobject\EqStruct.cpp
> tests\cpp\testobject\FastAssetAccount.cpp
> tests\cpp\testobject\InvalidPdxUsage.cpp
> tests\cpp\testobject\NestedPdxObject.cpp
> tests\cpp\testobject\PdxClassV1.cpp
> tests\cpp\testobject\PdxClassV2.cpp
> tests\cpp\testobject\PdxType.cpp
> tests\cpp\testobject\Portfolio.cpp
> tests\cpp\testobject\PortfolioPdx.cpp
> tests\cpp\testobject\Position.cpp
> tests\cpp\testobject\PositionPdx.cpp
>
[jira] [Assigned] (GEODE-9560) ECHO Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9560: Assignee: Donal Evans > ECHO Command Supported > -- > > Key: GEODE-9560 > URL: https://issues.apache.org/jira/browse/GEODE-9560 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers for the following command: > ECHO > +Acceptance Criteria+ > Unit/integration tests for both Geode and native Redis passing > DUNIT tests passing > README/redis_api_for_geode.html.md.erb updated to make command "supported" > or > Stories in the backlog to fix the identified issues (with JIRA tickets) and > problem tests that are ignored should be fixed and enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9578) bump spring-security to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9578: Assignee: Kirk Lund > bump spring-security to recommended version > --- > > Key: GEODE-9578 > URL: https://issues.apache.org/jira/browse/GEODE-9578 > Project: Geode > Issue Type: Improvement > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.12.5, 1.13.5, 1.14.1 > > > 1.14 has spring-security 5.4.5, will bump to 5.4.8 > 1.13 has spring-security 5.3.9, will bump to 5.3.11 > 1.12 has spring-security 5.2.10, will bump to 5.2.12 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9608) Compile NetCore Projects with Warnings as Errors and Add RelWithDebInfo
[ https://issues.apache.org/jira/browse/GEODE-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9608: Assignee: Michael Martell > Compile NetCore Projects with Warnings as Errors and Add RelWithDebInfo > --- > > Key: GEODE-9608 > URL: https://issues.apache.org/jira/browse/GEODE-9608 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > > The NetCore projects should be compiled with Warnings as Errors to be > consistent with other geode-native components. Also, some of the projects are > missing RelWithDebInfo configuration. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9606) CI Failure: PubSubIntegrationTest.testPatternWithoutAGlob fails with AssertionError
[ https://issues.apache.org/jira/browse/GEODE-9606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9606: Assignee: Jens Deppe > CI Failure: PubSubIntegrationTest.testPatternWithoutAGlob fails with > AssertionError > --- > > Key: GEODE-9606 > URL: https://issues.apache.org/jira/browse/GEODE-9606 > Project: Geode > Issue Type: Bug > Components: redis, tests >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Jens Deppe >Priority: Major > Labels: flaky-test, pull-request-available, unreleased > Fix For: 1.15.0 > > > The following failure occurred in a CI run: > org.apache.geode.redis.internal.executor.pubsub.PubSubIntegrationTest > > testPatternWithoutAGlob FAILED > java.lang.AssertionError: > Expecting actual: > [] > to contain exactly (and in same order): > ["hello"] > but could not find the following elements: > ["hello"] > at > org.apache.geode.redis.internal.executor.pubsub.AbstractPubSubIntegrationTest.testPatternWithoutAGlob(AbstractPubSubIntegrationTest.java:774) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) > at >
[jira] [Assigned] (GEODE-9609) Fix Compiler Warning in NetCore SessionState Project
[ https://issues.apache.org/jira/browse/GEODE-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9609: Assignee: Michael Martell > Fix Compiler Warning in NetCore SessionState Project > > > Key: GEODE-9609 > URL: https://issues.apache.org/jira/browse/GEODE-9609 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9629) GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API
[ https://issues.apache.org/jira/browse/GEODE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9629: Assignee: Owen Nichols > GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API > - > > Key: GEODE-9629 > URL: https://issues.apache.org/jira/browse/GEODE-9629 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Assignee: Owen Nichols >Priority: Blocker > Labels: pull-request-available > Fix For: 1.15.0 > > > GatewaySender.setRetriesToGetTransactionEventsFromQueue is defined on the > public API. > The problem with this is that Geode should not allow for the simple > modification of settings for a GatewaySender. Without proper process / > management around the changing of the properties it would be too simple to > introduce side-effects by changing settings on the GatewaySender. > We (Geode) should NOT allow for the direct manipulation of configuration of > ANY component without it having gone through a controlled process, to ensure > that there aren't any side effects resulting from the change. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9630: Assignee: Owen Nichols > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Assignee: Owen Nichols >Priority: Blocker > Labels: pull-request-available > Fix For: 1.15.0 > > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9634: Assignee: Jacob Barrett > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jacob Barrett >Priority: Blocker > Labels: pull-request-available > Fix For: 1.15.0 > > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9639) Make native client compatible with C++20
[ https://issues.apache.org/jira/browse/GEODE-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9639: Assignee: Matthew Reddington > Make native client compatible with C++20 > > > Key: GEODE-9639 > URL: https://issues.apache.org/jira/browse/GEODE-9639 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Assignee: Matthew Reddington >Priority: Major > Labels: pull-request-available > > There are standard library components that were removed in C++20, making our > library incompatible. Luckily, our use of deleted components are minimal and > replaceable without breaking API backward compatibility, but it will disrupt > ABI compatibility. > > The outcome needs to be tested against MSVC2017/v141 and MSVC2019/v142, > including examples. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9649) enforce use of version constraints in build and pom
[ https://issues.apache.org/jira/browse/GEODE-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9649: Assignee: Robert Houghton > enforce use of version constraints in build and pom > --- > > Key: GEODE-9649 > URL: https://issues.apache.org/jira/browse/GEODE-9649 > Project: Geode > Issue Type: Improvement > Components: build >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Create a spotless rule that ensures all dependencies are fetched from the > constraints BOM where possible. Some exceptions are tomcat, for which we have > several different versions, all in their own sub-modules -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9655) bump shiro to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9655: Assignee: Owen Nichols > bump shiro to recommended version > - > > Key: GEODE-9655 > URL: https://issues.apache.org/jira/browse/GEODE-9655 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage > Fix For: 1.12.5, 1.13.5, 1.14.1 > > > 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9673) CI Failure: AuthExpirationDUnitTest > newClient_registeredInterest_slowReAuth_policyNone_durableClient
[
https://issues.apache.org/jira/browse/GEODE-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9673:
Assignee: Jinmei Liao
> CI Failure: AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient
> --
>
> Key: GEODE-9673
> URL: https://issues.apache.org/jira/browse/GEODE-9673
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jinmei Liao
>Priority: Major
>
> AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient failed with
> the following stacktrace (abridged for readability):
> {code:java}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$612/337713063.run
> in VM 0 running on Host
> heavy-lifter-2a774957-60f5-572d-bfa8-d0f3496af7cb.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.newClient_registeredInterest_slowReAuth_policyNone_durableClient(AuthExpirationDUnitTest.java:629)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.security.AuthExpirationDUnitTest that uses
> org.apache.geode.cache.Region
> Expected size: 100 but was: 88 in:
> ["key93",
> ...,
> "key55"] within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$newClient_registeredInterest_slowReAuth_policyNone_durableClient$bb17a952$2(AuthExpirationDUnitTest.java:631)
> Caused by:
> java.lang.AssertionError:
> Expected size: 100 but was: 88 in:
> ["key93",
> ...,
> "key55"]
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$17(AuthExpirationDUnitTest.java:632)
> {code}
> CI Failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/241#B
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9661) CI failure: SetRangeNativeRedisAcceptanceTest because native redis server went down
[ https://issues.apache.org/jira/browse/GEODE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9661: Assignee: Donal Evans > CI failure: SetRangeNativeRedisAcceptanceTest because native redis server > went down > --- > > Key: GEODE-9661 > URL: https://issues.apache.org/jira/browse/GEODE-9661 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Donal Evans >Priority: Major > Labels: ci-failure, flaky > > Given that this is caused by a crash of the native redis server, this ticket > should not hold up a geode release. > SetRangeNativeRedisAcceptanceTest > setRange_replacesMiddle FAILED > redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The > cluster is down -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9679) Improve Test Coverage for SingleResultCollector
[ https://issues.apache.org/jira/browse/GEODE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9679: Assignee: Darrel Schneider > Improve Test Coverage for SingleResultCollector > --- > > Key: GEODE-9679 > URL: https://issues.apache.org/jira/browse/GEODE-9679 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.15.0 > > > The org.apache.geode.redis.internal.executor.SingleResultCollector has > insufficient test coverage that must be improved. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9686) Upgrade GemfireDataCommandsDistributedTestBase to not use deprecated methods
[ https://issues.apache.org/jira/browse/GEODE-9686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9686: Assignee: Nabarun Nag > Upgrade GemfireDataCommandsDistributedTestBase to not use deprecated methods > > > Key: GEODE-9686 > URL: https://issues.apache.org/jira/browse/GEODE-9686 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > * remove all deprecated components. > * the overriding method was lost in one of the refactorings and hence the > http version of the test was not testing the http component. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9687) Remove deprecated elements from RegionMembershipMBeanDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9687: Assignee: Nabarun Nag > Remove deprecated elements from RegionMembershipMBeanDistributedTestBase > > > Key: GEODE-9687 > URL: https://issues.apache.org/jira/browse/GEODE-9687 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9688) .Net core builds should be x64
[ https://issues.apache.org/jira/browse/GEODE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9688: Assignee: Blake Bender > .Net core builds should be x64 > -- > > Key: GEODE-9688 > URL: https://issues.apache.org/jira/browse/GEODE-9688 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ernest Burghardt >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9705) When create PR failed with DistributedSystemDisconnectedException, should use it as cause of PartitionedRegionException
[ https://issues.apache.org/jira/browse/GEODE-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9705: Assignee: Xiaojian Zhou > When create PR failed with DistributedSystemDisconnectedException, should use > it as cause of PartitionedRegionException > --- > > Key: GEODE-9705 > URL: https://issues.apache.org/jira/browse/GEODE-9705 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When PR failed with register itself, it will throw > DistributedSystemDisconnectedException in cleanupFailedInitialization(). > LockServiceDestroyedException should be the cause of > DistributedSystemDisconnectedException. > Currently, we throw PartitionedRegionException directly using > LockServiceDestroyedException, which is not expected. > The fix is to throw PartitionedRegionException using > DistributedSystemDisconnectedException (or any other RuntimeException) as > cause, then set LockServiceDestroyedException as the cause of the cause. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9693) Remove deprecated elements from ListIndexCommandDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9693: Assignee: Nabarun Nag > Remove deprecated elements from ListIndexCommandDistributedTestBase > --- > > Key: GEODE-9693 > URL: https://issues.apache.org/jira/browse/GEODE-9693 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9709) Clean up GcCommandDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9709: Assignee: Nabarun Nag > Clean up GcCommandDUnitTest > --- > > Key: GEODE-9709 > URL: https://issues.apache.org/jira/browse/GEODE-9709 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9732) CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException: CLUSTERDOWN The cluster is down
[
https://issues.apache.org/jira/browse/GEODE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9732:
Assignee: Donal Evans
> CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException:
> CLUSTERDOWN The cluster is down
> -
>
> Key: GEODE-9732
> URL: https://issues.apache.org/jira/browse/GEODE-9732
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Donal Evans
>Priority: Major
>
> Looks like every test in the class fails when whatever caused this happens.
> {noformat}
> ExpireNativeRedisAcceptanceTest >
> usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> at redis.clients.jedis.Jedis.hset(Jedis.java:831)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:652)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:649)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.hset(JedisCluster.java:654)
> at
> org.apache.geode.redis.internal.executor.key.AbstractExpireIntegrationTest.usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey(AbstractExpireIntegrationTest.java:268)
> 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.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:121)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
>
[jira] [Assigned] (GEODE-9710) Clean up PRColocationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9710: Assignee: Nabarun Nag > 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 >Assignee: 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] [Assigned] (GEODE-9761) CI Failure in ZRevRangeByScoreNativeRedisAcceptanceTest.shouldReturnEmptyList_givenZeroCount
[
https://issues.apache.org/jira/browse/GEODE-9761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9761:
Assignee: Owen Nichols
> CI Failure in
> ZRevRangeByScoreNativeRedisAcceptanceTest.shouldReturnEmptyList_givenZeroCount
>
>
> Key: GEODE-9761
> URL: https://issues.apache.org/jira/browse/GEODE-9761
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
>
> {noformat}
> ZRevRangeByScoreNativeRedisAcceptanceTest >
> shouldReturnEmptyList_givenZeroCount FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> at redis.clients.jedis.Jedis.zadd(Jedis.java:1716)
> at redis.clients.jedis.JedisCluster$83.execute(JedisCluster.java:1104)
> at redis.clients.jedis.JedisCluster$83.execute(JedisCluster.java:1101)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode.redis.internal.executor.sortedset.AbstractZRevRangeByScoreIntegrationTest.createZSetRangeTestMap(AbstractZRevRangeByScoreIntegrationTest.java:362)
> at
> org.apache.geode.redis.internal.executor.sortedset.AbstractZRevRangeByScoreIntegrationTest.shouldReturnEmptyList_givenZeroCount(AbstractZRevRangeByScoreIntegrationTest.java:236)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9762) CI Failure in ZRevRangeByScoreNativeRedisAcceptanceTest.shouldReturnRange_givenMultipleMembersWithDifferentScores
[
https://issues.apache.org/jira/browse/GEODE-9762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9762:
Assignee: Owen Nichols
> CI Failure in
> ZRevRangeByScoreNativeRedisAcceptanceTest.shouldReturnRange_givenMultipleMembersWithDifferentScores
> -
>
> Key: GEODE-9762
> URL: https://issues.apache.org/jira/browse/GEODE-9762
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
>
> {noformat}
> ZRevRangeByScoreNativeRedisAcceptanceTest >
> shouldReturnRange_givenMultipleMembersWithDifferentScores FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> at redis.clients.jedis.Jedis.zadd(Jedis.java:1716)
> at redis.clients.jedis.JedisCluster$83.execute(JedisCluster.java:1104)
> at redis.clients.jedis.JedisCluster$83.execute(JedisCluster.java:1101)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode.redis.internal.executor.sortedset.AbstractZRevRangeByScoreIntegrationTest.shouldReturnRange_givenMultipleMembersWithDifferentScores(AbstractZRevRangeByScoreIntegrationTest.java:135)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9771) change CI target for Java API test
[
https://issues.apache.org/jira/browse/GEODE-9771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9771:
Assignee: Robert Houghton
> change CI target for Java API test
> --
>
> Key: GEODE-9771
> URL: https://issues.apache.org/jira/browse/GEODE-9771
> Project: Geode
> Issue Type: Test
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Robert Houghton
>Assignee: Robert Houghton
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> In preparation for moving the {{japicmp}} test-target in Gradle, move to a
> more generic target in our CI definition
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9775) CI changes in preparation for change in cloud infrastructure
[ https://issues.apache.org/jira/browse/GEODE-9775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9775: Assignee: Sean Goller > CI changes in preparation for change in cloud infrastructure > > > Key: GEODE-9775 > URL: https://issues.apache.org/jira/browse/GEODE-9775 > Project: Geode > Issue Type: Improvement > Components: ci >Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > The way CI currently obtains some cloud infrastructure information will no > longer be available when we migrate. This issue covers the necessary changes > that can be done in advance to maintain compatibility. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9783) stray jars in pulse.war
[ https://issues.apache.org/jira/browse/GEODE-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9783: Assignee: Owen Nichols > stray jars in pulse.war > --- > > Key: GEODE-9783 > URL: https://issues.apache.org/jira/browse/GEODE-9783 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.5 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.12.6 > > > due to an issue backporting GEODE-9486, a couple unneeded jars appeared in > the war file for pulse in 1.12.5 only. while harmless, this should be > cleaned up. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9822) Split-brain Certain During Network Partition in Two-Locator Cluster
[ https://issues.apache.org/jira/browse/GEODE-9822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9822: Assignee: Bill Burcham > Split-brain Certain During Network Partition in Two-Locator Cluster > --- > > Key: GEODE-9822 > URL: https://issues.apache.org/jira/browse/GEODE-9822 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > In a two-locator cluster with default member weights and default setting > (true) of enable-network-partition-detection, if a long-lived network > partition separates the two members, a split-brain will arise: there will be > two coordinators at the same time. > The reason for this can be found in the GMSJoinLeave.isNetworkPartition() > method. That method's name is misleading. A name like isMajorityLost() would > probably be more apt. It needs to return true iff the weight of "crashed" > members (in the prospective view) is greater-than-or-equal-to half (50%) of > the total weight (of all members in the current view). > What the method actually does is return true iff the weight of "crashed" > members is greater-than 51% of the total weight. As a result, if we have two > members of equal weight, and the coordinator sees that the non-coordinator is > "crashed", the coordinator will keep running. If a network partition is > happening, and the non-coordinator is still running, then it will become a > coordinator and start producing views. Now we'll have two coordinators > producing views concurrently. > For this discussion "crashed" members are members for which the coordinator > has received a RemoveMemberRequest message. These are members that the > failure detector has deemed failed. Keep in mind the failure detector is > imperfect (it's not always right), and that's kind of the whole point of this > ticket: we've lost contact with the non-coordinator member, but that doesn't > mean it can't still be running (on the other side of a partition). > This bug is not limited to the two-locator scenario. Any set of members that > can be partitioned into two equal sets is susceptible. In fact it's even a > little worse than that. Any set of members that can be partitioned (into more > than one set), where any two-or-more sets, each still have 49% or more of the > total weight, will result in a split-brain -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9812) Kill multiple Radish servers expecting operations to continue
[ https://issues.apache.org/jira/browse/GEODE-9812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9812: Assignee: Jens Deppe > Kill multiple Radish servers expecting operations to continue > - > > Key: GEODE-9812 > URL: https://issues.apache.org/jira/browse/GEODE-9812 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Kill more than one server and expect the distributed system to recover. Data > loss is expected. The motivation behind this test is to ensure that, in a > situation where both the primary and secondary buckets are not available, > Redis clients are able to continue doing ops without getting stuck or hitting > loops of MOVED responses etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9848) Duplicate and Unnecessary REGISTER_INTEREST Message Sent to Server
[ https://issues.apache.org/jira/browse/GEODE-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9848: Assignee: Blake Bender > Duplicate and Unnecessary REGISTER_INTEREST Message Sent to Server > -- > > Key: GEODE-9848 > URL: https://issues.apache.org/jira/browse/GEODE-9848 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > In the course of debugging a RegisterAllKeys bug (GEMNC-508), it was > discovered that a second REGISTER_INTEREST message is being sent to the same > server. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9847) Benchmark instability in PartitionedPutLongBenchmark with security manager on support/1.14
[
https://issues.apache.org/jira/browse/GEODE-9847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9847:
Assignee: Kamilla Aslami
> Benchmark instability in PartitionedPutLongBenchmark with security manager on
> support/1.14
> --
>
> Key: GEODE-9847
> URL: https://issues.apache.org/jira/browse/GEODE-9847
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.1
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
>
> PartitionedPutLongBenchmark failed in
> apache-support-1-14-main/benchmark-with-security-manager. This issue could
> have the same root cause as GEODE-9340, but GEODE-9340 fails on 1.15 and in
> another CI job (apache-develop-main/benchmark-base).
> {noformat}
> org.apache.geode.benchmark.tests.PartitionedPutLongBenchmark
> 05:20:08 average ops/second Baseline:381785.31 Test:
> 351135.20 Difference: -8.0%
> 05:20:08 ops/second standard error Baseline: 2163.90 Test:
> 3115.81 Difference: +44.0%
> 05:20:08 ops/second standard deviation Baseline: 37417.40 Test:
> 53877.38 Difference: +44.0%
> 05:20:08 YS 99th percentile latency Baseline: 1606.00 Test:
> 1606.00 Difference: +0.0%
> 05:20:08 median latency Baseline: 1068031.00 Test:
> 1065983.00 Difference: -0.2%
> 05:20:08 90th percentile latency Baseline: 1364991.00 Test:
> 1356799.00 Difference: -0.6%
> 05:20:08 99th percentile latency Baseline: 7688191.00 Test:
> 8138751.00 Difference: +5.9%
> 05:20:08 99.9th percentile latency Baseline: 209584127.00 Test:
> 260964351.00 Difference: +24.5%
> 05:20:08 average latency Baseline: 1884576.09 Test:
> 2050262.70 Difference: +8.8%
> 05:20:08 latency standard deviation Baseline: 11587055.57 Test:
> 14728140.58 Difference: +27.1%
> 05:20:08 latency standard error Baseline: 1083.17 Test:
> 1435.92 Difference: +32.6%
> 05:20:08 average ops/second Baseline:381621.08 Test:
> 350789.84 Difference: -8.1%
> 05:20:08BENCHMARK FAILED:
> org.apache.geode.benchmark.tests.PartitionedPutLongBenchmark average latency
> is 5% worse than baseline.
> 05:20:08{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9851) Use strongly typed enums rather than int for enumeration like values.
[ https://issues.apache.org/jira/browse/GEODE-9851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9851: Assignee: Jacob Barrett > Use strongly typed enums rather than int for enumeration like values. > - > > Key: GEODE-9851 > URL: https://issues.apache.org/jira/browse/GEODE-9851 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Internally register interest has both an interest policy and data storage > policy that it passes around as `int`. Since these values are finite and have > well defined values it makes sense to pass them as proper Java enums. > Strongly typing them provides compile time checks on acceptable values and > makes the code more readable. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9870) JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
[
https://issues.apache.org/jira/browse/GEODE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9870:
Assignee: Jens Deppe
> JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
> --
>
> Key: GEODE-9870
> URL: https://issues.apache.org/jira/browse/GEODE-9870
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> CI failure here
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315]:
>
> {code:java}
> AuthWhileServersRestartDUnitTest > testReconnectionWithAuthAndServerRestarts
> FAILED
> redis.clients.jedis.exceptions.JedisMovedDataException: MOVED 12539
> 127.0.0.1:26259
> at redis.clients.jedis.Protocol.processError(Protocol.java:119)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.BinaryJedis.flushAll(BinaryJedis.java:826)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:147)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:131)
> at
> org.apache.geode.redis.internal.executor.auth.AuthWhileServersRestartDUnitTest.after(AuthWhileServersRestartDUnitTest.java:88){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9875) AuthenticationRequiredException: Failed to find the authenticated user.
[
https://issues.apache.org/jira/browse/GEODE-9875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9875:
Assignee: Jinmei Liao
> AuthenticationRequiredException: Failed to find the authenticated user.
> ---
>
> Key: GEODE-9875
> URL: https://issues.apache.org/jira/browse/GEODE-9875
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> Client connects to a server:
> One thread is doing puts using the connection with a valid uniqueId
> The ClientCacheUpdater thread failed to initialize, gets an IOException while
> trying to connect to the server:
> {quote}
> [warn 2021/12/06 17:41:16.345 PST edgegemfire1_host1_9691
> tid=0x37] Cache Client Updater Thread on
> rs-RunItNow-HQ1613a0i3large-hydra-client-30(bridgegemfire1_host1_13308:13308):41001
> port 23326 (rs-RunItNow-HQ1613a0i3large-hydra-client-30:23326): Caught
> following exception while attempting to create a server-to-client
> communication socket and will exit: java.net.SocketTimeoutException: Read
> timed out
> {quote}
> Then the ClientCacheUpdator resets the connections userId back to -1.
> The put thread uses this -1 as the uniqueId and then gets the exception back.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9884) update CI max_in_flight limits
[ https://issues.apache.org/jira/browse/GEODE-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-9884: Assignee: Owen Nichols > update CI max_in_flight limits > -- > > Key: GEODE-9884 > URL: https://issues.apache.org/jira/browse/GEODE-9884 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > max_in_flight limits are set on the main CI pipeline to avoid overloading > concourse when a large number of commits are coming through at the same time > these limits were last calculated a few years ago based on avg time each jobs > takes, and many jobs now take much longer and should be recalculated -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9943) ReplicatedIndexedQueryBenchmark perfomance degradation
[
https://issues.apache.org/jira/browse/GEODE-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-9943:
Assignee: Bala Tripura Sundari Kaza Venkata
> ReplicatedIndexedQueryBenchmark perfomance degradation
> --
>
> Key: GEODE-9943
> URL: https://issues.apache.org/jira/browse/GEODE-9943
> Project: Geode
> Issue Type: Bug
>Reporter: Bala Tripura Sundari Kaza Venkata
>Assignee: Bala Tripura Sundari Kaza Venkata
>Priority: Major
>
> There is performance degradation on the ReplicatedIndexedQuery benchmark.
> Below is the output:
> {code:java}
> org.apache.geode.benchmark.tests.ReplicatedIndexedQueryBenchmark
> average ops/second Baseline: 31678.93 Test: 28420.90
> Difference: -10.3%
>ops/second standard error Baseline:48.69 Test:50.69
> Difference: +4.1%
>ops/second standard deviation Baseline: 840.57 Test: 874.99
> Difference: +4.1%
> YS 99th percentile latency Baseline: 20095.61 Test: 20094.75
> Difference: -0.0%
> median latency Baseline: 7467007.00 Test: 7217151.00
> Difference: -3.3%
> 90th percentile latency Baseline: 54657023.00 Test: 81788927.00
> Difference: +49.6%
> 99th percentile latency Baseline: 111345663.00 Test: 134217727.00
> Difference: +20.5%
>99.9th percentile latency Baseline: 226623487.00 Test: 202899455.00
> Difference: -10.5%
> average latency Baseline: 18182876.80 Test: 20330177.60
> Difference: +11.8%
> latency standard deviation Baseline: 28044862.49 Test: 33920338.87
> Difference: +21.0%
> latency standard error Baseline: 9109.64 Test: 11652.11
> Difference: +27.9%
> average ops/second Baseline: 31594.76 Test: 28257.85
> Difference: -10.6%
> {code}
> Failure seen in this CI run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/83
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10082) Duplicate values found in DSCode enums
[ https://issues.apache.org/jira/browse/GEODE-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10082: -- Labels: needsTriage (was: ) > Duplicate values found in DSCode enums > -- > > Key: GEODE-10082 > URL: https://issues.apache.org/jira/browse/GEODE-10082 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: needsTriage > > The following snippet appears in DSCode.hpp: > ``` > CacheableEnum = 94, > ClientProxyMembershipId = 38, > CacheableUserData = 39, > CacheableUserData2 = 38, > CacheableUserData4 = 37, > PDX = 93, > PDX_ENUM = 94, > InterestResultPolicy = 37, > }; > ``` > `CacheableEnum` is the name of the class that geode-native uses for > `PDX_ENUM`, it should not exist as an enum value. `ClientProxyMembershipId`, > `InternalDistributedMember`, and `InterestResultPolicy` are > `DataSerializableFixedId` values, and belong in that enum rather than DSCode. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10081) Freeze during launch of locator
[ https://issues.apache.org/jira/browse/GEODE-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10081: -- Labels: needsTriage (was: ) > Freeze during launch of locator > --- > > Key: GEODE-10081 > URL: https://issues.apache.org/jira/browse/GEODE-10081 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.14.2 >Reporter: Julien Gilles >Priority: Major > Labels: needsTriage > > We are using gfsh with a script to automatically launch a locator and a > server. > During the launch of the locator, the process gfsh just freezes randomly. The > locator process is forked, but gfsh remains frozen. > A jstack on the process shows that the process is stuck on an internal > NativeLibrary.load call. This one happens when gfsh try to attach to the > process : internally the jvm loads the libattach.so library, but the call > never return. > To be complete, Geode is here deployed inside a docker container, using ubi8 > as base image, java is jdk11.0.11 - we have tested with 11.0.13, same issue. > > The stack is the following : > "main" #1 prio=5 os_prio=0 cpu=2402.78ms elapsed=1924.45s allocated=236M > defined_classes=10346 tid=0x7fc904024000 nid=0x16 runnable > [0x7fc90a84a000] > java.lang.Thread.State: RUNNABLE > at java.lang.ClassLoader$NativeLibrary.load0(java.base@11.0.11/Native > Method) > at java.lang.ClassLoader$NativeLibrary.load(java.base@11.0.11/Unknown > Source) > at > java.lang.ClassLoader$NativeLibrary.loadLibrary(java.base@11.0.11/Unknown > Source) > - locked <0x823efe60> (a java.util.HashSet) > at java.lang.ClassLoader.loadLibrary0(java.base@11.0.11/Unknown Source) > at java.lang.ClassLoader.loadLibrary(java.base@11.0.11/Unknown Source) > at java.lang.Runtime.loadLibrary0(java.base@11.0.11/Unknown Source) > - locked <0x828224b8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(java.base@11.0.11/Unknown Source) > at > sun.tools.attach.VirtualMachineImpl.(jdk.attach@11.0.11/Unknown > Source) > at > sun.tools.attach.AttachProviderImpl.attachVirtualMachine(jdk.attach@11.0.11/Unknown > Source) > at com.sun.tools.attach.VirtualMachine.attach(jdk.attach@11.0.11/Unknown > Source) > at > org.apache.geode.internal.process.MBeanProcessController.getJMXServiceURL(MBeanProcessController.java:227) > at > org.apache.geode.internal.process.MBeanProcessController.connect(MBeanProcessController.java:192) > at > org.apache.geode.internal.process.MBeanProcessController.invokeOperationOnTargetMBean(MBeanProcessController.java:159) > at > org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:136) > at > org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:81) > at > org.apache.geode.internal.process.MBeanOrFileProcessController.status(MBeanOrFileProcessController.java:37) > at > org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:1012) > at > org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:940) > at > org.apache.geode.distributed.LocatorLauncher$LocatorState.fromDirectory(LocatorLauncher.java:2077) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.doStartLocator(StartLocatorCommand.java:267) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.startLocator(StartLocatorCommand.java:133) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.11/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.11/Unknown > Source) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.11/Unknown > Source) > at java.lang.reflect.Method.invoke(java.base@11.0.11/Unknown Source) > at > org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:139) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:149) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10077) wan-copy region command does not prevent callbacks to be executed on the remote site
[ https://issues.apache.org/jira/browse/GEODE-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10077: -- Labels: needsTriage (was: ) > wan-copy region command does not prevent callbacks to be executed on the > remote site > > > Key: GEODE-10077 > URL: https://issues.apache.org/jira/browse/GEODE-10077 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > The wan-copy region command does not always prevent that callbacks are > executed at the remote site for the entries copied. > For example, if the remote site has more than one server and the gateway > receiver that gets the entries copied does not host the primary bucket of the > entry received, it will send the put operation to the server than hosts the > primary bucket and on this server, callbacks will be executed, provoking, for > example, that if a gateway sender is configured for the region, the event > will be sent by that gateway sender in the remote site. > Also, if the remote site has more than one server and the region has at least > one replica (either because it is a replicated region or because it is a > partitioned region with number of replicas greater than 1) then servers in > the remote site that receive an UpdateMessage from the server that received > the copied entry via the gateway receiver, would execute the callbacks, > provoking, like in the above case that if a gateway sender is configured for > the region, the event will be sent by that gateway sender in the remote site. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10075) Fix support for jacoco code coverage in Geode build
[ https://issues.apache.org/jira/browse/GEODE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10075: -- Labels: needsTriage (was: ) > Fix support for jacoco code coverage in Geode build > --- > > Key: GEODE-10075 > URL: https://issues.apache.org/jira/browse/GEODE-10075 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Dan Smith >Priority: Major > Labels: needsTriage > > We haven't been maintaining this gradle build support, but it is useful to be > able to get code coverage from distributed test runs, eg. > ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX > geode-core:jacocoDistributedTestReport > If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10066:
--
Labels: needsTriage (was: )
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
>
[jira] [Updated] (GEODE-10065) Fix regexp in gnmsg for handshake messages
[ https://issues.apache.org/jira/browse/GEODE-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10065: -- Labels: needsTriage (was: ) > Fix regexp in gnmsg for handshake messages > -- > > Key: GEODE-10065 > URL: https://issues.apache.org/jira/browse/GEODE-10065 > Project: Geode > Issue Type: Bug >Reporter: Michael Martell >Priority: Major > Labels: needsTriage > > gnmsg tool has a bug in the regexp for handshake messages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10063) A closed/destroyed connection can be set as a primary queueConnection in QueueManager
[ https://issues.apache.org/jira/browse/GEODE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10063: -- Labels: needsTriage (was: ) > A closed/destroyed connection can be set as a primary queueConnection in > QueueManager > - > > Key: GEODE-10063 > URL: https://issues.apache.org/jira/browse/GEODE-10063 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > In certain race cases, a destroyed connection is set to be the primary queue > connection connected to servers. If re-auth is enabled, and server pauses the > primary queue waiting for the re-auth token, there will be no client to > server connection available to send the valid re-auth token for server to > unpause the queue. And said client can not receive any events. > The situation should be detected during RedundancySatisfierTask, but it could > not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10061) CI:
[
https://issues.apache.org/jira/browse/GEODE-10061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10061:
--
Labels: needsTriage (was: )
> CI:
>
>
> Key: GEODE-10061
> URL: https://issues.apache.org/jira/browse/GEODE-10061
> Project: Geode
> Issue Type: Bug
>Reporter: Kristen
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-core:distributedTest
> PRClientServerRegionFunctionExecutionDUnitTest >
> testserverMultiKeyExecution_ThrowException[ExecuteFunctionById] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest$$Lambda$337/1157292204.run
> in VM 3 running on Host
> heavy-lifter-36926f81-68ee-5ab9-b87b-3d77805b70b1.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest.testserverMultiKeyExecution_ThrowException(PRClientServerRegionFunctionExecutionDUnitTest.java:379)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected Socket closed connection=Pooled Connection to
> heavy-lifter-36926f81-68ee-5ab9-b87b-3d77805b70b1.c.apachegeode-ci.internal:20923,heavy-lifter-36926f81-68ee-5ab9-b87b-3d77805b70b1(304549):42669:
> Connection[DESTROYED] attempt=3). Server unreachable: could not connect
> after 3 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:671)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:502)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:155)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805)
> at
> org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:158)
> at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3048)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3163)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5620)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5598)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5053)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1649)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1636)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
> at
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest.serverMultiKeyExecution_ThrowException(PRClientServerRegionFunctionExecutionDUnitTest.java:916)
> at
> org.apache.geode.internal.cache.execute.PRClientServerRegionFunctionExecutionDUnitTest.lambda$testserverMultiKeyExecution_ThrowException$bb17a952$1(PRClientServerRegionFunctionExecutionDUnitTest.java:380)
> Caused by:
> java.net.SocketException: Socket closed
> at java.net.SocketInputStream.read(SocketInputStream.java:204)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> ...
> {code}
> {code:java}
> ReconnectDUnitTest > testReconnectWithRoleLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run. Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 444 [fatal
> 2022/02/12 20:58:08.620 UTC receiver,heavy-lifter-36926f81-68ee-5ab9-b87b-3d77805b70b1-64966> tid=108]
> Membership service failure: Member isn't responding to heartbeat requests
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests at
>
[jira] [Updated] (GEODE-10059) CI: geode-wan:upgradeTest FAILED
[ https://issues.apache.org/jira/browse/GEODE-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10059: -- Labels: needsTriage (was: ) > CI: geode-wan:upgradeTest FAILED > > > Key: GEODE-10059 > URL: https://issues.apache.org/jira/browse/GEODE-10059 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.8 >Reporter: Kristen >Priority: Major > Labels: needsTriage > > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.4.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > oldEventShouldBeProcessedAtTwoNewSender[from_v1.4.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > oldEventShouldBeProcessedAtNewSender[from_v1.4.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.5.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > oldEventShouldBeProcessedAtTwoNewSender[from_v1.5.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > oldEventShouldBeProcessedAtNewSender[from_v1.5.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.6.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > oldEventShouldBeProcessedAtTwoNewSender[from_v1.6.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > > oldEventShouldBeProcessedAtNewSender[from_v1.6.0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host > 64b741e8194f with 7 VMs with version 1.3.0 > Caused by: > java.lang.IllegalStateException: VM not available: VM 5 running on > Host 64b741e8194f with 7 VMs with version 1.3.0 > org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent > >
[jira] [Updated] (GEODE-10057) Redis documentation has passive and active expiration descriptions reversed
[ https://issues.apache.org/jira/browse/GEODE-10057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10057: -- Labels: needsTriage (was: ) > Redis documentation has passive and active expiration descriptions reversed > --- > > Key: GEODE-10057 > URL: https://issues.apache.org/jira/browse/GEODE-10057 > Project: Geode > Issue Type: Bug > Components: docs, redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Priority: Major > Labels: needsTriage > > The geode-for-redis documentation describes the difference in behaviour for > active expiration and passive expiration, but the way these terms are used is > flipped from how they're typically used in documentation about open source > Redis: https://redis.io/commands/expire#how-redis-expires-keys. The docs > should be updated to match the usage in open source Redis documentation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10056) Gateway-reciver load mantained only on one locator
[ https://issues.apache.org/jira/browse/GEODE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10056: -- Labels: needsTriage (was: ) > Gateway-reciver load mantained only on one locator > -- > > Key: GEODE-10056 > URL: https://issues.apache.org/jira/browse/GEODE-10056 > Project: Geode > Issue Type: Bug >Reporter: Jakov Varenina >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10055) AbstractLauncher print info and debug with stderr instead of stdout
[
https://issues.apache.org/jira/browse/GEODE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10055:
--
Labels: needsTriage (was: )
> AbstractLauncher print info and debug with stderr instead of stdout
> ---
>
> Key: GEODE-10055
> URL: https://issues.apache.org/jira/browse/GEODE-10055
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.12.8, 1.13.7, 1.14.3
>Reporter: Mario Kevo
>Priority: Major
> Labels: needsTriage
>
> The problem happened with locator/server launcher logs which are printed with
> stderr in both cases, for info and debug.
> {code:java}
> protected void info(final Object message, final Object... args) {
> if (args != null && args.length > 0) {
> System.err.printf(message.toString(), args);
> } else {
> System.err.print(message);
> }
> }
> {code}
> And when it is redirected to some tools it represents it like an error as it
> is printed with stderr, instead of stdout.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10054) CI Failure: EnsurePrimaryStaysPutDUnitTest.localFunctionRetriesIfNotOnPrimary fails because primary moved
[
https://issues.apache.org/jira/browse/GEODE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10054:
--
Labels: needsTriage (was: )
> CI Failure: EnsurePrimaryStaysPutDUnitTest.localFunctionRetriesIfNotOnPrimary
> fails because primary moved
> -
>
> Key: GEODE-10054
> URL: https://issues.apache.org/jira/browse/GEODE-10054
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.16.0
>Reporter: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> This test fails with the following stack trace because the primary moved when
> it wasn't supposed to.
> {code:java}
> EnsurePrimaryStaysPutDUnitTest > localFunctionRetriesIfNotOnPrimary FAILED
> org.opentest4j.AssertionFailedError: [CheckPrimaryBucketFunction
> determined that the primary has moved]
> Expecting value to be true but was false
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest.primaryRemainsWhileFunctionExecutes(EnsurePrimaryStaysPutDUnitTest.java:170)
> at
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest.localFunctionRetriesIfNotOnPrimary(EnsurePrimaryStaysPutDUnitTest.java:93)
> {code}
--
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 ] Alexander Murmann updated GEODE-10053: -- Labels: needsTriage (was: ) > 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 >Priority: Major > Labels: needsTriage > > 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-10052) CI Failure: OutOfMemoryDUnitTest tests of Publish command fail expecting exception that was not thrown
[
https://issues.apache.org/jira/browse/GEODE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10052:
--
Labels: needsTriage (was: )
> CI Failure: OutOfMemoryDUnitTest tests of Publish command fail expecting
> exception that was not thrown
> --
>
> Key: GEODE-10052
> URL: https://issues.apache.org/jira/browse/GEODE-10052
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.16.0
>Reporter: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> There were three failures within a couple of days. They are all in publish
> tests.
> {code:java}
> OutOfMemoryDUnitTest > shouldReturnOOMError_forPublish_whenThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting code to raise a throwable.
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeysToServer1UntilOOMExceptionIsThrown(OutOfMemoryDUnitTest.java:357)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:344)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldReturnOOMError_forPublish_whenThresholdReached(OutOfMemoryDUnitTest.java:210)
> {code}
> {code:java}
> OutOfMemoryDUnitTest > shouldReturnOOMError_forPublish_whenThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting code to raise a throwable.
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeysToServer1UntilOOMExceptionIsThrown(OutOfMemoryDUnitTest.java:357)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:344)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldReturnOOMError_forPublish_whenThresholdReached(OutOfMemoryDUnitTest.java:210)
> {code}
> {code:java}
> OutOfMemoryDUnitTest > shouldAllowPublish_afterDroppingBelowCriticalThreshold
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a org.apache.geode.redis.OutOfMemoryDUnitTest
> Expecting code to raise a throwable within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowPublish_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:328)
> Caused by:
> java.lang.AssertionError:
> Expecting code to raise a throwable.
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$shouldAllowPublish_afterDroppingBelowCriticalThreshold$36(OutOfMemoryDUnitTest.java:328)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10015) gfsh does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann reassigned GEODE-10015:
-
Assignee: Jacob Barrett
> gfsh does not send hostname in SNI header
> -
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10047) Warning message in geode-for-redis PassiveExpirationManager is inaccurate
[
https://issues.apache.org/jira/browse/GEODE-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10047:
--
Labels: needsTriage (was: )
> Warning message in geode-for-redis PassiveExpirationManager is inaccurate
> -
>
> Key: GEODE-10047
> URL: https://issues.apache.org/jira/browse/GEODE-10047
> Project: Geode
> Issue Type: Bug
> Components: logging, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> If an exception is encountered during the {{doDataExpiration()}} method in
> {{{}PassiveExpirationManager{}}}, the following message is logged:
> {code:java}
> logger.warn("Passive expiration failed. Will try again in 1 second.",
> ex);{code}
> However, the passive expiration interval in geode-for-redis defaults to 180
> seconds and can be configured by the user to other values. The log message
> should reflect the configured value for passive expiration interval.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10043) TransactionCleaningTest.txWithStoppedServer is sporiously failing
[ https://issues.apache.org/jira/browse/GEODE-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10043: -- Labels: needsTriage (was: ) > TransactionCleaningTest.txWithStoppedServer is sporiously failing > - > > Key: GEODE-10043 > URL: https://issues.apache.org/jira/browse/GEODE-10043 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > This new-IT is failing from time to time due to concurrent modification > exception. > Here there are some executions in which can be seen the failure: > - > [https://concourse.apachegeode-ci.info/builds/25709909|https://concourse.apachegeode-ci.info/builds/25709909] > - > [https://concourse.apachegeode-ci.info/builds/26267825|https://concourse.apachegeode-ci.info/builds/26267825] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-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 ] Alexander Murmann updated GEODE-10042: -- Labels: needsTriage (was: ) > 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 >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage > > 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] [Updated] (GEODE-10041) CI: org.apache.geode.connectors.jdbc.PostgresJdbcWriterIntegrationTest > classMethod FAILED
[ https://issues.apache.org/jira/browse/GEODE-10041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10041: -- Labels: needsTriage (was: ) > CI: org.apache.geode.connectors.jdbc.PostgresJdbcWriterIntegrationTest > > classMethod FAILED > --- > > Key: GEODE-10041 > URL: https://issues.apache.org/jira/browse/GEODE-10041 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.4 >Reporter: Kristen >Priority: Major > Labels: needsTriage > > org.apache.geode.connectors.jdbc.PostgresJdbcWriterIntegrationTest > > classMethod FAILED > org.testcontainers.containers.ContainerLaunchException: Container startup > failed > Caused by: > org.rnorth.ducttape.RetryCountExceededException: Retry limit hit with > exception > Caused by: > org.testcontainers.containers.ContainerLaunchException: Could not > create/start container > Caused by: > java.lang.IllegalStateException: Container did not start > correctly. > 139 tests completed, 1 failed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10039: -- Labels: needsTriage (was: ) > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Priority: Major > Labels: needsTriage > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10038:
--
Labels: needsTriage (was: )
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: needsTriage
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10037: -- Labels: needsTriage (was: ) > Make org.apache.geode.internal.cache.wan.spi.WANFactory SPI interface part of > the non-internal, public API > -- > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Major > Labels: needsTriage > > See GEODE- -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10036:
--
Labels: needsTriage (was: )
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10031) Can't stop embedded locator when SSL endpoint validation is enabled.
[
https://issues.apache.org/jira/browse/GEODE-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10031:
--
Labels: needsTriage (was: )
> Can't stop embedded locator when SSL endpoint validation is enabled.
>
>
> Key: GEODE-10031
> URL: https://issues.apache.org/jira/browse/GEODE-10031
> Project: Geode
> Issue Type: Bug
> Components: jmx, locator, security
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When {{ssl-endpoint-identifcation-enable=true}} an embedded locator,
> typically used in testing, can't be stopped. The hostname the client side of
> the SSL connection tries to validate is `0.0.0.0`, which of course won't be
> in the certificate SAN tries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10030: -- Labels: needsTriage (was: ) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Priority: Major > Labels: needsTriage > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10029: -- Labels: needsTriage (was: ) > Strings are not correctly serialized > > > Key: GEODE-10029 > URL: https://issues.apache.org/jira/browse/GEODE-10029 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a PdxSerializable implementation with a string field > *WHEN* an ASCII string is written > *THEN* the string is serialized with the DSCode CacheableString > > *Additional information.* In the Java client, whenever writing an string, the > string is parsed and the DSCode is assigned depending on the string > codification. In the native client, it's always set to CacheableString, > whenever for example in the case of an ASCII string should be > CacheableASCIIString -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10028) Testing the needsTriage bot
[ https://issues.apache.org/jira/browse/GEODE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10028: -- > Testing the needsTriage bot > --- > > Key: GEODE-10028 > URL: https://issues.apache.org/jira/browse/GEODE-10028 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Priority: Major > Labels: needsTriage > > this is text for the humans -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10028) Testing the needsTriage bot
Alexander Murmann created GEODE-10028: - Summary: Testing the needsTriage bot Key: GEODE-10028 URL: https://issues.apache.org/jira/browse/GEODE-10028 Project: Geode Issue Type: Bug Reporter: Alexander Murmann this is text for the humans -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Deleted] (GEODE-10028) Testing the needsTriage bot
[ https://issues.apache.org/jira/browse/GEODE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann deleted GEODE-10028: -- > Testing the needsTriage bot > --- > > Key: GEODE-10028 > URL: https://issues.apache.org/jira/browse/GEODE-10028 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Priority: Major > Labels: needsTriage > > this is text for the humans -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10023) Security and management classes have broken javadocs
[ https://issues.apache.org/jira/browse/GEODE-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10023: -- Labels: needsTriage (was: ) > Security and management classes have broken javadocs > > > Key: GEODE-10023 > URL: https://issues.apache.org/jira/browse/GEODE-10023 > Project: Geode > Issue Type: Bug > Components: management, security >Reporter: Kirk Lund >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10022:
--
Labels: needsTriage (was: )
> 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
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10017:
--
Labels: needsTriage (was: )
> Fix new ITs unstability for TC that involves members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10015:
--
Labels: blocks-1.15.0 (was: needsTriage)
> gfsh sends does not send hostname in SNI header
> ---
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Blocker
> Labels: blocks-1.15.0
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
>
> Reproduction:
> {noformat}
> gfsh -e version --full -e start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007
> --security-properties-file=/path/to/security.properties --http-service-port=0
> --locators=myhost.example.com[20004]
> (1) Executing - version --full
> ...
> Product-Version: 1.16.0-build.0
> ...
> (2) Executing - start locator --name=locator2
> --bind-address=myhost.example.com --port=20005
> --J=-Dgemfire.jmx-manager-port=20007 --security-properties-file=
> --http-service-port=0 --locators=myhost.example.com[20004]
> ...
> [fatal 2022/02/02 19:47:27.050 PST tid=0x1] Problem forming SSL
> connection to /192.168.68.56[20007].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 192.168.68.56 found
> ...
> Locator in /path/to/locator2 on myhost.example.com[20005] as locator2 is
> currently online.
> ...
> Unable to auto-connect (Security Manager may be enabled). Please use "connect
> --locator=myhost.example.com[20005]" to connect Gfsh to the locator.
> SSL configuration required to connect to the Manager.
> Failed to connect; unknown cause: error during JRMP connection establishment;
> nested exception is:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> {noformat}
> Where {{/path/to/security.properties}} contains:
> {noformat}
> ssl-require-authentication=true
> ssl-keystore=/path/to/keystore.jks
> ssl-truststore-type=jks
> ssl-keystore-password=password
> ssl-truststore=/path/to/truststore.jks
> ssl-enabled-components=all
> ssl-truststore-password=password
> ssl-protocols=any
> ssl-endpoint-identification-enabled=true
> ssl-keystore-type=jks
> {noformat}
> The certificate used in the key store is singed by a fake CA and contains
> only the hostname, {{myhost.example.com}}. The trust store contains the fake
> CA.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10015) gfsh sends does not send hostname in SNI header
[
https://issues.apache.org/jira/browse/GEODE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10015:
--
Labels: needsTriage (was: )
> gfsh sends does not send hostname in SNI header
> ---
>
> Key: GEODE-10015
> URL: https://issues.apache.org/jira/browse/GEODE-10015
> Project: Geode
> Issue Type: Bug
> Components: gfsh, jmx
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When {{gfsh}} tries to connect the JMX port on the locator it sends the IP
> address of the locator in the SNI header rather than the hostname. This
> results in a certificate validation failure when the IP is not found in the
> SAN entries.
> Version 1.14.3 sends the correct hostname in the SNI. Something changed
> between 1.14.3 and now.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10012:
--
Labels: needsTriage (was: )
> Avoid retries for non-HA function execution
> ---
>
> Key: GEODE-10012
> URL: https://issues.apache.org/jira/browse/GEODE-10012
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* a cluster with 3 servers and 1 locator
> *AND* a PartitionedRegion with redundant-copies="1"
> *AND* a user-defined Function with isHA=false
> *AND* a geode-native client with a pool with single-hop enabled and retry
> attempts set to 2
> *WHEN* execution fails due to a connectivity issue/connection
> timeout/internal cluster error
> *THEN* function is retried twice
>
> *Additional information.* The function is retried at the network code layer,
> and given whenever there is a timeout/connectivity error, the BSL is removed
> from the ClientMetadataService, whenever retries happen, you might get a
> *InternalFunctionInvocationTargetException* exception thrown indicating:
> {code:java}
> Multiple target nodes found for single hop operation {code}
> Also, have into account that Java client API behaviour never retries a
> Function Execution if isHA=false for that function, and whenever isHA=true,
> the function is retried but on the function execution logic and not at the
> networking layer.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10011:
--
Labels: needsTriage (was: )
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire set, but for small set sizes (the set in the failure above
> only has 2 members) it's possible that the first scan will return all
> elements and a cursor value of 0, meaning that the second scan will also
> return all elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10010:
--
Labels: needsTriage (was: )
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
> Labels: needsTriage
>
> [*http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/*]
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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:all-tabpanel ] Alexander Murmann updated GEODE-10009: -- Labels: needsTriage (was: ) > 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 >Priority: Major > Labels: needsTriage > > 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] [Updated] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10008: -- Labels: needsTriage (was: ) > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 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.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) > at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) > at >
[jira] [Updated] (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:all-tabpanel
]
Alexander Murmann updated GEODE-10004:
--
Labels: needsTriage (was: )
> 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: needsTriage
>
> 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] [Updated] (GEODE-10002) Document recommendation but not 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 ] Alexander Murmann updated GEODE-10002: -- Labels: needsTriage (was: ) > Document recommendation but not 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 >Priority: Major > Labels: needsTriage > > 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 recommended 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-10001) CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
[
https://issues.apache.org/jira/browse/GEODE-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10001:
--
Labels: needsTriage (was: )
> CI Failure: ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats
> ---
>
> Key: GEODE-10001
> URL: https://issues.apache.org/jira/browse/GEODE-10001
> Project: Geode
> Issue Type: Bug
> Components: gfsh, logging
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> ExportLogsStatsOverHttpDistributedTest.testExportLogsAndStats has failed with
> missing files in a windows job. It appears that the server 1 logs and stats
> are not there.
> {code:java}
> ExportLogsStatsOverHttpDistributedTest > testExportLogsAndStats FAILED
> java.lang.AssertionError:
> Expecting HashSet:
> ["locator-0\\locator-0.log"]
> to contain:
> ["server-1\\server-1.log", "locator-0\\locator-0.log",
> "server-1\\statistics.gfs"]
> but could not find the following element(s):
> ["server-1\\server-1.log", "server-1\\statistics.gfs"]
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsStatsDistributedTestBase.testExportLogsAndStats(ExportLogsStatsDistributedTestBase.java:96)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:130)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
>
[jira] [Updated] (GEODE-10000) Avoid gfsh stop gateway sender error when stopped a second time
[ https://issues.apache.org/jira/browse/GEODE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-1: -- Labels: needsTriage (was: ) > Avoid gfsh stop gateway sender error when stopped a second time > --- > > Key: GEODE-1 > URL: https://issues.apache.org/jira/browse/GEODE-1 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > After changing the implementation of the "stop gateway sender" command to be > parallel, when it is invoked a second time it fails with the following error: > Error while processing command Reason : > Task java.util.concurrent.FutureTask@513d30f9 rejected from > java.util.concurrent.ThreadPoolExecutor@85189b9[Terminated, pool size = 0, > active threads = 0, queued tasks = 0, completed tasks = 2] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9996) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
[
https://issues.apache.org/jira/browse/GEODE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9996:
-
Labels: needsTriage (was: )
> CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest >
> testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
> --
>
> Key: GEODE-9996
> URL: https://issues.apache.org/jira/browse/GEODE-9996
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> Test failed with the following exception:
> {code:java}
> SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest >
> testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
> FAILED
> java.lang.AssertionError: expected:<0> but was:<5>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:170)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9995:
-
Labels: needsTriage (was: )
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9739) CI: WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo failed with MemberDisconnectedException
[
https://issues.apache.org/jira/browse/GEODE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483461#comment-17483461
]
Alexander Murmann commented on GEODE-9739:
--
[~balesh2] Thank you for picking this up after it had been in limbo for a bit.
Have you had any luck reproducing this? Anil's suggestion of going for 5k runs
seems like a good one. Would be really great to know if this is new or not.
> CI: WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo failed
> with MemberDisconnectedException
> --
>
> Key: GEODE-9739
> URL: https://issues.apache.org/jira/browse/GEODE-9739
> Project: Geode
> Issue Type: Bug
> Components: membership, wan
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo >
> CreateGatewaySenderMixedSiteOneCurrentSiteTwo[from_v1.12.2] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm6.log' at line 481[fatal
> 2021/10/13 23:34:55.115 UTC receiver,heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3-37210> tid=830]
> Membership service failure: Membership coordinator
> heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(39325:locator):53919
> has declared that a network partition has occurred
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(39325:locator):53919
> has declared that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processNetworkPartitionMessage(GMSJoinLeave.java:1466)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1367)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1303)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at
> org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.base/java.lang.Thread.run(Thread.java:829)
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 549[fatal
> 2021/10/13 23:34:54.989 UTC tid=858] Possible
> loss of quorum due to the loss of 1 cache processes:
> [heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(41092):53920]
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 551[fatal
> 2021/10/13 23:34:56.179 UTC tid=858]
> Membership service failure: Exiting due to possible network partition event
> due to loss of 1 cache processes:
> [heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(41092):53920]
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
>
[jira] [Updated] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9994: - Labels: needsTriage (was: ) > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Priority: Major > Labels: needsTriage > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9993: - Labels: needsTriage (was: ) > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Priority: Major > Labels: needsTriage > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9991:
-
Labels: needsTriage (was: )
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.13.7, 1.14.3, 1.15.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-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:all-tabpanel
]
Alexander Murmann updated GEODE-9990:
-
Labels: needsTriage (was: )
> 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
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> 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.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
> in
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
>
[jira] [Updated] (GEODE-9989) add a few info level logs in PersistenceAdvisorImpl to identify splitbrain issue
[
https://issues.apache.org/jira/browse/GEODE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9989:
-
Labels: needsTriage (was: )
> add a few info level logs in PersistenceAdvisorImpl to identify splitbrain
> issue
>
>
> Key: GEODE-9989
> URL: https://issues.apache.org/jira/browse/GEODE-9989
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> In scenario like:
> {code:java}
> 03:33:03.644 dataStoregemfire4_4494 recovered from disk
> 03:33:03.732 dataStoregemfire4_4494 closing
> 03:33:03.735 dataStoregemfire4_4494 Initialization of region replicate_5
> completed, send newId(let’s name it 4494) to gemfire2
> 03:33:03.754 dataStoregemfire2_4493 recovered from disk
> 03:33:03.770 dataStoregemfire2_4493 closing
> 03:33:03.792 dataStoregemfire2_4493 Initialization of region replicate_5
> completed. send newId(let’s name is 4493) to gemfire4, but gemfire4 is
> offline. So gemfire4 does not know gemfire2’s newId 4493.
> 03:34:11.247 gemfire4_9779 restarted, it does not know 4493
> 03:34:11.269 gemfire2_9856 restarted, it sends oldId=4493, newId=9856 to
> gemfire4, but gemfire4 does not know either of gemfire2’s oldId and newId
> When gemfire2_9856 asked gemfire4_9779 for its state, gemfire4_9779 replied
> "I don't know you", then gemfire2_9856's starting ends with
> ConflictingPersistentDataException.
> {code}
> We need more log to identify the issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
