[jira] [Updated] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal operations
[
https://issues.apache.org/jira/browse/GEODE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10383:
--
Labels: (was: needsTriage)
> lucene may log many warnings about BucketNotFound during normal operations
> --
>
> Key: GEODE-10383
> URL: https://issues.apache.org/jira/browse/GEODE-10383
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.16.0
>Reporter: Darrel Schneider
>Priority: Major
>
> This seems much like GEODE-1557 but it may be this exception is coming from a
> different place. Once again it involves a test that has primaries moving
> around due to new servers starting up.
> I don't see any value in logging the stack trace in this case.
> If we are going to log about this should the message also include an
> explanation as to why it can happen during normal operations?
> Also should it really be a warning since it can occur during normal
> operations? It looks like the fix for GEODE-1557 made it "debug" level.
> I see a bunch of the following warnings logged:
> {noformat}
> .cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFo
> undException: Unable to find lucene index because no longer primary for
> bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFoundException: Unable to find
> lucene ind
> ex because no longer primary for bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal operations
[
https://issues.apache.org/jira/browse/GEODE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10383:
--
Affects Version/s: 1.16.0
> lucene may log many warnings about BucketNotFound during normal operations
> --
>
> Key: GEODE-10383
> URL: https://issues.apache.org/jira/browse/GEODE-10383
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.16.0
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> This seems much like GEODE-1557 but it may be this exception is coming from a
> different place. Once again it involves a test that has primaries moving
> around due to new servers starting up.
> I don't see any value in logging the stack trace in this case.
> If we are going to log about this should the message also include an
> explanation as to why it can happen during normal operations?
> Also should it really be a warning since it can occur during normal
> operations? It looks like the fix for GEODE-1557 made it "debug" level.
> I see a bunch of the following warnings logged:
> {noformat}
> .cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFo
> undException: Unable to find lucene index because no longer primary for
> bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFoundException: Unable to find
> lucene ind
> ex because no longer primary for bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10376) Client event processing waits for event registrations to finish.
[
https://issues.apache.org/jira/browse/GEODE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10376:
--
Labels: (was: needsTriage)
> Client event processing waits for event registrations to finish.
> --
>
> Key: GEODE-10376
> URL: https://issues.apache.org/jira/browse/GEODE-10376
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.16.0
>Reporter: Anilkumar Gingade
>Priority: Major
>
> Currently while processing the events from server the client event processing
> (Cache Client Updater) thread will wait for event registrations to finish;
> this will slowdown the event processing and may cause event build of on
> server.
> The code in question:
> {code:java}
> In CacheClientUpdater.processMessage():
> // Wait for the previously failed cache client updater
> // to finish. This will avoid out of order messages.
> waitForFailedUpdater();
> cache.waitForRegisterInterestsInProgress();
> {code}
> We need to see if "waitForInterestRegistration" needs to be done if there is
> no failure in updater thread.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10376) Client event processing waits for event registrations to finish
[
https://issues.apache.org/jira/browse/GEODE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10376:
--
Summary: Client event processing waits for event registrations to finish
(was: Client event processing waits for event registrations to finish. )
> Client event processing waits for event registrations to finish
> ---
>
> Key: GEODE-10376
> URL: https://issues.apache.org/jira/browse/GEODE-10376
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.16.0
>Reporter: Anilkumar Gingade
>Priority: Major
>
> Currently while processing the events from server the client event processing
> (Cache Client Updater) thread will wait for event registrations to finish;
> this will slowdown the event processing and may cause event build of on
> server.
> The code in question:
> {code:java}
> In CacheClientUpdater.processMessage():
> // Wait for the previously failed cache client updater
> // to finish. This will avoid out of order messages.
> waitForFailedUpdater();
> cache.waitForRegisterInterestsInProgress();
> {code}
> We need to see if "waitForInterestRegistration" needs to be done if there is
> no failure in updater thread.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10376) Client event processing waits for event registrations to finish.
Anilkumar Gingade created GEODE-10376:
-
Summary: Client event processing waits for event registrations to
finish.
Key: GEODE-10376
URL: https://issues.apache.org/jira/browse/GEODE-10376
Project: Geode
Issue Type: Bug
Components: client/server
Affects Versions: 1.16.0
Reporter: Anilkumar Gingade
Currently while processing the events from server the client event processing
(Cache Client Updater) thread will wait for event registrations to finish; this
will slowdown the event processing and may cause event build of on server.
The code in question:
{code:java}
In CacheClientUpdater.processMessage():
// Wait for the previously failed cache client updater
// to finish. This will avoid out of order messages.
waitForFailedUpdater();
cache.waitForRegisterInterestsInProgress();
{code}
We need to see if "waitForInterestRegistration" needs to be done if there is no
failure in updater thread.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10373) CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test run to timeout
[ https://issues.apache.org/jira/browse/GEODE-10373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10373: -- Labels: (was: needsTriage) > CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test > run to timeout > -- > > Key: GEODE-10373 > URL: https://issues.apache.org/jira/browse/GEODE-10373 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Eric Shu >Assignee: Robert Houghton >Priority: Major > > LuceneIndexCommandsWithReindexAllowedIntegrationTest > > whenLuceneReindexingInProgressThenListIndexCommandMustExecuteSuccessfully > FAILED > java.lang.OutOfMemoryError: Java heap space -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10350) volunteerForPrimary should proceed when being elector or knowing elector
[ https://issues.apache.org/jira/browse/GEODE-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade resolved GEODE-10350. --- Resolution: Abandoned The issue was created based on the assumption that the elector was not properly set/used. The planned change (PR in this ticket) is causing issue with Fixed partitioning. We need to understand more about the primary logic. Closing this issue for now. > volunteerForPrimary should proceed when being elector or knowing elector > > > Key: GEODE-10350 > URL: https://issues.apache.org/jira/browse/GEODE-10350 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Joris Melchior >Priority: Major > Labels: needsTriage, pull-request-available > > Inside BucketAdvisor.volunteerForPrimary(), when current member is elector or > has profile for elector, then current member should proceed to volunteer for > primary bucket. > Current logic happened to be opposite. It might be due to careless code. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-8977: - Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was: GeodeOperationAPI pull-request-available) > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-8977: - Affects Version/s: 1.15.0 > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10353) Change IndexThresholdSize default value
[
https://issues.apache.org/jira/browse/GEODE-10353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10353:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Change IndexThresholdSize default value
> ---
>
> Key: GEODE-10353
> URL: https://issues.apache.org/jira/browse/GEODE-10353
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When doing range queries with the wildcard character(%), there are no result.
> The problem is that when we are doing a range query like this:
> {code:java}
> query --query="SELECT e.key, e.value from /example-region.entrySet e
> where e.value.positions['SUN'] LIKE 'abc%'"
> {code}
> The printed results will be null.
> The comparison will be divided into two comparison >='abc' and <'abd'.
> First it checks all entries that are lower than 'abd' and store them in the
> intermediate results. There are all entries which attribute 'SUN' is lower
> than 'abd' which can be a very high number. It iterates through all entries
> and store first 100 entries in the intermediate results. The limit is 100, it
> can be changed if an user sets the indexThresholdSize to higher value when
> starting servers, but in many cases the user couldn't know how many entries
> will be in the region.
> So the best way is to set this indexThresholdSize to Integer.MAX_VALUE by
> default so the query will always give the correct results.
> The limit which is set in query is not the same as this limit, so with this
> change it will still put limit on printing results.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10352) Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10352: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode > documentation > --- > > Key: GEODE-10352 > URL: https://issues.apache.org/jira/browse/GEODE-10352 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The script to preview the documentation of Geode (./preview-user-guide.sh) is > not working anymore. > The following error appears while running it (unless you have a previously > downloaded geodedocs/temp docker image in your local docker repo): > ERROR: Error installing elasticsearch: > The last version of faraday (>= 0) to support your Ruby & RubyGems was > 1.10.0. Try installing it with `gem install faraday -v 1.10.0` and then > running the current command again > faraday requires Ruby version >= 2.6. The current ruby version is > 2.5.9.229. > That error prevents the preview script to work. > It is needed to update the docker image used to preview the documentation to > use a Ruby version >= 2.6 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-10351:
-
Assignee: Jinmei Liao
> [CI failure] ModifyColocationIntegrationTest > testModifyColocation
> ---
>
> Key: GEODE-10351
> URL: https://issues.apache.org/jira/browse/GEODE-10351
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> ModifyColocationIntegrationTest > testModifyColocation FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.IllegalStateException
> but was:
> org.apache.geode.cache.CacheClosedException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed., caused by
> org.apache.geode.cache.DiskAccessException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5221)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3123)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10350) volunteerForPrimary should proceed when being elector or knowing elector
[ https://issues.apache.org/jira/browse/GEODE-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-10350: - Assignee: Joris Melchior > volunteerForPrimary should proceed when being elector or knowing elector > > > Key: GEODE-10350 > URL: https://issues.apache.org/jira/browse/GEODE-10350 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Joris Melchior >Priority: Major > Labels: needsTriage > > Inside BucketAdvisor.volunteerForPrimary(), when current member is elector or > has profile for elector, then current member should proceed to volunteer for > primary bucket. > Current logic happened to be opposite. It might be due to careless code. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10349) Client connects to a new server socket should check its availability
[ https://issues.apache.org/jira/browse/GEODE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10349: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Client connects to a new server socket should check its availability > - > > Key: GEODE-10349 > URL: https://issues.apache.org/jira/browse/GEODE-10349 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > When client connects to a new server (or restarted server), it might > encounter SocketTimeoutException which could take 59 seconds. > To speed up, the idea is to check if the server address's is reachable with > smaller timeout. > If the server's address is not reachable, no need to block waiting for 59 > seconds (DEFAULT_SOCKET_CONNECT_TIMEOUT). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10349) Client connects to a new server socket should check its availability
[ https://issues.apache.org/jira/browse/GEODE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-10349: - Assignee: Xiaojian Zhou > Client connects to a new server socket should check its availability > - > > Key: GEODE-10349 > URL: https://issues.apache.org/jira/browse/GEODE-10349 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: needsTriage, pull-request-available > > When client connects to a new server (or restarted server), it might > encounter SocketTimeoutException which could take 59 seconds. > To speed up, the idea is to check if the server address's is reachable with > smaller timeout. > If the server's address is not reachable, no need to block waiting for 59 > seconds (DEFAULT_SOCKET_CONNECT_TIMEOUT). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-10106:
-
Assignee: (was: Hale Bales)
> CI Failure: CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer
> ---
>
> Key: GEODE-10106
> URL: https://issues.apache.org/jira/browse/GEODE-10106
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
> {noformat}
> CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer FAILED
> 11:49:39java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 11:49:39Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 11:49:39
> ---
> 11:49:39Found suspect string in 'dunit_suspect-vm4.log' at line 431
> 11:49:39
> 11:49:39[error 2022/03/05 19:49:36.075 UTC
> tid=55] Error in
> redundancy satisfier
> 11:49:39java.lang.NullPointerException
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
> 11:49:39 at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
> 11:49:39 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:49:39 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:49:39 at java.lang.Thread.run(Thread.java:750)
> 11:49:39at org.junit.Assert.fail(Assert.java:89)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> 11:49:39at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:49:39at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:49:39at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:49:39at java.lang.reflect.Method.invoke(Method.java:498)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> 11:49:39at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 11:49:39at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 11:49:39at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 11:49:39at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> 11:49:39at
[jira] [Updated] (GEODE-10279) Need to lock RVV and flush before backup
[ https://issues.apache.org/jira/browse/GEODE-10279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10279: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Need to lock RVV and flush before backup > > > Key: GEODE-10279 > URL: https://issues.apache.org/jira/browse/GEODE-10279 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > When using async disk writer, in memory RVV has contained all the operations > in async queue. The items in the async queue might not have completely > flushed to disk. So RVV mismatch with the entries' status. > When restored and GII, since RVVs are the same, no GII will be triggered. > Thus the data mismatched in different members. > To fix it, introduce a step to lock rvvs for all the regions of all the > diskstores that will be backup. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10250) The LockGrantor can grant a lock to a member that has left the distributed system
[ https://issues.apache.org/jira/browse/GEODE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10250: -- Labels: GeodeOperationAPI pull-request-available (was: pull-request-available) > The LockGrantor can grant a lock to a member that has left the distributed > system > - > > Key: GEODE-10250 > URL: https://issues.apache.org/jira/browse/GEODE-10250 > Project: Geode > Issue Type: Bug > Components: distributed lock service >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > If a member requests a distributed lock and then leaves the distributed > system, the grantor may grant that request and leave itself in a state where > the lock has been granted but the member has left. > Here are the steps: > # The lock requesting server requests a lock > # The grantor server is delayed in granting that lock > # The lock requesting server shutsdown in the meantime > # The grantor server finally grants the lock after it has released all locks > and pending requests for the lock requesting server > # The lock requesting server receives the lock response but drops it since > the thread pool has been already shutdown -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10250) The LockGrantor can grant a lock to a member that has left the distributed system
[ https://issues.apache.org/jira/browse/GEODE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10250: -- Labels: pull-request-available (was: needsTriage pull-request-available) > The LockGrantor can grant a lock to a member that has left the distributed > system > - > > Key: GEODE-10250 > URL: https://issues.apache.org/jira/browse/GEODE-10250 > Project: Geode > Issue Type: Bug > Components: distributed lock service >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > If a member requests a distributed lock and then leaves the distributed > system, the grantor may grant that request and leave itself in a state where > the lock has been granted but the member has left. > Here are the steps: > # The lock requesting server requests a lock > # The grantor server is delayed in granting that lock > # The lock requesting server shutsdown in the meantime > # The grantor server finally grants the lock after it has released all locks > and pending requests for the lock requesting server > # The lock requesting server receives the lock response but drops it since > the thread pool has been already shutdown -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9484) Data inconsistency in replicated region with 3 or more servers, and one server is down
[ https://issues.apache.org/jira/browse/GEODE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531896#comment-17531896 ] Anilkumar Gingade edited comment on GEODE-9484 at 5/4/22 6:58 PM: -- [~mivanac] Can you please revert these changes. Re-open the ticket, address the NPE with new additional tests. It will be very helpful; if you could revert this sooner; this could be masking other issues, that may not get surfaced. Or we may go ahead and revert these changes. was (Author: agingade): [~mivanac] Can you please revert these changes. Re-open the ticket, address the NPE with new additional tests. > Data inconsistency in replicated region with 3 or more servers, and one > server is down > --- > > Key: GEODE-9484 > URL: https://issues.apache.org/jira/browse/GEODE-9484 > Project: Geode > Issue Type: Improvement > Components: client/server, regions >Affects Versions: 1.13.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > We have configured replicated region with 3 or more servers, and client is > configured with read timeout set to value same or smaller than member timeout. > In case while client is putting data in region, one of replicated servers is > shutdown, it is observed that we have data inconsistency. > > We see that data part of data is written in server connected with client, but > in remaining replicated servers it is missing. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9484) Data inconsistency in replicated region with 3 or more servers, and one server is down
[ https://issues.apache.org/jira/browse/GEODE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531896#comment-17531896 ] Anilkumar Gingade edited comment on GEODE-9484 at 5/4/22 6:56 PM: -- [~mivanac] Can you please revert these changes. Re-open the ticket, address the NPE with new additional tests. was (Author: agingade): [~mivanac] Can you please revert these changes. Re-open the ticket, address the NPE with new additional tests. > Data inconsistency in replicated region with 3 or more servers, and one > server is down > --- > > Key: GEODE-9484 > URL: https://issues.apache.org/jira/browse/GEODE-9484 > Project: Geode > Issue Type: Improvement > Components: client/server, regions >Affects Versions: 1.13.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > We have configured replicated region with 3 or more servers, and client is > configured with read timeout set to value same or smaller than member timeout. > In case while client is putting data in region, one of replicated servers is > shutdown, it is observed that we have data inconsistency. > > We see that data part of data is written in server connected with client, but > in remaining replicated servers it is missing. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9484) Data inconsistency in replicated region with 3 or more servers, and one server is down
[ https://issues.apache.org/jira/browse/GEODE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531896#comment-17531896 ] Anilkumar Gingade commented on GEODE-9484: -- [~mivanac] Can you please revert these changes. Re-open the ticket, address the NPE with new additional tests. > Data inconsistency in replicated region with 3 or more servers, and one > server is down > --- > > Key: GEODE-9484 > URL: https://issues.apache.org/jira/browse/GEODE-9484 > Project: Geode > Issue Type: Improvement > Components: client/server, regions >Affects Versions: 1.13.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > We have configured replicated region with 3 or more servers, and client is > configured with read timeout set to value same or smaller than member timeout. > In case while client is putting data in region, one of replicated servers is > shutdown, it is observed that we have data inconsistency. > > We see that data part of data is written in server connected with client, but > in remaining replicated servers it is missing. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9484) Data inconsistency in replicated region with 3 or more servers, and one server is down
[ https://issues.apache.org/jira/browse/GEODE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531895#comment-17531895 ] Anilkumar Gingade commented on GEODE-9484: -- [~mivanac] The PR/Fix for this issue is showing up NPE in internal tests. Here is the stack trace: java.lang.NullPointerException at org.apache.geode.internal.tcp.TCPConduit.getFirstScanForConnection(TCPConduit.java:958) at org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:477) at org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:277) at org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:543) at org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348) at org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293) at org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067) at org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1994) at org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2031) at org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1088) at org.apache.geode.internal.cache.CreateRegionProcessor.initializeRegion(CreateRegionProcessor.java:115) at org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1176) at org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1107) at org.apache.geode.internal.cache.HARegion.initialize(HARegion.java:323) at org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3103) at org.apache.geode.internal.cache.HARegion.getInstance(HARegion.java:246) at org.apache.geode.internal.cache.ha.HARegionQueue.(HARegionQueue.java:365) at org.apache.geode.internal.cache.ha.HARegionQueue$BlockingHARegionQueue.(HARegionQueue.java:2233) at org.apache.geode.internal.cache.ha.HARegionQueue$DurableHARegionQueue.(HARegionQueue.java:2478) at org.apache.geode.internal.cache.ha.HARegionQueue.getHARegionQueueInstance(HARegionQueue.java:2015) at org.apache.geode.internal.cache.tier.sockets.MessageDispatcher.getMessageQueue(MessageDispatcher.java:166) at org.apache.geode.internal.cache.tier.sockets.MessageDispatcher.(MessageDispatcher.java:146) at org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.createMessageDispatcher(CacheClientProxy.java:1685) at org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.initializeMessageDispatcher(CacheClientProxy.java:1677) at org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.initializeProxy(CacheClientNotifier.java:502) at org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerClientInternal(CacheClientNotifier.java:406) at org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerClient(CacheClientNotifier.java:221) at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$ClientQueueInitializerTask.run(AcceptorImpl.java:1896) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeClientQueueInitializerThreadPool$1(AcceptorImpl.java:678) at org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at java.lang.Thread.run(Thread.java:750) > Data inconsistency in replicated region with 3 or more servers, and one > server is down > --- > > Key: GEODE-9484 > URL: https://issues.apache.org/jira/browse/GEODE-9484 > Project: Geode > Issue Type: Improvement > Components: client/server, regions >Affects Versions: 1.13.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > We have configured replicated region with 3 or more servers, and client is > configured with read timeout set to value same or smaller than member timeout. > In case while client is putting data in region, one of replicated servers is > shutdown, it is observed that we have data inconsistency. > > We see that
[jira] [Updated] (GEODE-10247) CI: spring-compatibility-test compile failure
[ https://issues.apache.org/jira/browse/GEODE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10247: -- Labels: needsTriage redis-triage (was: needsTriage) > CI: spring-compatibility-test compile failure > - > > Key: GEODE-10247 > URL: https://issues.apache.org/jira/browse/GEODE-10247 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage, redis-triage > > It's found in > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14671910 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643323 > ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (java-compile) > on project spring-data-geode: Compilation failure: Compilation failure: > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[103,43] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_BIND_ADDRESS > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[104,38] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_ENABLED > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[105,35] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_PORT > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[106,47] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_REDUNDANT_COPIES > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[107,39] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_USERNAME > [ERROR] location: interface ConfigurationProperties -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10059) CI: WANRollingUpgradeNewSenderProcessOldEvent > oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade resolved GEODE-10059.
---
Resolution: Cannot Reproduce
The issue did not reproduce in successive runs.
> CI: WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED
> -
>
> Key: GEODE-10059
> URL: https://issues.apache.org/jira/browse/GEODE-10059
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.13.8
>Reporter: Kristen
>Priority: Major
> Labels: needsTriage
>
>
> {code:java}
> > Task :geode-wan:upgradeTest
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
>
[jira] [Commented] (GEODE-10059) CI: WANRollingUpgradeNewSenderProcessOldEvent > oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521297#comment-17521297
]
Anilkumar Gingade commented on GEODE-10059:
---
Sounds related to environment issue. The test has passed in successive runs.
Closing this for now; we will re-open once this surfaces again.
> CI: WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.13.7] FAILED
> -
>
> Key: GEODE-10059
> URL: https://issues.apache.org/jira/browse/GEODE-10059
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.13.8
>Reporter: Kristen
>Priority: Major
> Labels: needsTriage
>
>
> {code:java}
> > Task :geode-wan:upgradeTest
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.4.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.5.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtTwoNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 5 running on Host
> 64b741e8194f with 7 VMs with version 1.3.0
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 5 running on
> Host 64b741e8194f with 7 VMs with version 1.3.0
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent >
> oldEventShouldBeProcessedAtNewSender[from_v1.6.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.IgnoredException$1.run
[jira] [Updated] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9889:
-
Labels: redis-triage (was: needsTriage)
> 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: redis-triage
>
> 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] [Updated] (GEODE-3492) ServerLauncherRemoteFileIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-3492:
-
Labels: IntegrationTest Windows (was: IntegrationTest Windows needsTriage)
> ServerLauncherRemoteFileIntegrationTest fails on Windows
>
>
> Key: GEODE-3492
> URL: https://issues.apache.org/jira/browse/GEODE-3492
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidReturnsStopped FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidReturnsStopped(ServerLauncherRemoteFileIntegrationTest.java:75)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidDeletesPidFile FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidDeletesPidFile(ServerLauncherRemoteFileIntegrationTest.java:63)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidStopsServerProcess FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
>
[jira] [Updated] (GEODE-8641) CI Failure: PartitionedIndexedQueryBenchmark.run
[
https://issues.apache.org/jira/browse/GEODE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-8641:
-
Labels: (was: needsTriage)
> CI Failure: PartitionedIndexedQueryBenchmark.run
>
>
> Key: GEODE-8641
> URL: https://issues.apache.org/jira/browse/GEODE-8641
> Project: Geode
> Issue Type: Test
> Components: benchmarks, tests
>Reporter: Jens Deppe
>Priority: Major
>
> Benchmarking looks like some internal error:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/406
> {noformat}
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9987) Mass-Test_Run: HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
[
https://issues.apache.org/jira/browse/GEODE-9987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9987:
-
Labels: pull-request-available (was: needsTriage pull-request-available)
> Mass-Test_Run: HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
>
>
> Key: GEODE-9987
> URL: https://issues.apache.org/jira/browse/GEODE-9987
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.HostedLocatorsDUnitTest$1.call in VM 3 running
> on Host
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal
> with 4 VMs
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm3.log' at line 458
> [fatal 2022/01/22 17:02:39.638 UTC receiver,heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204-65003> tid=125]
> Membership service failure: Member isn't responding to heartbeat requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1806)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1120)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:723)
> ...
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.HostedLocatorsDUnitTest$1.call in VM 3 running
> on Host
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.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:473)
> at
> org.apache.geode.distributed.HostedLocatorsDUnitTest.testGetAllHostedLocators(HostedLocatorsDUnitTest.java:92)
> Caused by:
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204(heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal_HostedLocatorsDUnitTest_testGetAllHostedLocators-3:115919:locator):59339
> started at Sat Jan 22 17:02:21 UTC 2022: Member isn't responding to
> heartbeat requests, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java: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
>
[jira] [Updated] (GEODE-10056) Gateway-reciver connection load mantained only on one locator
[
https://issues.apache.org/jira/browse/GEODE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10056:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Gateway-reciver connection load mantained only on one locator
> -
>
> Key: GEODE-10056
> URL: https://issues.apache.org/jira/browse/GEODE-10056
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
>
> The first problem is that servers send incorrect gateway-receiver connection
> load to locators with CacheServerLoadMessage. The second problem is that the
> locator doesn't refresh gateway-receivers load per server in the local map
> with the load received in CacheServerLoadMessage. This seems to be a bug, as
> there is already a mechanism to track and store gateway-receiver connection
> load per server in the locator, but that load is never refreshed by a fault
> at the reception of CacheServerLoadMessage. Currently, receiver load is only
> refreshed/increased on the locator that is handling
> ClientConnectionRequest\{group=__recv_group...} and ClientConnectionResponse
> messages from a remote server that is trying to establish gateway sender
> connection. All other locators in a cluster will never refresh the
> gateway-receiver connection load in this case. When the locator that was
> serving remote gateway-senders goes down then a new locator will take that
> job. Problem is that the new locator will not have a correct load (it was
> never refreshed) and that would in most situations result in new
> gateway-sender connections being established in an unbalanced way.
> Way to reproduce the issue:
> Start 2 clusters, Let's call site1 the sending and site2 the receiving site,
> The receiving site should have at least 2 locators. Both have 2 servers. No
> regions are needed.
> Cluster-1 gfsh>list members
> Member Count : 3Name | Id
> - | -
> locator10 | 10.0.2.15(locator10:7332:locator):41000 [Coordinator]
> server11 | 10.0.2.15(server11:8358):41003
> server12 | 10.0.2.15(server12:8717):41005
>
> Cluster-2 gfsh>list members
> Member Count : 4Name | Id
> - | -
> locator10 | 10.0.2.15(locator10:7562:locator):41001 [Coordinator]
> locator11 | 10.0.2.15(locator11:8103:locator):41002
> server11 | 10.0.2.15(server11:8547):41004
> server12 | 10.0.2.15(server12:8908):41006
>
> Create GW receiver in Site2 on both servers.
>
> Cluster-2 gfsh>list gateways
> GatewayReceiver Section Member | Port | Sender
> Count | Senders Connected
> -- | | | -
> 10.0.2.15(server11:8547):41004 | 5175 | 0 |
> 10.0.2.15(server12:8908):41006 | 5457 | 0 |
> Create GW sender in Site1 on both servers. Use 10 dispatcher threads for
> easier obervation.
> Cluster-1 gfsh>list gateways
> GatewaySender SectionGatewaySender Id | Member |
> Remote Cluster Id | Type | Status | Queued Events |
> Receiver Location
> | -- | - |
> | - | - | -
> senderTo2 | 10.0.2.15(server11:8358):41003 | 2 |
> Parallel | Running and Connected | 0 | 10.0.2.15:5457
> senderTo2 | 10.0.2.15(server12:8717):41005 | 2 |
> Parallel | Running and Connected | 0 | 10.0.2.15:5457
>
> Observe balance in GW receiver connections in Site2. It will be perfect.
>
> Cluster-2 gfsh>list gateways
> GatewayReceiver Section Member | Port | Sender
> Count | Senders Connected
> -- | | |
> -
> 10.0.2.15(server11:8547):41004 | 5175 | 12 |
> 10.0.2.15(server12:8717):41005, 10.0.2.15(server12:8717):41005,
> 10.0.2.15(server11:8358):41003, 10.0.2.15(server11:..
> 10.0.2.15(server12:8908):41006 | 5457 | 12 |
> 10.0.2.15(server12:8717):41005, 10.0.2.15(server12:8717):41005,
> 10.0.2.15(server12:8717):41005, 10.0.2.15(server12:..
>
> 12 connections each - 10 payload + 2 ping connections.
> Now stop GW receiver in one server of site2. In Site1 do a stop/start
> gateway-sender command - all connections will go to the only receiver in
> site2 (as expected). Check it:
>
> Cluster-2 gfsh>list gateways
> GatewayReceiver Section
[jira] [Updated] (GEODE-10095) TcrConnection::readHandshakeData reads too many bytes
[ https://issues.apache.org/jira/browse/GEODE-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10095: -- Labels: (was: needsTriage) > TcrConnection::readHandshakeData reads too many bytes > - > > Key: GEODE-10095 > URL: https://issues.apache.org/jira/browse/GEODE-10095 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Matthew Reddington >Priority: Major > > This method is called to read bytes from a socket, and return said data in a > `std::vector`. For some inexplicable (inexcusable?) reason, the > method always adds a 0 byte to the end of the vector, as if it were > null-terminating a string. So, `readHandshakeData(1)` returns 2 bytes, > `readHandshakeData(5)` returns 6 bytes, etc. > This is extremely misleading, given the name of the method and the fact that > the requested number of bytes is a parameter passed in. Also, in no > circumstance is this method used to actually read a string, i.e. something > that may require null-termination. Please remove the extra byte from the > returned vector, and if possible add a unit test to the suite that reads _n_ > bytes and asserts that the method always returns _n_ bytes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10012:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Avoid retries for non-HA function execution
> ---
>
> Key: GEODE-10012
> URL: https://issues.apache.org/jira/browse/GEODE-10012
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *GIVEN* a cluster with 3 servers and 1 locator
> *AND* a PartitionedRegion with redundant-copies="1"
> *AND* a user-defined Function with isHA=false
> *AND* a geode-native client with a pool with single-hop enabled and retry
> attempts set to 2
> *WHEN* execution fails due to a connectivity issue/connection
> timeout/internal cluster error
> *THEN* function is retried twice
>
> *Additional information.* The function is retried at the network code layer,
> and given whenever there is a timeout/connectivity error, the BSL is removed
> from the ClientMetadataService, whenever retries happen, you might get a
> *InternalFunctionInvocationTargetException* exception thrown indicating:
> {code:java}
> Multiple target nodes found for single hop operation {code}
> Also, have into account that Java client API behaviour never retries a
> Function Execution if isHA=false for that function, and whenever isHA=true,
> the function is retried but on the function execution logic and not at the
> networking layer.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10017:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9753: - Labels: pull-request-available (was: needsTriage pull-request-available) > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10217) Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10217:
--
Labels: (was: needsTriage)
> Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
> -
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
>
> Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
> Byte Buddy could not instrument all classes within the mock's type hierarchy.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
> 10:19:40at
>
[jira] [Updated] (GEODE-10208) Support branches fail to run geode-connectors acceptanceTests due to stale dependency
[
https://issues.apache.org/jira/browse/GEODE-10208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10208:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Support branches fail to run geode-connectors acceptanceTests due to stale
> dependency
> -
>
> Key: GEODE-10208
> URL: https://issues.apache.org/jira/browse/GEODE-10208
> Project: Geode
> Issue Type: Bug
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> Attempting to execute geode-connectors:acceptanceTests on support/1.12 or
> 1.13 results in failures with message:
> {noformat}
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No such
> image: quay.io/testcontainers/ryuk:0.2.3"}
> {noformat}
> These support branches are using testcontainers version 1.13. Versions prior
> to 1.14.3 are no longer available anywhere:
> https://stackoverflow.com/questions/61887363/testcontainers-cant-pull-ryuk-image-quay-io-is-not-reachable
> All branches need to be updated to use 1.14.3 or later.
> {noformat}
> > Task :geode-connectors:acceptanceTest
> org.apache.geode.connectors.jdbc.MySqlJdbcWriterIntegrationTest > classMethod
> FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.MySqlJdbcDistributedTest > classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.PostgresJdbcLoaderIntegrationTest >
> classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.internal.PostgresTableMetaDataManagerIntegrationTest
> > classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.internal.MySqlTableMetaDataManagerIntegrationTest
> > classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> > Task :geode-redis:acceptanceTest
> org.apache.geode.redis.ExpireNativeRedisAcceptanceTest > classMethod FAILED
> org.testcontainers.containers.ContainerLaunchException: Container startup
> failed
> at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:322)
> at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:302)
> at
> org.apache.geode.redis.ExpireNativeRedisAcceptanceTest.setUp(ExpireNativeRedisAcceptanceTest.java:43)
> Caused by:
> org.testcontainers.containers.ContainerFetchException: Can't get
> Docker image:
> RemoteDockerImage(imageNameFuture=java.util.concurrent.CompletableFuture@28de948a[Completed
> normally], imagePullPolicy=DefaultPullPolicy(),
> dockerClient=LazyDockerClient.INSTANCE)
> at
> org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1265)
> at
> org.testcontainers.containers.GenericContainer.logger(GenericContainer.java:600)
> at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:311)
> ... 2 more
> Caused by:
> com.github.dockerjava.api.exception.NotFoundException:
> {"message":"No such image: quay.io/testcontainers/ryuk:0.2.3"}
> at
> org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.execute(OkHttpInvocationBuilder.java:281)
> at
> org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.execute(OkHttpInvocationBuilder.java:265)
> at
> org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.post(OkHttpInvocationBuilder.java:136)
> at
> com.github.dockerjava.core.exec.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:33)
> at
> com.github.dockerjava.core.exec.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:13)
> at
> com.github.dockerjava.core.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> com.github.dockerjava.core.command.CreateContainerCmdImpl.exec(CreateContainerCmdImpl.java:1139)
> at
> org.testcontainers.utility.ResourceReaper.start(ResourceReaper.java:91)
> at
> org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:155)
>
[jira] [Commented] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517736#comment-17517736
]
Anilkumar Gingade commented on GEODE-10215:
---
[~jvarenina]Are you working/fixing on this issue.
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needsTriage
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10215:
--
Labels: needsTriage (was: needs)
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needsTriage
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10215:
--
Labels: needs (was: needsTriage)
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needs
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10188) AvailablePortHelperIntegrationTest > initializeUniquePortRange_returnSamePortsForSameRange gets different ports on subsequent tries
[
https://issues.apache.org/jira/browse/GEODE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10188:
--
Labels: (was: needsTriage)
> AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange gets different ports on
> subsequent tries
> ---
>
> Key: GEODE-10188
> URL: https://issues.apache.org/jira/browse/GEODE-10188
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.9
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14294054]
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange(useMembershipPortRange=true)
> FAILED
> org.junit.ComparisonFailure: expected:<[460[10, 46011, 4601]2]> but
> was:<[460[00, 46001, 4600]2]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_returnSamePortsForSameRange(AvailablePortHelperIntegrationTest.java:322)
> 4023 tests completed, 1 failed, 82 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-results/integrationTest/1648509410/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-artifacts/1648509410/integrationtestfiles-openjdk11-1.13.9-build.0668.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10205:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10189) Errors encountered during Apache Geode upgrade
[
https://issues.apache.org/jira/browse/GEODE-10189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10189:
--
Labels: (was: needsTriage)
> Errors encountered during Apache Geode upgrade
> --
>
> Key: GEODE-10189
> URL: https://issues.apache.org/jira/browse/GEODE-10189
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.1
>Reporter: Swetha Sudheesh
>Priority: Critical
>
> We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1*
> version to avoid any vulnerabilities. We also added all the dependencies
> mentioned in the Maven with the latest versions. Our application uses {*}JDK
> 11{*}. We faced few issues such as the one described below:
>
> Exception in thread "Locator" *java.lang.ExceptionInInitializerError*
> at
> org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)
> at
> org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)
> at
> org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
>
> Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the
> wrong class: UUID*
> at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167)
> ... 17 more
> Please let us know why we are encountering this error and how can it be
> resolved? Also let us know the right dependencies that need to be added for
> Apache Geode 1.14.1 upgrade.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10195) MicrometerBinderTest > processorMetricsBinderExists FAILED
[
https://issues.apache.org/jira/browse/GEODE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10195:
--
Labels: (was: needsTriage)
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> --
>
> Key: GEODE-10195
> URL: https://issues.apache.org/jira/browse/GEODE-10195
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
>
> windows-acceptance-test-openjdk11 failed with the following error.
>
> {noformat}
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-ceacbfa8-6147-51ca-affd-b497cd16e2ef(4420:loner):54545:7074b0d7:
> Function named CheckIfMeterExistsFunction is not registered to FunctionService
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377)
> at
> org.apache.geode.metrics.MicrometerBinderTest.processorMetricsBinderExists(MicrometerBinderTest.java:152)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10077) wan-copy region command does not prevent callbacks to be executed on the remote site
[ https://issues.apache.org/jira/browse/GEODE-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10077: -- Labels: pull-request-available (was: needsTriage pull-request-available) > wan-copy region command does not prevent callbacks to be executed on the > remote site > > > Key: GEODE-10077 > URL: https://issues.apache.org/jira/browse/GEODE-10077 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The wan-copy region command does not always prevent that callbacks are > executed at the remote site for the entries copied. > For example, if the remote site has more than one server and the gateway > receiver that gets the entries copied does not host the primary bucket of the > entry received, it will send the put operation to the server than hosts the > primary bucket and on this server, callbacks will be executed, provoking, for > example, that if a gateway sender is configured for the region, the event > will be sent by that gateway sender in the remote site. > Also, if the remote site has more than one server and the region has at least > one replica (either because it is a replicated region or because it is a > partitioned region with number of replicas greater than 1) then servers in > the remote site that receive an UpdateMessage from the server that received > the copied entry via the gateway receiver, would execute the callbacks, > provoking, like in the above case that if a gateway sender is configured for > the region, the event will be sent by that gateway sender in the remote site. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10187) PutAllGlobalDUnitTest > testputAllGlobalRemoteVM fails to receive expected TimeoutException
[
https://issues.apache.org/jira/browse/GEODE-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10187:
--
Labels: (was: needsTriage)
> PutAllGlobalDUnitTest > testputAllGlobalRemoteVM fails to receive expected
> TimeoutException
> ---
>
> Key: GEODE-10187
> URL: https://issues.apache.org/jira/browse/GEODE-10187
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.14.5
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14277444]
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.internal.cache.PutAllGlobalDUnitTest >
> testputAllGlobalRemoteVM FAILED
> java.lang.AssertionError: async2 failed
> at org.apache.geode.test.dunit.Assert.fail(Assert.java:66)
> at
> org.apache.geode.internal.cache.PutAllGlobalDUnitTest.testputAllGlobalRemoteVM(PutAllGlobalDUnitTest.java:215)
> Caused by:
> java.lang.AssertionError: Should have thrown TimeoutException
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.internal.cache.PutAllGlobalDUnitTest$2.run2(PutAllGlobalDUnitTest.java:193)
> 8805 tests completed, 1 failed, 455 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0942/test-results/distributedTest/1648360227/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0942/test-artifacts/1648360227/distributedtestfiles-openjdk11-1.14.5-build.0942.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10155: -- Labels: pull-request-available (was: needsTriage pull-request-available) > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > If a Geode client executes a server function with a timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10170) CI failure: DistributedSystemBridgeIntegrationTest > testPrepareErrorAbortsBackup
[
https://issues.apache.org/jira/browse/GEODE-10170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10170:
--
Labels: (was: needsTriage)
> CI failure: DistributedSystemBridgeIntegrationTest >
> testPrepareErrorAbortsBackup
> -
>
> Key: GEODE-10170
> URL: https://issues.apache.org/jira/browse/GEODE-10170
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> DistributedSystemBridgeIntegrationTest > testPrepareErrorAbortsBackup FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.RuntimeException
> but was:
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:333)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:307)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:264)
> ...(83 remaining lines not displayed - this can be changed with
> Assertions.setMaxStackTraceElementsDisplayed)
> at
> org.apache.geode.management.internal.beans.DistributedSystemBridgeIntegrationTest.testPrepareErrorAbortsBackup(DistributedSystemBridgeIntegrationTest.java:134)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10169) CI failure: DistributedSystemBridgeIntegrationTest > testSuccessfulBackup
[
https://issues.apache.org/jira/browse/GEODE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10169:
--
Labels: (was: needsTriage)
> CI failure: DistributedSystemBridgeIntegrationTest > testSuccessfulBackup
> -
>
> Key: GEODE-10169
> URL: https://issues.apache.org/jira/browse/GEODE-10169
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> DistributedSystemBridgeIntegrationTest > testSuccessfulBackup FAILED
> 17:57:56java.lang.ExceptionInInitializerError
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.fullAddCount(ConcurrentHashMap.java:2526)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2266)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1166)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap.expungeStaleEntries(WeakConcurrentMap.java:139)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap$WithInlinedExpunction.containsKey(WeakConcurrentMap.java:272)
> 17:57:56at
> org.mockito.internal.creation.bytebuddy.MockMethodAdvice.isMock(MockMethodAdvice.java:169)
> 17:57:56at
> org.mockito.internal.creation.bytebuddy.MockMethodAdvice.isMocked(MockMethodAdvice.java:174)
> 17:57:56at java.util.Properties.getProperty(Properties.java:969)
> 17:57:56at java.lang.System.getProperty(System.java:722)
> 17:57:56at java.lang.Long.getLong(Long.java:1208)
> 17:57:56at java.lang.Long.getLong(Long.java:1157)
> 17:57:56at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.(StoppableCountDownLatch.java:36)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:333)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:307)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:264)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:249)
> 17:57:56at
> org.apache.geode.internal.admin.remote.AdminMultipleReplyProcessor.(AdminMultipleReplyProcessor.java:32)
> 17:57:56at
> org.apache.geode.internal.admin.remote.MissingPersistentIDsRequest$MissingPersistentIDProcessor.(MissingPersistentIDsRequest.java:115)
> 17:57:56at
> org.apache.geode.internal.admin.remote.MissingPersistentIDsRequest$MissingPersistentIDProcessor.(MissingPersistentIDsRequest.java:108)
> 17:57:56at
> org.apache.geode.internal.admin.remote.MissingPersistentIDsRequest.send(MissingPersistentIDsRequest.java:55)
> 17:57:56at
> org.apache.geode.admin.internal.AdminDistributedSystemImpl.getMissingPersistentMembers(AdminDistributedSystemImpl.java:2226)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation$DefaultMissingPersistentMembersProvider.getMissingPersistentMembers(BackupOperation.java:147)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation.performBackupUnderLock(BackupOperation.java:89)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation.performBackup(BackupOperation.java:77)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation.backupAllMembers(BackupOperation.java:71)
> 17:57:56at
> org.apache.geode.management.internal.beans.DistributedSystemBridge.backupAllMembers(DistributedSystemBridge.java:489)
> 17:57:56at
> org.apache.geode.management.internal.beans.DistributedSystemBridgeIntegrationTest.testSuccessfulBackup(DistributedSystemBridgeIntegrationTest.java:113)
> 17:57:56
> 17:57:56Caused by:
> 17:57:56java.lang.NullPointerException
> 17:57:56at
> java.util.concurrent.ThreadLocalRandom.getProbe(ThreadLocalRandom.java:980)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.fullAddCount(ConcurrentHashMap.java:2526)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2266)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1166)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap.expungeStaleEntries(WeakConcurrentMap.java:139)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap$WithInlinedExpunction.containsKey(WeakConcurrentMap.java:272)
> 17:57:56at
>
[jira] [Updated] (GEODE-10168) CI failure: RestAPICompatibilityTest > restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible
[
https://issues.apache.org/jira/browse/GEODE-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10168:
--
Labels: (was: needsTriage)
> CI failure: RestAPICompatibilityTest >
> restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible
>
>
> Key: GEODE-10168
> URL: https://issues.apache.org/jira/browse/GEODE-10168
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> RestAPICompatibilityTest >
> restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible[1.13.0] FAILED
> 13:12:20java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 13:12:20Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 13:12:20
> ---
> 13:12:20Found suspect string in 'dunit_suspect-vm1.log' at line 511
> 13:12:20
> 13:12:20[fatal 2022/03/24 20:11:53.071 UTC receiver,heavy-lifter-8ca77d83-23cd-5773-ab23-a0729142416f-17781> tid=55]
> Membership service failure: Member isn't responding to heartbeat requests
> 13:12:20
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> 13:12:20 at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> 13:12:20 at org.jgroups.JChannel.up(JChannel.java:741)
> 13:12:20 at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> 13:12:20 at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 13:12:20 at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> 13:12:20 at
> org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> 13:12:20 at
> org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> 13:12:20 at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> 13:12:20 at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> 13:12:20 at
> org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> 13:12:20 at
> org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> 13:12:20 at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> 13:12:20 at org.jgroups.protocols.TP.receive(TP.java:1714)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> 13:12:20 at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> 13:12:20 at java.base/java.lang.Thread.run(Thread.java:829)
> 13:12:20at org.junit.Assert.fail(Assert.java:89)
> 13:12:20at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 13:12:20at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 13:12:20at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 13:12:20at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> 13:12:20at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> 13:12:20at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> 13:12:20at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 13:12:20at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 13:12:20at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 13:12:20at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 13:12:20at
>
[jira] [Updated] (GEODE-10167) CI failure: RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled > luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
[
https://issues.apache.org/jira/browse/GEODE-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10167:
--
Labels: (was: needsTriage)
> CI failure:
> RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> > luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> ---
>
> Key: GEODE-10167
> URL: https://issues.apache.org/jira/browse/GEODE-10167
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> >
> luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled[from_v1.8.0,
> with reindex=false, singleHopEnabled=true] FAILED
> 00:24:01org.gradle.internal.exceptions.DefaultMultiCauseException:
> Multiple Failures (2 failures)
> 00:24:01 org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeTestBase$$Lambda$422/0x000100379c40.run
> in VM 2 running on Host
> heavy-lifter-138290eb-3fbe-5801-8565-60d3c24284e9.c.apachegeode-ci.internal
> with 4 VMs
> 00:24:01 java.lang.AssertionError: Suspicious strings were written to
> the log during this run.
> 00:24:01Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:24:01
> ---
> 00:24:01Found suspect string in 'dunit_suspect-vm2.log' at line 3243
> 00:24:01
> 00:24:01[fatal 2022/03/25 07:23:55.137 UTC receiver,heavy-lifter-138290eb-3fbe-5801-8565-60d3c24284e9-23002> tid=49]
> Membership service failure: Member isn't responding to heartbeat requests
> 00:24:01
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1806)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1120)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:723)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1367)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1303)
> 00:24:01 at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> 00:24:01 at org.jgroups.JChannel.up(JChannel.java:741)
> 00:24:01 at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> 00:24:01 at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 00:24:01 at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> 00:24:01 at
> org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> 00:24:01 at
> org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> 00:24:01 at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> 00:24:01 at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> 00:24:01 at
> org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> 00:24:01 at
> org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> 00:24:01 at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> 00:24:01 at org.jgroups.protocols.TP.receive(TP.java:1714)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160)
> 00:24:01 at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> 00:24:01 at java.base/java.lang.Thread.run(Thread.java:829)
> 00:24:01at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> 00:24:01at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> 00:24:01at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> 00:24:01at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> 00:24:01at
>
[jira] [Updated] (GEODE-10176) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
[
https://issues.apache.org/jira/browse/GEODE-10176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10176:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
> ---
>
> Key: GEODE-10176
> URL: https://issues.apache.org/jira/browse/GEODE-10176
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
> FAILED
> 15:29:54org.junit.ComparisonFailure: [channel subscription was not
> received]
> 15:29:54Expecting value to be true but was false expected:<[tru]e> but
> was:<[fals]e>
> 15:29:54at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 15:29:54at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 15:29:54at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 15:29:54at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher(PubSubDUnitTest.java:225)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/distributedTest/1648080229/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648080229/distributedtestfiles-openjdk8-1.14.5-build.0938.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10177) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers
[
https://issues.apache.org/jira/browse/GEODE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10177:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers
>
>
> Key: GEODE-10177
> URL: https://issues.apache.org/jira/browse/GEODE-10177
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers
> FAILED
> 15:35:00org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest that uses
> java.util.concurrent.Future null within 5 minutes.
> 15:35:00at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 15:35:00at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 15:35:00at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 15:35:00at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 15:35:00at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 15:35:00at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers(PubSubDUnitTest.java:319)
> 15:35:00
> 15:35:00Caused by:
> 15:35:00java.util.concurrent.TimeoutException
> 15:35:00at
> java.util.concurrent.FutureTask.get(FutureTask.java:205)
> 15:35:00at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
> 15:35:00at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
> 15:35:00at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:101)
> 15:35:00... 5 more {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10175) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
[
https://issues.apache.org/jira/browse/GEODE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10175:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
> -
>
> Key: GEODE-10175
> URL: https://issues.apache.org/jira/browse/GEODE-10175
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
> FAILED
> 15:29:24org.junit.ComparisonFailure: [channel subscription was not
> received]
> 15:29:24Expecting value to be true but was false expected:<[tru]e> but
> was:<[fals]e>
> 15:29:24at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 15:29:24at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 15:29:24at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 15:29:24at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher(PubSubDUnitTest.java:255)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/distributedTest/1648080229/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648080229/distributedtestfiles-openjdk8-1.14.5-build.0938.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9664) Two different clients with the same durable id will both connect to the servers and receive messages
[
https://issues.apache.org/jira/browse/GEODE-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9664:
-
Labels: (was: needsTriage)
> Two different clients with the same durable id will both connect to the
> servers and receive messages
>
>
> Key: GEODE-9664
> URL: https://issues.apache.org/jira/browse/GEODE-9664
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Barrett Oglesby
>Priority: Major
>
> There are two cases:
> # The number of queues is the same as the number of servers (e.g. client
> with subscription-redundancy=1 and 2 servers)
> # The number of queues is less than the number of servers (e.g. client with
> subscription-redundancy=0 and 2 servers)
> h2. Case 1
> In this case, the client first attempts to connect to the primary and fails.
> {noformat}
> [warn 2021/10/01 14:37:56.209 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal about to
> register
> clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300])
> [warn 2021/10/01 14:37:56.209 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61581; primary=true; version=GEODE 1.15.0]
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing
> proxy isPaused=false
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] The requested durable client has the same identifier (
> client-a ) as an existing durable client (
> CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61581; primary=true; version=GEODE 1.15.0] ). Duplicate
> durable clients are not allowed.
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] CacheClientNotifier: Unsuccessfully registered client
> with identifier
> identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]) and response code 64
> {noformat}
> It then attempts to connect to the secondary and succeeds.
> {noformat}
> [warn 2021/10/01 14:37:56.215 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal about to
> register
> clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300])
> [warn 2021/10/01 14:37:56.215 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61578; primary=false; version=GEODE 1.15.0]
> [warn 2021/10/01 14:37:56.216 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal existing
> proxy isPaused=true
> [warn 2021/10/01 14:37:56.217 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal
> reinitialized existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61578; primary=true; version=GEODE 1.15.0]
> {noformat}
> The previous secondary is reinitialized and made into a primary. Both queues
> will dispatch events.
> The CacheClientNotifier.registerClientInternal method invoked when a client
> connects does:
> {noformat}
> if (cacheClientProxy.isPaused()) {
> ...
> cacheClientProxy.reinitialize(...);
> } else {
> unsuccessfulMsg = String.format("The requested durable client has the same
> identifier ( %s ) as an existing durable client...);
> logger.warn(unsuccessfulMsg);
> }
> {noformat}
> The CacheClientProxy is paused when the durable client it represents has
> disconnected. Unfortunately, a secondary CacheClientProxy is also paused. So,
> this check is not good enough to prevent a duplicate durable client from
> connecting.
> There are a few things that can also be checked. One of them is:
> {noformat}
> cacheClientProxy.getCommBuffer() == null
> {noformat}
> With that check added, when the client attempts to connect to the secondary,
> it fails just like the it does with the primary.
> The client then exits with this exception:
[jira] [Updated] (GEODE-10174) CI Failure: PubSubDUnitTest > testConcurrentPubSub
[
https://issues.apache.org/jira/browse/GEODE-10174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10174:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest > testConcurrentPubSub
> --
>
> Key: GEODE-10174
> URL: https://issues.apache.org/jira/browse/GEODE-10174
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> testConcurrentPubSub FAILED
> 15:28:39java.util.concurrent.ExecutionException:
> redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> 15:28:39
> 15:28:39Caused by:
> 15:28:39redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> 15:28:39at
> redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:205)
> 15:28:39at
> redis.clients.jedis.util.RedisInputStream.readByte(RedisInputStream.java:43)
> 15:28:39at redis.clients.jedis.Protocol.process(Protocol.java:155)
> 15:28:39at redis.clients.jedis.Protocol.read(Protocol.java:220)
> 15:28:39at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:283)
> 15:28:39at
> redis.clients.jedis.Connection.getIntegerReply(Connection.java:225)
> 15:28:39at redis.clients.jedis.Jedis.publish(Jedis.java:2908)
> 15:28:39at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.lambda$testConcurrentPubSub$16(PubSubDUnitTest.java:373)
> 15:28:39
> 15:28:39Caused by:
> 15:28:39java.net.SocketTimeoutException: Read timed out
> 15:28:39at java.net.SocketInputStream.socketRead0(Native
> Method)
> 15:28:39at
> java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> 15:28:39at
> java.net.SocketInputStream.read(SocketInputStream.java:171)
> 15:28:39at
> java.net.SocketInputStream.read(SocketInputStream.java:141)
> 15:28:39at
> java.net.SocketInputStream.read(SocketInputStream.java:127)
> 15:28:39at
> redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:199)
> 15:28:39... 7 more
> 15:29:24 {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9744) bug like CVE-2020-8908
[ https://issues.apache.org/jira/browse/GEODE-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9744: - Labels: pull-request-available (was: needsTriage pull-request-available) > bug like CVE-2020-8908 > -- > > Key: GEODE-9744 > URL: https://issues.apache.org/jira/browse/GEODE-9744 > Project: Geode > Issue Type: Bug >Reporter: lujie >Priority: Major > Labels: pull-request-available > > see [https://www.cvedetails.com/cve/CVE-2020-8908/] > A temp directory creation vulnerability exists in all versions of Guava, > allowing an attacker with access to the machine to potentially access data in > a temporary directory created by the Guava API > com.google.common.io.Files.createTempDir(). By default, on unix-like systems, > the created directory is world-readable (readable by an attacker with access > to the system). The method in question has been marked > [@deprecated|https://github.com/deprecated] in versions 30.0 and later and > should not be used. For Android developers, we recommend choosing a temporary > directory API provided by Android, such as context.getCacheDir(). For other > Java developers, we recommend migrating to the Java 7 API > java.nio.file.Files.createTempDirectory() which explicitly configures > permissions of 700, or configuring the Java runtime's java.io.tmpdir system > property to point to a location whose permissions are appropriately > configured. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10081) Freeze during launch of locator
[ https://issues.apache.org/jira/browse/GEODE-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10081: -- Labels: (was: needsTriage) > Freeze during launch of locator > --- > > Key: GEODE-10081 > URL: https://issues.apache.org/jira/browse/GEODE-10081 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.14.2 >Reporter: Julien Gilles >Priority: Major > Attachments: jstackout.txt > > > We are using gfsh with a script to automatically launch a locator and a > server. > During the launch of the locator, the process gfsh just freezes randomly. The > locator process is forked, but gfsh remains frozen. > A jstack on the process shows that the process is stuck on an internal > NativeLibrary.load call. This one happens when gfsh try to attach to the > process : internally the jvm loads the libattach.so library, but the call > never return. > To be complete, Geode is here deployed inside a docker container, using ubi8 > as base image, java is jdk11.0.11 - we have tested with 11.0.13, same issue. > > The stack is the following (full jstack dump attached) > "main" #1 prio=5 os_prio=0 cpu=2402.78ms elapsed=1924.45s allocated=236M > defined_classes=10346 tid=0x7fc904024000 nid=0x16 runnable > [0x7fc90a84a000] > java.lang.Thread.State: RUNNABLE > at java.lang.ClassLoader$NativeLibrary.load0(java.base@11.0.11/Native > Method) > at java.lang.ClassLoader$NativeLibrary.load(java.base@11.0.11/Unknown > Source) > at > java.lang.ClassLoader$NativeLibrary.loadLibrary(java.base@11.0.11/Unknown > Source) > - locked <0x823efe60> (a java.util.HashSet) > at java.lang.ClassLoader.loadLibrary0(java.base@11.0.11/Unknown Source) > at java.lang.ClassLoader.loadLibrary(java.base@11.0.11/Unknown Source) > at java.lang.Runtime.loadLibrary0(java.base@11.0.11/Unknown Source) > - locked <0x828224b8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(java.base@11.0.11/Unknown Source) > at > sun.tools.attach.VirtualMachineImpl.(jdk.attach@11.0.11/Unknown > Source) > at > sun.tools.attach.AttachProviderImpl.attachVirtualMachine(jdk.attach@11.0.11/Unknown > Source) > at com.sun.tools.attach.VirtualMachine.attach(jdk.attach@11.0.11/Unknown > Source) > at > org.apache.geode.internal.process.MBeanProcessController.getJMXServiceURL(MBeanProcessController.java:227) > at > org.apache.geode.internal.process.MBeanProcessController.connect(MBeanProcessController.java:192) > at > org.apache.geode.internal.process.MBeanProcessController.invokeOperationOnTargetMBean(MBeanProcessController.java:159) > at > org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:136) > at > org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:81) > at > org.apache.geode.internal.process.MBeanOrFileProcessController.status(MBeanOrFileProcessController.java:37) > at > org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:1012) > at > org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:940) > at > org.apache.geode.distributed.LocatorLauncher$LocatorState.fromDirectory(LocatorLauncher.java:2077) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.doStartLocator(StartLocatorCommand.java:267) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.startLocator(StartLocatorCommand.java:133) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.11/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.11/Unknown > Source) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.11/Unknown > Source) > at java.lang.reflect.Method.invoke(java.base@11.0.11/Unknown Source) > at > org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:139) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:149) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10003) Support JDK 17 on Geode
[ https://issues.apache.org/jira/browse/GEODE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10003: -- Labels: jdk17 (was: ) > Support JDK 17 on Geode > --- > > Key: GEODE-10003 > URL: https://issues.apache.org/jira/browse/GEODE-10003 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Priority: Major > Labels: jdk17 > > JDK 17 Schedule: [https://openjdk.java.net/projects/jdk/17/] > The first ticket to suggest going beyond JDK8 was GEODE-3. Now that JDK17 is > LTS, and Spring and other users are embracing JDK17, Geode should at least > run (if not compile) on JDK17. > This may take a lot of work, possibly requiring a new major release. Please > add subtasks to this ticket as necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10036:
--
Labels: jdk17 (was: needsTriage)
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: jdk17
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10037: -- Labels: (was: needsTriage) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Minor > > For the same reasons that were stated in GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10115:
--
Labels: (was: needsTriage)
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Reporter: Lynn Gallinat
>Priority: Major
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10132) org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest Failed
[ https://issues.apache.org/jira/browse/GEODE-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10132: -- Labels: (was: needsTriage) > org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest > Failed > - > > Key: GEODE-10132 > URL: https://issues.apache.org/jira/browse/GEODE-10132 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Eric Shu >Priority: Major > > cannotStopServerByNameWhenNotConnected > org.opentest4j.AssertionFailedError: [Exit value from process started by > [fcdfe561432081bf: gfsh -e start locator --name=locator -e start server > --name=server --server-port=0]] > expected: 0 > but was: 1 > 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.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:129) > at > org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:32) > 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.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at > org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) > at > org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) > at > org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52) > at > org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96) > at > org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75) > at >
[jira] [Updated] (GEODE-10143) ClusterStartupRule.withLogFile does not seem to work as described in comment
[ https://issues.apache.org/jira/browse/GEODE-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10143: -- Labels: GeodeOperationAPI (was: GeodeOperationAPI needsTriage) > ClusterStartupRule.withLogFile does not seem to work as described in comment > > > Key: GEODE-10143 > URL: https://issues.apache.org/jira/browse/GEODE-10143 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.14.4 >Reporter: Joris Melchior >Priority: Minor > Labels: GeodeOperationAPI > > ClusterStartupRule.withLogFile method comment describes that using the flag > will redirect output from standard out to log files. When used this does not > seem to be the case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10156) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10156: -- Labels: (was: needsTriage) > RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] > FAILED > - > > Key: GEODE-10156 > URL: https://issues.apache.org/jira/browse/GEODE-10156 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Eric Shu >Priority: Major > > org.opentest4j.AssertionFailedError: [Exit value from process started by > [4f44cb7de3b710f1: gfsh -e start locator --name=loc1 --port=20846 > --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20847 -e start locator > --name=loc2 --port=20848 --http-service-port=0 --locators=localhost[20846] > --J=-Dgemfire.jmx-manager-port=20849 -e start server --name=server1 > --server-port=20850 --locators=localhost[20846] -e start server > --name=server2 --server-port=20851 --locators=localhost[20846] -e deploy > --dir=/tmp/junit4947263696282150978/junit6257623670577599443]] > expected: 0 > but was: 1 > 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.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) > at > org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153) > at > org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:93) > 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.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at > org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) > at > org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) > at >
[jira] [Updated] (GEODE-9789) CI Failure: ConnectCommandWithSSLMultiKeyTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9789:
-
Labels: (was: needsTriage)
> CI Failure: ConnectCommandWithSSLMultiKeyTest > classMethod FAILED
> --
>
> Key: GEODE-9789
> URL: https://issues.apache.org/jira/browse/GEODE-9789
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Jens Deppe
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/windows-gfsh-distributed-test-openjdk8/builds/49
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLMultiKeyTest
> > classMethod FAILED
> 19:03:00org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 0
> running on Host
> heavy-lifter-b81c90cf-1834-5764-b07d-52bb4df9d090.c.apachegeode-ci.internal
> with 4 VMs
> 19:03:00at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 19:03:00at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> 19:03:00at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:225)
> 19:03:00at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:218)
> 19:03:00at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLMultiKeyTest.beforeClass(ConnectCommandWithSSLMultiKeyTest.java:80)
> 19:03:00
> 19:03:00Caused by:
> 19:03:00org.apache.geode.GemFireConfigException: Unable to join the
> distributed system. Operation either timed out, was stopped or Locator does
> not exist. {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0297/test-results/distributedTest/1635475233/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0297/test-artifacts/1635475233/windows-gfshdistributedtest-openjdk8-1.12.6-build.0297.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9989) add a few info level logs in PersistenceAdvisorImpl to identify splitbrain issue
[
https://issues.apache.org/jira/browse/GEODE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9989:
-
Labels: (was: needsTriage)
> add a few info level logs in PersistenceAdvisorImpl to identify splitbrain
> issue
>
>
> Key: GEODE-9989
> URL: https://issues.apache.org/jira/browse/GEODE-9989
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
>
> In scenario like:
> {code:java}
> 03:33:03.644 dataStoregemfire4_4494 recovered from disk
> 03:33:03.732 dataStoregemfire4_4494 closing
> 03:33:03.735 dataStoregemfire4_4494 Initialization of region replicate_5
> completed, send newId(let’s name it 4494) to gemfire2
> 03:33:03.754 dataStoregemfire2_4493 recovered from disk
> 03:33:03.770 dataStoregemfire2_4493 closing
> 03:33:03.792 dataStoregemfire2_4493 Initialization of region replicate_5
> completed. send newId(let’s name is 4493) to gemfire4, but gemfire4 is
> offline. So gemfire4 does not know gemfire2’s newId 4493.
> 03:34:11.247 gemfire4_9779 restarted, it does not know 4493
> 03:34:11.269 gemfire2_9856 restarted, it sends oldId=4493, newId=9856 to
> gemfire4, but gemfire4 does not know either of gemfire2’s oldId and newId
> When gemfire2_9856 asked gemfire4_9779 for its state, gemfire4_9779 replied
> "I don't know you", then gemfire2_9856's starting ends with
> ConflictingPersistentDataException.
> {code}
> We need more log to identify the issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9777) CI failure: QueryConfigurationServiceConstraintsDistributedTest queriesInFlightExecutedByClientsShouldNotBeAffectedWhenMethodAuthorizerIsChanged(RegionType:PARTITION) FAI
[ https://issues.apache.org/jira/browse/GEODE-9777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9777: - Labels: (was: needsTriage) > CI failure: QueryConfigurationServiceConstraintsDistributedTest > queriesInFlightExecutedByClientsShouldNotBeAffectedWhenMethodAuthorizerIsChanged(RegionType:PARTITION) > FAILED > - > > Key: GEODE-9777 > URL: https://issues.apache.org/jira/browse/GEODE-9777 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > > cause of the failure was: AuthenticationRequiredException: Failed to find the > authenticated user -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest fails due to PoolImpl.getRedundantNames() not returning expected servers
[
https://issues.apache.org/jira/browse/GEODE-9785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9785:
-
Labels: (was: needsTriage)
> CI Failure: RedundancyLevelPart2DUnitTest fails due to
> PoolImpl.getRedundantNames() not returning expected servers
> --
>
> Key: GEODE-9785
> URL: https://issues.apache.org/jira/browse/GEODE-9785
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Priority: Major
>
> {noformat}
> org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
> 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:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Updated] (GEODE-10065) Fix regexp in gnmsg for handshake messages
[ https://issues.apache.org/jira/browse/GEODE-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10065: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Fix regexp in gnmsg for handshake messages > -- > > Key: GEODE-10065 > URL: https://issues.apache.org/jira/browse/GEODE-10065 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > gnmsg tool has a bug in the regexp for handshake messages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10065) Fix regexp in gnmsg for handshake messages
[ https://issues.apache.org/jira/browse/GEODE-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10065: -- Component/s: native client > Fix regexp in gnmsg for handshake messages > -- > > Key: GEODE-10065 > URL: https://issues.apache.org/jira/browse/GEODE-10065 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: needsTriage, pull-request-available > > gnmsg tool has a bug in the regexp for handshake messages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9804: - Labels: pull-request-available (was: needsTriage pull-request-available) > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jacob Barrett >Priority: Major > Labels: pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9804: - Component/s: native client > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9711) Fix the typos in ConflationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9711: - Labels: pull-request-available (was: needsTriage pull-request-available) > Fix the typos in ConflationDUnitTestHelper > -- > > Key: GEODE-9711 > URL: https://issues.apache.org/jira/browse/GEODE-9711 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9880:
-
Labels: blocks-1.12.10 blocks-1.15.0 membership (was: blocks-1.12.10
blocks-1.15.0 blocks-1.15.0 membership)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9880:
-
Labels: blocks-1.12.10 blocks-1.15.0 blocks-1.15.0 membership (was:
blocks-1.12.10 blocks-1.15.0 membership)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10210) [CI Failure] : InternalConfigurationPersistenceServiceDeploymentTest > addSemanticAndPlainJarToThisLocator FAILED
[
https://issues.apache.org/jira/browse/GEODE-10210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10210:
--
Labels: windows (was: needsTriage windows)
> [CI Failure] : InternalConfigurationPersistenceServiceDeploymentTest >
> addSemanticAndPlainJarToThisLocator FAILED
> -
>
> Key: GEODE-10210
> URL: https://issues.apache.org/jira/browse/GEODE-10210
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: windows
>
> {code:java}
> InternalConfigurationPersistenceServiceDeploymentTest >
> addSemanticAndPlainJarToThisLocator FAILED
> java.lang.AssertionError:
> Expecting actual:
> ["abc-1.0.jar", "abc.jar", "def-1.0.jar"]
> to contain exactly in any order:
> ["abc.jar", "def-1.0.jar"]
> but the following elements were unexpected:
> ["abc-1.0.jar"]
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceServiceDeploymentTest.addSemanticAndPlainJarToThisLocator(InternalConfigurationPersistenceServiceDeploymentTest.java:173)
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Note:
> C:\\Users\\geode\\geode\\extensions\\geode-modules-test\\src\\main\\java\\org\\apache\\geode\\modules\\session\\AbstractSessionsTest.java
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note:
> C:\\Users\\geode\\geode\\extensions\\geode-modules-test\\src\\main\\java\\org\\apache\\geode\\modules\\session\\catalina\\AbstractDeltaSessionManagerTest.java
> uses unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details. {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10209:
--
Labels: (was: needsTriage)
> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
>
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
> in VM 0 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
> in VM 1 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
>
[jira] [Updated] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-7710:
-
Labels: GeodeOperationAPI flaky pull-request-available (was:
GeodeOperationAPI flaky needsTriage pull-request-available)
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> This test fails due to GEODE-7739. Enter new failures against that ticket.
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10200) [CI Failure] : SocketCreatorUpgradeTest > upgradingToNewGeodeAndNewJavaWithProtocolsAny[1.14.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-10200:
-
Assignee: Jacob Barrett
> [CI Failure] : SocketCreatorUpgradeTest >
> upgradingToNewGeodeAndNewJavaWithProtocolsAny[1.14.0] FAILED
> ---
>
> Key: GEODE-10200
> URL: https://issues.apache.org/jira/browse/GEODE-10200
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
>
> {code:java}
> SocketCreatorUpgradeTest >
> upgradingToNewGeodeAndNewJavaWithProtocolsAny[1.14.0] FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [1fa9fcaebd8c018e: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator2
> --bind-address=heavy-lifter-5c2a1d0b-5930-5788-97d6-3ca24d2f026a.c.apachegeode-ci.internal
> --port=21172 --J=-Dgemfire.jmx-manager-port=21173
> --security-properties-file=/tmp/junit1876902159761664930/junit7901411307157053608.tmp
>
> --locators=heavy-lifter-5c2a1d0b-5930-5788-97d6-3ca24d2f026a.c.apachegeode-ci.internal[21170]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:133)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsAny(SocketCreatorUpgradeTest.java:450)
> {code}
> In the logs we can see that there are a lot SSLv2Hello not supported errors.
> {code:java}
> [warn 2022/03/30 11:49:45.067 UTC locator2
> tid=0x38] SSL handshake exception
> javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled
> at
> sun.security.ssl.SSLEngineInputRecord.handleUnknownRecord(SSLEngineInputRecord.java:366)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:193)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
> at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:575)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:531)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:398)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:377)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:147)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:436)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1775)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1563)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1500)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748) {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10186) CI failure: RedundancyLevelPart1DUnitTest > testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU times out waiting for getClientProxies() to return more than 0 objects
[
https://issues.apache.org/jira/browse/GEODE-10186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10186:
--
Labels: (was: needsTriage)
> CI failure: RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU times out waiting for
> getClientProxies() to return more than 0 objects
> -
>
> Key: GEODE-10186
> URL: https://issues.apache.org/jira/browse/GEODE-10186
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14277358]
>
> {noformat}
> > Task :geode-core:distributedTest
> RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest$$Lambda$543/510122765.run
> in VM 2 running on Host
> heavy-lifter-f58561da-caf9-5bc0-a7fa-f938c3fd1e51.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU(RedundancyLevelPart1DUnitTest.java:284)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest
> that uses org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier
> Expecting actual:
> 0
> to be greater than:
> 0
> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.verifyInterestRegistration(RedundancyLevelPart1DUnitTest.java:505)
> Caused by:
> java.lang.AssertionError:
> Expecting actual:
> 0
> to be greater than:
> 0
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.lambda$verifyInterestRegistration$19(RedundancyLevelPart1DUnitTest.java:506)
> 8352 tests completed, 1 failed, 414 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1033/test-results/distributedTest/1648331031/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.1033/test-artifacts/1648331031/distributedtestfiles-openjdk8-1.15.0-build.1033.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10192) CI hang: testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
[
https://issues.apache.org/jira/browse/GEODE-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10192:
--
Labels: (was: needsTriage)
> CI hang:
> testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> ---
>
> Key: GEODE-10192
> URL: https://issues.apache.org/jira/browse/GEODE-10192
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> Hung here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/246#C]
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> timeout exceeded
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/integrationTest/1648477166/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648477166/integrationtestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
> The only test in the "started" state is:
>
> {noformat}
> |2.3.1| bburcham-a01 in
> ~/Downloads/integrationtestfiles-openjdk8-1.15.0-build.1035
> ○ → progress -s started
> org.apache.geode.internal.cache.DiskRandomOperationsAndRecoveryJUnitTest.testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> Iteration: 1
> Start: 2022-03-28 13:41:07.109 +
> End: 0001-01-01 00:00:00.000 +
> Duration: 0s
> Status: started
> {noformat}
> That JUnit test takes about 20s to run on a Macbook Pro.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10147) CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception while trying to run ssl benchmarks
[
https://issues.apache.org/jira/browse/GEODE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10147:
--
Labels: (was: needsTriage)
> CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception
> while trying to run ssl benchmarks
> --
>
> Key: GEODE-10147
> URL: https://issues.apache.org/jira/browse/GEODE-10147
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> P2pPartitionedPutBenchmark > run() FAILED
> net.schmizz.sshj.transport.TransportException: Connection reset
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.copyFromNode(SshInfrastructure.java:185)
> at
> org.apache.geode.perftest.jvms.RemoteJVMs.copyResults(RemoteJVMs.java:87)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:112)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> at
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark.run(P2pPartitionedPutBenchmark.java:52)
> Caused by:
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:186)
> at java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.net.SocketInputStream.read(SocketInputStream.java:200)
> at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> ... 8 more
> 4 tests completed, 1 failed
> This is ITERATION 2 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> ReplicatedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by:
> java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
> ... 6 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during identification exchange
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> ... 7 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during identification exchange
> at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:214)
> at
>
[jira] [Resolved] (GEODE-10107) CI Failure: ReplicateRegionNetsearchDistributedTest > proxyReplicateDoesNetsearchFromOnlyOneFullReplicate
[
https://issues.apache.org/jira/browse/GEODE-10107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade resolved GEODE-10107.
---
Resolution: Won't Fix
Closing i as infrastructure issue. The week this was reproduced was flaky. Will
open if it surfaces again.
> 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.15.0
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/]
>
> {noformat}
> ReplicateRegionNetsearchDistributedTest >
> proxyReplicateDoesNetsearchFromOnlyOneFullReplicate FAILED
> org.opentest4j.AssertionFailedError:
> expected: 1L
> but was: 0L
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.cache.ReplicateRegionNetsearchDistributedTest.proxyReplicateDoesNetsearchFromOnlyOneFullReplicate(ReplicateRegionNetsearchDistributedTest.java:391)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-results/distributedTest/1646476338/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0115/test-artifacts/1646476338/distributedtestfiles-openjdk8-1.16.0-build.0115.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-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
]
Anilkumar Gingade updated GEODE-10160:
--
Labels: pull-request-available redis-triage (was: blocks-1.15.0
pull-request-available)
> 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
>
> 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] [Updated] (GEODE-10171) AbstractRedisData version being incremented for no-op operations can lead to delta not being applied on secondary
[
https://issues.apache.org/jira/browse/GEODE-10171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10171:
--
Labels: pull-request-available redis-triage (was: blocks-1.15.0
pull-request-available)
> AbstractRedisData version being incremented for no-op operations can lead to
> delta not being applied on secondary
> -
>
> Key: GEODE-10171
> URL: https://issues.apache.org/jira/browse/GEODE-10171
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Kristen
>Priority: Major
> Labels: pull-request-available, redis-triage
>
> For SADD, which may or may not modify the data in the region depending on
> whether the member being added is already present in the set, the version in
> AbstractRedisData is updated regardless of whether a Delta is sent to the
> secondary. This can lead to the version on the primary wrapping around to be
> equal to the version on the secondary, which means that if a delta is sent,
> it will not be applied on the secondary, leading to potential data loss.
> Below is a test to show this behaviour:
> {code:java}
> @Test
> public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
> String originalMember = "fixedMemberName";
> String key = clusterStartUp.getKeyOnServer("tag", 1);
>
> // Version of primary = 0
> // Version of secondary = 0
> jedis.sadd(key, originalMember);
> // No changes are made to the set, since adding an already existing member
> doesn't modify it
> // Version of primary wraps around back to -1
> // Version of secondary doesn't change because we don't send a delta
> for (int i = 0; i < 255; ++i) {
> jedis.sadd(key, originalMember);
> }
> String newMember = "aNewMemberName";
> // Version of primary = 0
> // Version of secondary = 0, delta is not applied
> jedis.sadd(key, newMember);
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> clusterStartUp.crashVM(1); // kill primary server
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> } {code}
> The example here uses SADD, but potentially, any command that can be a no-op
> and uses a versioned Delta is at risk of hitting this. All commands should be
> checked to ensure they're not vulnerable to this bug.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10091) Benchmark instability in RedisZaddAndZremBenchmark
[
https://issues.apache.org/jira/browse/GEODE-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10091:
--
Labels: redis-triage (was: )
> Benchmark instability in RedisZaddAndZremBenchmark
> --
>
> Key: GEODE-10091
> URL: https://issues.apache.org/jira/browse/GEODE-10091
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Eric Zoerner
>Priority: Major
> Labels: redis-triage
>
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> RedisGetBenchmark avg ops/sec
> Baseline:428358.55 Test:446241.49 Difference: +4.2%
> avg latency
> Baseline: 1678809.55 Test: 1611045.34 Difference: -4.0%
> RedisHgetBenchmark avg ops/sec
> Baseline:438535.25 Test:441078.97 Difference: +0.6%
> avg latency
> Baseline: 1638968.92 Test: 1630999.16 Difference: -0.5%
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:191331.54 Test:186806.37 Difference: -2.4%
> avg latency
> Baseline: 3759694.09 Test: 3850396.04 Difference: +2.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:308079.41 Test:303715.78 Difference: -1.4%
> avg latency
> Baseline: 2332102.91 Test: 2367639.93 Difference: +1.5%
> RedisSetBenchmark avg ops/sec
> Baseline:318147.74 Test:326996.22 Difference: +2.8%
> avg latency
> Baseline: 2263687.57 Test: 2198181.68 Difference: -2.9%
> RedisWeightedHsetAndHgetBenchmark avg ops/sec
> Baseline:390383.79 Test:385565.48 Difference: -1.2%
> avg latency
> Baseline: 1842561.96 Test: 1864716.09 Difference: +1.2%
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:375078.82 Test:350886.03 Difference: -6.5%
> avg latency
> Baseline: 1917476.15 Test: 2049452.87 Difference: +6.9%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:124763.60 Test:118600.72 Difference: -4.9%
> avg latency
> Baseline: 5766048.34 Test: 6065491.13 Difference: +5.2%
> RedisZaddBenchmark avg ops/sec
> Baseline:432494.29 Test:438594.53 Difference: +1.4%
> avg latency
> Baseline: 1662639.09 Test: 1639906.18 Difference: -1.4%
> RedisZrangeBenchmark avg ops/sec
> Baseline:295523.77 Test:340381.87 Difference: +15.2%
> avg latency
> Baseline: 2433250.54 Test: 2112961.66 Difference: -13.2%
> RedisZrangeByScoreBenchmark avg ops/sec
> Baseline:285836.33 Test:356142.91 Difference: +24.6%
> avg latency
> Baseline: 2515708.23 Test: 2019249.68 Difference: -19.7%
> This is ITERATION 2 of benchmarking against baseline.
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:358570.33 Test:348012.02 Difference: -2.9%
> avg latency
> Baseline: 2005804.05 Test: 2066535.24 Difference: +3.0%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:122900.38 Test:115226.22 Difference: -6.2%
> avg latency
> Baseline: 5858357.13 Test: 6243018.38 Difference: +6.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:125677.36 Test:118359.94 Difference: -5.8%
> avg latency
> Baseline: 5721859.26 Test: 6082944.28 Difference: +6.3%
> This is ITERATION 4 of benchmarking against baseline.
>
[jira] [Updated] (GEODE-10091) Benchmark instability in RedisZaddAndZremBenchmark
[
https://issues.apache.org/jira/browse/GEODE-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10091:
--
Labels: (was: needsTriage)
> Benchmark instability in RedisZaddAndZremBenchmark
> --
>
> Key: GEODE-10091
> URL: https://issues.apache.org/jira/browse/GEODE-10091
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Eric Zoerner
>Priority: Major
>
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> RedisGetBenchmark avg ops/sec
> Baseline:428358.55 Test:446241.49 Difference: +4.2%
> avg latency
> Baseline: 1678809.55 Test: 1611045.34 Difference: -4.0%
> RedisHgetBenchmark avg ops/sec
> Baseline:438535.25 Test:441078.97 Difference: +0.6%
> avg latency
> Baseline: 1638968.92 Test: 1630999.16 Difference: -0.5%
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:191331.54 Test:186806.37 Difference: -2.4%
> avg latency
> Baseline: 3759694.09 Test: 3850396.04 Difference: +2.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:308079.41 Test:303715.78 Difference: -1.4%
> avg latency
> Baseline: 2332102.91 Test: 2367639.93 Difference: +1.5%
> RedisSetBenchmark avg ops/sec
> Baseline:318147.74 Test:326996.22 Difference: +2.8%
> avg latency
> Baseline: 2263687.57 Test: 2198181.68 Difference: -2.9%
> RedisWeightedHsetAndHgetBenchmark avg ops/sec
> Baseline:390383.79 Test:385565.48 Difference: -1.2%
> avg latency
> Baseline: 1842561.96 Test: 1864716.09 Difference: +1.2%
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:375078.82 Test:350886.03 Difference: -6.5%
> avg latency
> Baseline: 1917476.15 Test: 2049452.87 Difference: +6.9%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:124763.60 Test:118600.72 Difference: -4.9%
> avg latency
> Baseline: 5766048.34 Test: 6065491.13 Difference: +5.2%
> RedisZaddBenchmark avg ops/sec
> Baseline:432494.29 Test:438594.53 Difference: +1.4%
> avg latency
> Baseline: 1662639.09 Test: 1639906.18 Difference: -1.4%
> RedisZrangeBenchmark avg ops/sec
> Baseline:295523.77 Test:340381.87 Difference: +15.2%
> avg latency
> Baseline: 2433250.54 Test: 2112961.66 Difference: -13.2%
> RedisZrangeByScoreBenchmark avg ops/sec
> Baseline:285836.33 Test:356142.91 Difference: +24.6%
> avg latency
> Baseline: 2515708.23 Test: 2019249.68 Difference: -19.7%
> This is ITERATION 2 of benchmarking against baseline.
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:358570.33 Test:348012.02 Difference: -2.9%
> avg latency
> Baseline: 2005804.05 Test: 2066535.24 Difference: +3.0%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:122900.38 Test:115226.22 Difference: -6.2%
> avg latency
> Baseline: 5858357.13 Test: 6243018.38 Difference: +6.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:125677.36 Test:118359.94 Difference: -5.8%
> avg latency
> Baseline: 5721859.26 Test: 6082944.28 Difference: +6.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisZaddAndZremBenchmark avg
[jira] [Commented] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511454#comment-17511454 ] Anilkumar Gingade commented on GEODE-10148: --- >From Barry: >> The communication between servers and the JMX manager (locator) is async (a >> no-ack region). This test is most likely failing because of that. > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-10121:
-
Assignee: (was: Anilkumar Gingade)
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-10121:
-
Assignee: Anilkumar Gingade
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: blocks-1.15.0
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9704) When durable clients recovers, it sends "ready for event" signal before register for interest, this might cause problem for caching_proxy regions
[ https://issues.apache.org/jira/browse/GEODE-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade resolved GEODE-9704. -- Resolution: Won't Fix > When durable clients recovers, it sends "ready for event" signal before > register for interest, this might cause problem for caching_proxy regions > - > > Key: GEODE-9704 > URL: https://issues.apache.org/jira/browse/GEODE-9704 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.1, pull-request-available > > This is the old Geode behavior, but may or may not be the correct behavior. > When durable clients recovers, there is a queueTimer thread that runs > `QueueManagerImp.recoverPrimary` method, it > * makes new connection to server > - sends readyForEvents (which will cause the server to start sending the > queued events) > - recovers interest > - clears the region of keys of interest > - re-registers interest > It sends readyForEvents before it clears region of keys of interest, if > server sends some events of those keys in between, it will clear them, thus > it seems to the user that the client region doesn't have those keys. > > Run geode-core distributedTest > AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(), > change the InterestResultPolicy to NONE, you would see the test would fail > occasionally, Adding sleep code in QueueManagerImp.recoverPrimary between > `createNewPrimary` and `recoverInterest` would make the test fail more > consistently. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10144: -- Affects Version/s: 1.15.0 > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-10144: - Assignee: Jinmei Liao > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10118) PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in clearShouldFailWhenCoordinatorMemberIsBounced
[ https://issues.apache.org/jira/browse/GEODE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10118: -- Labels: (was: needsTriage) > PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in > clearShouldFailWhenCoordinatorMemberIsBounced > --- > > Key: GEODE-10118 > URL: https://issues.apache.org/jira/browse/GEODE-10118 > Project: Geode > Issue Type: Sub-task >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Priority: Major > > In PR Clear feature branch, after rebase merged in GEODE-9522, > clusterDistributionManager setRootCause before TCPConduit.stop. It could > cause restarting of server hang after force disconnect. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9910) Failure to auto-reconnect upon network partition
[ https://issues.apache.org/jira/browse/GEODE-9910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502521#comment-17502521 ] Anilkumar Gingade commented on GEODE-9910: -- [~smudundi] The ticket says affected version is 1.14...Are you continue to use 1.14; are you looking for fix immediately. > Failure to auto-reconnect upon network partition > > > Key: GEODE-9910 > URL: https://issues.apache.org/jira/browse/GEODE-9910 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.0 >Reporter: Surya Mudundi >Assignee: Barrett Oglesby >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, needsTriage, > pull-request-available > Attachments: geode-logs.zip > > > Two node cluster with embedded locators failed to auto-reconnect when node-1 > experienced network outage for couple of minutes and when node-1 recovered > from the outage, node-2 failed to auto-reconnect. > node-2 tried to re-connect to node-1 as: > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #1. > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #2. > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Attempting to reconnect to the distributed system. This is attempt #3. > Finally reported below error after 3 attempts as: > INFO > [org.apache.geode.logging.internal.LoggingProviderLoader]-[ReconnectThread] > [] Using org.apache.geode.logging.internal.SimpleLoggingProvider for service > org.apache.geode.logging.internal.spi.LoggingProvider > INFO [org.apache.geode.internal.InternalDataSerializer]-[ReconnectThread] [] > initializing InternalDataSerializer with 0 services > INFO > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] performing a quorum check to see if location services can be started early > INFO > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Quorum check passed - allowing location services to start early > WARN > [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread] > [] Exception occurred while trying to connect the system during reconnect > java.lang.IllegalStateException: A locator can not be created because one > already exists in this JVM. > at > org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:298) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:273) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSystem.java:916) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:768) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2605) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2424) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1275) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2326) > ~[geode-core-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1187) > ~[geode-membership-1.14.0.jar:?] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$forceDisconnect$0(GMSMembership.java:1811) > ~[geode-membership-1.14.0.jar:?] > at java.lang.Thread.run(Thread.java:829) [?:?] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10084) Gfsh ImportDataCommand causes a ClassCastException
[ https://issues.apache.org/jira/browse/GEODE-10084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17497811#comment-17497811 ] Anilkumar Gingade commented on GEODE-10084: --- Additional detail from the discussion: In this case: *The server has a pool defined:* [info 2022/02/24 14:52:16.371 CST tid=0x1] Pool localhost:16000 started with multiuser-authentication=false That locator is defined by this system property: -DLIVE_LOCATORS=localhost:16000 This causes a ClientTypeRegistration to be created. The import command is trying to find the existing PdxType for that id. The ClientTypeRegistration executes a GetPDXTypeByIdOp on the pool (normally a server - not sure what it is in this case): PdxType type = GetPDXTypeByIdOp.execute((ExecutablePool) pool, typeId); And that returns null, so the exception is thrown. *Need to address this issue; even when pool is defined on server side.* Another case with pool: For example, a WAN gateway creates a pool, but that doesn't count for determining the TypeRegistry. Other server pools shouldn't necessarily count either. > Gfsh ImportDataCommand causes a ClassCastException > -- > > Key: GEODE-10084 > URL: https://issues.apache.org/jira/browse/GEODE-10084 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage > > When `ImportDataFunction` throws an InternalGemfireError, gfsh will report a > `ClassCastException` > error 2022/02/22 09:55:27.275 CST ech-10-157-129-162-locator1 Connection(10)-10.157.129.162> tid=0x84] Could not execute “import data > --region=UDTVersionIndex_Stage > --file=/apps_data_01/fraud/UDTVersionIndex_Stage.gfd > --member=ech-10-157-129-162-server1”. > java.lang.ClassCastException: org.apache.geode.InternalGemFireError cannot be > cast to org.apache.geode.management.internal.functions.CliFunctionResult > at > org.apache.geode.management.internal.cli.result.model.ResultModel.addTableAndSetStatus(ResultModel.java:214) > at > org.apache.geode.management.internal.cli.result.model.ResultModel.createMemberStatusResult(ResultModel.java:377) > at > org.apache.geode.management.internal.cli.result.model.ResultModel.createMemberStatusResult(ResultModel.java:357) > at > org.apache.geode.management.internal.cli.commands.ImportDataCommand.importData(ImportDataCommand.java:74) > 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.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:138) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:148) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:76) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:61) > at > org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:132) > at > org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommandReturningJson(OnlineCommandProcessor.java:138) > at > org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1252) > at > org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:424) > 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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at > com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193) > at > com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175) > at >
[jira] [Updated] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10009: -- Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0 needsTriage pull-request-available) > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10009) The CacheClientProxy for a durable client can be terminated when it shouldn't be
[ https://issues.apache.org/jira/browse/GEODE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10009: -- Labels: blocks-1.15.0 needsTriage pull-request-available (was: needsTriage pull-request-available) > The CacheClientProxy for a durable client can be terminated when it shouldn't > be > > > Key: GEODE-10009 > URL: https://issues.apache.org/jira/browse/GEODE-10009 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.15.0 >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: blocks-1.15.0, needsTriage, pull-request-available > > When the client connection is closed but the server has not left or crashed > (e.g in the re-authentication failed case), its possible that two threads in > a durable client can interleave in a way that causes an extra durable task to > be created on the server that eventually causes the CacheClientProxy to be > terminated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9980) Startup of Locator or Server should fail fast if geode.enableGlobalSerialFilter is enabled but fails configuration
[
https://issues.apache.org/jira/browse/GEODE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9980:
-
Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was:
GeodeOperationAPI pull-request-available)
> Startup of Locator or Server should fail fast if
> geode.enableGlobalSerialFilter is enabled but fails configuration
> --
>
> Key: GEODE-9980
> URL: https://issues.apache.org/jira/browse/GEODE-9980
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>
> The following error conditions need better handling which includes handling
> of all errors consistently and cause the startup of a Locator or Server to
> fail if it's unable to honor the setting of
> {{-Dgeode.enableGlobalSerialFilter=true}} for any reason. Currently, if
> {{-Dgeode.enableGlobalSerialFilter=true}} is specified but Geode is unable to
> create a global serial filter, then it will will log a warning and continue
> running. A user may easily miss that log statement and believe that the JVM
> is running with a properly configured serialization filter.
> 1) The user is trying to secure the JVM very thoroughly and accidentally
> specifies both {{-Djdk.serialFilter}} and
> {{-Dgeode.enableGlobalSerialFilter}}.
> 2) The user runs some non-Geode code in the same JVM that invokes
> {{ObjectInputFilter.Config.setFilter(...)}} directly.
> 3) The user is using a version of Java 8 prior to 8u121 (the release that
> first added {{sun.misc.ObjectInputFilter}}) and specifies
> {{-Dgeode.enableGlobalSerialFilter=true}}. Also, the same behavior occurs if
> they do NOT specify enabling that property.
> 4) {{LocatorLauncher}} or {{ServerLauncher}} is started in a JVM that has
> already created at least one {{ObjectInputStream}} which will cause
> {{ObjectInputFilter.Config.setFilter(...)}} to fail.
> 5) {{LocatorLauncher}} or {{ServerLauncher}} is started in a Java 8 JVM that
> is not based on OpenJDK (ie {{sun.misc.ObjectInputFilter}} does not exist).
> 6) {{LocatorLauncher}} or {{ServerLauncher}} is started in an unforeseen
> environment that causes invocation of
> {{ObjectInputFilter.Config.setFilter(...)}} via Java Reflection to throw
> {{IllegalAccessException}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
