[jira] [Commented] (GEODE-10048) Create Common Infrastructure for Blocking Commands and Keyspace Event Notifications
[ https://issues.apache.org/jira/browse/GEODE-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510983#comment-17510983 ] ASF subversion and git services commented on GEODE-10048: - Commit 6b43b76e3d5a9c5b0c84df8e1995d61528871068 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6b43b76 ] GEODE-10048: Add framework for Redis events and BLPOP command (#7408) * GEODE-10048: Add framework for Redis events and BLPOP command This commit adds a simple eventing framework to be used by blocking commands as well as keyspace event notification (still to be implemented). The main components are: - EventListener: an interface to be immplemented by anything wishing to receive events. Currently only implemented for blocking commands in the form of BlockingCommandListener. - EventDistributor: the component to which listeners are registered and where events are received and distributed. A single EventDistributor exists in the system and is associated with each ExecutionHandlerContext. - Event: not implemented as a separate class but logically consists of the command (RedisCommandType) and key (RedisKey). When a blocking command receives a relevant event the command is resubmitted into the Netty pipeline. This also means that something could happen (another command) that causes the blocking command to re-block and not complete. This is also what happens with native Redis. For example: - BLPOP 0 A executes and blocks - LPUSH A some-value - Before LPUSH fires an event, LPOP A is received but needs to wait to acquire the lock on A - LPUSH fires an event which the BLPOP listener receives and resubmits BLPOP into the pipeline - Once LPUSH completes, LPOP is next and removes A - BLPOP A runs and ends up blocking again because there is nothing to pop from A > Create Common Infrastructure for Blocking Commands and Keyspace Event > Notifications > --- > > Key: GEODE-10048 > URL: https://issues.apache.org/jira/browse/GEODE-10048 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Create the common infrastructure that will be used for implementing both > Redis blocking commands and Keyspace Event Notifications. > > +Acceptance Criteria+ > > The common infrastructure has been implemented along with appropriate unit > testing. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510975#comment-17510975
]
Geode Integration commented on GEODE-9889:
--
Seen on support/1.14 in [integration-test-openjdk11
#35|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/integration-test-openjdk11/builds/35]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0937/test-results/integrationTest/1647994055/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0937/test-artifacts/1647994055/integrationtestfiles-openjdk11-1.14.5-build.0937.tgz].
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Hale Bales
>Priority: Major
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-7988) AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is failing in mass test run
[
https://issues.apache.org/jira/browse/GEODE-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510974#comment-17510974
]
Geode Integration commented on GEODE-7988:
--
Seen on support/1.14 in [distributed-test-openjdk8
#36|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/distributed-test-openjdk8/builds/36]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0937/test-results/distributedTest/1648000241/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0937/test-artifacts/1648000241/distributedtestfiles-openjdk8-1.14.5-build.0937.tgz].
> AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is
> failing in mass test run
> ---
>
> Key: GEODE-7988
> URL: https://issues.apache.org/jira/browse/GEODE-7988
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {noformat}
> testClientDynamicallyDropsStoppedLocator
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1993
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1940
> {noformat}
>
> This is also reproducible using dunitrunner.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-10121:
-
Assignee: (was: Anilkumar Gingade)
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-10121:
-
Assignee: Anilkumar Gingade
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: blocks-1.15.0
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Reopened] (GEODE-9704) When durable clients recovers, it sends "ready for event" signal before register for interest, this might cause problem for caching_proxy regions
[ https://issues.apache.org/jira/browse/GEODE-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson reopened GEODE-9704: > When durable clients recovers, it sends "ready for event" signal before > register for interest, this might cause problem for caching_proxy regions > - > > Key: GEODE-9704 > URL: https://issues.apache.org/jira/browse/GEODE-9704 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.1, pull-request-available > > This is the old Geode behavior, but may or may not be the correct behavior. > When durable clients recovers, there is a queueTimer thread that runs > `QueueManagerImp.recoverPrimary` method, it > * makes new connection to server > - sends readyForEvents (which will cause the server to start sending the > queued events) > - recovers interest > - clears the region of keys of interest > - re-registers interest > It sends readyForEvents before it clears region of keys of interest, if > server sends some events of those keys in between, it will clear them, thus > it seems to the user that the client region doesn't have those keys. > > Run geode-core distributedTest > AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(), > change the InterestResultPolicy to NONE, you would see the test would fail > occasionally, Adding sleep code in QueueManagerImp.recoverPrimary between > `createNewPrimary` and `recoverInterest` would make the test fail more > consistently. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9704) When durable clients recovers, it sends "ready for event" signal before register for interest, this might cause problem for caching_proxy regions
[ https://issues.apache.org/jira/browse/GEODE-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade resolved GEODE-9704. -- Resolution: Won't Fix > When durable clients recovers, it sends "ready for event" signal before > register for interest, this might cause problem for caching_proxy regions > - > > Key: GEODE-9704 > URL: https://issues.apache.org/jira/browse/GEODE-9704 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.1, pull-request-available > > This is the old Geode behavior, but may or may not be the correct behavior. > When durable clients recovers, there is a queueTimer thread that runs > `QueueManagerImp.recoverPrimary` method, it > * makes new connection to server > - sends readyForEvents (which will cause the server to start sending the > queued events) > - recovers interest > - clears the region of keys of interest > - re-registers interest > It sends readyForEvents before it clears region of keys of interest, if > server sends some events of those keys in between, it will clear them, thus > it seems to the user that the client region doesn't have those keys. > > Run geode-core distributedTest > AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(), > change the InterestResultPolicy to NONE, you would see the test would fail > occasionally, Adding sleep code in QueueManagerImp.recoverPrimary between > `createNewPrimary` and `recoverInterest` would make the test fail more > consistently. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9704) When durable clients recovers, it sends "ready for event" signal before register for interest, this might cause problem for caching_proxy regions
[ https://issues.apache.org/jira/browse/GEODE-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-9704: --- Labels: GeodeOperationAPI blocks-1.15.1 pull-request-available (was: GeodeOperationAPI blocks-1.15.0 pull-request-available) > When durable clients recovers, it sends "ready for event" signal before > register for interest, this might cause problem for caching_proxy regions > - > > Key: GEODE-9704 > URL: https://issues.apache.org/jira/browse/GEODE-9704 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.1, pull-request-available > > This is the old Geode behavior, but may or may not be the correct behavior. > When durable clients recovers, there is a queueTimer thread that runs > `QueueManagerImp.recoverPrimary` method, it > * makes new connection to server > - sends readyForEvents (which will cause the server to start sending the > queued events) > - recovers interest > - clears the region of keys of interest > - re-registers interest > It sends readyForEvents before it clears region of keys of interest, if > server sends some events of those keys in between, it will clear them, thus > it seems to the user that the client region doesn't have those keys. > > Run geode-core distributedTest > AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(), > change the InterestResultPolicy to NONE, you would see the test would fail > occasionally, Adding sleep code in QueueManagerImp.recoverPrimary between > `createNewPrimary` and `recoverInterest` would make the test fail more > consistently. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9704) When durable clients recovers, it sends "ready for event" signal before register for interest, this might cause problem for caching_proxy regions
[ https://issues.apache.org/jira/browse/GEODE-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-9704: --- Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was: GeodeOperationAPI blocks-1.15.1 pull-request-available) > When durable clients recovers, it sends "ready for event" signal before > register for interest, this might cause problem for caching_proxy regions > - > > Key: GEODE-9704 > URL: https://issues.apache.org/jira/browse/GEODE-9704 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > > This is the old Geode behavior, but may or may not be the correct behavior. > When durable clients recovers, there is a queueTimer thread that runs > `QueueManagerImp.recoverPrimary` method, it > * makes new connection to server > - sends readyForEvents (which will cause the server to start sending the > queued events) > - recovers interest > - clears the region of keys of interest > - re-registers interest > It sends readyForEvents before it clears region of keys of interest, if > server sends some events of those keys in between, it will clear them, thus > it seems to the user that the client region doesn't have those keys. > > Run geode-core distributedTest > AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(), > change the InterestResultPolicy to NONE, you would see the test would fail > occasionally, Adding sleep code in QueueManagerImp.recoverPrimary between > `createNewPrimary` and `recoverInterest` would make the test fail more > consistently. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[
https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510954#comment-17510954
]
Barrett Oglesby commented on GEODE-10144:
-
Here is why this test passes with the previous server code.
In the previous server code, after the Client Message Dispatcher caught an
AuthenticationExpiredException, it slept for 200 ms before trying again. It
does this for up to 5 seconds before giving up. Each time it retries, it asks
for authorization again.
Here is a case where SimulatedExpirationSecurityManager.authorize throws an
AuthenticationExpiredException:
{noformat}
[warn 2022/03/22 14:59:04.110 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_CREATE; key=key130
[warn 2022/03/22 14:59:04.110 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to throw
AuthenticationExpiredException
[warn 2022/03/22 14:59:04.110 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher caught AuthenticationExpiredException
[warn 2022/03/22 14:59:04.110 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher skipped sending ClientReAuthenticateMessage
clientVersion=GFE 9.0
{noformat}
The Client Message Dispatcher sleeps for 200 ms:
{noformat}
[warn 2022/03/22 14:59:04.110 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to sleep 1 for 200 ms
[warn 2022/03/22 14:59:04.311 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher done sleep 1
{noformat}
When it wakes up, it checks for authorization again. This time, the
SimulatedExpirationSecurityManager returns true, so the message is sent:
{noformat}
[warn 2022/03/22 14:59:04.311 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_CREATE; key=key130
[warn 2022/03/22 14:59:04.311 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 14:59:04.311 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher done dispatchMessage operation=AFTER_CREATE;
key=key130
{noformat}
This path is not relying on outside operations to notify the Client Message
Dispatcher. The SimulatedExpirationSecurityManager authorizes the operation
after the sleep.
So at the end of the run where there are no client operations, the Client
Message Dispatcher is most likely only going to sleep 200 ms. There is never
going to be a 5 second wait.
I did see a few times where the Client Message Dispatcher slept twice through
the loop (so 400 ms):
{noformat}
[warn 2022/03/22 14:59:23.924 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_UPDATE; key=key4820
[warn 2022/03/22 14:59:23.924 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to throw
AuthenticationExpiredException
[warn 2022/03/22 14:59:23.924 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher caught AuthenticationExpiredException
[warn 2022/03/22 14:59:23.924 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher skipped sending ClientReAuthenticateMessage
clientVersion=GFE 9.0
[warn 2022/03/22 14:59:23.924 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to sleep 1 for 200 ms
[warn 2022/03/22 14:59:24.124 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher done sleep 1
[warn 2022/03/22 14:59:24.124 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_UPDATE; key=key4820
[warn 2022/03/22 14:59:24.124 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to throw
AuthenticationExpiredException
[warn 2022/03/22 14:59:24.124 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher caught AuthenticationExpiredException
[warn 2022/03/22 14:59:24.124 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to sleep 2 for
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[
https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510953#comment-17510953
]
Barrett Oglesby commented on GEODE-10144:
-
Even though this JIRA is resolved, I did some analysis on it.
I see whats going on in this test.
At the beginning of the test client cache operations are occurring
simultaneously with message dispatching from the server to the client.
Here is a ServerConnection processing puts:
{noformat}
[warn 2022/03/22 15:40:01.096 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX Put70.cmdExecute operation=UPDATE;
key=key50
[warn 2022/03/22 15:40:01.096 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.099 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX Put70.cmdExecute operation=UPDATE;
key=key51
[warn 2022/03/22 15:40:01.099 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.101 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX Put70.cmdExecute operation=UPDATE;
key=key52
[warn 2022/03/22 15:40:01.102 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.104 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX Put70.cmdExecute operation=UPDATE;
key=key53
[warn 2022/03/22 15:40:01.104 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.106 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX Put70.cmdExecute operation=UPDATE;
key=key54
[warn 2022/03/22 15:40:01.107 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x50] XXX
SimulatedExpirationSecurityManager.authorize about to return true
{noformat}
At the same time, the Client Message Dispatcher is dispatching events to the
client:
{noformat}
[warn 2022/03/22 15:40:01.098 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_CREATE; key=key50
[warn 2022/03/22 15:40:01.098 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.099 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher done dispatchMessage operation=AFTER_CREATE;
key=key50
[warn 2022/03/22 15:40:01.101 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_CREATE; key=key51
[warn 2022/03/22 15:40:01.101 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.101 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher done dispatchMessage operation=AFTER_CREATE;
key=key51
[warn 2022/03/22 15:40:01.103 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_CREATE; key=key52
[warn 2022/03/22 15:40:01.104 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.104 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher done dispatchMessage operation=AFTER_CREATE;
key=key52
[warn 2022/03/22 15:40:01.106 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher about to dispatchMessage
operation=AFTER_CREATE; key=key53
[warn 2022/03/22 15:40:01.106 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
SimulatedExpirationSecurityManager.authorize about to return true
[warn 2022/03/22 15:40:01.106 PDT
CqPlusAuthInitializeTest_reAuthenticateWithDurable_server_0 tid=0x51] XXX
MessageDispatcher.runDispatcher done dispatchMessage operation=AFTER_CREATE;
key=key53
{noformat}
While the Client Message Dispatcher, it requests authorization which fails.
Since the NC is not the latest version, no ClientReAuthenticateMessage is sent
to it. The dispatcher waits anyway in case another operation updates the
credentials:
{noformat}
[warn 2022/03/22 15:40:01.109 PDT
[jira] [Created] (GEODE-10152) Make gfsh "wrapper" scripts compatible with Java 17
Dale Emery created GEODE-10152:
--
Summary: Make gfsh "wrapper" scripts compatible with Java 17
Key: GEODE-10152
URL: https://issues.apache.org/jira/browse/GEODE-10152
Project: Geode
Issue Type: Improvement
Components: gfsh
Affects Versions: 1.15.0
Reporter: Dale Emery
On JDK 17, the Gfsh "wrapper" scripts (geode-assembly/src/main/dist/bin/gfsh
and geode-assembly/src/main/dist/bin/gfsh.bat) must open/export all required
packages when they run the Geode CLI launcher
(org.apache.geode.management.internal.cli.Launcher) via Java.
Also, Gfsh must open and export all required packages whenever it starts Java
process that will execute Geode code.
Here is a possible approach: * Create argument files for each set of
opens/exports that are selected together. Each argument file will define the
{{--add-opens}} and {{--add-exports}} commands for the relevant packages.
* Change the Gfsh executables (geode-assembly/src/main/dist/bin/gfsh and
geode-assembly/src/main/dist/bin/gfsh) to:
** Inspect the requested JDK to learn the version and OS it reports.
** Select the argument files for the JDK based on its version and OS
** Add the argument files to the java command line when starting the CLI
launcher.
* Change Gfsh Java classes to forward the opens/exports when launching java
subprocesses (e.g. when starting a locator or server).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10152) Make gfsh "wrapper" scripts compatible with Java 17
[
https://issues.apache.org/jira/browse/GEODE-10152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10152:
---
Labels: Java17 (was: )
> Make gfsh "wrapper" scripts compatible with Java 17
> ---
>
> Key: GEODE-10152
> URL: https://issues.apache.org/jira/browse/GEODE-10152
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, the Gfsh "wrapper" scripts (geode-assembly/src/main/dist/bin/gfsh
> and geode-assembly/src/main/dist/bin/gfsh.bat) must open/export all required
> packages when they run the Geode CLI launcher
> (org.apache.geode.management.internal.cli.Launcher) via Java.
>
> Also, Gfsh must open and export all required packages whenever it starts Java
> process that will execute Geode code.
>
> Here is a possible approach: * Create argument files for each set of
> opens/exports that are selected together. Each argument file will define the
> {{--add-opens}} and {{--add-exports}} commands for the relevant packages.
> * Change the Gfsh executables (geode-assembly/src/main/dist/bin/gfsh and
> geode-assembly/src/main/dist/bin/gfsh) to:
> ** Inspect the requested JDK to learn the version and OS it reports.
> ** Select the argument files for the JDK based on its version and OS
> ** Add the argument files to the java command line when starting the CLI
> launcher.
> * Change Gfsh Java classes to forward the opens/exports when launching java
> subprocesses (e.g. when starting a locator or server).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510939#comment-17510939 ] Jinmei Liao commented on GEODE-10144: - commit reverted > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10144. - Fix Version/s: 1.15.0 Resolution: Fixed > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9980) Startup of Locator or Server should fail fast if geode.enableGlobalSerialFilter is enabled but fails configuration
[
https://issues.apache.org/jira/browse/GEODE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510937#comment-17510937
]
ASF subversion and git services commented on GEODE-9980:
Commit 5d9e4b5b54b84c2de28b670fe6feb0b0c3f7 in geode's branch
refs/heads/support/1.14 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5d9e4b5 ]
GEODE-9980: Improve error handling of serial filters (#7355)
Improves the error handling of serial filter configuration and
filtering. The API throws a runtime exception wrapping any thrown
exceptions.
When geode.enableGlobalSerialFilter is FALSE:
* Startup succeeds without throwing any exceptions even if an older
version of Java throws "java.lang.ClassNotFoundException
sun.misc.ObjectInputFilter".
When geode.enableGlobalSerialFilter is TRUE:
* Startup fails by throwing an exception when configuration of serial
filter fails for any reason.
Renames ObjectInputFilter to avoid confusion with the Java interface of
the same name.
Fixes a bug found in ReflectiveFacadeGlobalSerialFilterTest which
resulted in configuring a non-mocked process-wide serial filter that
polluted the JVM for all later tests.
Fixes other minor details in LocatorLauncher, InternalDataSerializer
and various related tests.
(cherry picked from commit ce57e9fd2b8b644cadc469209e12e4fbd281e0d9)
(cherry picked from commit 6ecdce0d9ef9040f3bbb90c8ea4ff5eb99d712fc)
> Startup of Locator or Server should fail fast if
> geode.enableGlobalSerialFilter is enabled but fails configuration
> --
>
> Key: GEODE-9980
> URL: https://issues.apache.org/jira/browse/GEODE-9980
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>
> The following error conditions need better handling which includes handling
> of all errors consistently and cause the startup of a Locator or Server to
> fail if it's unable to honor the setting of
> {{-Dgeode.enableGlobalSerialFilter=true}} for any reason. Currently, if
> {{-Dgeode.enableGlobalSerialFilter=true}} is specified but Geode is unable to
> create a global serial filter, then it will will log a warning and continue
> running. A user may easily miss that log statement and believe that the JVM
> is running with a properly configured serialization filter.
> 1) The user is trying to secure the JVM very thoroughly and accidentally
> specifies both {{-Djdk.serialFilter}} and
> {{-Dgeode.enableGlobalSerialFilter}}.
> 2) The user runs some non-Geode code in the same JVM that invokes
> {{ObjectInputFilter.Config.setFilter(...)}} directly.
> 3) The user is using a version of Java 8 prior to 8u121 (the release that
> first added {{sun.misc.ObjectInputFilter}}) and specifies
> {{-Dgeode.enableGlobalSerialFilter=true}}. Also, the same behavior occurs if
> they do NOT specify enabling that property.
> 4) {{LocatorLauncher}} or {{ServerLauncher}} is started in a JVM that has
> already created at least one {{ObjectInputStream}} which will cause
> {{ObjectInputFilter.Config.setFilter(...)}} to fail.
> 5) {{LocatorLauncher}} or {{ServerLauncher}} is started in a Java 8 JVM that
> is not based on OpenJDK (ie {{sun.misc.ObjectInputFilter}} does not exist).
> 6) {{LocatorLauncher}} or {{ServerLauncher}} is started in an unforeseen
> environment that causes invocation of
> {{ObjectInputFilter.Config.setFilter(...)}} via Java Reflection to throw
> {{IllegalAccessException}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9758) Provide an easy to configure a process-wide serialization filter for use on Java 8
[ https://issues.apache.org/jira/browse/GEODE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510936#comment-17510936 ] ASF subversion and git services commented on GEODE-9758: Commit f0809e411d561226f736adca9d40cbbe27033e53 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0809e4 ] GEODE-9758: Add internal serial filter API (#7217) GEODE-9758: Add internal serial filter API #7217 Expand ObjectInputStreamFilterWrapper to be an internal API which supports all of Geode's uses of Java's ObjectInputFilter. Introduce a new system property, geode.enableGlobalSerialFilter, to enable a process-wide filter with all serializable Geode classes on the classpath and the value of serializable-object-filter accept-listed. To enable the process-wide filter with GFSH start commands, add: * --J=-Dgeode.enableGlobalSerialFilter=true Functional Capabilities The internal API lives in geode-serialization and works on OpenJDK based JREs providing a facade for Java's ObjectInputFilter in Java 8 and Java 9 or greater using reflection. The API provides the following capabilities: * creating an ObjectInputFilter * setting an ObjectInputFilter on an ObjectInputStream * getting an ObjectInputFilter from a ObjectInputStream * setting a process-wide ObjectInputFilter * getting a process-wide ObjectInputFilter Design Notes The API defines the following primary interface types: * factory interfaces for creating instances of types within the API * filter interfaces to split out single ops from Java's ObjectInputFilter * configuration interfaces for handling system properties, logging, and config validation The concrete classes in the API receive parameters injected via a constructor for any collaborators that are not specified by the interfaces. This is intentional even when the instance is only used once before de-referencing it. All collaborators that are defined in the interface are passed in as parameters to the implementing method; all others are passed in via the constructor and stored as fields. (cherry picked from commit 7978abf34707d11da45cff0b7cb7445f18d21438) > Provide an easy to configure a process-wide serialization filter for use on > Java 8 > -- > > Key: GEODE-9758 > URL: https://issues.apache.org/jira/browse/GEODE-9758 > Project: Geode > Issue Type: Improvement > Components: configuration, serialization >Affects Versions: 1.12.7, 1.13.0, 1.14.0 >Reporter: Jianxia Chen >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, pull-request-available > > Provide an easy way to configure a process-wide serialization filter for use > on Java 8. When enabled, validate-serializable-objects should be enabled and > the process-wide serialization filter should be configured to accept only JDK > classes and Geode classes in addition to anything the user might specify with > serializable-object-filter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9879) Extract part of SystemPropertyHelper to geode-common for wider use
[ https://issues.apache.org/jira/browse/GEODE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510935#comment-17510935 ] ASF subversion and git services commented on GEODE-9879: Commit 2652bd65cd4192068de6c601f7ba92d120816593 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2652bd6 ] GEODE-9879: Extract SystemProperty to geode-common (#7177) Extract part of SystemPropertyHelper to geode-common for use in modules that are upstream from geode-core. Define new DEFAULT_PREFIX that maps to GEODE_PREFIX and use that everywhere that GEODE_PREFIX was previously used. * Inline prefix constants in SystemPropertyHelper * Use static imports for system property prefixes. * Split up large tests in SystemPropertyHelperTest. * Fix JAXBService (cherry picked from commit ebf8479fffb5775b1f45801aa9382c2dad7106e0) > Extract part of SystemPropertyHelper to geode-common for wider use > -- > > Key: GEODE-9879 > URL: https://issues.apache.org/jira/browse/GEODE-9879 > Project: Geode > Issue Type: Wish > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > I need to use the dual property prefix part of SystemPropertyHelper to > geode-common so that it can be used from non-core geode modules such as > geode-serialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9758) Provide an easy to configure a process-wide serialization filter for use on Java 8
[ https://issues.apache.org/jira/browse/GEODE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510933#comment-17510933 ] ASF subversion and git services commented on GEODE-9758: Commit 3f66ab05e5683edb4bcb43e52304d8e5f58ac707 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f66ab0 ] GEODE-9758: Move SanctionedSerializables to filter package (#7165) Move SanctionedSerializables to new package org.apache.geode.internal.serialization.filter. (cherry picked from commit db64b4948e790d61e82f95ae6163a62adc4c67fb) > Provide an easy to configure a process-wide serialization filter for use on > Java 8 > -- > > Key: GEODE-9758 > URL: https://issues.apache.org/jira/browse/GEODE-9758 > Project: Geode > Issue Type: Improvement > Components: configuration, serialization >Affects Versions: 1.12.7, 1.13.0, 1.14.0 >Reporter: Jianxia Chen >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, pull-request-available > > Provide an easy way to configure a process-wide serialization filter for use > on Java 8. When enabled, validate-serializable-objects should be enabled and > the process-wide serialization filter should be configured to accept only JDK > classes and Geode classes in addition to anything the user might specify with > serializable-object-filter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-10151: -- Component/s: redis > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Priority: Major > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
Dan Smith created GEODE-10151: - Summary: Make geode-for-redis an optional dependency of a geode server Key: GEODE-10151 URL: https://issues.apache.org/jira/browse/GEODE-10151 Project: Geode Issue Type: Improvement Reporter: Dan Smith The geode-for-redis module and its related dependencies are on the classpath of the server by default when starting a server with gfsh start server or using the geode dependencies jar. We should make the module an optional dependencies, like some of our other extensions (for example, the tomcat http session modules). This would allow a user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10119:
--
Assignee: Dale Emery
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage, pull-request-available
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> 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:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
> Suppressed: java.net.SocketException: Broken pipe
> at
> java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
> at
>
[jira] [Updated] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10119:
---
Labels: Java17 needsTriage pull-request-available (was: Java17 needsTriage)
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage, pull-request-available
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> 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:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
> Suppressed: java.net.SocketException: Broken pipe
> at
> java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
> at
>
[jira] [Commented] (GEODE-10079) CI scripts no longer supply docker images for pre-1.15 PR precheck tasks
[ https://issues.apache.org/jira/browse/GEODE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510919#comment-17510919 ] Robert Houghton commented on GEODE-10079: - I committed `05e7ba28948e4b73739e45fd4db2a2f40335120f` to enable a 1.14 specific PR pipeline. > CI scripts no longer supply docker images for pre-1.15 PR precheck tasks > > > Key: GEODE-10079 > URL: https://issues.apache.org/jira/browse/GEODE-10079 > Project: Geode > Issue Type: Test > Components: ci >Affects Versions: 1.12.9, 1.13.8, 1.14.4 >Reporter: Dale Emery >Priority: Major > > The CI scripts no longer supply docker images when they run PR precheck tasks > that use the `-PdunitDockerImage` property. > For PRs with base branches prior to `support/1.15`, the `distributedTest` and > `upgradeTest` precheck tasks must run each test class in a separate docker > container. When `dunitDockerImage` is not defined, these tasks instead run > tests concurrently outside of docker. This results in swarms of failures, as > the concurrently executing tests all attempt to bind to the same ports. > Examples: > - https://concourse.apachegeode-ci.info/builds/27926695 > - https://concourse.apachegeode-ci.info/builds/27632643 > - https://concourse.apachegeode-ci.info/builds/28861132 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510906#comment-17510906
]
Dale Emery commented on GEODE-10119:
On JDK 17, this exception can occur multiple times, causing
\{{SocketCreator.configureClientSSLSocket}} to write multiple "fatal" log
entries.
Further up the call stack,
\{{ConnectionFactoryImpl.createClientToServerConnection()}} also logs each
occurrence as a warning. Perhaps it should log this as debug instead.
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> 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:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
>
[jira] [Updated] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10150: --- Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0) > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510904#comment-17510904 ] Dave Barnes commented on GEODE-10150: - [~dkhopade] Please review the pull request https://github.com/apache/geode/pull/7474 > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10149) don't reset radish benchmark baseline on a patch release
[ https://issues.apache.org/jira/browse/GEODE-10149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510902#comment-17510902 ] Geode Integration commented on GEODE-10149: --- Seen in [benchmark-radish #229|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/229]. > don't reset radish benchmark baseline on a patch release > > > Key: GEODE-10149 > URL: https://issues.apache.org/jira/browse/GEODE-10149 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > radish benchmarks use a custom branch/tag > on a new minor, the release scripts should reset that to the new minor release > however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10149) don't reset radish benchmark baseline on a patch release
[ https://issues.apache.org/jira/browse/GEODE-10149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510898#comment-17510898 ] ASF subversion and git services commented on GEODE-10149: - Commit d5e3663a89c9346734711e846dc651d391a958d2 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d5e3663 ] GEODE-10149: Don't reset custom radish baseline on a patch release (#7472) * GEODE-10149: don't reset radish baseline prematurely radish benchmarks use a custom branch/tag on a new minor, the release scripts should reset that to the new minor release however, the scripts were incorrectly resetting it on every patch, oops if custom baseline on develop is newer [than release branch cut date], resetting might still be the wrong choice. but, assuming it's older, a new minor is the right time to un-custom it. hopefully PR review catches situation where the recommended change is not wanted...the alternative of not doing it by default seems much more likely to result in forgetting about it altogether > don't reset radish benchmark baseline on a patch release > > > Key: GEODE-10149 > URL: https://issues.apache.org/jira/browse/GEODE-10149 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > radish benchmarks use a custom branch/tag > on a new minor, the release scripts should reset that to the new minor release > however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10149) don't reset radish benchmark baseline on a patch release
[ https://issues.apache.org/jira/browse/GEODE-10149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10149. -- Fix Version/s: 1.15.0 Resolution: Fixed > don't reset radish benchmark baseline on a patch release > > > Key: GEODE-10149 > URL: https://issues.apache.org/jira/browse/GEODE-10149 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > radish benchmarks use a custom branch/tag > on a new minor, the release scripts should reset that to the new minor release > however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510896#comment-17510896 ] ASF subversion and git services commented on GEODE-10097: - Commit 08617a24de55cb2e2ba9ec438530e4b731a1b0a4 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=08617a2 ] Revert "GEODE-10097: Avoid Thread.sleep for reauthentication in MessageDispatcher (#7416)" (#7470) This reverts commit 2554f42b925f2b9b8ca7eee14c7a887436b1d9db. > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10149) don't reset radish benchmark baseline on a patch release
[ https://issues.apache.org/jira/browse/GEODE-10149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10149: --- Labels: pull-request-available (was: ) > don't reset radish benchmark baseline on a patch release > > > Key: GEODE-10149 > URL: https://issues.apache.org/jira/browse/GEODE-10149 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > radish benchmarks use a custom branch/tag > on a new minor, the release scripts should reset that to the new minor release > however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-10150: Labels: blocks-1.15.0 (was: ) > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0 > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-10150: --- Assignee: Dave Barnes > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
Dave Barnes created GEODE-10150: --- Summary: alter runtime command and change loglevel command docs bug & improvements Key: GEODE-10150 URL: https://issues.apache.org/jira/browse/GEODE-10150 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.14.4 Reporter: Deepak Khopade The parameters information for gfsh>alter runtime --log-level shows an incorrect parameter name in a table where all parameter's description is provided. The actual expects --log-level but the row in a table says --loglevel. See the screenshot attached. (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) Another important point is, we should add a line on both the links below to state the difference when using these commands (alter runtime and change loglevel). https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html When I tried both of these commands, it has been found that for locator we need to use gfsh>change loglevel --loglevel=config --member=locator and gfsh>alter runtime --log-level for cache server members. The alter runtime --log-level command doesn't work for Locators. So adding a line or changing an existing line on the docs will help new customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10149) don't reset radish benchmark baseline on a patch release
[ https://issues.apache.org/jira/browse/GEODE-10149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510881#comment-17510881 ] Geode Integration commented on GEODE-10149: --- Seen in [benchmark-radish #228|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/228]. > don't reset radish benchmark baseline on a patch release > > > Key: GEODE-10149 > URL: https://issues.apache.org/jira/browse/GEODE-10149 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > radish benchmarks use a custom branch/tag > on a new minor, the release scripts should reset that to the new minor release > however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10149) don't reset radish benchmark baseline on a patch release
[ https://issues.apache.org/jira/browse/GEODE-10149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510882#comment-17510882 ] Geode Integration commented on GEODE-10149: --- Seen in [benchmark-radish #227|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/227]. > don't reset radish benchmark baseline on a patch release > > > Key: GEODE-10149 > URL: https://issues.apache.org/jira/browse/GEODE-10149 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > radish benchmarks use a custom branch/tag > on a new minor, the release scripts should reset that to the new minor release > however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10149) don't reset radish benchmark baseline on a patch release
Owen Nichols created GEODE-10149: Summary: don't reset radish benchmark baseline on a patch release Key: GEODE-10149 URL: https://issues.apache.org/jira/browse/GEODE-10149 Project: Geode Issue Type: Task Components: release Reporter: Owen Nichols radish benchmarks use a custom branch/tag on a new minor, the release scripts should reset that to the new minor release however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10149) don't reset radish benchmark baseline on a patch release
[ https://issues.apache.org/jira/browse/GEODE-10149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-10149: Assignee: Owen Nichols > don't reset radish benchmark baseline on a patch release > > > Key: GEODE-10149 > URL: https://issues.apache.org/jira/browse/GEODE-10149 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > radish benchmarks use a custom branch/tag > on a new minor, the release scripts should reset that to the new minor release > however, the scripts are incorrectly resetting it on every patch, oops -- This message was sent by Atlassian Jira (v8.20.1#820001)
[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
]
ASF GitHub Bot updated GEODE-10106:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> CI Failure: CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer
> ---
>
> Key: GEODE-10106
> URL: https://issues.apache.org/jira/browse/GEODE-10106
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> [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)
>
[jira] [Commented] (GEODE-10131) Remove unused but set variable
[ https://issues.apache.org/jira/browse/GEODE-10131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510771#comment-17510771 ] ASF GitHub Bot commented on GEODE-10131: moleske commented on pull request #947: URL: https://github.com/apache/geode-native/pull/947#issuecomment-1075402829 being reverted [here](https://github.com/apache/geode/pull/7470), can rerun the pipelines after the change is merged in geode and a build is spat out of the geode pipeline for geode native pipeline to pickup -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove unused but set variable > -- > > Key: GEODE-10131 > URL: https://issues.apache.org/jira/browse/GEODE-10131 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > When on AppleClang 13.1.6.13160021 on macOS 12.3, native client fails to > compile due to warning as error -Wunused-but-set-variable > Remove the offending lines to compile -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10101) release 1.14.4
[ https://issues.apache.org/jira/browse/GEODE-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510739#comment-17510739 ] ASF subversion and git services commented on GEODE-10101: - Commit b3e261842be2f6d55be3d45e8b6d8a112877f70c in geode's branch refs/heads/develop from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b3e2618 ] GEODE-10101: Replace 1.14.3 with 1.14.4 as old version (#7460) Replace 1.14.3 with 1.14.4 in old versions and set as Benchmarks baseline on develop to enable rolling upgrade tests from 1.14.4 The serialization version has not changed between 1.14.3 and 1.14.4, so there should be no need to keep both > release 1.14.4 > -- > > Key: GEODE-10101 > URL: https://issues.apache.org/jira/browse/GEODE-10101 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > Fix For: 1.14.5, 1.15.0 > > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10145) CI alpine tools image is compatibility issue
[ https://issues.apache.org/jira/browse/GEODE-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510732#comment-17510732 ] ASF subversion and git services commented on GEODE-10145: - Commit 5e09c5ab15ca82ee078889385ae2a81af341d5f9 in geode's branch refs/heads/support/1.13 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5e09c5a ] GEODE-10145: Organize Dockerfile to work around alpine compat issues (#7466) Also add concourse resources to track our base-image versions to better track which dependencies may have caused the build issue. Still only triggering on the core base image, and our Dockerfile. Authored-by: Robert Houghton (cherry picked from commit 07a1aacc9275e028b0ab8dd57193f423f8f722c3) > CI alpine tools image is compatibility issue > > > Key: GEODE-10145 > URL: https://issues.apache.org/jira/browse/GEODE-10145 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Compatibility problem between alpine, cloud-sdk (google) and winrm-cli. > Re-organize the layers in the Dockerfile to straighten this out. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10145) CI alpine tools image is compatibility issue
[ https://issues.apache.org/jira/browse/GEODE-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510730#comment-17510730 ] ASF subversion and git services commented on GEODE-10145: - Commit d271f7825e42173f2cd77a9b165ddecd06a9547f in geode's branch refs/heads/support/1.14 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d271f78 ] GEODE-10145: Organize Dockerfile to work around alpine compat issues (#7466) Also add concourse resources to track our base-image versions to better track which dependencies may have caused the build issue. Still only triggering on the core base image, and our Dockerfile. Authored-by: Robert Houghton (cherry picked from commit 07a1aacc9275e028b0ab8dd57193f423f8f722c3) > CI alpine tools image is compatibility issue > > > Key: GEODE-10145 > URL: https://issues.apache.org/jira/browse/GEODE-10145 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Compatibility problem between alpine, cloud-sdk (google) and winrm-cli. > Re-organize the layers in the Dockerfile to straighten this out. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510485#comment-17510485 ] Blake Bender commented on GEODE-10144: -- Notes from investigation 2022-03-21: * Description of test: Test creates a durable cache, provides an instrumented AuthInitialize implementation to the client and a SecurityManager to the server. Test registers a listener that counts events, then does: 5000 puts, 5000 updates, 5000 destroys, then checks that the listener got 5000 LOCAL_CREATE, 5000 LOCAL_UPDATE, and 5000 LOCAL_DESTROY messages. Next, test shuts down the cache and creates a 2nd durable cache with the same durable-client-id, registers CQ again, and expects all events to still be in the queue and to receive them all again. After conversation with Barry, the 2nd part of the test may or may not be valid, but is at the very least a strange thing to do. * Prior to the commit in question, we discovered that the first half of the test would always pass, but the 2nd half was a little flaky when running a debug build of geode-native. Due to performance of unoptimized code and debug-level logging, the test would sometimes overrun the default subscription ack interval (100 seconds), thus losing some events from the queue and failing the event count. * After the bad commit, we've observed that no LOCAL_DESTROY events are received in the first part of the test. We are looking into why this is the case. > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510479#comment-17510479 ] Blake Bender commented on GEODE-10144: -- [~jinmeiliao] Be sure to check in with [~boglesby] before diving into this one, he and I have been working on it since yesterday. > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510367#comment-17510367
]
ASF subversion and git services commented on GEODE-10123:
-
Commit f4d173ba537e4ed70d62368d5266c209833fc219 in geode's branch
refs/heads/develop from Jakov Varenina
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f4d173b ]
GEODE-10123: Improve "create region" checks (#7443)
Sometimes the "create region" command executes successfully during
servers restart even though region is already available in the cluster
configuration. When this happens, cluster configuration contains a
duplicated region, so servers throw
"org.apache.geode.cache.RegionExistsException" at startup.
CreateRegionCommand class checks whether there is already an existing
region using the DistributedRegionMXBean service. This service is
unreliable during restarts, as it takes some time for the locator to
accumulate region information.
In addition to checks done against the DistributedRegionMXBean
information, this solution introduces the same checks against cluster
configuration (if used) stored in locators.
> Multiple execution of Create region command results with duplicated region in
> cluster configuration
> ---
>
> Key: GEODE-10123
> URL: https://issues.apache.org/jira/browse/GEODE-10123
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> We have observed that sometimes the "create region" command executes
> successfully during period when servers restart even though region is already
> available in the cluster configuration. When this happens, cluster
> configuration contains a duplicated region and servers throw the exception
> *org.apache.geode.cache.RegionExistsException* when restarted again:
> {code:java}
> Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
> parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
> while parsing XML.
> org.apache.geode.cache.RegionExistsException: /regionTest
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> Caused by: org.xml.sax.SAXException: A CacheException was thrown while
> parsing XML.
> {code}
> CreateRegionCommand checks whether there is already an existing region using
> the DistributedRegionMXBean service. This service is unreliable during
> restarts, as it takes some time for the locator to accumulate this
> information. So during the startup of the servers locator will send
> CreateRegionFunction to servers since it couldn't detect that region already
> exists using the DistributedRegionMXBean service. In most scenarios, the
> server will reject that function. The only case the server will execute the
> function is when using the local cache.xml configuration in addition to the
> cluster configuration. It seems that processing local cache.xml creates a
> time gap on the server that will accept CreateRegionFunction, although the
> region is already available in the cluster configuration.
> Solution:
> In addition to checks done against the DistributedRegionMXBean information,
> do the same checks against cluster configuration (if used) stored in
> locators. This way, the "create region" command is
[jira] [Resolved] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina resolved GEODE-10123.
Fix Version/s: 1.15.0
Resolution: Fixed
> Multiple execution of Create region command results with duplicated region in
> cluster configuration
> ---
>
> Key: GEODE-10123
> URL: https://issues.apache.org/jira/browse/GEODE-10123
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> We have observed that sometimes the "create region" command executes
> successfully during period when servers restart even though region is already
> available in the cluster configuration. When this happens, cluster
> configuration contains a duplicated region and servers throw the exception
> *org.apache.geode.cache.RegionExistsException* when restarted again:
> {code:java}
> Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
> parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
> while parsing XML.
> org.apache.geode.cache.RegionExistsException: /regionTest
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> Caused by: org.xml.sax.SAXException: A CacheException was thrown while
> parsing XML.
> {code}
> CreateRegionCommand checks whether there is already an existing region using
> the DistributedRegionMXBean service. This service is unreliable during
> restarts, as it takes some time for the locator to accumulate this
> information. So during the startup of the servers locator will send
> CreateRegionFunction to servers since it couldn't detect that region already
> exists using the DistributedRegionMXBean service. In most scenarios, the
> server will reject that function. The only case the server will execute the
> function is when using the local cache.xml configuration in addition to the
> cluster configuration. It seems that processing local cache.xml creates a
> time gap on the server that will accept CreateRegionFunction, although the
> region is already available in the cluster configuration.
> Solution:
> In addition to checks done against the DistributedRegionMXBean information,
> do the same checks against cluster configuration (if used) stored in
> locators. This way, the "create region" command is rejected immediately by
> the locator instead of later by the servers.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
