[jira] [Resolved] (GEODE-10322) Run various Analyze Serialiable tests from IntelliJ
[ https://issues.apache.org/jira/browse/GEODE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10322. Fix Version/s: 1.16.0 Resolution: Fixed > Run various Analyze Serialiable tests from IntelliJ > --- > > Key: GEODE-10322 > URL: https://issues.apache.org/jira/browse/GEODE-10322 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > When using Intellij to build and run tests (instead of gradle) I cannot run > any of the AnalyzeSerializable tests since the relevant classes are written > to a different output directory. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10322) Run various Analyze Serialiable tests from IntelliJ
[ https://issues.apache.org/jira/browse/GEODE-10322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10322: -- Assignee: Jens Deppe > Run various Analyze Serialiable tests from IntelliJ > --- > > Key: GEODE-10322 > URL: https://issues.apache.org/jira/browse/GEODE-10322 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > When using Intellij to build and run tests (instead of gradle) I cannot run > any of the AnalyzeSerializable tests since the relevant classes are written > to a different output directory. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10322) Run various Analyze Serialiable tests from IntelliJ
Jens Deppe created GEODE-10322: -- Summary: Run various Analyze Serialiable tests from IntelliJ Key: GEODE-10322 URL: https://issues.apache.org/jira/browse/GEODE-10322 Project: Geode Issue Type: Test Components: tests Reporter: Jens Deppe When using Intellij to build and run tests (instead of gradle) I cannot run any of the AnalyzeSerializable tests since the relevant classes are written to a different output directory. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9937) Add convenience methods to FileWatchingX509Extended*Manager
[ https://issues.apache.org/jira/browse/GEODE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9937. --- Fix Version/s: 1.15.0 Resolution: Fixed > Add convenience methods to FileWatchingX509Extended*Manager > --- > > Key: GEODE-9937 > URL: https://issues.apache.org/jira/browse/GEODE-9937 > Project: Geode > Issue Type: Improvement > Components: security >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10284) Add partition-listener option to gfsh create region command
[
https://issues.apache.org/jira/browse/GEODE-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10284.
Fix Version/s: 1.15.0
1.16.0
Resolution: Fixed
> Add partition-listener option to gfsh create region command
> ---
>
> Key: GEODE-10284
> URL: https://issues.apache.org/jira/browse/GEODE-10284
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> This adds a {{--partition-listener}} option to the {{create region}} gfsh
> command. I'm not sure why this was not added in the first place since all the
> plumbing to support it already seems to exist.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10284) Add partition-listener option to gfsh create region command
Jens Deppe created GEODE-10284:
--
Summary: Add partition-listener option to gfsh create region
command
Key: GEODE-10284
URL: https://issues.apache.org/jira/browse/GEODE-10284
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Jens Deppe
This adds a {{--partition-listener}} option to the {{create region}} gfsh
command. I'm not sure why this was not added in the first place since all the
plumbing to support it already seems to exist.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10284) Add partition-listener option to gfsh create region command
[
https://issues.apache.org/jira/browse/GEODE-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-10284:
--
Assignee: Jens Deppe
> Add partition-listener option to gfsh create region command
> ---
>
> Key: GEODE-10284
> URL: https://issues.apache.org/jira/browse/GEODE-10284
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This adds a {{--partition-listener}} option to the {{create region}} gfsh
> command. I'm not sure why this was not added in the first place since all the
> plumbing to support it already seems to exist.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10256) HttpSessionListener is not working
[
https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528391#comment-17528391
]
Jens Deppe commented on GEODE-10256:
Hello [~masaki.yamakawa]! Thank you for this ticket and the analysis.
So the relevant code is here in
[SessionExpirationCacheListener|https://github.com/apache/geode/blob/a5bd36f9fa787d3a71c6e6efafed5a7b0fe52d2b/extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/callback/SessionExpirationCacheListener.java].
The essence of what you're seeing is coming from the {{afterDestroy}} method
and the if-else block there. So the first part of the {{if}} handles a destroy
triggered by expiry on the client. The second part should handle an expiry from
the server. However the caveat is that you need to set the system parameter,
indicated in the comment there,
({{{}gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK{}}}), on the server. That should
then allow any listeners to fire even when receiving a destroy from the server.
The comment does indicate that this is only relevant for {{PROXY}} (empty)
regions but I think that may be incorrect. Please would you try this change and
let us know the outcome.
> HttpSessionListener is not working
> --
>
> Key: GEODE-10256
> URL: https://issues.apache.org/jira/browse/GEODE-10256
> Project: Geode
> Issue Type: Bug
> Components: expiration, http session
>Affects Versions: 1.15.0
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> I am using "HTTP Session Management Module for Tomcat".
> When data managed in a session expires, I want to use HttpSessionListener to
> handle the deletion of the associated data.
> However, the sessionDestroyed method is not called when the session expires.
> When session expiration is enabled,
> org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers
> and Clients.
> And when expiration occurs, ExpirationAction.DESTROY is executed.
> DESTROY is executed on all CacheServers and clients at about the same time,
> and the result of the deletion on the CacheServer is propagated to clients.
> At that time, the operation type of the message sent from the CacheServer to
> clients is DESTROY.
> SessionExpirationCacheListener is set in the client, but
> HttpSessionListener#sessionDestroyed will only be executed if
> Operation.EXPIRE_DESTROY.
> HttpSessionListener#sessionDestroyed is executed if the expiration process is
> run first on the client side, but HttpSessionListener#sessionDestroyed is
> executed if the CacheServer's DESTROY event is received first.
> sessionDestroyed is not executed.
> We should send the EXPIRE_DESTROY event from CacheServer, but I think this
> has a big impact.
> Therefore, I have introduced a Java system property that delays expiration
> processing on the CacheServer.
> By setting this, HttpSessionListener#sessionDestroyed will surely be executed
> by delaying the server-side expiration processing rather than the client's
> expiration processing.
> Also, if this system property is not set, the behavior will be the same as
> the current.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10245) Upgrade classgraph from 4.8.143 -> 4.8.145
[ https://issues.apache.org/jira/browse/GEODE-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10245. Fix Version/s: 1.15.0 Resolution: Fixed > Upgrade classgraph from 4.8.143 -> 4.8.145 > -- > > Key: GEODE-10245 > URL: https://issues.apache.org/jira/browse/GEODE-10245 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This fixes an issue as described here: > https://github.com/classgraph/classgraph/issues/673 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10161) Clean up synchronization in RedisList
[
https://issues.apache.org/jira/browse/GEODE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10161.
Fix Version/s: 1.15.0
Resolution: Fixed
> Clean up synchronization in RedisList
> -
>
> Key: GEODE-10161
> URL: https://issues.apache.org/jira/browse/GEODE-10161
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Prior to adding versioning, we needed {{synchronized}} on various helper
> methods that modified the internal list data structure. This was in order to
> ensure exclusive access in the event of a {{toData()}} call (during
> GII/bucket movement). {{toData()}} is also synchronized. However, now that
> we're synchronizing within more of the 'top-level' methods in RedisList,
> (because we're also changing the {{version}} value), I think that we should
> be able to remove all of the {{synchronized}} modifiers on the smaller helper
> methods.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10244) Clean up synchronization in AbstractRedisData.fromDelta
[ https://issues.apache.org/jira/browse/GEODE-10244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-10244: --- Summary: Clean up synchronization in AbstractRedisData.fromDelta (was: Clean up synchronization in AbstractRedisData.fromData) > Clean up synchronization in AbstractRedisData.fromDelta > --- > > Key: GEODE-10244 > URL: https://issues.apache.org/jira/browse/GEODE-10244 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Priority: Major > > Our use of synchronization when applying various delta types is inconsistent > and should be cleaned up - we should not need any synchronization when > applying deltas. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10245) Upgrade classgraph from 4.8.143 -> 4.8.145
Jens Deppe created GEODE-10245: -- Summary: Upgrade classgraph from 4.8.143 -> 4.8.145 Key: GEODE-10245 URL: https://issues.apache.org/jira/browse/GEODE-10245 Project: Geode Issue Type: Improvement Components: core Reporter: Jens Deppe This fixes an issue as described here: https://github.com/classgraph/classgraph/issues/673 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10245) Upgrade classgraph from 4.8.143 -> 4.8.145
[ https://issues.apache.org/jira/browse/GEODE-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10245: -- Assignee: Jens Deppe > Upgrade classgraph from 4.8.143 -> 4.8.145 > -- > > Key: GEODE-10245 > URL: https://issues.apache.org/jira/browse/GEODE-10245 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > This fixes an issue as described here: > https://github.com/classgraph/classgraph/issues/673 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10244) Clean up synchronization in AbstractRedisData.fromData
Jens Deppe created GEODE-10244: -- Summary: Clean up synchronization in AbstractRedisData.fromData Key: GEODE-10244 URL: https://issues.apache.org/jira/browse/GEODE-10244 Project: Geode Issue Type: Improvement Components: redis Reporter: Jens Deppe Our use of synchronization when applying various delta types is inconsistent and should be cleaned up - we should not need any synchronization when applying deltas. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10221) RedisList does not set memory usage correctly when creating a copy
[
https://issues.apache.org/jira/browse/GEODE-10221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10221.
Fix Version/s: 1.15.0
Resolution: Fixed
> RedisList does not set memory usage correctly when creating a copy
> --
>
> Key: GEODE-10221
> URL: https://issues.apache.org/jira/browse/GEODE-10221
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Since adding a constructor to {{RedisList}} that takes another list in order
> to create a copy, we don't update the memory overhead of the new list
> correctly.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10221) RedisList does not set memory usage correctly when creating a copy
Jens Deppe created GEODE-10221:
--
Summary: RedisList does not set memory usage correctly when
creating a copy
Key: GEODE-10221
URL: https://issues.apache.org/jira/browse/GEODE-10221
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Jens Deppe
Since adding a constructor to {{RedisList}} that takes another list in order to
create a copy, we don't update the memory overhead of the new list correctly.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10221) RedisList does not set memory usage correctly when creating a copy
[
https://issues.apache.org/jira/browse/GEODE-10221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-10221:
--
Assignee: Jens Deppe
> RedisList does not set memory usage correctly when creating a copy
> --
>
> Key: GEODE-10221
> URL: https://issues.apache.org/jira/browse/GEODE-10221
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> Since adding a constructor to {{RedisList}} that takes another list in order
> to create a copy, we don't update the memory overhead of the new list
> correctly.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10214) Improve performance of JvmSizeUtils.roundUpSize
[ https://issues.apache.org/jira/browse/GEODE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10214. Fix Version/s: 1.15.0 Resolution: Fixed > Improve performance of JvmSizeUtils.roundUpSize > --- > > Key: GEODE-10214 > URL: https://issues.apache.org/jira/browse/GEODE-10214 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This small method can still be optimized. It is used extensively (albeit > indirectly) in much of the geode-for-redis modules' data structure size > calculations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
[
https://issues.apache.org/jira/browse/GEODE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10160.
Fix Version/s: 1.15.0
Resolution: Fixed
> SizeableByteArrayList does not update the sizeInBytes for some non-overriden
> methods
>
>
> Key: GEODE-10160
> URL: https://issues.apache.org/jira/browse/GEODE-10160
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Steve Sienkowski
>Priority: Major
> Labels: pull-request-available, redis-triage
> Fix For: 1.15.0
>
>
> Some List methods aren't overriden in SizeableByteArrayList which means that
> the memoryOverhead doesn't get updated. add(int index, byte[] element),
> clear(), and set(int index, byte[] newElement) all need to update the size
> and don't.
> This can be accomplished by adding overrides to SizeableByteArrayList:
> {code:java}
> @Override
> public byte[] set(int index, byte[] newElement) {
> byte[] replacedElement = super.set(index, newElement);
> memberOverhead -= calculateByteArrayOverhead(replacedElement);
> memberOverhead += calculateByteArrayOverhead(newElement);
> return replacedElement;
> }
> @Override
> public void add(int index, byte[] element) {
> memberOverhead += calculateByteArrayOverhead(element);
> super.add(index, element);
> }
> {code}
> The test for set could look something like:
> {code:java}
> @Test
> public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
> SizeableByteArrayList list = new SizeableByteArrayList();
> byte[] element = "element".getBytes(StandardCharsets.UTF_8);
> list.addFirst(element);
> long initialSize = list.getSizeInBytes();
> assertThat(initialSize).isEqualTo(sizer.sizeof(list));
> list.set(0, "some really big new element
> name".getBytes(StandardCharsets.UTF_8));
> assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
> list.set(0, element);
> assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
> }
> {code}
> We need more tests than just this one. add(int, byte[]) needs to be tested as
> well. Any method on SizeableByteArrayList that modify the data should have a
> test that the memoryOverhead gets updated correctly.
> Clear itself isn't a problem - just set the memberOverhead to 0 - but the
> issue is that for the version of LTRIM in
> [PR#7403|https://github.com/apache/geode/pull/7403], we clear a sublist of
> SizeableByteArrayList. This means that the overridden clear method does not
> get called and the LinkedList implementation of clear does not call any other
> methods that we can override. There needs to be some new approach to LTRIM
> that doesn't use sublists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10126. Fix Version/s: 1.15.0 Resolution: Fixed > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10126: -- Assignee: Jens Deppe > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10214) Improve performance of JvmSizeUtils.roundUpSize
Jens Deppe created GEODE-10214: -- Summary: Improve performance of JvmSizeUtils.roundUpSize Key: GEODE-10214 URL: https://issues.apache.org/jira/browse/GEODE-10214 Project: Geode Issue Type: Improvement Components: core Reporter: Jens Deppe This small method can still be optimized. It is used extensively (albeit indirectly) in much of the geode-for-redis modules' data structure size calculations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10214) Improve performance of JvmSizeUtils.roundUpSize
[ https://issues.apache.org/jira/browse/GEODE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10214: -- Assignee: Jens Deppe > Improve performance of JvmSizeUtils.roundUpSize > --- > > Key: GEODE-10214 > URL: https://issues.apache.org/jira/browse/GEODE-10214 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > This small method can still be optimized. It is used extensively (albeit > indirectly) in much of the geode-for-redis modules' data structure size > calculations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10125) Refactor Redis to Use Public DataSerializable Framework
[ https://issues.apache.org/jira/browse/GEODE-10125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10125. Fix Version/s: 1.15.0 Resolution: Fixed > Refactor Redis to Use Public DataSerializable Framework > - > > Key: GEODE-10125 > URL: https://issues.apache.org/jira/browse/GEODE-10125 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Refactor Redis to use the public DataSerializable framework instead of the > DataSerializableFixedId serialization framework. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10125) Refactor Redis to Use Public DataSerializable Framework
[ https://issues.apache.org/jira/browse/GEODE-10125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10125: -- Assignee: Jens Deppe > Refactor Redis to Use Public DataSerializable Framework > - > > Key: GEODE-10125 > URL: https://issues.apache.org/jira/browse/GEODE-10125 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Refactor Redis to use the public DataSerializable framework instead of the > DataSerializableFixedId serialization framework. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-10191:
--
Assignee: Jens Deppe
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10191.
Fix Version/s: 1.15.0
Resolution: Fixed
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9889:
-
Assignee: Jens Deppe (was: Hale Bales)
> 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: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> 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] [Resolved] (GEODE-10190) Improve runtime of some Redis integration tests
[ https://issues.apache.org/jira/browse/GEODE-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10190. Fix Version/s: 1.15.0 Resolution: Fixed > Improve runtime of some Redis integration tests > --- > > Key: GEODE-10190 > URL: https://issues.apache.org/jira/browse/GEODE-10190 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > From Darrel: > _I’m doing some refactoring of the ResourceManager and my pr’s integration > tests are timing out after running for 45 minutes. Normally integration tests > take 18 minutes. When looking at whats tests took a long time I see that > AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time > it was run. On my laptop I see it run in 2.75 minutes. Another test method I > see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These > two methods are run twice so that adds up to 30 minutes in just two test > methods so I think that is the cause of the timeout. Both of these do > concurrency. Any ideas about this? Do you think my refactoring broke > something or did I just get a bad run of these tests?_ > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10190) Improve runtime of some Redis integration tests
[ https://issues.apache.org/jira/browse/GEODE-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10190: -- Assignee: Jens Deppe > Improve runtime of some Redis integration tests > --- > > Key: GEODE-10190 > URL: https://issues.apache.org/jira/browse/GEODE-10190 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > From Darrel: > _I’m doing some refactoring of the ResourceManager and my pr’s integration > tests are timing out after running for 45 minutes. Normally integration tests > take 18 minutes. When looking at whats tests took a long time I see that > AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time > it was run. On my laptop I see it run in 2.75 minutes. Another test method I > see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These > two methods are run twice so that adds up to 30 minutes in just two test > methods so I think that is the cause of the timeout. Both of these do > concurrency. Any ideas about this? Do you think my refactoring broke > something or did I just get a bad run of these tests?_ > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10190) Improve runtime of some Redis integration tests
Jens Deppe created GEODE-10190: -- Summary: Improve runtime of some Redis integration tests Key: GEODE-10190 URL: https://issues.apache.org/jira/browse/GEODE-10190 Project: Geode Issue Type: Improvement Components: redis Reporter: Jens Deppe >From Darrel: _I’m doing some refactoring of the ResourceManager and my pr’s integration tests are timing out after running for 45 minutes. Normally integration tests take 18 minutes. When looking at whats tests took a long time I see that AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time it was run. On my laptop I see it run in 2.75 minutes. Another test method I see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These two methods are run twice so that adds up to 30 minutes in just two test methods so I think that is the cause of the timeout. Both of these do concurrency. Any ideas about this? Do you think my refactoring broke something or did I just get a bad run of these tests?_ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9946) Implement LREM Command
[ https://issues.apache.org/jira/browse/GEODE-9946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9946. --- Fix Version/s: 1.15.0 Resolution: Fixed > Implement LREM Command > -- > > Key: GEODE-9946 > URL: https://issues.apache.org/jira/browse/GEODE-9946 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [LREM|https://redis.io/commands/lrem] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10050) Implement BLPOP
[ https://issues.apache.org/jira/browse/GEODE-10050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10050. Fix Version/s: 1.15.0 Assignee: Jens Deppe Resolution: Fixed > Implement BLPOP > --- > > Key: GEODE-10050 > URL: https://issues.apache.org/jira/browse/GEODE-10050 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Fix For: 1.15.0 > > > Implement the [BLPOP|https://redis.io/commands/blpop] Command. > > +Acceptance Criteria+ > The BLPOP command has been. implemented, per specifications, along with all > associated unit, acceptance, and system testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (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:all-tabpanel ] Jens Deppe reassigned GEODE-10048: -- Assignee: Jens Deppe > 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 >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > 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] [Resolved] (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:all-tabpanel ] Jens Deppe resolved GEODE-10048. Fix Version/s: 1.15.0 Resolution: Fixed > 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 > Fix For: 1.15.0 > > > 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] [Created] (GEODE-10161) Clean up synchronization in RedisList
Jens Deppe created GEODE-10161:
--
Summary: Clean up synchronization in RedisList
Key: GEODE-10161
URL: https://issues.apache.org/jira/browse/GEODE-10161
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Jens Deppe
Prior to adding versioning, we needed {{synchronized}} on various helper
methods that modified the internal list data structure. This was in order to
ensure exclusive access in the event of a {{toData()}} call (during GII/bucket
movement). {{toData()}} is also synchronized. However, now that we're
synchronizing within more of the 'top-level' methods in RedisList, (because
we're also changing the {{version}} value), I think that we should be able to
remove all of the {{synchronized}} modifiers on the smaller helper methods.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data
[
https://issues.apache.org/jira/browse/GEODE-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10157:
---
Labels: (was: needsTriage)
> Add unit tests for all Delta classes in package
> org.apache.geode.redis.internal.data
>
>
> Key: GEODE-10157
> URL: https://issues.apache.org/jira/browse/GEODE-10157
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Expand on tests in
> {{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other
> delta-related classes in this package.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data
Jens Deppe created GEODE-10157:
--
Summary: Add unit tests for all Delta classes in package
org.apache.geode.redis.internal.data
Key: GEODE-10157
URL: https://issues.apache.org/jira/browse/GEODE-10157
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Jens Deppe
Expand on tests in
{{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other
delta-related classes in this package.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10108) Duplicate Ops During GII/Delta Updates
[ https://issues.apache.org/jira/browse/GEODE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10108. Fix Version/s: 1.16.0 Resolution: Fixed > Duplicate Ops During GII/Delta Updates > --- > > Key: GEODE-10108 > URL: https://issues.apache.org/jira/browse/GEODE-10108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > When Redis commands are ongoing and a server that was previously not hosting > a bucket becomes the host of the primary bucket for a key, there exists a > time window where that server is performing GII but also receiving delta > updates from the previous primary bucket. This can lead to the delta being > applied to a data structure that is already in the “correct” state, resulting > in the command being applied twice. This can result in duplicated appends, > increments/decrements, and in the case of LTRIP and RPOP especially, > IndexOutOfBoundsException on the member applying the delta, as the index to > which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
[
https://issues.apache.org/jira/browse/GEODE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10109:
---
Labels: (was: needsTriage)
> CI Failure: CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> -
>
> Key: GEODE-10109
> URL: https://issues.apache.org/jira/browse/GEODE-10109
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
> {noformat}
> CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> FAILED
> 00:23:40java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 00:23:40Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:23:40
> ---
> 00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
> 00:23:40
> 00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> 00:23:40 at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> 00:23:40 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 00:23:40 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 00:23:40 at java.lang.Thread.run(Thread.java:750)
> 00:23:40Caused by: java.io.IOException: Cannot form connection to alert
> listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
> 00:23:40 ... 18 more
> 00:23:40at org.junit.Assert.fail(Assert.java:89)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> 00:23:40at
>
[jira] [Commented] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
[
https://issues.apache.org/jira/browse/GEODE-10109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502519#comment-17502519
]
Jens Deppe commented on GEODE-10109:
I think the test just needs to add another IgnoredException for the string
"{{{}Cannot form connection to alert listener{}}}".
> CI Failure: CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> -
>
> Key: GEODE-10109
> URL: https://issues.apache.org/jira/browse/GEODE-10109
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
> {noformat}
> CreateRegionCommandDUnitTest >
> createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
> FAILED
> 00:23:40java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 00:23:40Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:23:40
> ---
> 00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
> 00:23:40
> 00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
> 00:23:40 at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> 00:23:40 at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
> 00:23:40 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> 00:23:40 at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> 00:23:40 at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> 00:23:40 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 00:23:40 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 00:23:40 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 00:23:40 at java.lang.Thread.run(Thread.java:750)
> 00:23:40Caused by: java.io.IOException: Cannot form connection to alert
> listener
> heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
> 00:23:40 at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
> 00:23:40 at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
> 00:23:40 ... 18 more
> 00:23:40at org.junit.Assert.fail(Assert.java:89)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 00:23:40at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 00:23:40at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 00:23:40at
>
[jira] [Created] (GEODE-10109) CI Failure: CreateRegionCommandDUnitTest > createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
Jens Deppe created GEODE-10109:
--
Summary: CI Failure: CreateRegionCommandDUnitTest >
createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
Key: GEODE-10109
URL: https://issues.apache.org/jira/browse/GEODE-10109
Project: Geode
Issue Type: Bug
Components: gfsh
Affects Versions: 1.16.0
Reporter: Jens Deppe
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1332]
{noformat}
CreateRegionCommandDUnitTest >
createReplicatedRegionWithParallelGatewaySenderShouldThrowExceptionAndPreventTheRegionFromBeingCreated
FAILED
00:23:40java.lang.AssertionError: Suspicious strings were written to the
log during this run.
00:23:40Fix the strings or use IgnoredException.addIgnoredException to
ignore.
00:23:40
---
00:23:40Found suspect string in 'dunit_suspect-vm2.log' at line 491
00:23:40
00:23:40org.apache.geode.alerting.internal.spi.AlertingIOException:
java.io.IOException: Cannot form connection to alert listener
heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
00:23:40at
org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:461)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:186)
00:23:40at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:521)
00:23:40at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
00:23:40at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031)
00:23:40at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088)
00:23:40at
org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
00:23:40at
org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
00:23:40at
org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
00:23:40at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
00:23:40at java.util.concurrent.FutureTask.run(FutureTask.java:266)
00:23:40at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
00:23:40at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
00:23:40at java.lang.Thread.run(Thread.java:750)
00:23:40Caused by: java.io.IOException: Cannot form connection to alert
listener
heavy-lifter-88c2b61c-fece-57d4-844d-93053119db8b(locator-0:90922:locator):48500
00:23:40at
org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:400)
00:23:40at
org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:537)
00:23:40at
org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803)
00:23:40... 18 more
00:23:40at org.junit.Assert.fail(Assert.java:89)
00:23:40at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
00:23:40at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
00:23:40at
org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
00:23:40at
org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
00:23:40at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
00:23:40at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
00:23:40at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
00:23:40at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
00:23:40at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
00:23:40at
[jira] [Updated] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-7053:
--
Affects Version/s: 1.16.0
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.16.0
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the thread loses CPU for any reason.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9843) CI failure: DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts failed with TooFewActualInvocations
[
https://issues.apache.org/jira/browse/GEODE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9843:
--
Affects Version/s: 1.16.0
> CI failure:
> DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts
> failed with TooFewActualInvocations
> -
>
> Key: GEODE-9843
> URL: https://issues.apache.org/jira/browse/GEODE-9843
> Project: Geode
> Issue Type: Bug
> Components: core, management
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kamilla Aslami
>Priority: Major
>
> {noformat}
> DistributedSystemMXBeanWithAlertsDistributedTest >
> managerMissesAnyAlertsBeforeItStarts FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest$$Lambda$301/390135366.run
> in VM 0 running on Host
> heavy-lifter-993df0f4-3655-560f-82a7-0c09d04efdd9.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.managerMissesAnyAlertsBeforeItStarts(DistributedSystemMXBeanWithAlertsDistributedTest.java:379)
> Caused by:
> org.mockito.exceptions.verification.TooFewActualInvocations:
> notificationListener.handleNotification(
> ,
> isNull()
> );
> Wanted 3 times:
> -> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllNotifications(DistributedSystemMXBeanWithAlertsDistributedTest.java:439)
> But was 2 times:
> -> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> -> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllNotifications(DistributedSystemMXBeanWithAlertsDistributedTest.java:439)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.captureAllAlerts(DistributedSystemMXBeanWithAlertsDistributedTest.java:451)
> at
> org.apache.geode.management.DistributedSystemMXBeanWithAlertsDistributedTest.lambda$managerMissesAnyAlertsBeforeItStarts$bb17a952$6(DistributedSystemMXBeanWithAlertsDistributedTest.java:380)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10107:
---
Component/s: core
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
> Components: core, regions
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10107:
---
Component/s: regions
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10107:
---
Affects Version/s: 1.16.0
> CI Failure: ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
> -
>
> Key: GEODE-10107
> URL: https://issues.apache.org/jira/browse/GEODE-10107
> Project: Geode
> Issue Type: Bug
> Components: core, regions
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
Jens Deppe created GEODE-10107:
--
Summary: CI Failure: ReplicateRegionNetsearchDistributedTest >
proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
Key: GEODE-10107
URL: https://issues.apache.org/jira/browse/GEODE-10107
Project: Geode
Issue Type: Bug
Reporter: Jens Deppe
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
{noformat}
ReplicateRegionNetsearchDistributedTest >
proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
org.opentest4j.AssertionFailedError:
expected: 1L
but was: 0L
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
Jens Deppe created GEODE-10106:
--
Summary: CI Failure: CacheClientNotifierDUnitTest >
testNormalClient2MultipleCacheServer
Key: GEODE-10106
URL: https://issues.apache.org/jira/browse/GEODE-10106
Project: Geode
Issue Type: Bug
Components: wan
Affects Versions: 1.16.0
Reporter: Jens Deppe
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
{noformat}
CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer FAILED
11:49:39java.lang.AssertionError: Suspicious strings were written to the
log during this run.
11:49:39Fix the strings or use IgnoredException.addIgnoredException to
ignore.
11:49:39
---
11:49:39Found suspect string in 'dunit_suspect-vm4.log' at line 431
11:49:39
11:49:39[error 2022/03/05 19:49:36.075 UTC
tid=55] Error in
redundancy satisfier
11:49:39java.lang.NullPointerException
11:49:39at
org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
11:49:39at
org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
11:49:39at
org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
11:49:39at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
11:49:39at java.util.concurrent.FutureTask.run(FutureTask.java:266)
11:49:39at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
11:49:39at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
11:49:39at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
11:49:39at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
11:49:39at java.lang.Thread.run(Thread.java:750)
11:49:39at org.junit.Assert.fail(Assert.java:89)
11:49:39at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
11:49:39at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
11:49:39at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
11:49:39at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
11:49:39at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
11:49:39at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:49:39at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:49:39at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:49:39at java.lang.reflect.Method.invoke(Method.java:498)
11:49:39at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
11:49:39at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
11:49:39at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
11:49:39at
org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
11:49:39at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
11:49:39at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
11:49:39at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
11:49:39at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
11:49:39at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
11:49:39at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
11:49:39at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
11:49:39at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
11:49:39at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
11:49:39at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
11:49:39at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
11:49:39at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
11:49:39at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
11:49:39
[jira] [Commented] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502434#comment-17502434
]
Jens Deppe commented on GEODE-10066:
It looks like this test is broken under Windows.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
>
[jira] [Resolved] (GEODE-10083) Fix RedisProxy to correctly process MOVED responses
[ https://issues.apache.org/jira/browse/GEODE-10083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10083. Fix Version/s: 1.16.0 Resolution: Fixed > Fix RedisProxy to correctly process MOVED responses > --- > > Key: GEODE-10083 > URL: https://issues.apache.org/jira/browse/GEODE-10083 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > The RedisProxy test helper rewrites various redis responses to allow for > address translation when using a docker-based redis cluster. Due to the way > the internal netty processing pipeline was constructed, a received MOVED > response could have disrupted subsequent requests flowing through the proxy. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9949) Implement LPUSHX
[ https://issues.apache.org/jira/browse/GEODE-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9949. --- Fix Version/s: 1.16.0 Resolution: Fixed > Implement LPUSHX > > > Key: GEODE-9949 > URL: https://issues.apache.org/jira/browse/GEODE-9949 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Implement the [LPUSHX|https://redis.io/commands/lpushx] command. > > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9949) Implement LPUSHX
[ https://issues.apache.org/jira/browse/GEODE-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-9949: - Assignee: Eric Zoerner > Implement LPUSHX > > > Key: GEODE-9949 > URL: https://issues.apache.org/jira/browse/GEODE-9949 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > > Implement the [LPUSHX|https://redis.io/commands/lpushx] command. > > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10083) Fix RedisProxy to correctly process MOVED responses
[ https://issues.apache.org/jira/browse/GEODE-10083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10083: -- Assignee: Jens Deppe > Fix RedisProxy to correctly process MOVED responses > --- > > Key: GEODE-10083 > URL: https://issues.apache.org/jira/browse/GEODE-10083 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: needsTriage > > The RedisProxy test helper rewrites various redis responses to allow for > address translation when using a docker-based redis cluster. Due to the way > the internal netty processing pipeline was constructed, a received MOVED > response could have disrupted subsequent requests flowing through the proxy. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10083) Fix RedisProxy to correctly process MOVED responses
Jens Deppe created GEODE-10083: -- Summary: Fix RedisProxy to correctly process MOVED responses Key: GEODE-10083 URL: https://issues.apache.org/jira/browse/GEODE-10083 Project: Geode Issue Type: Bug Components: redis Reporter: Jens Deppe The RedisProxy test helper rewrites various redis responses to allow for address translation when using a docker-based redis cluster. Due to the way the internal netty processing pipeline was constructed, a received MOVED response could have disrupted subsequent requests flowing through the proxy. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10034. Fix Version/s: 1.16.0 Resolution: Fixed > Organize Geode For Redis Stats By Data Structure > > > Key: GEODE-10034 > URL: https://issues.apache.org/jira/browse/GEODE-10034 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > The Geode for Redis Stats should be organized by Data Structure. For the > stats not associated with a data structure, the stats should continue to be > exposed under > "GeodeForRedisStats". > > +Acceptance Criteria+ > All stats, associated with a command specific to a data structure, should be > exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, > Lists). > > All tests should pass. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reopened GEODE-10034: > Organize Geode For Redis Stats By Data Structure > > > Key: GEODE-10034 > URL: https://issues.apache.org/jira/browse/GEODE-10034 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Fix For: 1.16.0 > > > The Geode for Redis Stats should be organized by Data Structure. For the > stats not associated with a data structure, the stats should continue to be > exposed under > "GeodeForRedisStats". > > +Acceptance Criteria+ > All stats, associated with a command specific to a data structure, should be > exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, > Lists). > > All tests should pass. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-10034: --- Fix Version/s: (was: 1.16.0) > Organize Geode For Redis Stats By Data Structure > > > Key: GEODE-10034 > URL: https://issues.apache.org/jira/browse/GEODE-10034 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > > The Geode for Redis Stats should be organized by Data Structure. For the > stats not associated with a data structure, the stats should continue to be > exposed under > "GeodeForRedisStats". > > +Acceptance Criteria+ > All stats, associated with a command specific to a data structure, should be > exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, > Lists). > > All tests should pass. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10032) Redis Command Registry Needs to Include Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10032. Fix Version/s: 1.16.0 Resolution: Fixed > Redis Command Registry Needs to Include Data Structure > -- > > Key: GEODE-10032 > URL: https://issues.apache.org/jira/browse/GEODE-10032 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Not all Redis commands are associated with a data structure. For the > commands that are, we need to know which data structure that command is > associated with. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10032) Redis Command Registry Needs to Include Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10032: -- Assignee: Jens Deppe > Redis Command Registry Needs to Include Data Structure > -- > > Key: GEODE-10032 > URL: https://issues.apache.org/jira/browse/GEODE-10032 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > Not all Redis commands are associated with a data structure. For the > commands that are, we need to know which data structure that command is > associated with. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10034: -- Assignee: Jens Deppe > Organize Geode For Redis Stats By Data Structure > > > Key: GEODE-10034 > URL: https://issues.apache.org/jira/browse/GEODE-10034 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Fix For: 1.16.0 > > > The Geode for Redis Stats should be organized by Data Structure. For the > stats not associated with a data structure, the stats should continue to be > exposed under > "GeodeForRedisStats". > > +Acceptance Criteria+ > All stats, associated with a command specific to a data structure, should be > exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, > Lists). > > All tests should pass. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10034. Fix Version/s: 1.16.0 Resolution: Fixed > Organize Geode For Redis Stats By Data Structure > > > Key: GEODE-10034 > URL: https://issues.apache.org/jira/browse/GEODE-10034 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Fix For: 1.16.0 > > > The Geode for Redis Stats should be organized by Data Structure. For the > stats not associated with a data structure, the stats should continue to be > exposed under > "GeodeForRedisStats". > > +Acceptance Criteria+ > All stats, associated with a command specific to a data structure, should be > exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, > Lists). > > All tests should pass. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10018) Remove tx flag from Redis SetOptions
Jens Deppe created GEODE-10018:
--
Summary: Remove tx flag from Redis SetOptions
Key: GEODE-10018
URL: https://issues.apache.org/jira/browse/GEODE-10018
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Jens Deppe
A recent change ([https://github.com/apache/geode/pull/7321)] consolidated the
logic for transactional operations, avoiding the need for individual data
structs and commands to take different code paths to account for delta changes
vs tx contexts.
The MSET command still contains this older approach which can now be removed.
Practically, we can remove the {{SetOptions.inTransaction}} field and all logic
surrounding this flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9988) Log full exception when JNDI binding fails during cache creation
[
https://issues.apache.org/jira/browse/GEODE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9988.
---
Fix Version/s: 1.16.0
Resolution: Fixed
> Log full exception when JNDI binding fails during cache creation
>
>
> Key: GEODE-9988
> URL: https://issues.apache.org/jira/browse/GEODE-9988
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> When a cache.xml is configured with a {{jndi-binding}} construct it may fail
> to bind but the log does not contain a useful error message, only something
> like:
> {noformat}
> [warn 2022/01/25 13:26:41.286 PST tid=0x1] jndi-binding creation of
> SimpleDataSource failed with:
> org.apache.geode.internal.datasource.DataSourceCreateException: Failed to
> connect to "SimpleDataSource". See log for details {noformat}
> The full exception stack would contain a the real cause of the problem. In
> this case:
> {noformat}
> java.sql.SQLNonTransientConnectionException: java.net.ConnectException :
> Error connecting to server localhost on port 1,528 with message Connection
> refused (Connection refused).
> at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:111)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.getConnection(JNDIInvoker.java:429)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.validateAndBindDataSource(JNDIInvoker.java:413)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:392)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:366)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3064)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3485)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:226)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2007)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:881)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1784)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2969)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:113)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:867)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:796)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:142)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:644)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:328)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:233)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4203)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1625)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1451)
> 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
[jira] [Updated] (GEODE-9988) Log full exception when JNDI binding fails during cache creation
[
https://issues.apache.org/jira/browse/GEODE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9988:
--
Affects Version/s: 1.16.0
> Log full exception when JNDI binding fails during cache creation
>
>
> Key: GEODE-9988
> URL: https://issues.apache.org/jira/browse/GEODE-9988
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.16.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> When a cache.xml is configured with a {{jndi-binding}} construct it may fail
> to bind but the log does not contain a useful error message, only something
> like:
> {noformat}
> [warn 2022/01/25 13:26:41.286 PST tid=0x1] jndi-binding creation of
> SimpleDataSource failed with:
> org.apache.geode.internal.datasource.DataSourceCreateException: Failed to
> connect to "SimpleDataSource". See log for details {noformat}
> The full exception stack would contain a the real cause of the problem. In
> this case:
> {noformat}
> java.sql.SQLNonTransientConnectionException: java.net.ConnectException :
> Error connecting to server localhost on port 1,528 with message Connection
> refused (Connection refused).
> at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:111)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.getConnection(JNDIInvoker.java:429)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.validateAndBindDataSource(JNDIInvoker.java:413)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:392)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:366)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3064)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3485)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:226)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2007)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:881)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1784)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2969)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:113)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:867)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:796)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:142)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:644)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:328)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:233)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4203)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1625)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1451)
> 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.JtaDebug.insanity(JtaDebug.java:47)
> at
[jira] [Commented] (GEODE-9986) Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
[
https://issues.apache.org/jira/browse/GEODE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485509#comment-17485509
]
Jens Deppe commented on GEODE-9986:
---
This is definitely a flaky test issue. Unfortunately it is difficult to fully
debug since the error is being generated from a locator launched by a `gfsh`
invocation. It would be most helpful to see the logs of this invocation but
unfortunately those are not available or visible when the test errors. I have
some ideas on how to address that, but for now I believe it is safe not to
consider this a `blocker`.
> Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
> ---
>
> Key: GEODE-9986
> URL: https://issues.apache.org/jira/browse/GEODE-9986
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jens Deppe
>Priority: Major
>
> {code:java}
> > Task :geode-assembly:distributedTest
> StartLocatorCommandDUnitTest > testWithAvailablePort FAILED
> org.opentest4j.AssertionFailedError: [The Locator process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit4212781718034424448/junit8849905322533733269 for full details.
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001
> started at Sat Jan 22 08:31:19 UTC 2022: Message distribution has
> terminated, caused by org.apache.geode.ForcedDisconnectException: Member
> isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:734)
> at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:637)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:220)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.lang.Thread.run(Thread.java:750)
> ]
> expected: OK
> but was: ERROR
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.StartLocatorCommandDUnitTest.testWithAvailablePort(StartLocatorCommandDUnitTest.java:219)
> StartLocatorCommandDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
>
[jira] [Comment Edited] (GEODE-9986) Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
[
https://issues.apache.org/jira/browse/GEODE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485509#comment-17485509
]
Jens Deppe edited comment on GEODE-9986 at 2/1/22, 10:09 PM:
-
This is definitely a flaky test issue. Unfortunately it is difficult to fully
debug since the error is being generated from a locator launched by a {{gfsh}}
invocation. It would be most helpful to see the logs of this invocation but
unfortunately those are not available or visible when the test errors. I have
some ideas on how to address that, but for now I believe it is safe not to
consider this a `blocker`.
was (Author: jens.deppe):
This is definitely a flaky test issue. Unfortunately it is difficult to fully
debug since the error is being generated from a locator launched by a `gfsh`
invocation. It would be most helpful to see the logs of this invocation but
unfortunately those are not available or visible when the test errors. I have
some ideas on how to address that, but for now I believe it is safe not to
consider this a `blocker`.
> Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
> ---
>
> Key: GEODE-9986
> URL: https://issues.apache.org/jira/browse/GEODE-9986
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jens Deppe
>Priority: Major
>
> {code:java}
> > Task :geode-assembly:distributedTest
> StartLocatorCommandDUnitTest > testWithAvailablePort FAILED
> org.opentest4j.AssertionFailedError: [The Locator process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit4212781718034424448/junit8849905322533733269 for full details.
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001
> started at Sat Jan 22 08:31:19 UTC 2022: Message distribution has
> terminated, caused by org.apache.geode.ForcedDisconnectException: Member
> isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:734)
> at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:637)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:220)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.lang.Thread.run(Thread.java:750)
> ]
> expected: OK
> but was: ERROR
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
>
[jira] [Updated] (GEODE-9986) Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
[
https://issues.apache.org/jira/browse/GEODE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9986:
--
Labels: (was: needsTriage)
> Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
> ---
>
> Key: GEODE-9986
> URL: https://issues.apache.org/jira/browse/GEODE-9986
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jens Deppe
>Priority: Major
>
> {code:java}
> > Task :geode-assembly:distributedTest
> StartLocatorCommandDUnitTest > testWithAvailablePort FAILED
> org.opentest4j.AssertionFailedError: [The Locator process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit4212781718034424448/junit8849905322533733269 for full details.
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001
> started at Sat Jan 22 08:31:19 UTC 2022: Message distribution has
> terminated, caused by org.apache.geode.ForcedDisconnectException: Member
> isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:734)
> at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:637)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:220)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.lang.Thread.run(Thread.java:750)
> ]
> expected: OK
> but was: ERROR
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.StartLocatorCommandDUnitTest.testWithAvailablePort(StartLocatorCommandDUnitTest.java:219)
> StartLocatorCommandDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 591
> [fatal 2022/01/22 08:31:40.041 UTC
> tid=58] Possible loss of quorum due to the loss of 1 cache processes:
> [heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001]
> ---
>
[jira] [Updated] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9995:
--
Labels: pull-request-available (was: backport needsTriage
pull-request-available)
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9995.
---
Fix Version/s: 1.15.0
1.16.0
Resolution: Fixed
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10004) Starting server should fail fast when server port and redis port are the same
[
https://issues.apache.org/jira/browse/GEODE-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485009#comment-17485009
]
Jens Deppe commented on GEODE-10004:
Geode has other 'server' components that could all produce conflicting port
issues - WAN gateways, JMX, http and memcache come to mind.
> Starting server should fail fast when server port and redis port are the same
> -
>
> Key: GEODE-10004
> URL: https://issues.apache.org/jira/browse/GEODE-10004
> Project: Geode
> Issue Type: Bug
> Components: gfsh, redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Hale Bales
>Priority: Major
>
> When starting a cluster with GFSH with geode-for-redis enabled, starting a
> server fails when the geode-for-redis-port and server-port are set to the
> same port. It fails with the below stacktrace, but does not fail fast. We
> should be able to detect this issue before we reach the point of getting a
> bind exception.
> stacktrace:
> {code:java}
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred
> while starting a Server in /Users/hbales/workspace/geode/itch-proud-alpha on
> hbales-a01.vmware.com[6379]: Failed to create server socket on
> 192.168.0.4[6379]
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:863)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:258)
> Caused by: java.net.BindException: Failed to create server socket on
> 192.168.0.4[6379]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:522)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:573)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:291)
> at
> org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:420)
> at
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:377)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:1039)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:837)
> ... 2 more
> Caused by: java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 10 more
> {code}
> series of GFSH commands that led to this error:
> {code:java}
> > start locator
> > start server --J=-Dgemfire.geode-for-redis-enabled=true
> > --J=-Dgemfire.geode-for-redis-port=6379 --server-port=6379
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-9835: - Assignee: Bala Tripura Sundari Kaza Venkata > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Assignee: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9835) SSCAN Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9835: -- Affects Version/s: 1.15.0 1.16.0 > SSCAN Command Supported > --- > > Key: GEODE-9835 > URL: https://issues.apache.org/jira/browse/GEODE-9835 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The SSCAN command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9995:
--
Labels: backport needsTriage (was: needsTriage)
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: backport, needsTriage
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9995:
--
Affects Version/s: 1.15.0
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: backport, needsTriage
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9998) Update jedis library to the current latest (>= 4.1.0)
[ https://issues.apache.org/jira/browse/GEODE-9998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9998: -- Description: The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the last in the 3.x line). This is not a trivial change as various APIs have changed which will affect a lot of test code. was: The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the last in the 3.x line). This is not a trivial change as various APIs have changed and will touch a lot of code. > Update jedis library to the current latest (>= 4.1.0) > - > > Key: GEODE-9998 > URL: https://issues.apache.org/jira/browse/GEODE-9998 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > > The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the > last in the 3.x line). > This is not a trivial change as various APIs have changed which will affect a > lot of test code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9998) Update jedis library to the current latest (>= 4.1.0)
[ https://issues.apache.org/jira/browse/GEODE-9998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9998: -- Affects Version/s: 1.16.0 > Update jedis library to the current latest (>= 4.1.0) > - > > Key: GEODE-9998 > URL: https://issues.apache.org/jira/browse/GEODE-9998 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.16.0 >Reporter: Jens Deppe >Priority: Major > > The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the > last in the 3.x line). > This is not a trivial change as various APIs have changed which will affect a > lot of test code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9998) Update jedis library to the current latest (>= 4.1.0)
[ https://issues.apache.org/jira/browse/GEODE-9998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9998: -- Description: The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the last in the 3.x line). This is not a trivial change as various APIs have changed and will touch a lot of code. > Update jedis library to the current latest (>= 4.1.0) > - > > Key: GEODE-9998 > URL: https://issues.apache.org/jira/browse/GEODE-9998 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > > The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the > last in the 3.x line). > This is not a trivial change as various APIs have changed and will touch a > lot of code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9999) Update the Geode for Redis documentation
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-: -- Labels: backport (was: ) > Update the Geode for Redis documentation > > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: John Martin >Priority: Major > Labels: backport > > A few updates are needed to update the Geode for Redis documentation to > better reflect the current implementation of the Redis module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9998) Update jedis library to the current latest (>= 4.1.0)
Jens Deppe created GEODE-9998: - Summary: Update jedis library to the current latest (>= 4.1.0) Key: GEODE-9998 URL: https://issues.apache.org/jira/browse/GEODE-9998 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9988) Log full exception when JNDI binding fails during cache creation
[
https://issues.apache.org/jira/browse/GEODE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9988:
-
Assignee: Jens Deppe
> Log full exception when JNDI binding fails during cache creation
>
>
> Key: GEODE-9988
> URL: https://issues.apache.org/jira/browse/GEODE-9988
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> When a cache.xml is configured with a {{jndi-binding}} construct it may fail
> to bind but the log does not contain a useful error message, only something
> like:
> {noformat}
> [warn 2022/01/25 13:26:41.286 PST tid=0x1] jndi-binding creation of
> SimpleDataSource failed with:
> org.apache.geode.internal.datasource.DataSourceCreateException: Failed to
> connect to "SimpleDataSource". See log for details {noformat}
> The full exception stack would contain a the real cause of the problem. In
> this case:
> {noformat}
> java.sql.SQLNonTransientConnectionException: java.net.ConnectException :
> Error connecting to server localhost on port 1,528 with message Connection
> refused (Connection refused).
> at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:111)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.getConnection(JNDIInvoker.java:429)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.validateAndBindDataSource(JNDIInvoker.java:413)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:392)
> at
> org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:366)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3064)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3485)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:226)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2007)
> at
> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:881)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1784)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2969)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:113)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:867)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:796)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:142)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:644)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:328)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:233)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4203)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1625)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1451)
> 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.JtaDebug.insanity(JtaDebug.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Created] (GEODE-9988) Log full exception when JNDI binding fails during cache creation
Jens Deppe created GEODE-9988:
-
Summary: Log full exception when JNDI binding fails during cache
creation
Key: GEODE-9988
URL: https://issues.apache.org/jira/browse/GEODE-9988
Project: Geode
Issue Type: Improvement
Components: core
Reporter: Jens Deppe
When a cache.xml is configured with a {{jndi-binding}} construct it may fail to
bind but the log does not contain a useful error message, only something like:
{noformat}
[warn 2022/01/25 13:26:41.286 PST tid=0x1] jndi-binding creation of
SimpleDataSource failed with:
org.apache.geode.internal.datasource.DataSourceCreateException: Failed to
connect to "SimpleDataSource". See log for details {noformat}
The full exception stack would contain a the real cause of the problem. In this
case:
{noformat}
java.sql.SQLNonTransientConnectionException: java.net.ConnectException : Error
connecting to server localhost on port 1,528 with message Connection refused
(Connection refused).
at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown
Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:111)
at
org.apache.geode.internal.jndi.JNDIInvoker.getConnection(JNDIInvoker.java:429)
at
org.apache.geode.internal.jndi.JNDIInvoker.validateAndBindDataSource(JNDIInvoker.java:413)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:392)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:366)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:3064)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3485)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
at
com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:226)
at
com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2007)
at
com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:881)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1784)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2969)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:113)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:507)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:867)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:796)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:142)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:644)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:328)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:196)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:233)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4203)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1625)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1451)
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.JtaDebug.insanity(JtaDebug.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
[jira] [Assigned] (GEODE-9986) Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
[
https://issues.apache.org/jira/browse/GEODE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9986:
-
Assignee: Jens Deppe
> Mass-Test-Run: StartLocatorCommandDUnitTest > executionError FAILED
> ---
>
> Key: GEODE-9986
> URL: https://issues.apache.org/jira/browse/GEODE-9986
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-assembly:distributedTest
> StartLocatorCommandDUnitTest > testWithAvailablePort FAILED
> org.opentest4j.AssertionFailedError: [The Locator process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit4212781718034424448/junit8849905322533733269 for full details.
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001
> started at Sat Jan 22 08:31:19 UTC 2022: Message distribution has
> terminated, caused by org.apache.geode.ForcedDisconnectException: Member
> isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:734)
> at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:637)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:220)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.lang.Thread.run(Thread.java:750)
> ]
> expected: OK
> but was: ERROR
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.StartLocatorCommandDUnitTest.testWithAvailablePort(StartLocatorCommandDUnitTest.java:219)
> StartLocatorCommandDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 591
> [fatal 2022/01/22 08:31:40.041 UTC
> tid=58] Possible loss of quorum due to the loss of 1 cache processes:
> [heavy-lifter-501890ca-346e-5a45-9c21-2e28585dba8b(testWithAvailablePort:37687:locator):41001]
>
[jira] [Resolved] (GEODE-9958) Add tests that confirm that a geode-for-redis server can be successfully started using gfsh
[
https://issues.apache.org/jira/browse/GEODE-9958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9958.
---
Fix Version/s: 1.15.0
Assignee: Jens Deppe
Resolution: Fixed
> Add tests that confirm that a geode-for-redis server can be successfully
> started using gfsh
> ---
>
> Key: GEODE-9958
> URL: https://issues.apache.org/jira/browse/GEODE-9958
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The class {{GeodeRedisServerStartupUsingGfshAcceptanceTest}} has several
> tests that confirm various error cases for starting a geode-for-redis server
> using gfsh, but no test cases that show that a server can successfully be
> started with gfsh, connected to using a client, and successfully execute
> operations.
> Tests should be written to cover the happy-path situation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9957) Redis INFO command returns incorrect information
[
https://issues.apache.org/jira/browse/GEODE-9957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9957.
---
Fix Version/s: 1.15.0
Resolution: Duplicate
> Redis INFO command returns incorrect information
>
>
> Key: GEODE-9957
> URL: https://issues.apache.org/jira/browse/GEODE-9957
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
> Fix For: 1.15.0
>
>
> The geode-for-redis {{INFO}} command is supported, but has not been
> maintained or updated since the geode-for-redis module moved from standalone
> to cluster mode. As such, several fields returned by the command such as
> {{cluster_enabled}} and {{redis_mode}} return incorrect values.
> The output of the INFO command should be modified to return correct values
> for the current geode-for-redis configuration.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9957) Redis INFO command returns incorrect information
[
https://issues.apache.org/jira/browse/GEODE-9957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9957:
-
Assignee: Jens Deppe
> Redis INFO command returns incorrect information
>
>
> Key: GEODE-9957
> URL: https://issues.apache.org/jira/browse/GEODE-9957
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.15.0
> Fix For: 1.15.0
>
>
> The geode-for-redis {{INFO}} command is supported, but has not been
> maintained or updated since the geode-for-redis module moved from standalone
> to cluster mode. As such, several fields returned by the command such as
> {{cluster_enabled}} and {{redis_mode}} return incorrect values.
> The output of the INFO command should be modified to return correct values
> for the current geode-for-redis configuration.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9962) Redis INFO Command Support for Cluster Mode
[ https://issues.apache.org/jira/browse/GEODE-9962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9962. --- Fix Version/s: 1.15.0 Resolution: Fixed > Redis INFO Command Support for Cluster Mode > --- > > Key: GEODE-9962 > URL: https://issues.apache.org/jira/browse/GEODE-9962 > Project: Geode > Issue Type: Task > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > The Redis INFO command does not show correct information for cluster mode. > > Research what changes must occur to support the correct information for > cluster mode and ensure tickets are created for tracking. > > +Acceptance Criteria+ > > Gaps in cluster mode supported are identified and tickets are created for > tracking. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9962) Redis INFO Command Support for Cluster Mode
[ https://issues.apache.org/jira/browse/GEODE-9962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-9962: - Assignee: Jens Deppe > Redis INFO Command Support for Cluster Mode > --- > > Key: GEODE-9962 > URL: https://issues.apache.org/jira/browse/GEODE-9962 > Project: Geode > Issue Type: Task > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The Redis INFO command does not show correct information for cluster mode. > > Research what changes must occur to support the correct information for > cluster mode and ensure tickets are created for tracking. > > +Acceptance Criteria+ > > Gaps in cluster mode supported are identified and tickets are created for > tracking. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9962) Redis INFO Command Support for Cluster Mode
[ https://issues.apache.org/jira/browse/GEODE-9962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9962: -- Summary: Redis INFO Command Support for Cluster Mode (was: SPIKE: Redis INFO Command Support for Cluster Mode) > Redis INFO Command Support for Cluster Mode > --- > > Key: GEODE-9962 > URL: https://issues.apache.org/jira/browse/GEODE-9962 > Project: Geode > Issue Type: Task > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The Redis INFO command does not show correct information for cluster mode. > > Research what changes must occur to support the correct information for > cluster mode and ensure tickets are created for tracking. > > +Acceptance Criteria+ > > Gaps in cluster mode supported are identified and tickets are created for > tracking. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9966) Update redis info 'expires' and 'avg_ttl' properties with computed values
[
https://issues.apache.org/jira/browse/GEODE-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9966:
--
Summary: Update redis info 'expires' and 'avg_ttl' properties with computed
values (was: Update redis info 'expires' property with computed value)
> Update redis info 'expires' and 'avg_ttl' properties with computed values
> -
>
> Key: GEODE-9966
> URL: https://issues.apache.org/jira/browse/GEODE-9966
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> We're currently setting both {{expires}} and {{avg_ttl}} values (from
> {{{}INFO{}}}) to {{{}0{}}}. This information could easily be updated from the
> {{{}PassiveExpirationManager{}}}. Although the values will not necessarily be
> exactly accurate, (dependent on the frequency at which the PEM runs), they
> will at least be more accurate than they are currently.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9966) Update redis info 'expires' property with computed value
Jens Deppe created GEODE-9966:
-
Summary: Update redis info 'expires' property with computed value
Key: GEODE-9966
URL: https://issues.apache.org/jira/browse/GEODE-9966
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Jens Deppe
We're currently setting both {{expires}} and {{avg_ttl}} values (from
{{{}INFO{}}}) to {{{}0{}}}. This information could easily be updated from the
{{{}PassiveExpirationManager{}}}. Although the values will not necessarily be
exactly accurate, (dependent on the frequency at which the PEM runs), they will
at least be more accurate than they are currently.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9912) Add unique identifier to DUnit log lines
[
https://issues.apache.org/jira/browse/GEODE-9912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9912.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Add unique identifier to DUnit log lines
>
>
> Key: GEODE-9912
> URL: https://issues.apache.org/jira/browse/GEODE-9912
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Adding an arbitrary random string to DUnit log lines allows to distinguish
> individual test output for repeated tests. In such cases tests run in
> parallel and individual test log lines are interleaved making debugging very
> difficult. So log lines would look something like:
> {noformat}
> [vm0-51ec] [info 2021/12/24 15:43:54.367 UTC Connection(1)-10.138.0.70>; tid=0x1d] Reinitializing JarDeploymentService
> with new working directory: null
> [vm0-47b7] [info 2021/12/24 15:43:54.416 UTC Connection(1)-10.138.0.70> tid=0x1d] Reinitializing JarDeploymentService with
> new working directory: null
> [vm1-47b7] [info 2021/12/24 15:43:54.431 UTC Connection(1)-10.138.0.70> tid=0x1d] Received method:
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call with 0 args on
> object: IdentifiableCallable(0:start locator in vm0)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9911) Allow ExecutorServiceRule to name threads
[
https://issues.apache.org/jira/browse/GEODE-9911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9911.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Allow ExecutorServiceRule to name threads
> -
>
> Key: GEODE-9911
> URL: https://issues.apache.org/jira/browse/GEODE-9911
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> In some situations it may be useful to name the threads created by the
> {{{}ExecutorServiceRule{}}}. These would appear in log files and be helpful
> in debugging.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9860) NativeRedisRenameRedirectionsDUnitTest. initializationError
[
https://issues.apache.org/jira/browse/GEODE-9860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9860:
--
Labels: (was: needsTriage)
> NativeRedisRenameRedirectionsDUnitTest. initializationError
> ---
>
> Key: GEODE-9860
> URL: https://issues.apache.org/jira/browse/GEODE-9860
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Jens Deppe
>Priority: Major
>
> {noformat}
> NativeRedisRenameRedirectionsDUnitTest > initializationError FAILED
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.rnorth.ducttape.timeouts.Timeouts.callFuture(Timeouts.java:68)
> at
> org.rnorth.ducttape.timeouts.Timeouts.doWithTimeout(Timeouts.java:60)
> at
> org.testcontainers.containers.wait.strategy.WaitAllStrategy.waitUntilReady(WaitAllStrategy.java:53)
> at
> org.testcontainers.containers.DockerComposeContainer.waitUntilServiceStarted(DockerComposeContainer.java:285)
> at
> java.util.concurrent.ConcurrentHashMap.forEach(ConcurrentHashMap.java:1597)
> at
> org.testcontainers.containers.DockerComposeContainer.waitUntilServiceStarted(DockerComposeContainer.java:265)
> at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:179)
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:84)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
[jira] [Assigned] (GEODE-9860) NativeRedisRenameRedirectionsDUnitTest. initializationError
[
https://issues.apache.org/jira/browse/GEODE-9860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9860:
-
Assignee: Jens Deppe
> NativeRedisRenameRedirectionsDUnitTest. initializationError
> ---
>
> Key: GEODE-9860
> URL: https://issues.apache.org/jira/browse/GEODE-9860
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> NativeRedisRenameRedirectionsDUnitTest > initializationError FAILED
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.rnorth.ducttape.timeouts.Timeouts.callFuture(Timeouts.java:68)
> at
> org.rnorth.ducttape.timeouts.Timeouts.doWithTimeout(Timeouts.java:60)
> at
> org.testcontainers.containers.wait.strategy.WaitAllStrategy.waitUntilReady(WaitAllStrategy.java:53)
> at
> org.testcontainers.containers.DockerComposeContainer.waitUntilServiceStarted(DockerComposeContainer.java:285)
> at
> java.util.concurrent.ConcurrentHashMap.forEach(ConcurrentHashMap.java:1597)
> at
> org.testcontainers.containers.DockerComposeContainer.waitUntilServiceStarted(DockerComposeContainer.java:265)
> at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:179)
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:84)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Assigned] (GEODE-9937) Add convenience methods to FileWatchingX509Extended*Manager
[ https://issues.apache.org/jira/browse/GEODE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-9937: - Assignee: Jens Deppe > Add convenience methods to FileWatchingX509Extended*Manager > --- > > Key: GEODE-9937 > URL: https://issues.apache.org/jira/browse/GEODE-9937 > Project: Geode > Issue Type: Improvement > Components: security >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9937) Add convenience methods to FileWatchingX509Extended*Manager
Jens Deppe created GEODE-9937: - Summary: Add convenience methods to FileWatchingX509Extended*Manager Key: GEODE-9937 URL: https://issues.apache.org/jira/browse/GEODE-9937 Project: Geode Issue Type: Improvement Components: security Reporter: Jens Deppe -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9860) NativeRedisRenameRedirectionsDUnitTest. initializationError
[
https://issues.apache.org/jira/browse/GEODE-9860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470998#comment-17470998
]
Jens Deppe commented on GEODE-9860:
---
This appears to be a test issue. I'd say this testcontainers issue is related:
https://github.com/testcontainers/testcontainers-java/issues/3535
> NativeRedisRenameRedirectionsDUnitTest. initializationError
> ---
>
> Key: GEODE-9860
> URL: https://issues.apache.org/jira/browse/GEODE-9860
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> NativeRedisRenameRedirectionsDUnitTest > initializationError FAILED
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.rnorth.ducttape.timeouts.Timeouts.callFuture(Timeouts.java:68)
> at
> org.rnorth.ducttape.timeouts.Timeouts.doWithTimeout(Timeouts.java:60)
> at
> org.testcontainers.containers.wait.strategy.WaitAllStrategy.waitUntilReady(WaitAllStrategy.java:53)
> at
> org.testcontainers.containers.DockerComposeContainer.waitUntilServiceStarted(DockerComposeContainer.java:285)
> at
> java.util.concurrent.ConcurrentHashMap.forEach(ConcurrentHashMap.java:1597)
> at
> org.testcontainers.containers.DockerComposeContainer.waitUntilServiceStarted(DockerComposeContainer.java:265)
> at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:179)
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:84)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
> at
[jira] [Created] (GEODE-9922) Consistently check multi key arguments map to the same slot
Jens Deppe created GEODE-9922: - Summary: Consistently check multi key arguments map to the same slot Key: GEODE-9922 URL: https://issues.apache.org/jira/browse/GEODE-9922 Project: Geode Issue Type: Improvement Components: redis Reporter: Jens Deppe Multi-key commands should use a consistent approach to validate that all the given keys are in the same slot. This could be done in `RegionProvider.lockedExecute` since all commands eventually end up there. As an aside, checking slot equivalence is not the same as ensuring that keys are local to the server (which also still needs to happen). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9691) ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed fails sometimes
[
https://issues.apache.org/jira/browse/GEODE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9691.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed fails
> sometimes
> -
>
> Key: GEODE-9691
> URL: https://issues.apache.org/jira/browse/GEODE-9691
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Hale Bales
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> fails with the following stack trace:
> {code:java}
> java.util.concurrent.ExecutionException: org.opentest4j.AssertionFailedError:
> expected: 299L
> but was: 0L
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed(ZRemDUnitTest.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
>
