[jira] [Updated] (GEODE-10071) Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand
[ https://issues.apache.org/jira/browse/GEODE-10071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10071: --- Labels: pull-request-available (was: ) > Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand > > > Key: GEODE-10071 > URL: https://issues.apache.org/jira/browse/GEODE-10071 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0, 1.16.0 >Reporter: Udo Kohlmeyer >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > There is a cyclical dependency between the Command and the implementing > function for the Wan copy feature. > Logically, the command needs to have a dependency on the function. > The error messages currently defined in the Command class need to be moved to > the function class where they are used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10068) Make WanCopyRegionFunctionService thread pool configurable through configuration or property
[ https://issues.apache.org/jira/browse/GEODE-10068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10068: --- Labels: pull-request-available (was: ) > Make WanCopyRegionFunctionService thread pool configurable through > configuration or property > > > Key: GEODE-10068 > URL: https://issues.apache.org/jira/browse/GEODE-10068 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0, 1.16.0 >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > The current implementation of `WanCopyRegionFunctionService` creates a fixed > thread pool of size 10. This is possibly something that one would like to be > able to configure. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9950) Implement LRANGE
[ https://issues.apache.org/jira/browse/GEODE-9950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502406#comment-17502406 ] ASF subversion and git services commented on GEODE-9950: Commit 2cd5d8271357b76e76c584577ae0c214cc5cdc16 in geode's branch refs/heads/develop from Kris10 [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2cd5d82 ] GEODE-9950: Add Radish LRANGE command (#7389) This implements a version of the Redis LRANGE command, which is used for list data types. Associated tests were also added. Given a key, it returns a list of elements in the range (inclusive) for the specified start index and stop index. Both the start and stop indexes are zero based, which starts at the head of the list. Negative indexes start at the tail of the list. LINDEX was modified to use a new method created in this commit. The method converts negative indexes to the corresponding positive index. > Implement LRANGE > > > Key: GEODE-9950 > URL: https://issues.apache.org/jira/browse/GEODE-9950 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > > Implement the LRANGE command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17502431#comment-17502431
]
Geode Integration commented on GEODE-10066:
---
Seen in [windows-unit-test-openjdk11
#184|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/184]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0116/test-results/test/1646593149/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0116/test-artifacts/1646593149/windows-unittestfiles-openjdk11-1.16.0-build.0116.tgz].
> 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: needsTriage, 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.Gatewa
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17502435#comment-17502435
]
Geode Integration commented on GEODE-10066:
---
Seen in [windows-unit-test-openjdk11
#183|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/183]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0116/test-results/test/1646524811/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0116/test-artifacts/1646524811/windows-unittestfiles-openjdk11-1.16.0-build.0116.tgz].
> 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: needsTriage, 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.Gatewa
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17502434#comment-17502434
]
Jens Deppe commented on GEODE-10066:
It looks like this test is broken under Windows.
> 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: needsTriage, 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
> org.apache.geode.internal.cache.
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17502436#comment-17502436
]
Geode Integration commented on GEODE-10066:
---
Seen in [windows-unit-test-openjdk11
#182|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/182]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0116/test-results/test/1646518593/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0116/test-artifacts/1646518593/windows-unittestfiles-openjdk11-1.16.0-build.0116.tgz].
> 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: needsTriage, 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.Gatewa
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502437#comment-17502437
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#178|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/178].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[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
]
Alexander Murmann updated GEODE-10106:
--
Labels: needsTriage (was: )
> 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.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [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
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> 11:49:39at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
[jira] [Created] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
Jens Deppe created GEODE-10106:
--
Summary: 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.16.0
Reporter: Jens Deppe
[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:39at
org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
11:49:39at
org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
11:49:39at
org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
11:49:39at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
11:49:39at java.util.concurrent.FutureTask.run(FutureTask.java:266)
11:49:39at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
11:49:39at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
11:49:39at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
11:49:39at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
11:49:39at 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
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
11:49:39at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
11:49:39at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
11:49:39at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
11:49:39at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
11:49:39at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
11:49:39at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
11:49:39
[jira] [Commented] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502440#comment-17502440
]
Geode Integration commented on GEODE-10106:
---
Seen in [distributed-test-openjdk8
#1382|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646516490/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646516490/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz].
> 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.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [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:39
[jira] [Commented] (GEODE-8392) CI Failure: Jetty9CachingClientServerTest > sessionPicksUpSessionTimeoutConfiguredInWebXml
[ https://issues.apache.org/jira/browse/GEODE-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502442#comment-17502442 ] Geode Integration commented on GEODE-8392: -- Seen in [distributed-test-openjdk8 #1371|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1371] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646505871/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646505871/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz]. > CI Failure: Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml > -- > > Key: GEODE-8392 > URL: https://issues.apache.org/jira/browse/GEODE-8392 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Owen Nichols >Priority: Major > > Failure: [DistributedTestOpenJDK11 > #381|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/381#A] > org.apache.geode.session.tests.Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml FAILED > org.awaitility.core.ConditionTimeoutException: Condition with lambda > expression in org.apache.geode.session.tests.CargoTestBase was not fulfilled > within 5 minutes. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-results/distributedTest/1596061367/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-artifacts/1596061367/distributedtestfiles-OpenJDK11-1.14.0-build.0247.tgz*] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8392) CI Failure: Jetty9CachingClientServerTest > sessionPicksUpSessionTimeoutConfiguredInWebXml
[ https://issues.apache.org/jira/browse/GEODE-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502443#comment-17502443 ] Geode Integration commented on GEODE-8392: -- Seen in [distributed-test-openjdk8 #1303|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1303] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646449910/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646449910/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz]. > CI Failure: Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml > -- > > Key: GEODE-8392 > URL: https://issues.apache.org/jira/browse/GEODE-8392 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Owen Nichols >Priority: Major > > Failure: [DistributedTestOpenJDK11 > #381|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/381#A] > org.apache.geode.session.tests.Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml FAILED > org.awaitility.core.ConditionTimeoutException: Condition with lambda > expression in org.apache.geode.session.tests.CargoTestBase was not fulfilled > within 5 minutes. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-results/distributedTest/1596061367/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-artifacts/1596061367/distributedtestfiles-OpenJDK11-1.14.0-build.0247.tgz*] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8392) CI Failure: Jetty9CachingClientServerTest > sessionPicksUpSessionTimeoutConfiguredInWebXml
[ https://issues.apache.org/jira/browse/GEODE-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502444#comment-17502444 ] Geode Integration commented on GEODE-8392: -- Seen in [distributed-test-openjdk8 #1327|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1327] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646466602/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646466602/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz]. > CI Failure: Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml > -- > > Key: GEODE-8392 > URL: https://issues.apache.org/jira/browse/GEODE-8392 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Owen Nichols >Priority: Major > > Failure: [DistributedTestOpenJDK11 > #381|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/381#A] > org.apache.geode.session.tests.Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml FAILED > org.awaitility.core.ConditionTimeoutException: Condition with lambda > expression in org.apache.geode.session.tests.CargoTestBase was not fulfilled > within 5 minutes. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-results/distributedTest/1596061367/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-artifacts/1596061367/distributedtestfiles-OpenJDK11-1.14.0-build.0247.tgz*] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502448#comment-17502448 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #1370|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1370] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646502226/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646502226/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17502451#comment-17502451
]
Geode Integration commented on GEODE-10066:
---
Seen in [windows-unit-test-openjdk11
#185|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/185]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0122/test-results/test/1646673749/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0122/test-artifacts/1646673749/windows-unittestfiles-openjdk11-1.16.0-build.0122.tgz].
> 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: needsTriage, 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.Gatewa
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17502453#comment-17502453
]
Geode Integration commented on GEODE-10066:
---
Seen in [unit-test-openjdk11
#183|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/unit-test-openjdk11/builds/183]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0122/test-results/test/1646672922/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0122/test-artifacts/1646672922/unittestfiles-openjdk11-1.16.0-build.0122.tgz].
> 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: needsTriage, 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.GatewaySenderEventRemoteDispat
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502456#comment-17502456 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #1366|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1366] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646499269/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646499269/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502462#comment-17502462
]
ASF GitHub Bot commented on GEODE-10096:
mreddington commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r820950242
##
File path: cppcache/src/util/to_underlying.hpp
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef UTIL_UNDERLYING_TYPE_HPP
+#define UTIL_UNDERLYING_TYPE_HPP
+
+#include
+
+/* Note: this implementation can be thrown away once we upgrade to C++14. */
+
+template< class T >
+using underlying_type_t = typename std::underlying_type::type;
+
+/* Note: this implementation can be thrown away once we upgrade to C++23. */
+
+template< class Enum >
+constexpr underlying_type_t to_underlying( Enum e ) noexcept {
Review comment:
Counterpoints:
* This is a direct copy of an STL utility we just don't have in C++11.
* Look where I'm using it - at some point, we need to write these enum
values to the byte stream. Now there are two ways we can do that:
- We can map an enum to a value, and a value to an enum, like via some
switch statement. If we do that, then we don't need to specify the enum values
themselves, since we'd never cast the enum to or from an integer type. This is
just redundant in every way.
- We cast the enum where we write bytes to the wire.
* It doesn't need a reverse. You can static cast any integer to an enum and
the compiler will let you know if you're narrowing, but if you want to cast
from an enum to the numeric type used to implement it, that's built into the
enum type but you wouldn't know it, or can't rely on it since it can change,
either by the compiler, or in the case of an enum class, the implementer. The
compiler always knows, so this leverages deduction to get it right for you.
But I feel you. I don't like the use of enums overall. There's just
something about them that don't seem "good enough". I don't think C++ would
have had enumerations in the form we have them today if we didn't inherit from
C, so I'm always aware of the loose type safety they come with.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
>
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502470#comment-17502470 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #1346|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1346] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646483845/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646483845/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10107:
--
Labels: needsTriage (was: )
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> 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.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
Jens Deppe created GEODE-10107:
--
Summary: CI Failure: ReplicateRegionNetsearchDistributedTest >
proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
Key: GEODE-10107
URL: https://issues.apache.org/jira/browse/GEODE-10107
Project: Geode
Issue Type: Bug
Reporter: Jens Deppe
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
{noformat}
ReplicateRegionNetsearchDistributedTest >
proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
org.opentest4j.AssertionFailedError:
expected: 1L
but was: 0L
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.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10107:
---
Component/s: regions
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> 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.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10107:
---
Affects Version/s: 1.16.0
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
> Components: core, regions
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> 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.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10107:
---
Component/s: core
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
> Components: core, regions
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> 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.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502475#comment-17502475
]
Geode Integration commented on GEODE-10107:
---
Seen in [distributed-test-openjdk8
#1340|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1340]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz].
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
> Components: core, regions
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> 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.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9843) CI failure: DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts failed with TooFewActualInvocations
[
https://issues.apache.org/jira/browse/GEODE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502476#comment-17502476
]
Geode Integration commented on GEODE-9843:
--
Seen in [distributed-test-openjdk8
#1335|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1335]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646474825/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646474825/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz].
> CI failure:
> DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts
> failed with TooFewActualInvocations
> -
>
> Key: GEODE-9843
> URL: https://issues.apache.org/jira/browse/GEODE-9843
> Project: Geode
> Issue Type: Bug
> Components: core, management
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kamilla Aslami
>Priority: Major
>
> {noformat}
> DistributedSystemMXBeanWithAlertsDistributedTest >
> managerMissesAnyAlertsBeforeItStarts FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest$$Lambda$301/390135366.run
> in VM 0 running on Host
> heavy-lifter-993df0f4-3655-560f-82a7-0c09d04efdd9.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts(DistributedSystemMXBeanWithAlertsDistributedTest.java:379)
> Caused by:
> org.mockito.exceptions.verification.TooFewActualInvocations:
> notificationListener.handleNotification(
> ,
> isNull()
> );
> Wanted 3 times:
> -> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllNotifications(DistributedSystemMXBeanWithAlertsDistributedTest.java:439)
> But was 2 times:
> -> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> -> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllNotifications(DistributedSystemMXBeanWithAlertsDistributedTest.java:439)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllAlerts(DistributedSystemMXBeanWithAlertsDistributedTest.java:451)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.lambda$managerMissesAnyAlertsBeforeItStarts$bb17a952$6(DistributedSystemMXBeanWithAlertsDistributedTest.java:380)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9843) CI failure: DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts failed with TooFewActualInvocations
[
https://issues.apache.org/jira/browse/GEODE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9843:
--
Affects Version/s: 1.16.0
> CI failure:
> DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts
> failed with TooFewActualInvocations
> -
>
> Key: GEODE-9843
> URL: https://issues.apache.org/jira/browse/GEODE-9843
> Project: Geode
> Issue Type: Bug
> Components: core, management
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kamilla Aslami
>Priority: Major
>
> {noformat}
> DistributedSystemMXBeanWithAlertsDistributedTest >
> managerMissesAnyAlertsBeforeItStarts FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest$$Lambda$301/390135366.run
> in VM 0 running on Host
> heavy-lifter-993df0f4-3655-560f-82a7-0c09d04efdd9.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts(DistributedSystemMXBeanWithAlertsDistributedTest.java:379)
> Caused by:
> org.mockito.exceptions.verification.TooFewActualInvocations:
> notificationListener.handleNotification(
> ,
> isNull()
> );
> Wanted 3 times:
> -> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllNotifications(DistributedSystemMXBeanWithAlertsDistributedTest.java:439)
> But was 2 times:
> -> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> -> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllNotifications(DistributedSystemMXBeanWithAlertsDistributedTest.java:439)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllAlerts(DistributedSystemMXBeanWithAlertsDistributedTest.java:451)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.lambda$managerMissesAnyAlertsBeforeItStarts$bb17a952$6(DistributedSystemMXBeanWithAlertsDistributedTest.java:380)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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
]
Jens Deppe updated GEODE-7053:
--
Affects Version/s: 1.16.0
> 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.16.0
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>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.1#820001)
[jira] [Commented] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502489#comment-17502489
]
Geode Integration commented on GEODE-7053:
--
Seen in [distributed-test-openjdk8
#1323|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1323]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646466351/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646466351/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz].
> 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.16.0
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>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.1#820001)
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502491#comment-17502491
]
ASF GitHub Bot commented on GEODE-10096:
pivotal-jbarrett commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r820986411
##
File path: cppcache/src/util/to_underlying.hpp
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef UTIL_UNDERLYING_TYPE_HPP
+#define UTIL_UNDERLYING_TYPE_HPP
+
+#include
+
+/* Note: this implementation can be thrown away once we upgrade to C++14. */
+
+template< class T >
+using underlying_type_t = typename std::underlying_type::type;
+
+/* Note: this implementation can be thrown away once we upgrade to C++23. */
+
+template< class Enum >
+constexpr underlying_type_t to_underlying( Enum e ) noexcept {
Review comment:
Oh, I wasn't aware they added this in 14. Well then... if the C++ gods
like it then we should too. Thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10108) Duplicate Ops During GII/Delta Updates
[ https://issues.apache.org/jira/browse/GEODE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10108: -- Labels: needsTriage (was: ) > Duplicate Ops During GII/Delta Updates > --- > > Key: GEODE-10108 > URL: https://issues.apache.org/jira/browse/GEODE-10108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Priority: Major > Labels: needsTriage > > When Redis commands are ongoing and a server that was previously not hosting > a bucket becomes the host of the primary bucket for a key, there exists a > time window where that server is performing GII but also receiving delta > updates from the previous primary bucket. This can lead to the delta being > applied to a data structure that is already in the “correct” state, resulting > in the command being applied twice. This can result in duplicated appends, > increments/decrements, and in the case of LTRIP and RPOP especially, > IndexOutOfBoundsException on the member applying the delta, as the index to > which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10108) Duplicate Ops During GII/Delta Updates
Wayne created GEODE-10108: - Summary: Duplicate Ops During GII/Delta Updates Key: GEODE-10108 URL: https://issues.apache.org/jira/browse/GEODE-10108 Project: Geode Issue Type: Bug Components: redis Reporter: Wayne When Redis commands are ongoing and a server that was previously not hosting a bucket becomes the host of the primary bucket for a key, there exists a time window where that server is performing GII but also receiving delta updates from the previous primary bucket. This can lead to the delta being applied to a data structure that is already in the “correct” state, resulting in the command being applied twice. This can result in duplicated appends, increments/decrements, and in the case of LTRIP and RPOP especially, IndexOutOfBoundsException on the member applying the delta, as the index to which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10108) Duplicate Ops During GII/Delta Updates
[ https://issues.apache.org/jira/browse/GEODE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-10108: -- Labels: blocks-1.15.0 (was: ) > Duplicate Ops During GII/Delta Updates > --- > > Key: GEODE-10108 > URL: https://issues.apache.org/jira/browse/GEODE-10108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0 > > When Redis commands are ongoing and a server that was previously not hosting > a bucket becomes the host of the primary bucket for a key, there exists a > time window where that server is performing GII but also receiving delta > updates from the previous primary bucket. This can lead to the delta being > applied to a data structure that is already in the “correct” state, resulting > in the command being applied twice. This can result in duplicated appends, > increments/decrements, and in the case of LTRIP and RPOP especially, > IndexOutOfBoundsException on the member applying the delta, as the index to > which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10108) Duplicate Ops During GII/Delta Updates
[ https://issues.apache.org/jira/browse/GEODE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-10108: -- Labels: (was: needsTriage) > Duplicate Ops During GII/Delta Updates > --- > > Key: GEODE-10108 > URL: https://issues.apache.org/jira/browse/GEODE-10108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Priority: Major > > When Redis commands are ongoing and a server that was previously not hosting > a bucket becomes the host of the primary bucket for a key, there exists a > time window where that server is performing GII but also receiving delta > updates from the previous primary bucket. This can lead to the delta being > applied to a data structure that is already in the “correct” state, resulting > in the command being applied twice. This can result in duplicated appends, > increments/decrements, and in the case of LTRIP and RPOP especially, > IndexOutOfBoundsException on the member applying the delta, as the index to > which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502497#comment-17502497 ] Geode Integration commented on GEODE-10092: --- Seen in [distributed-test-openjdk8 #1312|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1312] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646457440/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646457440/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz]. > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9910) Failure to auto-reconnect upon network partition
[ https://issues.apache.org/jira/browse/GEODE-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502500#comment-17502500 ] ASF subversion and git services commented on GEODE-9910: Commit 72665b1ec5c6a6b91d0d6c57e997c23033578c58 in geode's branch refs/heads/develop from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=72665b1 ] GEODE-9910: Stop embedded locator after failed start (#7393) The start-locator property causes a locator to be started when the InternalDistributedSystem is initialized. The initialize method creates the locator and then creates a ClusterDistributionManager. If the creation of the ClusterDistributionManager failed, the started locator was not stopped. This change addresses that by stopping the locator if an exception occurs. > 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 >Assignee: Barrett Oglesby >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, needsTriage, > pull-request-available > Attachments: geode-logs.zip > > > 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.member
[jira] [Updated] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
[
https://issues.apache.org/jira/browse/GEODE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10109:
--
Labels: needsTriage (was: )
> CI Failure: CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> -
>
> Key: GEODE-10109
> URL: https://issues.apache.org/jira/browse/GEODE-10109
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
> {noformat}
> CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> FAILED
> 00:23:40java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 00:23:40Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:23:40
> ---
> 00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
> 00:23:40
> 00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> 00:23:40 at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> 00:23:40 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 00:23:40 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 00:23:40 at java.lang.Thread.run(Thread.java:750)
> 00:23:40Caused by: java.io.IOException: Cannot form connection to alert
> listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
> 00:23:40 ... 18 more
> 00:23:40at org.junit.Assert.fail(Assert.java:89)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> 00:23:40at
> org.apache.geode.test.dunit.rules
[jira] [Created] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
Jens Deppe created GEODE-10109:
--
Summary: CI Failure: CreateRegionCommandDUnitTest >
createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
Key: GEODE-10109
URL: https://issues.apache.org/jira/browse/GEODE-10109
Project: Geode
Issue Type: Bug
Components: gfsh
Affects Versions: 1.16.0
Reporter: Jens Deppe
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
{noformat}
CreateRegionCommandDUnitTest >
createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
FAILED
00:23:40java.lang.AssertionError: Suspicious strings were written to the
log during this run.
00:23:40Fix the strings or use IgnoredException.addIgnoredException to
ignore.
00:23:40
---
00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
00:23:40
00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
java.io.IOException: Cannot form connection to alert listener
heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
00:23:40at
org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
00:23:40at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
00:23:40at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
00:23:40at
org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
00:23:40at
org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
00:23:40at
org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
00:23:40at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
00:23:40at java.util.concurrent.FutureTask.run(FutureTask.java:266)
00:23:40at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
00:23:40at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
00:23:40at java.lang.Thread.run(Thread.java:750)
00:23:40Caused by: java.io.IOException: Cannot form connection to alert
listener
heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
00:23:40at
org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
00:23:40at
org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
00:23:40at
org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
00:23:40... 18 more
00:23:40at org.junit.Assert.fail(Assert.java:89)
00:23:40at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
00:23:40at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
00:23:40at
org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
00:23:40at
org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
00:23:40at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
00:23:40at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
00:23:40at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
00:23:40at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
00:23:40at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
00:23:40at
org.junit.runners.BlockJUnit4ClassRunner.runChi
[jira] [Commented] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
[
https://issues.apache.org/jira/browse/GEODE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502519#comment-17502519
]
Jens Deppe commented on GEODE-10109:
I think the test just needs to add another IgnoredException for the string
"{{{}Cannot form connection to alert listener{}}}".
> CI Failure: CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> -
>
> Key: GEODE-10109
> URL: https://issues.apache.org/jira/browse/GEODE-10109
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
> {noformat}
> CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> FAILED
> 00:23:40java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 00:23:40Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:23:40
> ---
> 00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
> 00:23:40
> 00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> 00:23:40 at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> 00:23:40 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 00:23:40 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 00:23:40 at java.lang.Thread.run(Thread.java:750)
> 00:23:40Caused by: java.io.IOException: Cannot form connection to alert
> listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
> 00:23:40 ... 18 more
> 00:23:40at org.junit.Assert.fail(Assert.java:89)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 00:23:40at
> org.apache
[jira] [Updated] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
[
https://issues.apache.org/jira/browse/GEODE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10109:
---
Labels: (was: needsTriage)
> CI Failure: CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> -
>
> Key: GEODE-10109
> URL: https://issues.apache.org/jira/browse/GEODE-10109
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
> {noformat}
> CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> FAILED
> 00:23:40java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 00:23:40Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:23:40
> ---
> 00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
> 00:23:40
> 00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> 00:23:40 at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> 00:23:40 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 00:23:40 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 00:23:40 at java.lang.Thread.run(Thread.java:750)
> 00:23:40Caused by: java.io.IOException: Cannot form connection to alert
> listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
> 00:23:40 ... 18 more
> 00:23:40at org.junit.Assert.fail(Assert.java:89)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule
[jira] [Commented] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
[
https://issues.apache.org/jira/browse/GEODE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502520#comment-17502520
]
Geode Integration commented on GEODE-10109:
---
Seen in [distributed-test-openjdk8
#1332|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646474139/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646474139/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz].
> CI Failure: CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> -
>
> Key: GEODE-10109
> URL: https://issues.apache.org/jira/browse/GEODE-10109
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
> {noformat}
> CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> FAILED
> 00:23:40java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 00:23:40Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:23:40
> ---
> 00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
> 00:23:40
> 00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> 00:23:40 at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> 00:23:40 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 00:23:40 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 00:23:40 at java.lang.Thread.run(Thread.java:750)
> 00:23:40Caused by: java.io.IOException: Cannot form connection to alert
> listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
> 00:23:40 ... 18 more
> 00:23:40at org.junit.Assert.fail(Assert.java:89)
> 00:23:40at
>
[jira] [Commented] (GEODE-9910) Failure to auto-reconnect upon network partition
[ https://issues.apache.org/jira/browse/GEODE-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502521#comment-17502521 ] Anilkumar Gingade commented on GEODE-9910: -- [~smudundi] The ticket says affected version is 1.14...Are you continue to use 1.14; are you looking for fix immediately. > 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 >Assignee: Barrett Oglesby >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, needsTriage, > pull-request-available > Attachments: geode-logs.zip > > > 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] [Commented] (GEODE-9910) Failure to auto-reconnect upon network partition
[ https://issues.apache.org/jira/browse/GEODE-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502527#comment-17502527 ] Surya Mudundi commented on GEODE-9910: -- [~agingade] - Issue was identified in 1.14.0 version. So, if the fix is made available in 1.14.x or 1.15.x then we will bump geode libraries to pick up the fix as soon as libraries are publicly available. Let us know which version of geode to consume that will include this fix. > 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 >Assignee: Barrett Oglesby >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, needsTriage, > pull-request-available > Attachments: geode-logs.zip > > > 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
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502562#comment-17502562
]
ASF subversion and git services commented on GEODE-9132:
Commit ec48272c1615b27c32e546a58c8736c5f84b427d in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec48272 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 1
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502564#comment-17502564
]
ASF subversion and git services commented on GEODE-9132:
Commit ce2a9eebfaa133978ef54d28d539498174eebc8b in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce2a9ee ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 3
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502563#comment-17502563
]
ASF subversion and git services commented on GEODE-9132:
Commit e3ef06166bea60459ec2ae33beca2e547af4224c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e3ef061 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 2
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502565#comment-17502565
]
ASF subversion and git services commented on GEODE-9132:
Commit 7e2ee0911f742fdaa855745e2e9fd3357db568e6 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e2ee09 ]
GEODE-9132: Always acquire write lock for PR clear
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502567#comment-17502567
]
ASF subversion and git services commented on GEODE-9132:
Commit 7427273bd3f8e6f65cfd1494f0d28baa379f0b48 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7427273 ]
GEODE-9132: Fix locking in PRClearCreateIndexDUnitTest
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502566#comment-17502566
]
ASF subversion and git services commented on GEODE-9132:
Commit a13961422e1d562406870ec190e25849ffa4ca3c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a139614 ]
GEODE-9132: Use factory method to avoid escaped reference
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502570#comment-17502570 ] ASF subversion and git services commented on GEODE-9194: Commit bed0734f729efb5a9ba564fa71191c377ec95714 in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bed0734 ] GEODE-9194: Feature/region stats update (#6430) * GEODE-9194: add PR Region Clear statistics > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9195) Remove redundant local locking from PartitionedRegionClear
[
https://issues.apache.org/jira/browse/GEODE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502568#comment-17502568
]
ASF subversion and git services commented on GEODE-9195:
Commit eb6f7c64c1d0c40368843a737696944e57e82c65 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=eb6f7c6 ]
GEODE-9195: Remove PR clear local locking (#6410)
Unit test changes in BucketRegion and DistributedRegion.
Unit test most of PartitionedRegionClearMessage.
> Remove redundant local locking from PartitionedRegionClear
> --
>
> Key: GEODE-9195
> URL: https://issues.apache.org/jira/browse/GEODE-9195
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear unconditionally acquires a global lock and also acquires local locks
> on all buckets before doing clear.
> Expected behavior:
> Now that PR clear acquires a global lock, it no longer needs to acquire local
> locks on all buckets before doing clear.
> Solution:
> Remove the logic taking lock in individual nodes in:
> {noformat}
> DistributedRegion.obtainWriteLocksForClear()
> {noformat}
> Remove:
> {noformat}
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502569#comment-17502569 ] ASF subversion and git services commented on GEODE-9194: Commit 85ecd69644e15353867368475445882aa2b9657c in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=85ecd69 ] GEODE-9194: Missing file is causing trouble (#6574) > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10098) TcrConnection::readMessage should not be explicitly allocating memory
[
https://issues.apache.org/jira/browse/GEODE-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502582#comment-17502582
]
ASF GitHub Bot commented on GEODE-10098:
mreddington commented on a change in pull request #943:
URL: https://github.com/apache/geode-native/pull/943#discussion_r821142656
##
File path: cppcache/src/TcrMessage.cpp
##
@@ -1373,14 +1360,10 @@ void TcrMessage::handleByteArrayResponse(
case TcrMessage::LOCAL_CREATE:
case TcrMessage::LOCAL_UPDATE: {
- int32_t regionLen = input.readInt32();
+ m_regionName.resize(input.readInt32());
Review comment:
The code never cared before. But I'll add a `min`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> TcrConnection::readMessage should not be explicitly allocating memory
> -
>
> Key: GEODE-10098
> URL: https://issues.apache.org/jira/browse/GEODE-10098
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> This method calls new to read an array of bytes, then returns it to the
> caller, whose responsibility is to delete it (what the heck???). Even
> better, the memory is deleted in a call to TcrMessage::setData, so not even
> in the same class. If this memory was a std::vector, we could
> probably take advantage of move semantics and maybe even improve performance
> a bit, in addition to avoiding potential leaks and weirdness...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10098) TcrConnection::readMessage should not be explicitly allocating memory
[ https://issues.apache.org/jira/browse/GEODE-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502583#comment-17502583 ] ASF GitHub Bot commented on GEODE-10098: mreddington commented on a change in pull request #943: URL: https://github.com/apache/geode-native/pull/943#discussion_r821143583 ## File path: cppcache/src/util/make_unique.hpp ## @@ -0,0 +1,57 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +#ifndef UTIL_MAKE_UNIQUE_H +#define UTIL_MAKE_UNIQUE_H + +#include +#include +#include +#include + +// N3656 standard revision of make_unique. + Review comment: I'm going to update the PR to address the rest and work on this one tomorrow. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > TcrConnection::readMessage should not be explicitly allocating memory > - > > Key: GEODE-10098 > URL: https://issues.apache.org/jira/browse/GEODE-10098 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > This method calls new to read an array of bytes, then returns it to the > caller, whose responsibility is to delete it (what the heck???). Even > better, the memory is deleted in a call to TcrMessage::setData, so not even > in the same class. If this memory was a std::vector, we could > probably take advantage of move semantics and maybe even improve performance > a bit, in addition to avoiding potential leaks and weirdness... -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502586#comment-17502586
]
ASF subversion and git services commented on GEODE-9132:
Commit e3ef06166bea60459ec2ae33beca2e547af4224c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e3ef061 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 2
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502587#comment-17502587
]
ASF subversion and git services commented on GEODE-9132:
Commit ce2a9eebfaa133978ef54d28d539498174eebc8b in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce2a9ee ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 3
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502589#comment-17502589
]
ASF subversion and git services commented on GEODE-9132:
Commit a13961422e1d562406870ec190e25849ffa4ca3c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a139614 ]
GEODE-9132: Use factory method to avoid escaped reference
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502588#comment-17502588
]
ASF subversion and git services commented on GEODE-9132:
Commit 7e2ee0911f742fdaa855745e2e9fd3357db568e6 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e2ee09 ]
GEODE-9132: Always acquire write lock for PR clear
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502590#comment-17502590
]
ASF subversion and git services commented on GEODE-9132:
Commit 7427273bd3f8e6f65cfd1494f0d28baa379f0b48 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7427273 ]
GEODE-9132: Fix locking in PRClearCreateIndexDUnitTest
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502585#comment-17502585
]
ASF subversion and git services commented on GEODE-9132:
Commit ec48272c1615b27c32e546a58c8736c5f84b427d in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec48272 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 1
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502592#comment-17502592 ] ASF subversion and git services commented on GEODE-9194: Commit 85ecd69644e15353867368475445882aa2b9657c in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=85ecd69 ] GEODE-9194: Missing file is causing trouble (#6574) > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502593#comment-17502593 ] ASF subversion and git services commented on GEODE-9194: Commit bed0734f729efb5a9ba564fa71191c377ec95714 in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bed0734 ] GEODE-9194: Feature/region stats update (#6430) * GEODE-9194: add PR Region Clear statistics > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9195) Remove redundant local locking from PartitionedRegionClear
[
https://issues.apache.org/jira/browse/GEODE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502591#comment-17502591
]
ASF subversion and git services commented on GEODE-9195:
Commit eb6f7c64c1d0c40368843a737696944e57e82c65 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=eb6f7c6 ]
GEODE-9195: Remove PR clear local locking (#6410)
Unit test changes in BucketRegion and DistributedRegion.
Unit test most of PartitionedRegionClearMessage.
> Remove redundant local locking from PartitionedRegionClear
> --
>
> Key: GEODE-9195
> URL: https://issues.apache.org/jira/browse/GEODE-9195
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear unconditionally acquires a global lock and also acquires local locks
> on all buckets before doing clear.
> Expected behavior:
> Now that PR clear acquires a global lock, it no longer needs to acquire local
> locks on all buckets before doing clear.
> Solution:
> Remove the logic taking lock in individual nodes in:
> {noformat}
> DistributedRegion.obtainWriteLocksForClear()
> {noformat}
> Remove:
> {noformat}
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502601#comment-17502601
]
ASF subversion and git services commented on GEODE-9132:
Commit e3ef06166bea60459ec2ae33beca2e547af4224c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e3ef061 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 2
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502600#comment-17502600
]
ASF subversion and git services commented on GEODE-9132:
Commit ec48272c1615b27c32e546a58c8736c5f84b427d in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec48272 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 1
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502603#comment-17502603
]
ASF subversion and git services commented on GEODE-9132:
Commit 7e2ee0911f742fdaa855745e2e9fd3357db568e6 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e2ee09 ]
GEODE-9132: Always acquire write lock for PR clear
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502602#comment-17502602
]
ASF subversion and git services commented on GEODE-9132:
Commit ce2a9eebfaa133978ef54d28d539498174eebc8b in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce2a9ee ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 3
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502607#comment-17502607 ] ASF subversion and git services commented on GEODE-9194: Commit 85ecd69644e15353867368475445882aa2b9657c in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=85ecd69 ] GEODE-9194: Missing file is causing trouble (#6574) > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502608#comment-17502608 ] ASF subversion and git services commented on GEODE-9194: Commit bed0734f729efb5a9ba564fa71191c377ec95714 in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bed0734 ] GEODE-9194: Feature/region stats update (#6430) * GEODE-9194: add PR Region Clear statistics > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502604#comment-17502604
]
ASF subversion and git services commented on GEODE-9132:
Commit a13961422e1d562406870ec190e25849ffa4ca3c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a139614 ]
GEODE-9132: Use factory method to avoid escaped reference
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502605#comment-17502605
]
ASF subversion and git services commented on GEODE-9132:
Commit 7427273bd3f8e6f65cfd1494f0d28baa379f0b48 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7427273 ]
GEODE-9132: Fix locking in PRClearCreateIndexDUnitTest
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9195) Remove redundant local locking from PartitionedRegionClear
[
https://issues.apache.org/jira/browse/GEODE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502606#comment-17502606
]
ASF subversion and git services commented on GEODE-9195:
Commit eb6f7c64c1d0c40368843a737696944e57e82c65 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=eb6f7c6 ]
GEODE-9195: Remove PR clear local locking (#6410)
Unit test changes in BucketRegion and DistributedRegion.
Unit test most of PartitionedRegionClearMessage.
> Remove redundant local locking from PartitionedRegionClear
> --
>
> Key: GEODE-9195
> URL: https://issues.apache.org/jira/browse/GEODE-9195
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear unconditionally acquires a global lock and also acquires local locks
> on all buckets before doing clear.
> Expected behavior:
> Now that PR clear acquires a global lock, it no longer needs to acquire local
> locks on all buckets before doing clear.
> Solution:
> Remove the logic taking lock in individual nodes in:
> {noformat}
> DistributedRegion.obtainWriteLocksForClear()
> {noformat}
> Remove:
> {noformat}
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502615#comment-17502615
]
ASF subversion and git services commented on GEODE-9132:
Commit e3ef06166bea60459ec2ae33beca2e547af4224c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e3ef061 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 2
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502614#comment-17502614
]
ASF subversion and git services commented on GEODE-9132:
Commit ec48272c1615b27c32e546a58c8736c5f84b427d in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec48272 ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 1
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502616#comment-17502616
]
ASF subversion and git services commented on GEODE-9132:
Commit ce2a9eebfaa133978ef54d28d539498174eebc8b in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce2a9ee ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 3
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502618#comment-17502618
]
ASF subversion and git services commented on GEODE-9132:
Commit a13961422e1d562406870ec190e25849ffa4ca3c in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a139614 ]
GEODE-9132: Use factory method to avoid escaped reference
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9195) Remove redundant local locking from PartitionedRegionClear
[
https://issues.apache.org/jira/browse/GEODE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502620#comment-17502620
]
ASF subversion and git services commented on GEODE-9195:
Commit eb6f7c64c1d0c40368843a737696944e57e82c65 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=eb6f7c6 ]
GEODE-9195: Remove PR clear local locking (#6410)
Unit test changes in BucketRegion and DistributedRegion.
Unit test most of PartitionedRegionClearMessage.
> Remove redundant local locking from PartitionedRegionClear
> --
>
> Key: GEODE-9195
> URL: https://issues.apache.org/jira/browse/GEODE-9195
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear unconditionally acquires a global lock and also acquires local locks
> on all buckets before doing clear.
> Expected behavior:
> Now that PR clear acquires a global lock, it no longer needs to acquire local
> locks on all buckets before doing clear.
> Solution:
> Remove the logic taking lock in individual nodes in:
> {noformat}
> DistributedRegion.obtainWriteLocksForClear()
> {noformat}
> Remove:
> {noformat}
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502619#comment-17502619
]
ASF subversion and git services commented on GEODE-9132:
Commit 7427273bd3f8e6f65cfd1494f0d28baa379f0b48 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7427273 ]
GEODE-9132: Fix locking in PRClearCreateIndexDUnitTest
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502617#comment-17502617
]
ASF subversion and git services commented on GEODE-9132:
Commit 7e2ee0911f742fdaa855745e2e9fd3357db568e6 in geode's branch
refs/heads/feature/GEODE-7665 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e2ee09 ]
GEODE-9132: Always acquire write lock for PR clear
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502622#comment-17502622 ] ASF subversion and git services commented on GEODE-9194: Commit bed0734f729efb5a9ba564fa71191c377ec95714 in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bed0734 ] GEODE-9194: Feature/region stats update (#6430) * GEODE-9194: add PR Region Clear statistics > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502621#comment-17502621 ] ASF subversion and git services commented on GEODE-9194: Commit 85ecd69644e15353867368475445882aa2b9657c in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=85ecd69 ] GEODE-9194: Missing file is causing trouble (#6574) > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10108) Duplicate Ops During GII/Delta Updates
[ https://issues.apache.org/jira/browse/GEODE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne reassigned GEODE-10108: - Assignee: Jens Deppe > Duplicate Ops During GII/Delta Updates > --- > > Key: GEODE-10108 > URL: https://issues.apache.org/jira/browse/GEODE-10108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: blocks-1.15.0 > > When Redis commands are ongoing and a server that was previously not hosting > a bucket becomes the host of the primary bucket for a key, there exists a > time window where that server is performing GII but also receiving delta > updates from the previous primary bucket. This can lead to the delta being > applied to a data structure that is already in the “correct” state, resulting > in the command being applied twice. This can result in duplicated appends, > increments/decrements, and in the case of LTRIP and RPOP especially, > IndexOutOfBoundsException on the member applying the delta, as the index to > which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502642#comment-17502642
]
ASF subversion and git services commented on GEODE-9132:
Commit d43efe3befd8f1ef6efacfac9ada9a12a798e7e2 in geode's branch
refs/heads/feature/GEODE-7665-save from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d43efe3 ]
GEODE-9132: Fix assertion in ResourceUtils
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502641#comment-17502641
]
ASF subversion and git services commented on GEODE-9132:
Commit 28b998cc60827287d3e4baaf6010c5a47bb47cd1 in geode's branch
refs/heads/feature/GEODE-7665-save from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=28b998c ]
GEODE-9132: PartitionedRegionClearWithConcurrentOperationsDUnitTest cleanup 3
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9195) Remove redundant local locking from PartitionedRegionClear
[
https://issues.apache.org/jira/browse/GEODE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502646#comment-17502646
]
ASF subversion and git services commented on GEODE-9195:
Commit a4e1128ffbb677cd9a842b6e8edceb1927894cc4 in geode's branch
refs/heads/feature/GEODE-7665-save from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a4e1128 ]
GEODE-9195: Remove PR clear local locking (#6410)
Unit test changes in BucketRegion and DistributedRegion.
Unit test most of PartitionedRegionClearMessage.
> Remove redundant local locking from PartitionedRegionClear
> --
>
> Key: GEODE-9195
> URL: https://issues.apache.org/jira/browse/GEODE-9195
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear unconditionally acquires a global lock and also acquires local locks
> on all buckets before doing clear.
> Expected behavior:
> Now that PR clear acquires a global lock, it no longer needs to acquire local
> locks on all buckets before doing clear.
> Solution:
> Remove the logic taking lock in individual nodes in:
> {noformat}
> DistributedRegion.obtainWriteLocksForClear()
> {noformat}
> Remove:
> {noformat}
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502644#comment-17502644
]
ASF subversion and git services commented on GEODE-9132:
Commit e3e262db7162adf0a6834572f938f72993c3 in geode's branch
refs/heads/feature/GEODE-7665-save from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e3e262d ]
GEODE-9132: Use factory method to avoid escaped reference
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502645#comment-17502645
]
ASF subversion and git services commented on GEODE-9132:
Commit 58049af0812a03c83d78768d52c520a741f9ba1f in geode's branch
refs/heads/feature/GEODE-7665-save from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=58049af ]
GEODE-9132: Fix locking in PRClearCreateIndexDUnitTest
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9132) PR clear to take locks on all buckets unconditionally.
[
https://issues.apache.org/jira/browse/GEODE-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502643#comment-17502643
]
ASF subversion and git services commented on GEODE-9132:
Commit cd192d74fb7adf447390cca5946ef244853a3588 in geode's branch
refs/heads/feature/GEODE-7665-save from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cd192d7 ]
GEODE-9132: Always acquire write lock for PR clear
> PR clear to take locks on all buckets unconditionally.
> --
>
> Key: GEODE-9132
> URL: https://issues.apache.org/jira/browse/GEODE-9132
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Blake Bender
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear employs two different locking behavior based on the presence of
> client subscription and cache-listeners. If there is no subscription or
> cache-listener it takes the bucket locks on local nodes else it will send a
> message to take locks on all buckets before doing the clear.
> Expected behavior:
> To keep the code/behavior simple PR clear to employ single locking behavior.
> It will take the lock on all buckets before doing clear irrespective of
> subscription or cache-listener presence.
> Solution:
> Remove the following check that drives taking lock on local nodes:
> {code}
> boolean acquireClearLockForNotification =
> (partitionedRegion.hasAnyClientsInterested() ||
> partitionedRegion.hasListener());
> {code}
> And it will call:
> {code}
> obtainLockForClear(regionEvent);
> {code}
> Also remove the logic taking lock in individual nodes in:
> DistributedRegion.obtainWriteLocksForClear()
> Remove:
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502647#comment-17502647 ] ASF subversion and git services commented on GEODE-9194: Commit 83e2e3bc6867197feff2f3c7cf340be22f0ee1a3 in geode's branch refs/heads/feature/GEODE-7665-save from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=83e2e3b ] GEODE-9194: Missing file is causing trouble (#6574) > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9194) Move PR clear related statistics to the appropriate classes
[ https://issues.apache.org/jira/browse/GEODE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502648#comment-17502648 ] ASF subversion and git services commented on GEODE-9194: Commit 6754d1a40822e966d9d420443daed84205d051ce in geode's branch refs/heads/feature/GEODE-7665-save from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6754d1a ] GEODE-9194: Feature/region stats update (#6430) * GEODE-9194: add PR Region Clear statistics > Move PR clear related statistics to the appropriate classes > --- > > Key: GEODE-9194 > URL: https://issues.apache.org/jira/browse/GEODE-9194 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Currently there are PR clear statistics that are not a part of the > Partitioned Region Stats. This feature work is to track the movement of those > stats. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
Eric Shu created GEODE-10110: Summary: When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException Key: GEODE-10110 URL: https://issues.apache.org/jira/browse/GEODE-10110 Project: Geode Issue Type: Bug Components: querying Affects Versions: 1.14.0, 1.13.0, 1.12.0, 1.15.0 Reporter: Eric Shu org.apache.geode.InternalGemFireException: unexpected exception on member rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) Caused by: Creation of index: statusIndex failed due to: org.apache.geode.cache.CacheClosedException: The cache is closed. at org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) at org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10110: -- Labels: needsTriage (was: ) > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10110: - Labels: GeodeOperationAPI (was: needsTriage) > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > Here is the exception thrown to the user: > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10110: - Description: Here is the exception thrown to the user: org.apache.geode.InternalGemFireException: unexpected exception on member rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) Caused by: Creation of index: statusIndex failed due to: org.apache.geode.cache.CacheClosedException: The cache is closed. at org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) at org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at java.lang.Thread.run(Thread.java:748) was: org.apache.geode.InternalGemFireException: unexpected exception on member rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) Caused by: Creation of index: statusIndex failed due to: org.apache.geode.cache.CacheClosedException: The cache is closed. at org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at org.apache.geode.distributed.inter
[jira] [Assigned] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10110: Assignee: Eric Shu > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > Here is the exception thrown to the user: > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10110: --- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Here is the exception thrown to the user: > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-288) Remove deprecated Admin API
[ https://issues.apache.org/jira/browse/GEODE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-288: - Labels: deprecated pull-request-available (was: deprecated) > Remove deprecated Admin API > --- > > Key: GEODE-288 > URL: https://issues.apache.org/jira/browse/GEODE-288 > Project: Geode > Issue Type: Sub-task > Components: jmx >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund >Priority: Major > Labels: deprecated, pull-request-available > > The Admin API (com.gemstone.gemfire.admin) and old JMX Agent have been > deprecated since GemFire 7.0. The Admin API was retired in favor of using the > new Management JMX API (com.gemstone.gemfire.management) and GFSH. > #1) move some Admin classes used internally by non-Admin code: > move com.gemstone.gemfire.admin.BackupStatus > move com.gemstone.gemfire.admin.OperationCancelledException > move com.gemstone.gemfire.admin.RegionNotFoundException > move > com.gemstone.gemfire.admin.internal.AdminDistributedSystemImpl.backupAllMembers > move > com.gemstone.gemfire.admin.internal.AdminDistributedSystemImpl.compactAllDiskStores > move com.gemstone.gemfire.admin.internal.FinishBackupRequest > move com.gemstone.gemfire.admin.internal.FlushToDiskRequest > move com.gemstone.gemfire.admin.internal.InetAddressUtil > move com.gemstone.gemfire.admin.internal.PrepareBackupRequest > #2) move com.gemstone.gemfire.admin to > com.gemstone.gemfire.internal.admin.api (temporarily) > #3) remove com.gemstone.gemfire.cache.* usage of admin > #4) remove com.gemstone.gemfire.distributed.* usage of admin > #5) remove com.gemstone.gemfire.internal.* usage of admin (except for > internal.admin.*) > #6) remove com.gemstone.gemfire.management.* usage of admin > #7) remove com.gemstone.gemfire.internal.admin.api if possible > #8) remove unused classes from com.gemstone.gemfire.internal.admin.* > Breakdown by package and class: > com.gemstone.gemfire > --change DataSerializer to use moved RegionNotFoundException > com.gemstone.gemfire.cache > com.gemstone.gemfire.cache.persistence > com.gemstone.gemfire.cache.util > --remove com.gemstone.gemfire.cache.util.UniversalMembershipListenerAdapter > com.gemstone.gemfire.distributed > --remove Admin API from javadocs in Locator and DistributedSystem > com.gemstone.gemfire.distributed.internal > --remove > com.gemstone.gemfire.distributed.internal.DistributionManager.createHealthMonitor > --remove remove com.gemstone.gemfire.distributed.internal.HealthMonitor > --remove remove com.gemstone.gemfire.distributed.internal.HealthMonitorImpl > --change > com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.hasAlertListenerFor > to not use AlertLevel > com.gemstone.gemfire.internal > --remove DSFIDFactory support for admin messages > --remove com.gemstone.gemfire.admin.jmx.internal.AgentLauncher from > GemFireUtilLauncher > --change MigrationServer to use moved InetAddressUtil > --change SocketCreator to use moved InetAddressUtil > --remove SystemAdmin.backup > --remove SystemAdmin.compactAllDiskStores > --remove SystemAdmin.shutDownAll > --remove SystemAdmin.listMissingDiskStores > --remove SystemAdmin.revokeMissingDiskStores > com.gemstone.gemfire.internal.cache > --replace use of com.gemstone.gemfire.admin.OperationCancelledException > --remove use of > com.gemstone.gemfire.admin.internal.SystemMemberCacheEventProcessor > com.gemstone.gemfire.internal.cache.partitioned > --replace use of com.gemstone.gemfire.admin.OperationCancelledException > com.gemstone.gemfire.internal.cache.snapshot > --replace use of com.gemstone.gemfire.admin.RegionNotFoundException > com.gemstone.gemfire.internal.tools.gfsh.app.command.task > --reimplement PartitionedRegionAttributeTask > com.gemstone.gemfire.internal.tools.gfsh.util > --reimplement RegionUtil > com.gemstone.gemfire.management.internal.beans > --change DistributedSystemBridge to use moved classes > com.gemstone.gemfire.management.internal.cli.commands > --change DiskStoreCommands to use moved classes > -- This message was sent by Atlassian Jira (v8.20.1#820001)
