[jira] [Assigned] (GEODE-7251) Incorrect/incomplete instructions on download page
[
https://issues.apache.org/jira/browse/GEODE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-7251:
Assignee: (was: Anthony Baker)
> Incorrect/incomplete instructions on download page
> --
>
> Key: GEODE-7251
> URL: https://issues.apache.org/jira/browse/GEODE-7251
> Project: Geode
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> There are some issues with the download page instructions.
> It still refers to checking MD5 hashes, but there are none.
> Also the gpg sig check needs a second parameter:
> gpg --verify ${filename}.tar.gz.asc ${filename}.tar.gz
> See https://www.apache.org/info/verification.html#specify_both
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-7053:
Assignee: (was: Anthony Baker)
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the thread loses CPU for any reason.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-1168) geode-dependencies manifest is missing jars that are present in the lib directory
[
https://issues.apache.org/jira/browse/GEODE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-1168:
Assignee: (was: Anthony Baker)
> geode-dependencies manifest is missing jars that are present in the lib
> directory
> -
>
> Key: GEODE-1168
> URL: https://issues.apache.org/jira/browse/GEODE-1168
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While looking into GEODE-1025, I discovered that we have a number of jars in
> the geode-assembly/build/install/apache-geode/lib directory that do not
> appear in geode-dependencies.jar or gfsh-dependencies.jar.
> I believe that means that these are not actually on the classpath for any
> geode process, which means they either shouldn't be shipped with geode at
> all, or they are supposed to be on the classpath but I getting skipped for
> some reason.
> These are the jars present in the lib directory, but not on the classpath,
> excluding the spring jars (I'm cleaning those up as part of GEODE-1025)
> {noformat}
> activation-1.1.jar
> commons-modeler-2.0.jar
> findbugs-annotations-1.3.9-1.jar
> geode-jca-1.0.0-incubating.M2-SNAPSHOT.rar
> geode-web-1.0.0-incubating.M2-SNAPSHOT.jar
> geode-web-api-1.0.0-incubating.M2-SNAPSHOT.jar
> guava-15.0.jar
> javax.mail-api-1.4.5.jar
> mx4j-3.0.1.jar
> mx4j-remote-3.0.1.jar
> mx4j-tools-3.0.1.jar
> ra.jar
> {noformat}
> Most of these jars appear to be coming from compile dependencies of
> geode-core.
> The jars in the lib directory are controlled by the distributions section of
> geode-assembly/build.gradle. The jars in the geode-dependencies.jar manifest
> are coming from the cp() method in geode-assembly/build.gradle.
> It seems like these two lists ought to be unified - we should only ship jars
> that appear in one of the two manifests, and what goes into the manifest
> should probably be controlled by the configurations of the other projects -
> In other words, if it's part of the runtime configuration of geode-core it
> should be part of the geode-dependencies.jar; it shouldn't be filtered by
> this cp() method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-2160) gfsh stop server/locator exits with code 0 before server/locator actually stops
[
https://issues.apache.org/jira/browse/GEODE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-2160:
Assignee: (was: Anthony Baker)
> gfsh stop server/locator exits with code 0 before server/locator actually
> stops
> ---
>
> Key: GEODE-2160
> URL: https://issues.apache.org/jira/browse/GEODE-2160
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.0.0-incubating
>Reporter: Jacob Barrett
>Priority: Major
>
> Executing
> {code}
> gfsh stop server --name=server1
> {code}
> {{gfsh}} exits, with code 0, prior to the server actually being stopped.
> This behavior isn't documented and makes scripting with gfsh difficult. One
> can't assume that the server has stopped after gfsh exits. To verify you must
> parse the server pid and check the status of the proc.
> Simple test:
> {code}
> gfsh start server --name=s2 && sleep 10 && gfsh stop server --dir=s2; echo
> $?; while (kill -0 `cat s2/vf.gf.server.pid`); do date +%s.%N; done
> {code}
> Starts server, waits 10s, stops server, prints exit code, loops until process
> is gone while printing the time since epoch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10430) Update JGroups to 4.+ to address CVE
[ https://issues.apache.org/jira/browse/GEODE-10430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-10430. --- Resolution: Won't Fix > Update JGroups to 4.+ to address CVE > > > Key: GEODE-10430 > URL: https://issues.apache.org/jira/browse/GEODE-10430 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.15.1 >Reporter: Luke DiGiacomo >Priority: Major > Labels: needsTriage > > The latest release of Geode, 1.15.1, declares a dependency on JGroups 3.6.14. > This version of JGroups is subject to a critical CVE, > [https://nvd.nist.gov/vuln/detail/CVE-2016-2141,] which requires moving to > JGroups 4.+. Geode's dependency on JGroups should be bumped to version 4.+ > and any related bug should be addressed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10430) Update JGroups to 4.+ to address CVE
[ https://issues.apache.org/jira/browse/GEODE-10430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17623977#comment-17623977 ] Anthony Baker commented on GEODE-10430: --- As noted in GEODE-10236, Geode is not impacted by this vulnerability. > Update JGroups to 4.+ to address CVE > > > Key: GEODE-10430 > URL: https://issues.apache.org/jira/browse/GEODE-10430 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.15.1 >Reporter: Luke DiGiacomo >Priority: Major > Labels: needsTriage > > The latest release of Geode, 1.15.1, declares a dependency on JGroups 3.6.14. > This version of JGroups is subject to a critical CVE, > [https://nvd.nist.gov/vuln/detail/CVE-2016-2141,] which requires moving to > JGroups 4.+. Geode's dependency on JGroups should be bumped to version 4.+ > and any related bug should be addressed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17603255#comment-17603255
]
Anthony Baker commented on GEODE-10415:
---
Let's leave jgroups out of the discussion. We know that Geode is not vulnerable
since it does not use the protocols in question.
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Weijie Xu
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10249) Add stats for BufferPoolMXBean
[ https://issues.apache.org/jira/browse/GEODE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10249: -- Fix Version/s: (was: 1.15.1) > Add stats for BufferPoolMXBean > -- > > Key: GEODE-10249 > URL: https://issues.apache.org/jira/browse/GEODE-10249 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > Java provides information on buffer pools used in the JVM via > BufferPoolMXBean. Add the output of these to the basic set of platform stats > to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10144: -- Fix Version/s: (was: 1.15.1) > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server, native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-9296) CI Failure: PutAllClientServerDistributedTest > testPartialKeyInPRSingleHopWithRedundancy
[ https://issues.apache.org/jira/browse/GEODE-9296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9296: - Fix Version/s: (was: 1.15.1) > CI Failure: PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy > - > > Key: GEODE-9296 > URL: https://issues.apache.org/jira/browse/GEODE-9296 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.15.0 >Reporter: Hale Bales >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > > org.apache.geode.internal.cache.PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHopWithRedundancy FAILED > org.junit.ComparisonFailure: expected:<[20]0> but was:<[17]0> > 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.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHopWithRedundancy(PutAllClientServerDistributedTest.java:2430) > failed in CI run: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253#B > artifacts available here: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0251/test-results/distributedTest/1621568801/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10382) Windows build broken after image update
[ https://issues.apache.org/jira/browse/GEODE-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10382: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Windows build broken after image update > --- > > Key: GEODE-10382 > URL: https://issues.apache.org/jira/browse/GEODE-10382 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.16.0 >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > The Windows 2019 build is broken in CI due to a new version of cmake not > liking one of our config parameters, and a couple of new build warnings being > flagged as errors after a compiler update. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10377) Add getter for CacheServiceProfile list to CacheDistributionAdvisor
[ https://issues.apache.org/jira/browse/GEODE-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10377: -- Labels: (was: blocks-1.15.0 needsTriage) > Add getter for CacheServiceProfile list to CacheDistributionAdvisor > --- > > Key: GEODE-10377 > URL: https://issues.apache.org/jira/browse/GEODE-10377 > Project: Geode > Issue Type: New Feature > Components: core >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > > Clients of CacheDistributionAdvisor could use this feature to determine > features of members of the cluster. For example, the version of extensions on > other members could be determined, enhancing forward and backward > compatibility to simplify rolling upgrades of extensions. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[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
]
Anthony Baker updated GEODE-10066:
--
Labels: pull-request-available ssl (was: blocks-1.12.10
pull-request-available ssl)
> 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
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available, ssl
> Fix For: 1.15.0
>
>
> 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
>
[jira] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10364:
--
Labels: blocks-1.16.0 (was: needsTriage)
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin), tests
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Minor
> Labels: blocks-1.16.0
>
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> is failing with unexpected log entries.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671
> {code:java}
> DeploymentManagementRedployDUnitTest >
> hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> 01:44:15java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 01:44:15Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 531
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:??Bp+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??4|'?=???PK??{}?T4|'?=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15--cvFOdAqPh74YsEftzj4GE_lSmdgeMggm6mUZS8E
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json
> 01:44:15
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 550
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:???p+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??=???PK??{}?T=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15---UjSGLHVgaMcjtjM7IJfWJ3fPZEhjOGN
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json {code}
> In order to resolve this issue the ManagementLoggingFilter needs to be a
> little more discriminant on what it logs out, as it currently is serializing
> the jar file contents as a String, which is causing this issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-6021) Introducing Lombok
[ https://issues.apache.org/jira/browse/GEODE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-6021. -- Resolution: Won't Do > Introducing Lombok > -- > > Key: GEODE-6021 > URL: https://issues.apache.org/jira/browse/GEODE-6021 > Project: Geode > Issue Type: Improvement >Reporter: Aditya Anchuri >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Want to introduce Lombok into the Geode code. [https://projectlombok.org/] > We see the following advantages of using Lombok: > -> Less boilerplate code, reduces the size of some classes significantly. > -> Can use builder pattern implicitly, which allows for much better > composeability of an object. > -> Increased readability > More details: [https://projectlombok.org/features/all > ]PR: https://github.com/apache/geode/pull/2815 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10106:
--
Labels: pull-request-available (was: blocks-1.15.0 pull-request-available)
> CI Failure: CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer
> ---
>
> Key: GEODE-10106
> URL: https://issues.apache.org/jira/browse/GEODE-10106
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
> {noformat}
> CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer FAILED
> 11:49:39java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 11:49:39Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 11:49:39
> ---
> 11:49:39Found suspect string in 'dunit_suspect-vm4.log' at line 431
> 11:49:39
> 11:49:39[error 2022/03/05 19:49:36.075 UTC
> tid=55] Error in
> redundancy satisfier
> 11:49:39java.lang.NullPointerException
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
> 11:49:39 at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
> 11:49:39 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:49:39 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:49:39 at java.lang.Thread.run(Thread.java:750)
> 11:49:39at org.junit.Assert.fail(Assert.java:89)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> 11:49:39at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:49:39at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:49:39at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:49:39at java.lang.reflect.Method.invoke(Method.java:498)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> 11:49:39at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 11:49:39at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 11:49:39at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 11:49:39at
>
[jira] [Updated] (GEODE-10361) AutoConnectionSourceImplIntegrationTest > test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators with NoAvailableLocatorsException
[
https://issues.apache.org/jira/browse/GEODE-10361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10361:
--
Labels: blocks-1.16.0 (was: needsTriage)
> AutoConnectionSourceImplIntegrationTest >
> test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators
> with NoAvailableLocatorsException
> --
>
> Key: GEODE-10361
> URL: https://issues.apache.org/jira/browse/GEODE-10361
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> AutoConnectionSourceImplIntegrationTest >
> test_DiscoverLocators_whenOneLocatorWasShutdown FAILED
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to
> connect to any locators in the list
> [heavy-lifter-972eb062-9b0f-52e1-a58b-0dd44f11dbcc:27503]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:159)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImplIntegrationTest.test_DiscoverLocators_whenOneLocatorWasShutdown(AutoConnectionSourceImplIntegrationTest.java:317)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10360:
--
Labels: blocks-1.16.0 (was: needsTriage)
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.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
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
>
[jira] [Updated] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10351:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> [CI failure] ModifyColocationIntegrationTest > testModifyColocation
> ---
>
> Key: GEODE-10351
> URL: https://issues.apache.org/jira/browse/GEODE-10351
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> ModifyColocationIntegrationTest > testModifyColocation FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.IllegalStateException
> but was:
> org.apache.geode.cache.CacheClosedException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed., caused by
> org.apache.geode.cache.DiskAccessException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5221)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3123)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10351:
--
Labels: blocks-1.16.0 pull-request-available (was: pull-request-available)
> [CI failure] ModifyColocationIntegrationTest > testModifyColocation
> ---
>
> Key: GEODE-10351
> URL: https://issues.apache.org/jira/browse/GEODE-10351
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jinmei Liao
>Priority: Major
> Labels: blocks-1.16.0, pull-request-available
>
> {noformat}
> ModifyColocationIntegrationTest > testModifyColocation FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.IllegalStateException
> but was:
> org.apache.geode.cache.CacheClosedException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed., caused by
> org.apache.geode.cache.DiskAccessException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5221)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3123)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
[
https://issues.apache.org/jira/browse/GEODE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-1957:
-
Labels: blocks-1.16.0 (was: needsTriage)
> CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
>
>
> Key: GEODE-1957
> URL: https://issues.apache.org/jira/browse/GEODE-1957
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.16.0
>
> This test failed in a CI run with SHA 7254cf3fb0ceb2255650d96f2b0ed615118ef700
> {noformat}
> org.apache.geode.internal.cache.DiskRegionAsyncRecoveryJUnitTest >
> testCloseOpenRegion FAILED
> java.lang.AssertionError: Failed on entry 40 expected: but was:
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at
> org.apache.geode.internal.cache.DiskRegionAsyncRecoveryJUnitTest.checkEntriesInMemory(DiskRegionAsyncRecoveryJUnitTest.java:456)
> at
> org.apache.geode.internal.cache.DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion(DiskRegionAsyncRecoveryJUnitTest.java:382)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10348) Correct documentation about conflation
[ https://issues.apache.org/jira/browse/GEODE-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10348: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Correct documentation about conflation > -- > > Key: GEODE-10348 > URL: https://issues.apache.org/jira/browse/GEODE-10348 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The Geode documentation states on conflation: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message assumes the value of the new update and the new update is dropped, as > shown here for key A." > Nevertheless, that is not correct. The actual behavior is the following: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message is removed and the new update is added to the end of the queue, as > shown here for key A." -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10346) Correct batch-time-interval description in documentation
[ https://issues.apache.org/jira/browse/GEODE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10346: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Correct batch-time-interval description in documentation > > > Key: GEODE-10346 > URL: https://issues.apache.org/jira/browse/GEODE-10346 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The description of the batch-time-interval parameter for the Gateway Sender > in the Geode documentation states the following: > "Maximum amount of time, in ms, that can elapse before a batch is delivered." > Nevertheless, that is not completely true. > The number of ms that can elapse before a batch is delivered could be longer > than what is configured in batch-time-interval in the case that the batch > being created has not yet reached the value of max-batch-size and there are > still events in the gateway sender's queue to be added to the batch. If that > is the case, new events will keep being added to the batch without taking > into account the value for batch-time-interval. > The batch-time-interval parameter is only used when the batch being filled > has not reached the max-batch-size but there are no events in the queue. In > that case, in order not to delay the delivery of the batch until there are > events in the queue, this value is used to determine if the batch must be > sent. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10339) The server fails to start because the .crf or the .drf file is missing
[
https://issues.apache.org/jira/browse/GEODE-10339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10339:
--
Labels: (was: needsTriage)
> The server fails to start because the .crf or the .drf file is missing
> --
>
> Key: GEODE-10339
> URL: https://issues.apache.org/jira/browse/GEODE-10339
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Priority: Major
>
> {color:#0e101a}The server fails with following:{color}
> {code:java}
> {"timestamp":"2022-05-16T08:25:35.708Z","severity":"error","message":"Cache
> initialization for GemFireCache[id = 776315735; isClosing = false;
> isShutDownAll = false; created = Mon May 16 08:25:33 UTC 2022; server =
> false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
> java.lang.IllegalStateException: The following required files could not be
> found: *.crf files with these ids:
> [33].","metadata":{"function":"KVDB"},"version":"1.1.0","service_id":"eric-udr-kvdb-ag","extra_data":{"thread_info":{"thread_name":"main","thread_id":"1"},"e":{"exception":""}}}
> {code}
>
> {color:#0e101a}As a last compaction step, the server deletes the compacted
> .crf file. The deletion is done in the following way:{color}
> # {color:#0e101a}Write delete operation (delete ".crf" file) in the ".if"
> file. {color}
> # {color:#0e101a}Delete .crf file{color}
> {color:#0e101a}The problem with server startup happens in the following
> scenario:{color}
> # {color:#0e101a}The server writes the delete operation (for .crf file) in
> the ".if" file. The write is not immediately flushed to the ".if" file, but
> it goes to the async write buffer.{color}
> # {color:#0e101a}The server deletes the ".crf" file.{color}
> # {color:#0e101a}The forceful restart happens before the async write buffer
> is flushed to the ".if" file. This scenario leaves the ".if" file not
> updated, and therefore server startup fails later on.{color}
>
> {color:#0e101a}To avoid the above issue, we can use the existing parameter in
> a geode that forces the server to write synchronously to the ".if"
> file:{color}
> {code:java}
> --J=-Dgemfire.syncMetaDataWrites=true
> {code}
> {color:#0e101a}This parameter is not mentioned anywhere in the documentation.
> So it would be good to add it to the following document:{color}
> {color:#0e101a}[https://geode.apache.org/docs/guide/114/managing/disk_storage/managing_disk_buffer_flushes.html]{color}
>
> {color:#0e101a}Changing this parameter's default value to true would also be
> good. {color}{color:#0e101a}This parameter should not affect performance as
> the ".if" file is not updated frequently.{color}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10281) Internal conflict replicated region resolution causes data inconsistency between two sites
[
https://issues.apache.org/jira/browse/GEODE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10281:
--
Labels: pull-request-available (was: blocks-1.15.0 pull-request-available)
> Internal conflict replicated region resolution causes data inconsistency
> between two sites
> --
>
> Key: GEODE-10281
> URL: https://issues.apache.org/jira/browse/GEODE-10281
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
>
> {color:#0e101a}It seems that the following PR
> {color}[{color:#4a6ee0}[https://github.com/apache/geode/pull/3044]{color}]{color:#0e101a}
> has not taken into consideration that event with a flag
> isConcurrencyConflict=true could delete the valid event from the queue due to
> conflation.{color}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availabi
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10329:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss 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 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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 junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> 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
[jira] [Updated] (GEODE-10324) [CI Failure] ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter
[
https://issues.apache.org/jira/browse/GEODE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10324:
--
Labels: (was: needsTriage)
> [CI Failure] ExportLogsOverHttpDistributedTest >
> testExportWithExactLogLevelFilter
> --
>
> Key: GEODE-10324
> URL: https://issues.apache.org/jira/browse/GEODE-10324
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.16.0
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> > Task :geode-web:distributedTest
> ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter FAILED
> java.lang.AssertionError:
> Expected size: 3 but was: 2 in:
>
> [C:\\Users\\geode\\AppData\\Local\\Temp\\junit3661184760048034890\\unzippedLogs\\locator-0,
>
> C:\\Users\\geode\\AppData\\Local\\Temp\\junit3661184760048034890\\unzippedLogs\\server-2]
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsDistributedTestBase.verifyZipFileContents(ExportLogsDistributedTestBase.java:283)
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsDistributedTestBase.testExportWithExactLogLevelFilter(ExportLogsDistributedTestBase.java:227)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 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.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
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
>
[jira] [Updated] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10323:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError:
> expected:<100> but was:<1048576>
>
>
> Key: GEODE-10323
> URL: https://issues.apache.org/jira/browse/GEODE-10323
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> 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.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10334) Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10334: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and > DistributedMulticastRegionDUnitTest > --- > > Key: GEODE-10334 > URL: https://issues.apache.org/jira/browse/GEODE-10334 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Refactor these tests to remove the deprecated APIs and use the updated test > framework -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10332:
--
Labels: (was: needsTriage)
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
>
> NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
> geode-core:upgradeTest which is running tests in parallel. To be well-behaved
> all ports must come from AvailablePortHelper and be well below the range of
> ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk11
> Gradle target: geode-core:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes. This range needs to be much
> lower.
> # The assertions in ClientAuthenticationTestCase don't provide enough info so
> debugging this test will require a lot of digging through log output and
> studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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
[jira] [Updated] (GEODE-10333) WANRollingUpgradeNewSenderProcessOldEvent > bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8, geode=1.7.0}] fails with ForcedDisconnectExcepti
[
https://issues.apache.org/jira/browse/GEODE-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10333:
--
Labels: (was: needsTriage)
> WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8,
> geode=1.7.0}] fails with ForcedDisconnectException: Member isn't responding
> to heartbeat requests
> --
>
> Key: GEODE-10333
> URL: https://issues.apache.org/jira/browse/GEODE-10333
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
>
> NOTE: WANRollingUpgradeNewSenderProcessOldEvent is a dunit test that runs
> during geode-wan:upgradeTest which is running tests in parallel. To be
> well-behaved all ports must come from AvailablePortHelper and be well below
> the range of ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371948
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426563/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk8
> Gradle target: geode-wan:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes. This range needs to be much
> lower.
> # The assertions in WANRollingUpgradeNewSenderProcessOldEvent don't provide
> enough info so debugging this test will require a lot of digging through log
> output and studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$344/1994402702.run
> in VM 5, Host Host
> heavy-lifter-f7f182f0-e980-587e-9bf7-d23392538e69.c.apachegeode-ci.internal
> with 7 VMs, Geode 1.7.0, Java 8
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startAndConfigureServers(WANRollingUpgradeDUnitTest.java:191)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent.bothOldAndNewEventsShouldBeProcessedByOldSender(WANRollingUpgradeNewSenderProcessOldEvent.java:276)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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
[jira] [Updated] (GEODE-10331) DistributionImpl.destroyMember keeps cache alive for some number of seconds
[ https://issues.apache.org/jira/browse/GEODE-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10331: -- Labels: blocks-1.16.0 (was: needsTriage) > DistributionImpl.destroyMember keeps cache alive for some number of seconds > --- > > Key: GEODE-10331 > URL: https://issues.apache.org/jira/browse/GEODE-10331 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > org.apache.geode.distributed.internal.DistributionImpl.destroyMember creates > a thread that will hold onto the DIstributesSystem/Cache through the > DirectChannel it has for 3 seconds by default. It could be even longer if > p2p.disconnectDelay is set to a value > 3000. > This can be a problem if the JVM is trying to reconnect since this old cache > uses memory. > Instead of creating a new thread for every call of destroyMember, we should > just have a single ScheduledExecutor that we schedule the background > "closeEndpoint" with. > Also since all this code interacts with the DirectChannel all the logic about > the executor and scheduling it should belong to DirectChannel, not the > DistributionImpl. > When the DirectChannel has disconnect called on it, then it should get rid of > all the tasks scheduled in the executor since they are no longer needed. > I think this issue has been around for a long time because the creation of > the thread refers to fixing "Bug 37944" which is on old bug system that is > not longer used for geode. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10335) TXManagerImpl.close does not remove itself from the static singeton
[ https://issues.apache.org/jira/browse/GEODE-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10335: -- Labels: blocks-1.16.0 (was: needsTriage) > TXManagerImpl.close does not remove itself from the static singeton > --- > > Key: GEODE-10335 > URL: https://issues.apache.org/jira/browse/GEODE-10335 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > TXManagerImpl.close does not remove itself from the static singleton. This > causes it to keep the GemFireCacheImpl alive after it has been closed. > The simple fix is to add "currentInstance = null" at the end of the close > method. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10337) SocketCreatorFactory does not null out instance static
[
https://issues.apache.org/jira/browse/GEODE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10337:
--
Labels: blocks-1.16.0 (was: needsTriage)
> SocketCreatorFactory does not null out instance static
> --
>
> Key: GEODE-10337
> URL: https://issues.apache.org/jira/browse/GEODE-10337
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Priority: Major
> Labels: blocks-1.16.0
>
> The SocketCreatorFactory has a static "instance" field that keeps the
> singleton factory. The factory has a reference in "distributionConfig" that
> ends up keeping the InternalDistributedSystem alive after disconnect.
> It also has a static close method but the product never calls it.
> To fix this leak do the following:
> On InternalDistributedSystem.disconnect add to the end of it:
> {code:java}
> if (!attemptingToReconnect) {
> SocketCreatorFactory.close();
> }
> {code}
> Also I think it would be good to change SocketCreatorFactory.getInstance to
> null out the static when close it called like so:
> {code:java}
> private static synchronized SocketCreatorFactory getInstance(boolean
> closing) {
> SocketCreatorFactory result = instance;
> if (result == null && !closing) {
> result = new SocketCreatorFactory();
> instance = result;
> } else if (result != null && closing) {
> instance = null;
> }
> return result;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
[ https://issues.apache.org/jira/browse/GEODE-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10336: -- Labels: blocks-1.16.0 (was: needsTriage) > ConnectionTable.close does not null out its static lastInstance field > - > > Key: GEODE-10336 > URL: https://issues.apache.org/jira/browse/GEODE-10336 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > The ConnectionTable.close method does a bunch of work but it does not null > out the static "lastInstance" atomic. This causes it to keep the > ConnectionTable alive which ends up keeping the InternalDistributedSystem > alive. > The easiest fix is to do this at the end of close: "emergencyClose();". The > emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10285) the auto reconnect after a forced disconnect uses more memory than needed
[ https://issues.apache.org/jira/browse/GEODE-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10285: -- Labels: blocks-1.16.0 (was: ) > the auto reconnect after a forced disconnect uses more memory than needed > - > > Key: GEODE-10285 > URL: https://issues.apache.org/jira/browse/GEODE-10285 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > When a member is forced out of the distributed system, if > disable-auto-reconnect=false (the default), then it will attempt to close its > cache, disconnect from the cluster, and then reconnect and create a new > cache. Because of the way this is implemented, the old cache is kept in > memory while the new cache is being created. This can end up causing > reconnect to use much more memory then it needs. That memory will be freed > after the reconnect completes, but it is possible for this to cause the JVM > to run out of memory during the reconnect. > So far I have found two places that keep the old cache around: > 1. InternalDistributedSystem.tryReconnect is passed the old cache as a > parameter. Only one caller exists and only a small block of code in > tryReconnect needs the old cache. So it would be easy to fix this by not > passing it in as a parameter. > 2. InternalDistributedSystem.reconnect (called by tryReconnect) keeps the old > cache in a local variable "cache". It only needs it to initialize "cacheXML" > and "cacheServerCreation". So once those are initialized it would be easy to > drop this ref. But cacheServerCreation also contains references to the old > cache through the "cache" instance variable on CacheServerCreation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
[
https://issues.apache.org/jira/browse/GEODE-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10338:
--
Labels: blocks-1.16.0 (was: needsTriage)
> LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
> --
>
> Key: GEODE-10338
> URL: https://issues.apache.org/jira/browse/GEODE-10338
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Darrel Schneider
>Priority: Major
> Labels: blocks-1.16.0
>
> The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
> When stopSession is called on the appender, it closes the ManagerLogWriter's
> files but does not release its reference to it and the LogWriterAppender
> instance is kept around after disconnect. So this ends up keeping the
> InternalDistributedSystem alive.
> To fix this change LogWriterAppender.stopSession like so:
> {code:java}
> public synchronized void stopSession() {
> LOGGER.info("Stopping session in {}.", this);
> if (logWriter == null) {
> // we are probably already paused but make sure we are
> pause();
> return;
> }
> logWriter.shuttingDown();
> pause();
> logWriter.closingLogFile();
> logWriter = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10304) CI Failure: ReconnectDUnitTest.testReconnectALocator
[
https://issues.apache.org/jira/browse/GEODE-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10304:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> CI Failure: ReconnectDUnitTest.testReconnectALocator
>
>
> Key: GEODE-10304
> URL: https://issues.apache.org/jira/browse/GEODE-10304
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ReconnectDUnitTest$14.run in VM 0 running on Host
> heavy-lifter-2ef8f049-b612-51d7-862a-3722e231b1de.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:676)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.assertGfshWaitingThreadAlive(ReconnectDUnitTest.java:646)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:587)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.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
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
>
[jira] [Updated] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10106:
--
Labels: blocks-1.15.0 pull-request-available (was: pull-request-available)
> CI Failure: CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer
> ---
>
> Key: GEODE-10106
> URL: https://issues.apache.org/jira/browse/GEODE-10106
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
> {noformat}
> CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer FAILED
> 11:49:39java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 11:49:39Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 11:49:39
> ---
> 11:49:39Found suspect string in 'dunit_suspect-vm4.log' at line 431
> 11:49:39
> 11:49:39[error 2022/03/05 19:49:36.075 UTC
> tid=55] Error in
> redundancy satisfier
> 11:49:39java.lang.NullPointerException
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
> 11:49:39 at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
> 11:49:39 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:49:39 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:49:39 at java.lang.Thread.run(Thread.java:750)
> 11:49:39at org.junit.Assert.fail(Assert.java:89)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> 11:49:39at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:49:39at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:49:39at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:49:39at java.lang.reflect.Method.invoke(Method.java:498)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> 11:49:39at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 11:49:39at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 11:49:39at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 11:49:39at
>
[jira] [Updated] (GEODE-10317) Range query with wildcard character doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10317: -- Labels: (was: needsTriage) > Range query with wildcard character doing wrong comparison > -- > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10287: -- Labels: (was: needsTriage) > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10308) CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
[
https://issues.apache.org/jira/browse/GEODE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10308:
--
Affects Version/s: 1.16.0
> CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
> --
>
> Key: GEODE-10308
> URL: https://issues.apache.org/jira/browse/GEODE-10308
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.cache.CacheClosedException: The cache is closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5207)
> at
> org.apache.geode.internal.cache.LocalRegion$Stopper.generateCancelledException(LocalRegion.java:11342)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
> at
> org.apache.geode.internal.cache.execute.InternalFunctionExecutionServiceImpl.onRegion(InternalFunctionExecutionServiceImpl.java:122)
> at
> org.apache.geode.cache.execute.FunctionService.onRegion(FunctionService.java:79)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.getExecutionForFunctionOnRegionWithFilter(ClientServerSessionCache.java:283)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.touchSessions(ClientServerSessionCache.java:101)
> at
> org.apache.geode.modules.session.catalina.DeltaSessionManager$1.run(DeltaSessionManager.java:534)
> at java.util.TimerThread.mainLoop(Timer.java:556)
> at java.util.TimerThread.run(Timer.java:506)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/334
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10305) CI Failure: TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest failed
[
https://issues.apache.org/jira/browse/GEODE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10305:
--
Affects Version/s: 1.16.0
> CI Failure:
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> failed
> -
>
> Key: GEODE-10305
> URL: https://issues.apache.org/jira/browse/GEODE-10305
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError: [The Cache Server process
> terminated unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit439159077415808630/server for full details.
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/tmp/geode_container_install8549633813411705254/cargo_containers/Tomcat8AndCurrentModules/tomcat-8.5.66/apache-tomcat-8.5.66/lib/slf4j-jdk14-1.7.32.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/home/geode/geode/geode-assembly/build/install/apache-geode/lib/log4j-slf4j-impl-2.17.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]
> {noformat}
> This is caused by ForcedDisconnectException during cache creation.
> {noformat}
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-e2fd6dd2-c530-54ef-ab7c-b95e0e8cca34(server:240126):41036
> started at Thu May 05 21:36:30 UTC 2022: Member isn't responding to heartbeat
> requests, caused by org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2899)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1183)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5201)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceImpl.(CqServiceImpl.java:166)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceFactoryImpl.create(CqServiceFactoryImpl.java:59)
> at
> org.apache.geode.cache.query.internal.cq.CqServiceProvider.create(CqServiceProvider.java:63)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:1004)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:864)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:913)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:814)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:740)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:259)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.DistributionImpl$LifecycleListenerImpl.forcedDisconnect(DistributionImpl.java:941)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1792)
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/331
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10298) [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest > testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
[
https://issues.apache.org/jira/browse/GEODE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10298:
--
Labels: (was: needsTriage)
> [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> -
>
> Key: GEODE-10298
> URL: https://issues.apache.org/jira/browse/GEODE-10298
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Owen Nichols
>Priority: Major
>
> {noformat}
> GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup 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 417
> [fatal 2022/05/10 18:57:14.216 UTC tid=226]
> Exception in processing request from 10.0.2.167
> 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:750)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:552)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:499)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:482)
> 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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.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
>
[jira] [Updated] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10312:
--
Labels: blocks-1.15.0 (was: blocks-1.15.0)
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Priority: Major
> Labels: blocks-1.15.0
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1352)
> at
>
[jira] [Updated] (GEODE-10290) GII requester should remove departed members
[ https://issues.apache.org/jira/browse/GEODE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10290: -- Labels: blocks-1.15.0 pull-request-available (was: needsTriage pull-request-available) > GII requester should remove departed members > > > Key: GEODE-10290 > URL: https://issues.apache.org/jira/browse/GEODE-10290 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > In non-persistent but concurrent-check enabled case, members departed will be > marked. They should be removed from RVV during GII to prevent memberToVersion > in RVV grows bigger and bigger. > However, we only removed them from GII provider, not in GII requester. The > good opportunity to remove them in GII requester is when calculating > unfinished operations. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10306) CacheServerImpl should stop the acceptor immediately after stop is called
[
https://issues.apache.org/jira/browse/GEODE-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10306:
--
Labels: (was: needsTriage)
> CacheServerImpl should stop the acceptor immediately after stop is called
> -
>
> Key: GEODE-10306
> URL: https://issues.apache.org/jira/browse/GEODE-10306
> Project: Geode
> Issue Type: Bug
>Reporter: Mark Hanson
>Priority: Major
>
> Currently, after cache server stop is called, it takes a while for the
> acceptor to stop taking new data, which can be a problem because the bigger
> the window of time, the greater the risk of data loss.
>
> {noformat}
> public synchronized void stop() {
> if (!isRunning()) {
> return;
> }
> RuntimeException firstException = null;
> try {
> if (loadMonitor != null) {
> loadMonitor.stop();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing load monitor", e);
> firstException = e;
> }
> try {
> if (advisor != null) {
> advisor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing advisor", e);
> firstException = e;
> }
> PROBLEM -> try {
> if (acceptor != null) {
> acceptor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing acceptor monitor", e);
> if (firstException != null) {
> firstException = e;
> }
> } {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[ https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10300: -- Labels: pull-request-available (was: needsTriage pull-request-available) > C++ Native client messages coming from the locator cannot be longer than 3000 > bytes > --- > > Key: GEODE-10300 > URL: https://issues.apache.org/jira/browse/GEODE-10300 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > If a locator sends a response to the C++ native client that is longer than > 3000 bytes the C++ native client library will only read the first 3000 bytes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
[ https://issues.apache.org/jira/browse/GEODE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10296: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Parser error in HDR histogram log can result in terminate of JVM > > > Key: GEODE-10296 > URL: https://issues.apache.org/jira/browse/GEODE-10296 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > > The HDR histogram parser exits the JVM on parsing errors. This results in > benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10282) Migrate from springfox to springdoc
[ https://issues.apache.org/jira/browse/GEODE-10282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10282: -- Labels: blocks-1.15.0 pull-request-available (was: pull-request-available) > Migrate from springfox to springdoc > --- > > Key: GEODE-10282 > URL: https://issues.apache.org/jira/browse/GEODE-10282 > Project: Geode > Issue Type: Task > Components: rest (admin), rest (dev) >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > Replace springfox with springdoc because springfox is no longer active. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10281) Internal conflict replicated region resolution causes data inconsistency between two sites
[
https://issues.apache.org/jira/browse/GEODE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10281:
--
Labels: blocks-1.15.0 pull-request-available (was: needsTriage
pull-request-available)
> Internal conflict replicated region resolution causes data inconsistency
> between two sites
> --
>
> Key: GEODE-10281
> URL: https://issues.apache.org/jira/browse/GEODE-10281
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> {color:#0e101a}Still working on the issue, but so far, it seems that the
> following PR
> {color}[{color:#4a6ee0}https://github.com/apache/geode/pull/3044{color}]{color:#0e101a}
> has not taken into consideration that event with a flag
> isConcurrencyConflict=true could delete the valid event from the queue due to
> conflation.{color}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10277) Exception thrown when checking gatewaySender EventQueueSize, while restarting gateway sender with clean queue option
[ https://issues.apache.org/jira/browse/GEODE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10277: -- Labels: blocks-1.15.0 pull-request-available (was: needsTriage pull-request-available) > Exception thrown when checking gatewaySender EventQueueSize, while restarting > gateway sender with clean queue option > > > Key: GEODE-10277 > URL: https://issues.apache.org/jira/browse/GEODE-10277 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.15.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > In case we are checking EventQueueSize in server with full parallel gateway > sender queue, and gateway sender is restarted with --cleanqueue option, > NullPointerException occures in JMX client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10277) Exception thrown when checking gatewaySender EventQueueSize, while restarting gateway sender with clean queue option
[ https://issues.apache.org/jira/browse/GEODE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10277: -- Affects Version/s: 1.15.0 > Exception thrown when checking gatewaySender EventQueueSize, while restarting > gateway sender with clean queue option > > > Key: GEODE-10277 > URL: https://issues.apache.org/jira/browse/GEODE-10277 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.15.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage, pull-request-available > > In case we are checking EventQueueSize in server with full parallel gateway > sender queue, and gateway sender is restarted with --cleanqueue option, > NullPointerException occures in JMX client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10268) Peer-to-peer connection due to race condition overtakes the --server-port causing server to hang during startup
[ https://issues.apache.org/jira/browse/GEODE-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10268: -- Labels: (was: needsTriage) > Peer-to-peer connection due to race condition overtakes the --server-port > causing server to hang during startup > --- > > Key: GEODE-10268 > URL: https://issues.apache.org/jira/browse/GEODE-10268 > Project: Geode > Issue Type: Bug >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10266: -- Labels: pull-request-available (was: needsTriage pull-request-available) > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10267) Create parallel gw sender with non-existent disk store does not fail
[
https://issues.apache.org/jira/browse/GEODE-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10267:
--
Labels: (was: needsTriage)
> Create parallel gw sender with non-existent disk store does not fail
>
>
> Key: GEODE-10267
> URL: https://issues.apache.org/jira/browse/GEODE-10267
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.14.4
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> While creating a parallel gw sender with a non-existing disk store, the
> command passed successfully but shouldn't.
> {code:java}
> gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
> --parallel=true --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- | ---
> server1 | OK | GatewaySender "ln" created on "server1"
> server2 | OK | GatewaySender "ln" created on "server2"
> Cluster configuration for group 'cluster' is updated.
> gfsh>list disk-stores
> No Disk Stores Found
> {code}
> For the serial gw sender, it throws that disk-store is not found as expected.
> {code:java}
> gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
> --parallel=false --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- |
> ---
> server1 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> server2 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10265) DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML cannot be run in parallel with itself.
[
https://issues.apache.org/jira/browse/GEODE-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10265:
--
Labels: (was: needsTriage)
> DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML
> cannot be run in parallel with itself.
>
>
> Key: GEODE-10265
> URL: https://issues.apache.org/jira/browse/GEODE-10265
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
>
> This test uses a hardcoded cache.xml with a server port inside that is
> hardcoded. Basically, the second test started in parallel will have a bind
> error because the port is already in use. We should consider generating the
> file rather than using a static one.
>
> Stress-new-test failure.
> [https://concourse.apachegeode-ci.info/builds/48751343]
>
> This issue was discovered as part of the stress-new-test of GEODE-10228's PR
> {noformat}
>
> name="client"
> subscription-enabled="true"
> load-conditioning-interval="6"
> read-timeout="3" retry-attempts="5" >
> The Problem > < The Problem
>
>
> id="testReadyForEventsNotCalledImplicitlyWithCacheXML_region"
> statistics-enabled="true" pool-name="client" refid="PROXY">
>
> org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil$ControlListener
>
>
> {noformat}
>
> {noformat}
> DurableClientSimpleDUnitTest >
> testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest$$Lambda$364/438711076.call
> in VM 0 running on Host
> heavy-lifter-f7bd4fb4-95bb-5e71-b25c-83f8d8a79c56.c.apachegeode-ci.internal
> with 4 VMs
> 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 450
> [error 2022/04/28 00:39:54.901 UTC
> tid=32] Cache initialization for GemFireCache[id = 1097663966; isClosing =
> false; isShutDownAll = false; created = Thu Apr 28 00:37:54 UTC 2022; server
> = true; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
> org.apache.geode.GemFireIOException: While starting cache server
> CacheServer on port=10188 client subscription config policy=entry client
> subscription config capacity=1000 client subscription config overflow
> directory=.
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:801)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:600)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4202)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1620)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1445)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil.createCacheServerFromXmlN(CacheServerTestUtil.java:253)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.lambda$testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML$515fd116$1(DurableClientSimpleDUnitTest.java:584)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (GEODE-10261) VMProvider.invokeAsync does not consistently use Generic types
[ https://issues.apache.org/jira/browse/GEODE-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10261: -- Labels: pull-request-available (was: needsTriage pull-request-available) > VMProvider.invokeAsync does not consistently use Generic types > -- > > Key: GEODE-10261 > URL: https://issues.apache.org/jira/browse/GEODE-10261 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.14.4 >Reporter: Joris Melchior >Assignee: Patrick Johnsn >Priority: Minor > Labels: pull-request-available > > In the VMProvider class there are several invokeAsync methods with various > signatures and in some cases they come with Generic type parameters and in > some cases they don't. > It's possible that some of this is influenced by the use of > SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little > deeper to find out to what degree we need to or can make changes here. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10228:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.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:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> 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:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10255) PdxSerializable not working correctly for multiple versions of the same class
[ https://issues.apache.org/jira/browse/GEODE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10255: -- Labels: (was: needsTriage) > PdxSerializable not working correctly for multiple versions of the same class > - > > Key: GEODE-10255 > URL: https://issues.apache.org/jira/browse/GEODE-10255 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *GIVEN* a couple of PdxSerializable implementations for the same class, let's > say v1 and v2 > *WHEN* you GET a v1 entry of this PdxSerializable just after client startup > and after that perform a PUT of v2 entry. > *THEN* the PUT operation uses the PdxType from v1 instead of the right one, > leading to data corruption -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525824#comment-17525824 ] Anthony Baker commented on GEODE-10144: --- I think the action here is to 1) update the SecurityManager implementation in the test to consistently evaluate tokens (ie never authorize an expired token) 2) Remove CQ/RI since this is not supported for reauthentication + old protocol versions > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server, native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10144: -- Component/s: native client > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server, native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10144: -- Labels: NativeClient (was: blocks-1.15.0 needsTriage) > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker reassigned GEODE-10144: - Assignee: Blake Bender (was: Jinmei Liao) > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: blocks-1.15.0, needsTriage > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10242: -- Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was: GeodeOperationAPI blocks-1.15.0 needsTriage pull-request-available) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10252) Update website privacy notice
Anthony Baker created GEODE-10252: - Summary: Update website privacy notice Key: GEODE-10252 URL: https://issues.apache.org/jira/browse/GEODE-10252 Project: Geode Issue Type: Task Components: website Reporter: Anthony Baker PMC's have been instructed to: 1) Remove all use of google analytics 2) Link to the ASF privacy notice: [https://privacy.apache.org/policies/privacy-policy-public.html] AFAICT, geode.apache.org does not use google analytics. We just need to add another footer item for the privacy notice. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10236) Compatibility issues while upgrading Jgroups to versions 4.0+
[
https://issues.apache.org/jira/browse/GEODE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10236:
--
Labels: (was: needsTriage)
> Compatibility issues while upgrading Jgroups to versions 4.0+
> -
>
> Key: GEODE-10236
> URL: https://issues.apache.org/jira/browse/GEODE-10236
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Rohan Jagtap
>Priority: Major
>
> According to a recent CVE:
> {quote}CVE-2016-2141
> NVD: 2016/06/30 - CVSS v2 Base Score: 7.5 - CVSS v3.1 Base Score: 9.8
> JGroups before 4.0 does not require the proper headers for the ENCRYPT and
> AUTH protocols from nodes joining the cluster, which allows remote attackers
> to bypass security restrictions and send and receive messages within the
> cluster via unspecified vectors.
>
> {quote}
> Hence we intend to upgrade jgroups to a recommended version.
> However, even the latest version of apache geode ([geode-core
> 1.14.4|https://mvnrepository.com/artifact/org.apache.geode/geode-core/1.14.4])
> uses jgroups 3.6.14 which has the aforementioned vulnerability.
> Overriding the jgroups dependency to anything over 4.0+ gives the following
> issue on running:
> {{Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'gemfireCache': FactoryBean threw exception on object
> creation; nested exception is java.lang.ExceptionInInitializerError}}
> {{ at
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:176)}}
> {{ at
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:101)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1828)}}
> {{ at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getObjectForBeanInstance(AbstractAutowireCapableBeanFactory.java:1265)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:334)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)}}
> {{ at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:330)}}
> {{ ... 32 common frames omitted}}
> {{Caused by: java.lang.ExceptionInInitializerError: null}}
> {{ at
> org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)}}
> {{ at
> org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)}}
> {{ at
> org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:150)}}
> {{ at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:217)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3036)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:216)}}
> {{ at
> org.apache.geode.internal.cache.InternalCacheBuilder.createInternalDistributedSystem(InternalCacheBuilder.java:346)}}
> {{ at java.base/java.util.Optional.orElseGet(Optional.java:369)}}
> {{ at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:157)}}
> {{ at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)}}
> {{ at
> org.springframework.data.gemfire.CacheFactoryBean.createCache(CacheFactoryBean.java:472)}}
> {{ at
> org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:326)}}
> {{ at
> org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:270)}}
> {{ at
[jira] [Updated] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10223:
--
Fix Version/s: 1.15.0
(was: 1.12.10)
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anthony Baker
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-10223:
-
Assignee: Anthony Baker
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anthony Baker
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.12.10
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10223:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anthony Baker
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.10
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10236) Compatibility issues while upgrading Jgroups to versions 4.0+
[
https://issues.apache.org/jira/browse/GEODE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-10236.
---
Resolution: Not A Bug
Please see [1]. Geode uses jgroups for reliable UDP transport. The
vulnerability exists only for AUTH / ENCRYPT which Geode does not use. This is
not a security issue.
I realize that it can be hard when scanners generate false positives like this.
However, upgrading to a new major version of JGroups is a large effort and may
break Geode guarantees like rolling upgrades. I think it's more likely that we
would invest in building a different transport layer for membership messages so
that we can control breaking changes introduced by jgroups.
[1] https://lists.apache.org/thread/ymj65x43g2k1ozdckkr92tt8rysrn8wd
> Compatibility issues while upgrading Jgroups to versions 4.0+
> -
>
> Key: GEODE-10236
> URL: https://issues.apache.org/jira/browse/GEODE-10236
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Rohan Jagtap
>Priority: Major
> Labels: needsTriage
>
> According to a recent CVE:
> {quote}CVE-2016-2141
> NVD: 2016/06/30 - CVSS v2 Base Score: 7.5 - CVSS v3.1 Base Score: 9.8
> JGroups before 4.0 does not require the proper headers for the ENCRYPT and
> AUTH protocols from nodes joining the cluster, which allows remote attackers
> to bypass security restrictions and send and receive messages within the
> cluster via unspecified vectors.
>
> {quote}
> Hence we intend to upgrade jgroups to a recommended version.
> However, even the latest version of apache geode ([geode-core
> 1.14.4|https://mvnrepository.com/artifact/org.apache.geode/geode-core/1.14.4])
> uses jgroups 3.6.14 which has the aforementioned vulnerability.
> Overriding the jgroups dependency to anything over 4.0+ gives the following
> issue on running:
> {{Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'gemfireCache': FactoryBean threw exception on object
> creation; nested exception is java.lang.ExceptionInInitializerError}}
> {{ at
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:176)}}
> {{ at
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:101)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1828)}}
> {{ at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getObjectForBeanInstance(AbstractAutowireCapableBeanFactory.java:1265)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:334)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)}}
> {{ at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:330)}}
> {{ ... 32 common frames omitted}}
> {{Caused by: java.lang.ExceptionInInitializerError: null}}
> {{ at
> org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)}}
> {{ at
> org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)}}
> {{ at
> org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:150)}}
> {{ at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:217)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3036)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:216)}}
> {{ at
>
[jira] [Commented] (GEODE-10189) Errors encountered during Apache Geode upgrade
[
https://issues.apache.org/jira/browse/GEODE-10189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522386#comment-17522386
]
Anthony Baker commented on GEODE-10189:
---
Please provide details on the dependencies you were trying to use. Note that
the binary convenience downloads provided on the geode website or in maven
provide all necessary version and are validated to work together correctly. If
you are trying to change library versions (such as using JGroups 4) you will
mostly likely encounter errors like above.
> Errors encountered during Apache Geode upgrade
> --
>
> Key: GEODE-10189
> URL: https://issues.apache.org/jira/browse/GEODE-10189
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.1
>Reporter: Swetha Sudheesh
>Priority: Critical
>
> We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1*
> version to avoid any vulnerabilities. We also added all the dependencies
> mentioned in the Maven with the latest versions. Our application uses {*}JDK
> 11{*}. We faced few issues such as the one described below:
>
> Exception in thread "Locator" *java.lang.ExceptionInInitializerError*
> at
> org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)
> at
> org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)
> at
> org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> 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)
>
> Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the
> wrong class: UUID*
> at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167)
> ... 17 more
> Please let us know why we are encountering this error and how can it be
> resolved? Also let us know the right dependencies that need to be added for
> Apache Geode 1.14.1 upgrade.
--
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
]
Anthony Baker updated GEODE-10066:
--
Labels: blocks-1.12.10 pull-request-available ssl (was: blocks-1.12.10
blocks-1.15.0 pull-request-available ssl)
> 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
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.12.10, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> 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
>
[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
]
Anthony Baker updated GEODE-10066:
--
Labels: blocks-1.12.10 blocks-1.15.0 pull-request-available ssl (was:
blocks-1.15.0 pull-request-available ssl)
> 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
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, pull-request-available,
> ssl
> Fix For: 1.15.0
>
>
> 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
[jira] [Updated] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10215:
--
Labels: (was: needsTriage)
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10220) Coredump while initializing PdxType remoteToLocal
[ https://issues.apache.org/jira/browse/GEODE-10220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10220: -- Labels: (was: needsTriage) > Coredump while initializing PdxType remoteToLocal > - > > Key: GEODE-10220 > URL: https://issues.apache.org/jira/browse/GEODE-10220 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *GIVEN* a cluster with 1 server and 1 locator > *AND* a native client connected to the cluster > *WHEN* deserializing a PdxSerializable like object > *AND* and a new PdxType is fetched from the server > *THEN* a coredump happens whenever initializing the remoteToLocal map. > --- > *Additional information.* The coredump happens whenever > PdxType::initRemoteToLocal is called -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (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:comment-tabpanel=17516048#comment-17516048
]
Anthony Baker commented on GEODE-9991:
--
See https://issues.apache.org/jira/browse/GEODE-10200
> 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.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> 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-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10121:
--
Labels: pull-request-available redis-triage (was: blocks-1.15.0
pull-request-available)
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: pull-request-available, redis-triage
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10147) CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception while trying to run ssl benchmarks
[
https://issues.apache.org/jira/browse/GEODE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516045#comment-17516045
]
Anthony Baker commented on GEODE-10147:
---
Does this just indicate a network/infrastructure failure during the test run?
> CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception
> while trying to run ssl benchmarks
> --
>
> Key: GEODE-10147
> URL: https://issues.apache.org/jira/browse/GEODE-10147
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> P2pPartitionedPutBenchmark > run() FAILED
> net.schmizz.sshj.transport.TransportException: Connection reset
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.copyFromNode(SshInfrastructure.java:185)
> at
> org.apache.geode.perftest.jvms.RemoteJVMs.copyResults(RemoteJVMs.java:87)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:112)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> at
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark.run(P2pPartitionedPutBenchmark.java:52)
> Caused by:
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:186)
> at java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.net.SocketInputStream.read(SocketInputStream.java:200)
> at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> ... 8 more
> 4 tests completed, 1 failed
> This is ITERATION 2 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> ReplicatedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by:
> java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
> ... 6 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during identification exchange
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> ... 7 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during identification exchange
> at
>
[jira] [Updated] (GEODE-10198) LINSERT is case-sensitive for arguments
[ https://issues.apache.org/jira/browse/GEODE-10198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10198: -- Labels: redis-triage (was: needsTriage) > LINSERT is case-sensitive for arguments > --- > > Key: GEODE-10198 > URL: https://issues.apache.org/jira/browse/GEODE-10198 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Priority: Major > Labels: redis-triage > > Qualifier arguments for LINSERT (e.g. BEFORE, AFTER) are only recognized if > they are uppercased. Native Redis is not case-sensitive with respect to these > arguments. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9700) ZUNIONSTORE and ZINTERSTORE need to work with regular sets as inputs
[ https://issues.apache.org/jira/browse/GEODE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9700: - Labels: redis-triage (was: release-blocker) > ZUNIONSTORE and ZINTERSTORE need to work with regular sets as inputs > > > Key: GEODE-9700 > URL: https://issues.apache.org/jira/browse/GEODE-9700 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Priority: Major > Labels: redis-triage > > Some of the Redis TCL tests fail when running against Geode due to > ZUNIONSTORE and ZINTERSTORE taking regular sets (as opposed to sorted sets) > as input. Geode returns the error "WRONGTYPE Operation against a key holding > the wrong kind of value" when native Redis succeeds. > The tests include: > * ZUNIONSTORE with a regular set and weights > * ZINTERSTORE with a regular set and weights > * ZINTERSTORE regression with two sets, intset+hashtable > * ZINTERSTORE #516 regression, mixed sets and ziplist zsets > Enable these tests as part of this fix. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-7710:
Assignee: (was: Kirk Lund)
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, needsTriage,
> pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> This test fails due to GEODE-7739. Enter new failures against that ticket.
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10045:
--
Labels: Micrometer blocks-1.15.0 (was: Micrometer)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer, blocks-1.15.0
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9880:
-
Labels: blocks-1.12.10 blocks-1.15.0 membership (was: blocks-1.12.10
membership)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
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
]
Anthony Baker updated GEODE-10055:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> 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
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> 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-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
]
Anthony Baker updated GEODE-10066:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> 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
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> 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
>
[jira] [Updated] (GEODE-9910) Failure to auto-reconnect upon network partition
[ https://issues.apache.org/jira/browse/GEODE-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9910: - Labels: blocks-1.15.0 (was: ) > Failure to auto-reconnect upon network partition > > > Key: GEODE-9910 > URL: https://issues.apache.org/jira/browse/GEODE-9910 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.0 >Reporter: Surya Mudundi >Priority: Major > Labels: blocks-1.15.0 > > Two node cluster with embedded locators failed to auto-reconnect when node-1 > experienced network outage for couple of minutes and when node-1 recovered > from the outage, node-2 failed to auto-reconnect. > node-2 tried to re-connect to node-1 as: > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #1. > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #2. > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #3. > Finally reported below error after 3 attempts as: > INFO > [org.apache.geode.logging.internal.LoggingProviderLoader]-[ReconnectThread] > [] Using org.apache.geode.logging.internal.SimpleLoggingProvider for service > org.apache.geode.logging.internal.spi.LoggingProvider > INFO [org.apache.geode.internal.InternalDataSerializer]-[ReconnectThread] [] > initializing InternalDataSerializer with 0 services > INFO > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] performing a quorum check to see if location services can be started early > INFO > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Quorum check passed - allowing location services to start early > WARN > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Exception occurred while trying to connect the system during reconnect > java.lang.IllegalStateException: A locator can not be created because one > already exists in this JVM. > at > org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:298) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:273) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSystem.java:916) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:768) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2605) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2424) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1275) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2326) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1187) > ~[geode-membership-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$forceDisconnect$0(GMSMembership.java:1811) > ~[geode-membership-1.14.0.jar:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10047) Warning message in geode-for-redis PassiveExpirationManager is inaccurate
[
https://issues.apache.org/jira/browse/GEODE-10047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10047:
--
Labels: blocks-1.15.0 pull-request-available (was: needsTriage
pull-request-available)
> Warning message in geode-for-redis PassiveExpirationManager is inaccurate
> -
>
> Key: GEODE-10047
> URL: https://issues.apache.org/jira/browse/GEODE-10047
> Project: Geode
> Issue Type: Bug
> Components: logging, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> If an exception is encountered during the {{doDataExpiration()}} method in
> {{{}PassiveExpirationManager{}}}, the following message is logged:
> {code:java}
> logger.warn("Passive expiration failed. Will try again in 1 second.",
> ex);{code}
> However, the passive expiration interval in geode-for-redis defaults to 180
> seconds and can be configured by the user to other values. The log message
> should reflect the configured value for passive expiration interval.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10039: -- Labels: blocks-1.15.0 (was: needsTriage) > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Priority: Major > Labels: blocks-1.15.0 > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [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
]
Anthony Baker updated GEODE-10031:
--
Labels: (was: needsTriage)
> Can't stop embedded locator when SSL endpoint validation is enabled.
>
>
> Key: GEODE-10031
> URL: https://issues.apache.org/jira/browse/GEODE-10031
> Project: Geode
> Issue Type: Bug
> Components: jmx, locator, security, tests
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Priority: Minor
>
> 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-9087) Fix the documentation for SCAN commands.
[ https://issues.apache.org/jira/browse/GEODE-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9087: - Component/s: docs > Fix the documentation for SCAN commands. > > > Key: GEODE-9087 > URL: https://issues.apache.org/jira/browse/GEODE-9087 > Project: Geode > Issue Type: Bug > Components: docs, redis >Reporter: Nabarun Nag >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Fix documentation for SCAN command, especially the data types accepted by it. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-1537) DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA
[ https://issues.apache.org/jira/browse/GEODE-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-1537: - Labels: CI pull-request-available testing (was: CI pull-request-available) > DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA > > > Key: GEODE-1537 > URL: https://issues.apache.org/jira/browse/GEODE-1537 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Jinmei Liao >Assignee: Jens Deppe >Priority: Major > Labels: CI, pull-request-available, testing > Fix For: 1.15.0 > > > Geode_develop_DistributedTests/2883 > Error Message > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest$$Lambda$373/449639279.run > in VM 1 running on Host timor.gemstone.com with 4 VMs > Stacktrace > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest$$Lambda$373/449639279.run > in VM 1 running on Host timor.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293) > at > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA(DurableRegistrationDUnitTest.java:421) > 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:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > 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.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor426.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.GeneratedMethodAccessor425.invoke(Unknown Source) > at >
[jira] [Updated] (GEODE-6143) PowerMock should not be used in Geode tests [PERMANENT]
[
https://issues.apache.org/jira/browse/GEODE-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-6143:
-
Issue Type: Task (was: Bug)
> PowerMock should not be used in Geode tests [PERMANENT]
> ---
>
> Key: GEODE-6143
> URL: https://issues.apache.org/jira/browse/GEODE-6143
> Project: Geode
> Issue Type: Task
> Components: build, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
> Time Spent: 13h 10m
> Remaining Estimate: 0h
>
> At least one usage of PowerMock in our unit tests is leaking and causing
> other tests to fail with the following stack.
> No further tests should be written using PowerMock and all tests that
> currently use it need to be identified and changed (along with product code
> refactoring) to not use PowerMock.
> We will then remove PowerMock as a dependency from Geode.
> {noformat}
> 2018-12-04 18:11:36,258 Distributed system shutdown hook ERROR Could not
> reconfigure JMX java.lang.LinkageError: loader constraint violation: loader
> (instance of org/powermock/core/classloader/MockClassLoader) previously
> initiated loading for a different type with name
> "javax/management/MBeanServer"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> org.powermock.core.classloader.MockClassLoader.loadUnmockedClass(MockClassLoader.java:262)
> at
> org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:206)
> at
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass1(DeferSupportingClassLoader.java:89)
> at
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:79)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:337)
> at
> org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:261)
> at
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:165)
> at
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:141)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:558)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:636)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:661)
> at
> org.apache.geode.internal.logging.LogService.getLogger(LogService.java:64)
> at
> org.apache.geode.internal.tcp.ConnectionTable.(ConnectionTable.java:61)
> at
> org.apache.geode.distributed.DistributedSystem.setThreadsSocketPolicy(DistributedSystem.java:263)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.lambda$static$0(InternalDistributedSystem.java:2317)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8192) Redis MSET command needs to be atomic
[ https://issues.apache.org/jira/browse/GEODE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8192: - Labels: pull-request-available unreleased (was: pull-request-available) > Redis MSET command needs to be atomic > - > > Key: GEODE-8192 > URL: https://issues.apache.org/jira/browse/GEODE-8192 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > All of the supported and unsupported redis string commands (for the 1.14 > release) that need to be atomic now are except for MSET. > Note that MGET does not need to be atomic. > To make MSET atomic it could do something like RENAME does to lock multiple > keys in a manner that prevent a distributed deadlock. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8097) ClientClusterManagementServiceTest expects 1 callback but gets 295
[
https://issues.apache.org/jira/browse/GEODE-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8097:
-
Labels: GeodeOperationAPI blocks-1.14.0 pull-request-available testing
(was: GeodeOperationAPI blocks-1.14.0 pull-request-available)
> ClientClusterManagementServiceTest expects 1 callback but gets 295
> --
>
> Key: GEODE-8097
> URL: https://issues.apache.org/jira/browse/GEODE-8097
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0,
> pull-request-available, testing
> Fix For: 1.14.0, 1.15.0
>
>
> CI test failed here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/138#A
> {code}
> org.apache.geode.management.internal.ClientClusterManagementServiceTest >
> getOperationCallsSubmitMessageAndReturnsFuture FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.ClientClusterManagementServiceTest
> clusterManagementServiceTransport.submitMessageForGetOperation(
>
> same(org.apache.geode.management.operation.RebalanceOperation@6d6b2db0),
> same("opId")
> );
> Wanted 1 time:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementServiceTest.lambda$getOperationCallsSubmitMessageAndReturnsFuture$1(ClientClusterManagementServiceTest.java:170)
> But was 295 times:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> …
> {code}
> Ran it 100 times in IntelliJ with no failures.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8528) PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to missing disk store after server restart
[ https://issues.apache.org/jira/browse/GEODE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8528: - Labels: GeodeOperationAPI testing (was: GeodeOperationAPI) > PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to > missing disk store after server restart > -- > > Key: GEODE-8528 > URL: https://issues.apache.org/jira/browse/GEODE-8528 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.12.0 >Reporter: Benjamin P Ross >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, testing > Fix For: 1.15.0 > > > org.apache.geode.internal.cache.PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHop FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$313/839097690.call > in VM 1 running on Host 3e9ce4ee92bd with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) > at org.apache.geode.test.dunit.VM.invoke(VM.java:462) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop(PutAllClientServerDistributedTest.java:1894) > Caused by: > java.lang.IllegalStateException: Disk store ds1 not found > at > org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7480) > at > org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRegion.java:9203) > at > org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:602) > at > org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:546) > at > org.apache.geode.internal.cache.PartitionedRegion.(PartitionedRegion.java:760) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:2925) > at > org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2869) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2853) > at > org.apache.geode.cache.RegionFactory.create(RegionFactory.java:768) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.createServer(PutAllClientServerDistributedTest.java:2797) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testPartialKeyInPRSingleHop$515fd116$1(PutAllClientServerDistributedTest.java:1894) > Halfway through the test we shutdown Server2 and restart it, but upon > attempting to start the server with the same disk store name we used original > we get missing disk store errors. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8616:
-
Labels: GeodeOperationAPI flaky-test pull-request-available testing (was:
GeodeOperationAPI flaky-test pull-request-available)
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1, 1.13.7, 1.14.3, 1.15.0
>Reporter: Donal Evans
>Assignee: Nabarun Nag
>Priority: Major
> Labels: GeodeOperationAPI, flaky-test, pull-request-available,
> testing
> Fix For: 1.15.0, 1.16.0
>
> Attachments: hansonm-findfailures-11-10-2021-23-52-38-logs.tgz,
> hansonm-findfailures-11-10-2021-23-52-45-logs.tgz
>
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8859) Redis data structures may not accurately reflect their size in Geode stats
[
https://issues.apache.org/jira/browse/GEODE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8859:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Redis data structures may not accurately reflect their size in Geode stats
> --
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
> Issue Type: Bug
> Components: redis, statistics
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> Here is a comment from Darrel regarding this issue. For some background, the
> Redis structures implement {{Delta}}.
>
> {quote}I was playing around with RedisInsight and was able to get most the
> the overview dashboard and the data browser working with geode redis. But I
> found a problem with how we are using geode that causes the geode stats that
> track how much data is stored in a partitioned region to be wrong and the
> bucket sizes used for rebalancing are also wrong. Basically when we do create
> ops on the region the stats track it okay. But when we do updates then geode
> always thinks that nothing (size wise) changed. So for example I created a
> string by doing a redis “set” command. I saw the size of the string accounted
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on
> that key and the dataStoreBytesInUse did not change at all. I think the
> problem is in how we are updating the data structure in place instead of
> getting a copy, modifying it, and then putting the copy into the region.
> Avoiding this copy gives us MUCH better performance but it messes up geode
> when it is trying to calculate the memory increase or decrease. It is
> possible that this is only an issue on the primary and that the secondary
> sizing may be correct. If so that could lead to other problems because for a
> given bucket our primary size would be different than the secondary. The
> bucket sizes are used when you do a rebalance but basically we can have a
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced
> but geode will think the buckets are balanced. I’m not sure what we should do
> about this.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8644: - Labels: GeodeOperationAPI pull-request-available testing (was: GeodeOperationAPI pull-request-available test) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, testing > Fix For: 1.15.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8644: - Labels: GeodeOperationAPI pull-request-available test (was: GeodeOperationAPI pull-request-available) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, test > Fix For: 1.15.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
