[jira] [Commented] (GEODE-9751) [CI-only] render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430272#comment-17430272 ] ASF subversion and git services commented on GEODE-9751: Commit 3284b3adb8ae31955a9a6f2325a984ad6ca12f2e in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3284b3a ] GEODE-9751: load yaml vars safely (unsafe load was deprecated and is now removed) (#7016) (cherry picked from commit 6a60434984ab131e5910442fb7c29245a1e442e1) > [CI-only] render.py needs to call yaml.safe_load instead of yaml.load > - > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9751. - Fix Version/s: 1.15.0 1.14.1 1.13.5 1.12.6 Resolution: Fixed this is a CI-only fix > render.py needs to call yaml.safe_load instead of yaml.load > --- > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9751) [CI-only] render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9751: Summary: [CI-only] render.py needs to call yaml.safe_load instead of yaml.load (was: render.py needs to call yaml.safe_load instead of yaml.load) > [CI-only] render.py needs to call yaml.safe_load instead of yaml.load > - > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430270#comment-17430270 ] ASF subversion and git services commented on GEODE-9751: Commit 8bc3021815e3f2b396ad57ebc39e128ac148e54b in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8bc3021 ] GEODE-9751: load yaml vars safely (unsafe load was deprecated and is now removed) (#7016) (cherry picked from commit 6a60434984ab131e5910442fb7c29245a1e442e1) > render.py needs to call yaml.safe_load instead of yaml.load > --- > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430267#comment-17430267 ] ASF subversion and git services commented on GEODE-9751: Commit 969afbd2bee133588faedd74103a8d4009fb962c in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=969afbd ] GEODE-9751: load yaml vars safely (unsafe load was deprecated and is now removed) (#7016) (cherry picked from commit 6a60434984ab131e5910442fb7c29245a1e442e1) > render.py needs to call yaml.safe_load instead of yaml.load > --- > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9713) DistributedExecutorServiceRule should have parameter to specify threadCount
[ https://issues.apache.org/jira/browse/GEODE-9713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430263#comment-17430263 ] ASF subversion and git services commented on GEODE-9713: Commit 636bea3fd14c634d2568ed49eba3b13f1797d1ff in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=636bea3 ] GEODE-9713: Support thread count in ExecutorService rules (#7002) Restores thread count support to ExecutorServiceRule, and adds it to DistributedExecutorServiceRule. PROBLEM ExecutorService rules currently create a newCachedThreadPool which creates new threads as needed. Some usages would benefit from the option of specifying a threadCount limit which would create a newFixedThreadPool that reuses a fixed number of threads. SOLUTION Add optional threadCount creation parameter to both ExecutorServiceRule and DistributedExecutorServiceRule. Creating a ExecutorService rule without a threadCount will still create a newCachedThreadPool. Using a threadCount will now create a newFixedThreadPool. > DistributedExecutorServiceRule should have parameter to specify threadCount > --- > > Key: GEODE-9713 > URL: https://issues.apache.org/jira/browse/GEODE-9713 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > DistributedExecutorServiceRule should have parameter to specify threadCount > in addition to vmCount. ExecutorServiceRule has a parameter to specify > threadCount so it's just a matter of propagating it to the super constructor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430261#comment-17430261 ] ASF subversion and git services commented on GEODE-9751: Commit 6a60434984ab131e5910442fb7c29245a1e442e1 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6a60434 ] GEODE-9751: load yaml vars safely (unsafe load was deprecated and is now removed) (#7016) > render.py needs to call yaml.safe_load instead of yaml.load > --- > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9752) Limit Memory Consumption for Read Operation
[ https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430259#comment-17430259 ] Darrel Schneider commented on GEODE-9752: - If we find read ops that will consume more memory (than a single netty ByteBuf for example) then those read ops should probably do a critical memory check before they consume that memory. The can just call ExecutionHandlerContext.checkForLowMemory. > Limit Memory Consumption for Read Operation > --- > > Key: GEODE-9752 > URL: https://issues.apache.org/jira/browse/GEODE-9752 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > > The "read" commands can be made more memory friendly by streaming back their > result to netty a "batch" at a time. They can get the netty ByteBuf and write > the result directly to it. Once the buffer contains a certain number of bytes > (say 4k) it do a write and flush. Once that completes it can then use the > same buffer to send the next 4k bytes to the client. Writing the response > directly to the netty ByteBuf will also produce less garbage. The only > downside to it is that the writing will be done while holding the stripe > lock. This probably will not be any slower unless the buffer fills up while > we still hold the lock. The last buffer (the one that is not full) can be > done after the lock is released just as we currently do by returning a > RedisResponse outside the lock and then asking it to write itself to netty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9751: -- Labels: needsTriage pull-request-available (was: needsTriage) > render.py needs to call yaml.safe_load instead of yaml.load > --- > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9752) Limit Memory Consumption for Read Operation
Wayne created GEODE-9752: Summary: Limit Memory Consumption for Read Operation Key: GEODE-9752 URL: https://issues.apache.org/jira/browse/GEODE-9752 Project: Geode Issue Type: Improvement Components: redis Affects Versions: 1.15.0 Reporter: Wayne The "read" commands can be made more memory friendly by streaming back their result to netty a "batch" at a time. They can get the netty ByteBuf and write the result directly to it. Once the buffer contains a certain number of bytes (say 4k) it do a write and flush. Once that completes it can then use the same buffer to send the next 4k bytes to the client. Writing the response directly to the netty ByteBuf will also produce less garbage. The only downside to it is that the writing will be done while holding the stripe lock. This probably will not be any slower unless the buffer fills up while we still hold the lock. The last buffer (the one that is not full) can be done after the lock is released just as we currently do by returning a RedisResponse outside the lock and then asking it to write itself to netty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-9751: --- Assignee: Owen Nichols > render.py needs to call yaml.safe_load instead of yaml.load > --- > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9751: - Labels: needsTriage (was: ) > render.py needs to call yaml.safe_load instead of yaml.load > --- > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9751) render.py needs to call yaml.safe_load instead of yaml.load
Owen Nichols created GEODE-9751: --- Summary: render.py needs to call yaml.safe_load instead of yaml.load Key: GEODE-9751 URL: https://issues.apache.org/jira/browse/GEODE-9751 Project: Geode Issue Type: Bug Components: ci Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 Reporter: Owen Nichols after previously being deprecated, the latest version of pyyaml removes this insecure call (see https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). render.py is used in several jobs in our meta pipeline to transform our jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9749) CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
[
https://issues.apache.org/jira/browse/GEODE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9749:
--
Labels: GeodeOperationAPI needsTriage pull-request-available (was:
GeodeOperationAPI needsTriage)
> CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
>
>
> Key: GEODE-9749
> URL: https://issues.apache.org/jira/browse/GEODE-9749
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> {noformat}
> AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyKeys_durableClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$586/1671380377.run
> in VM 0 running on Host
> heavy-lifter-7e6fdcdb-51cc-5806-8b5c-ced329b97430.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(AuthExpirationDUnitTest.java:197)
> Caused by:
> org.apache.geode.cache.EntryDestroyedException: key0
> at
> org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62)
> at
> org.apache.geode.internal.cache.NonTXEntry.getKey(NonTXEntry.java:81)
> at java.util.AbstractMap.putAll(AbstractMap.java:281)
> at java.util.TreeMap.putAll(TreeMap.java:327)
> at java.util.TreeMap.(TreeMap.java:185)
> at
> org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:702)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:464)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:236)
> at
> org.assertj.core.error.MessageFormatter.asText(MessageFormatter.java:78)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:69)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:62)
> at
> org.assertj.core.error.BasicErrorMessageFactory.create(BasicErrorMessageFactory.java:107)
> at
> org.assertj.core.internal.Failures.assertionErrorMessage(Failures.java:144)
> at org.assertj.core.internal.Failures.failure(Failures.java:125)
> at
> org.assertj.core.internal.CommonValidations.checkSizes(CommonValidations.java:124)
> at org.assertj.core.internal.Maps.assertHasSize(Maps.java:179)
> at
> org.assertj.core.api.AbstractMapAssert.hasSize(AbstractMapAssert.java:259)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$5(AuthExpirationDUnitTest.java:199)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430236#comment-17430236 ] Xiaojian Zhou commented on GEODE-7309: -- This is related with https://issues.apache.org/jira/browse/GEODE-9636. Next time when this ticket is re-implemented and merged, should merge 9636's pull request too. > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430224#comment-17430224 ] ASF GitHub Bot commented on GEODE-9719: --- mmartell merged pull request #881: URL: https://github.com/apache/geode-native/pull/881 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430223#comment-17430223 ] ASF subversion and git services commented on GEODE-9719: Commit 5a1ba8d19709dcda170ea7e313cbae7ad92f797c in geode-native's branch refs/heads/develop from Michael Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=5a1ba8d ] GEODE-9719: Start/Stop cluster in a test fixture (#881) * Start/Stop cluster in a test fixture * Create an authRegion in same cluster * Turn off cluster output after all tests run > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9749) CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
[
https://issues.apache.org/jira/browse/GEODE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-9749:
--
Assignee: Jinmei Liao
> CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
>
>
> Key: GEODE-9749
> URL: https://issues.apache.org/jira/browse/GEODE-9749
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyKeys_durableClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$586/1671380377.run
> in VM 0 running on Host
> heavy-lifter-7e6fdcdb-51cc-5806-8b5c-ced329b97430.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(AuthExpirationDUnitTest.java:197)
> Caused by:
> org.apache.geode.cache.EntryDestroyedException: key0
> at
> org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62)
> at
> org.apache.geode.internal.cache.NonTXEntry.getKey(NonTXEntry.java:81)
> at java.util.AbstractMap.putAll(AbstractMap.java:281)
> at java.util.TreeMap.putAll(TreeMap.java:327)
> at java.util.TreeMap.(TreeMap.java:185)
> at
> org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:702)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:464)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:236)
> at
> org.assertj.core.error.MessageFormatter.asText(MessageFormatter.java:78)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:69)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:62)
> at
> org.assertj.core.error.BasicErrorMessageFactory.create(BasicErrorMessageFactory.java:107)
> at
> org.assertj.core.internal.Failures.assertionErrorMessage(Failures.java:144)
> at org.assertj.core.internal.Failures.failure(Failures.java:125)
> at
> org.assertj.core.internal.CommonValidations.checkSizes(CommonValidations.java:124)
> at org.assertj.core.internal.Maps.assertHasSize(Maps.java:179)
> at
> org.assertj.core.api.AbstractMapAssert.hasSize(AbstractMapAssert.java:259)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$5(AuthExpirationDUnitTest.java:199)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9749) CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
[
https://issues.apache.org/jira/browse/GEODE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-9749:
---
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
>
>
> Key: GEODE-9749
> URL: https://issues.apache.org/jira/browse/GEODE-9749
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyKeys_durableClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$586/1671380377.run
> in VM 0 running on Host
> heavy-lifter-7e6fdcdb-51cc-5806-8b5c-ced329b97430.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(AuthExpirationDUnitTest.java:197)
> Caused by:
> org.apache.geode.cache.EntryDestroyedException: key0
> at
> org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62)
> at
> org.apache.geode.internal.cache.NonTXEntry.getKey(NonTXEntry.java:81)
> at java.util.AbstractMap.putAll(AbstractMap.java:281)
> at java.util.TreeMap.putAll(TreeMap.java:327)
> at java.util.TreeMap.(TreeMap.java:185)
> at
> org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:702)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:464)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:236)
> at
> org.assertj.core.error.MessageFormatter.asText(MessageFormatter.java:78)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:69)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:62)
> at
> org.assertj.core.error.BasicErrorMessageFactory.create(BasicErrorMessageFactory.java:107)
> at
> org.assertj.core.internal.Failures.assertionErrorMessage(Failures.java:144)
> at org.assertj.core.internal.Failures.failure(Failures.java:125)
> at
> org.assertj.core.internal.CommonValidations.checkSizes(CommonValidations.java:124)
> at org.assertj.core.internal.Maps.assertHasSize(Maps.java:179)
> at
> org.assertj.core.api.AbstractMapAssert.hasSize(AbstractMapAssert.java:259)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$5(AuthExpirationDUnitTest.java:199)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9750) add geode-for-redis stats for publish and subscribe
[ https://issues.apache.org/jira/browse/GEODE-9750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9750: Affects Version/s: 1.15.0 > add geode-for-redis stats for publish and subscribe > --- > > Key: GEODE-9750 > URL: https://issues.apache.org/jira/browse/GEODE-9750 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > > GeodeRedisStats should have some pub/sub stats. We already have stats for the > commands themselves. But that does not help much with publish which has an > async implementation. > For those async publishes we need a stat that tells how many are in progress > and a time stat that tells the total amount of time async publish took. Also > a publish can "miss" (i.e. not find any subscribers) and it is worth having a > stat show how many of the publishes missed. > It would also be nice to see how many subscribers a server has (include both > subscribe and psubscribe) since these can be unbalanced and cause memory or > perf issues. > Pattern subscriptions are more expensive if you have many of them that are > different patterns. So we should having something like "uniquePatterns". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9750) add geode-for-redis stats for publish and subscribe
Darrel Schneider created GEODE-9750: --- Summary: add geode-for-redis stats for publish and subscribe Key: GEODE-9750 URL: https://issues.apache.org/jira/browse/GEODE-9750 Project: Geode Issue Type: Improvement Components: redis Reporter: Darrel Schneider GeodeRedisStats should have some pub/sub stats. We already have stats for the commands themselves. But that does not help much with publish which has an async implementation. For those async publishes we need a stat that tells how many are in progress and a time stat that tells the total amount of time async publish took. Also a publish can "miss" (i.e. not find any subscribers) and it is worth having a stat show how many of the publishes missed. It would also be nice to see how many subscribers a server has (include both subscribe and psubscribe) since these can be unbalanced and cause memory or perf issues. Pattern subscriptions are more expensive if you have many of them that are different patterns. So we should having something like "uniquePatterns". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9720) redis FunctionExecutor classes should be renamed or removed
[ https://issues.apache.org/jira/browse/GEODE-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9720: Affects Version/s: 1.15.0 > redis FunctionExecutor classes should be renamed or removed > --- > > Key: GEODE-9720 > URL: https://issues.apache.org/jira/browse/GEODE-9720 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > the geode-for-redis implementation has a bunch of classes whose name ends > with "FunctionExecutor". These used to actually be implemented using geode > functions. But now they are just part of the top level command executor and > usually deal with locking down the geode primary bucket and obtaining striped > locks. > They should be renamed or removed. Renaming is easier but removal also > simplifies the code and makes it easier in the future to add more commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9721) the constant names for redis gemfire properties should contain GEODE_FOR_REDIS
[ https://issues.apache.org/jira/browse/GEODE-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9721: Labels: (was: needsTriage) > the constant names for redis gemfire properties should contain GEODE_FOR_REDIS > -- > > Key: GEODE-9721 > URL: https://issues.apache.org/jira/browse/GEODE-9721 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > > The following constant names in ConfigurationProperties should all be > renamed: REDIS_PORT, REDIS_USERNAME, REDIS_ENABLED, REDIS_BIND_ADDRESS > to: GEODE_FOR_REDIS_PORT, GEODE_FOR_REDIS_USERNAME, GEODE_FOR_REDIS_ENABLED, > GEODE_FOR_REDIS_BIND_ADDRESS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9553) Review and eliminate all remaining usage of sprintf, snprintf, etc
[
https://issues.apache.org/jira/browse/GEODE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430185#comment-17430185
]
ASF subversion and git services commented on GEODE-9553:
Commit 5ba942c7811819ada9baa182da4e38e70db3a221 in geode-native's branch
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=5ba942c ]
GEODE-9553: remove sprintf usage in test utility code (/tests/cpp) (#883)
> Review and eliminate all remaining usage of sprintf, snprintf, etc
> --
>
> Key: GEODE-9553
> URL: https://issues.apache.org/jira/browse/GEODE-9553
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> From time to time, we will pick up a new version of a compiler on one or
> another platform we build on, and get new complaints about potential buffer
> overflows or other assorted badness around persistent use of sprintf. See
> the following pull request, e.g.:
> https://github.com/apache/geode-native/pull/861
> Fixing these when they come up is good as far as it goes, but we're really
> just applying band-aids to the problem. *All* use of sprintf is bad,
> snprintf only slightly less so. Someone needs to just go through the code
> and rewrite all instances in modern C++ using std::string, std::stringstream,
> etc.
> At a glance, here is the list of remaining files containing calls to sprintf:
> {code}
> c:\Users\bblake\src\geode-native>findstr /sm sprintf *.cpp
> cppcache\integration\test\ThinClientConflation.cpp
> cppcache\integration-test\fw_dunit.cpp
> cppcache\integration-test\testCacheless.cpp
> cppcache\integration-test\testOverflowPutGetSqLite.cpp
> cppcache\integration-test\testRegionMap.cpp
> cppcache\integration-test\testSerialization.cpp
> cppcache\integration-test\testThinClientBigValue.cpp
> cppcache\integration-test\testThinClientCacheablesLimits.cpp
> cppcache\integration-test\testThinClientCacheableStringArray.cpp
> cppcache\integration-test\testThinClientConflation.cpp
> cppcache\integration-test\testThinClientCq.cpp
> cppcache\integration-test\testThinClientCqDurable.cpp
> cppcache\integration-test\testThinClientCqFailover.cpp
> cppcache\integration-test\testThinClientCqHAFailover.cpp
> cppcache\integration-test\testThinClientCqIR.cpp
> cppcache\integration-test\testThinClientDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientGetInterests.cpp
> cppcache\integration-test\testThinClientHADistOps.cpp
> cppcache\integration-test\testThinClientHAEventIDMap.cpp
> cppcache\integration-test\testThinClientHAFailover.cpp
> cppcache\integration-test\testThinClientHAFailoverRegex.cpp
> cppcache\integration-test\testThinClientHAMixedRedundancy.cpp
> cppcache\integration-test\testThinClientHAPeriodicAck.cpp
> cppcache\integration-test\testThinClientHeapLRU.cpp
> cppcache\integration-test\testThinClientInterest1_Bug1001.cpp
> cppcache\integration-test\testThinClientInterestNotify.cpp
> cppcache\integration-test\testThinClientIntResPolKeysInv.cpp
> cppcache\integration-test\testThinClientListenerCallbackArgTest.cpp
> cppcache\integration-test\testThinClientLRUExpiration.cpp
> cppcache\integration-test\testThinClientMultiDS.cpp
> cppcache\integration-test\testThinClientNotificationWithDeltaWithoutcache.cpp
> cppcache\integration-test\testThinClientPdxDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientPdxInstance.cpp
> cppcache\integration-test\testThinClientPoolAttrTest.cpp
> cppcache\integration-test\testThinClientPoolExecuteFunctionThrowsException.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunction.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunctionPrSHOP.cpp
> cppcache\integration-test\testThinClientPoolRedundancy.cpp
> cppcache\integration-test\testThinClientPRPutAllFailover.cpp
> cppcache\integration-test\testThinClientRemoteQueryRS.cpp
> cppcache\integration-test\testThinClientRemoteQuerySS.cpp
> cppcache\integration-test\testThinClientRemoteRegionQuery.cpp
> cppcache\integration-test\testThinClientRemoveOps.cpp
> cppcache\integration-test\testThinClientSecurityPostAuthorization.cpp
> cppcache\integration-test\testXmlCacheCreationWithPools.cpp
> cppcache\integration-test\testXmlCacheInitialization.cpp
> tests\cpp\security\PkcsCredentialGenerator.cpp
> tests\cpp\security\XmlAuthzCredentialGenerator.cpp
> tests\cpp\testobject\BatchObject.cpp
> tests\cpp\testobject\DeltaPSTObject.cpp
> tests\cpp\testobject\DeltaTestImpl.cpp
> tests\cpp\testobject\EqStruct.cpp
> tests\cpp\testobject\FastAssetAccount.cpp
> tests\cpp\testobject\InvalidPdxUsage.cpp
> tests\cpp\testobject\NestedPdxObject.cpp
> tests\cpp\testobject\PdxClassV1.cpp
>
[jira] [Commented] (GEODE-9553) Review and eliminate all remaining usage of sprintf, snprintf, etc
[
https://issues.apache.org/jira/browse/GEODE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430186#comment-17430186
]
ASF GitHub Bot commented on GEODE-9553:
---
pdxcodemonkey merged pull request #883:
URL: https://github.com/apache/geode-native/pull/883
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Review and eliminate all remaining usage of sprintf, snprintf, etc
> --
>
> Key: GEODE-9553
> URL: https://issues.apache.org/jira/browse/GEODE-9553
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> From time to time, we will pick up a new version of a compiler on one or
> another platform we build on, and get new complaints about potential buffer
> overflows or other assorted badness around persistent use of sprintf. See
> the following pull request, e.g.:
> https://github.com/apache/geode-native/pull/861
> Fixing these when they come up is good as far as it goes, but we're really
> just applying band-aids to the problem. *All* use of sprintf is bad,
> snprintf only slightly less so. Someone needs to just go through the code
> and rewrite all instances in modern C++ using std::string, std::stringstream,
> etc.
> At a glance, here is the list of remaining files containing calls to sprintf:
> {code}
> c:\Users\bblake\src\geode-native>findstr /sm sprintf *.cpp
> cppcache\integration\test\ThinClientConflation.cpp
> cppcache\integration-test\fw_dunit.cpp
> cppcache\integration-test\testCacheless.cpp
> cppcache\integration-test\testOverflowPutGetSqLite.cpp
> cppcache\integration-test\testRegionMap.cpp
> cppcache\integration-test\testSerialization.cpp
> cppcache\integration-test\testThinClientBigValue.cpp
> cppcache\integration-test\testThinClientCacheablesLimits.cpp
> cppcache\integration-test\testThinClientCacheableStringArray.cpp
> cppcache\integration-test\testThinClientConflation.cpp
> cppcache\integration-test\testThinClientCq.cpp
> cppcache\integration-test\testThinClientCqDurable.cpp
> cppcache\integration-test\testThinClientCqFailover.cpp
> cppcache\integration-test\testThinClientCqHAFailover.cpp
> cppcache\integration-test\testThinClientCqIR.cpp
> cppcache\integration-test\testThinClientDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientGetInterests.cpp
> cppcache\integration-test\testThinClientHADistOps.cpp
> cppcache\integration-test\testThinClientHAEventIDMap.cpp
> cppcache\integration-test\testThinClientHAFailover.cpp
> cppcache\integration-test\testThinClientHAFailoverRegex.cpp
> cppcache\integration-test\testThinClientHAMixedRedundancy.cpp
> cppcache\integration-test\testThinClientHAPeriodicAck.cpp
> cppcache\integration-test\testThinClientHeapLRU.cpp
> cppcache\integration-test\testThinClientInterest1_Bug1001.cpp
> cppcache\integration-test\testThinClientInterestNotify.cpp
> cppcache\integration-test\testThinClientIntResPolKeysInv.cpp
> cppcache\integration-test\testThinClientListenerCallbackArgTest.cpp
> cppcache\integration-test\testThinClientLRUExpiration.cpp
> cppcache\integration-test\testThinClientMultiDS.cpp
> cppcache\integration-test\testThinClientNotificationWithDeltaWithoutcache.cpp
> cppcache\integration-test\testThinClientPdxDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientPdxInstance.cpp
> cppcache\integration-test\testThinClientPoolAttrTest.cpp
> cppcache\integration-test\testThinClientPoolExecuteFunctionThrowsException.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunction.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunctionPrSHOP.cpp
> cppcache\integration-test\testThinClientPoolRedundancy.cpp
> cppcache\integration-test\testThinClientPRPutAllFailover.cpp
> cppcache\integration-test\testThinClientRemoteQueryRS.cpp
> cppcache\integration-test\testThinClientRemoteQuerySS.cpp
> cppcache\integration-test\testThinClientRemoteRegionQuery.cpp
> cppcache\integration-test\testThinClientRemoveOps.cpp
> cppcache\integration-test\testThinClientSecurityPostAuthorization.cpp
> cppcache\integration-test\testXmlCacheCreationWithPools.cpp
> cppcache\integration-test\testXmlCacheInitialization.cpp
> tests\cpp\security\PkcsCredentialGenerator.cpp
> tests\cpp\security\XmlAuthzCredentialGenerator.cpp
> tests\cpp\testobject\BatchObject.cpp
> tests\cpp\testobject\DeltaPSTObject.cpp
> tests\cpp\testobject\DeltaTestImpl.cpp
> tests\cpp\testobject\EqStruct.cpp
> tests\cpp\testobject\FastAssetAccount.cpp
>
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[
https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430182#comment-17430182
]
ASF GitHub Bot commented on GEODE-9719:
---
pdxcodemonkey commented on a change in pull request #881:
URL: https://github.com/apache/geode-native/pull/881#discussion_r731252105
##
File path: netcore/shared/GfshExecute.cs
##
@@ -28,11 +28,19 @@ public class GfshExecute : Gfsh
private String connectionCommand_ = null;
private ITestOutputHelper output;
-public GfshExecute(ITestOutputHelper output)
+public ITestOutputHelper Output
{
-this.output = output;
+ get { return output; }
+ set { output = value; }
}
+
+public GfshExecute(ITestOutputHelper output)
+{
+//Output = output;
+this.output = output;
+}
Review comment:
Looks like you have a tabs vs spaces issue in this file(?). Please fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Switch .NET Core Tests to Xunit Fixtures
>
>
> Key: GEODE-9719
> URL: https://issues.apache.org/jira/browse/GEODE-9719
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Michael Martell
>Priority: Major
> Labels: pull-request-available
>
> The programmatic cluster support brought in by
> [GEODE-9600|http://example.com] currently starts and stops the geode cluster
> for each test. This ticket is to switch the tests to an Xunit fixture model
> wherein all tests for netcore-lib will be run against a single cluster
> start/stop, and similarly for netcore-session.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9749) CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
[
https://issues.apache.org/jira/browse/GEODE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430174#comment-17430174
]
Geode Integration commented on GEODE-9749:
--
Seen in [distributed-test-openjdk8
#2112|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2112]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634364521/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634364521/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
>
>
> Key: GEODE-9749
> URL: https://issues.apache.org/jira/browse/GEODE-9749
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyKeys_durableClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$586/1671380377.run
> in VM 0 running on Host
> heavy-lifter-7e6fdcdb-51cc-5806-8b5c-ced329b97430.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(AuthExpirationDUnitTest.java:197)
> Caused by:
> org.apache.geode.cache.EntryDestroyedException: key0
> at
> org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62)
> at
> org.apache.geode.internal.cache.NonTXEntry.getKey(NonTXEntry.java:81)
> at java.util.AbstractMap.putAll(AbstractMap.java:281)
> at java.util.TreeMap.putAll(TreeMap.java:327)
> at java.util.TreeMap.(TreeMap.java:185)
> at
> org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:702)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:464)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:236)
> at
> org.assertj.core.error.MessageFormatter.asText(MessageFormatter.java:78)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:69)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:62)
> at
> org.assertj.core.error.BasicErrorMessageFactory.create(BasicErrorMessageFactory.java:107)
> at
> org.assertj.core.internal.Failures.assertionErrorMessage(Failures.java:144)
> at org.assertj.core.internal.Failures.failure(Failures.java:125)
> at
> org.assertj.core.internal.CommonValidations.checkSizes(CommonValidations.java:124)
> at org.assertj.core.internal.Maps.assertHasSize(Maps.java:179)
> at
> org.assertj.core.api.AbstractMapAssert.hasSize(AbstractMapAssert.java:259)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$5(AuthExpirationDUnitTest.java:199)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9749) CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
[
https://issues.apache.org/jira/browse/GEODE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430173#comment-17430173
]
Bill Burcham commented on GEODE-9749:
-
GEODE-9704 happens in the same test but seems to represent a different problem
> CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
>
>
> Key: GEODE-9749
> URL: https://issues.apache.org/jira/browse/GEODE-9749
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyKeys_durableClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$586/1671380377.run
> in VM 0 running on Host
> heavy-lifter-7e6fdcdb-51cc-5806-8b5c-ced329b97430.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(AuthExpirationDUnitTest.java:197)
> Caused by:
> org.apache.geode.cache.EntryDestroyedException: key0
> at
> org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62)
> at
> org.apache.geode.internal.cache.NonTXEntry.getKey(NonTXEntry.java:81)
> at java.util.AbstractMap.putAll(AbstractMap.java:281)
> at java.util.TreeMap.putAll(TreeMap.java:327)
> at java.util.TreeMap.(TreeMap.java:185)
> at
> org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:702)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:464)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:236)
> at
> org.assertj.core.error.MessageFormatter.asText(MessageFormatter.java:78)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:69)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:62)
> at
> org.assertj.core.error.BasicErrorMessageFactory.create(BasicErrorMessageFactory.java:107)
> at
> org.assertj.core.internal.Failures.assertionErrorMessage(Failures.java:144)
> at org.assertj.core.internal.Failures.failure(Failures.java:125)
> at
> org.assertj.core.internal.CommonValidations.checkSizes(CommonValidations.java:124)
> at org.assertj.core.internal.Maps.assertHasSize(Maps.java:179)
> at
> org.assertj.core.api.AbstractMapAssert.hasSize(AbstractMapAssert.java:259)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$5(AuthExpirationDUnitTest.java:199)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9749) CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
[
https://issues.apache.org/jira/browse/GEODE-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9749:
-
Labels: needsTriage (was: )
> CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
>
>
> Key: GEODE-9749
> URL: https://issues.apache.org/jira/browse/GEODE-9749
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyKeys_durableClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$586/1671380377.run
> in VM 0 running on Host
> heavy-lifter-7e6fdcdb-51cc-5806-8b5c-ced329b97430.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(AuthExpirationDUnitTest.java:197)
> Caused by:
> org.apache.geode.cache.EntryDestroyedException: key0
> at
> org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62)
> at
> org.apache.geode.internal.cache.NonTXEntry.getKey(NonTXEntry.java:81)
> at java.util.AbstractMap.putAll(AbstractMap.java:281)
> at java.util.TreeMap.putAll(TreeMap.java:327)
> at java.util.TreeMap.(TreeMap.java:185)
> at
> org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:702)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:464)
> at
> org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:236)
> at
> org.assertj.core.error.MessageFormatter.asText(MessageFormatter.java:78)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:69)
> at
> org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:62)
> at
> org.assertj.core.error.BasicErrorMessageFactory.create(BasicErrorMessageFactory.java:107)
> at
> org.assertj.core.internal.Failures.assertionErrorMessage(Failures.java:144)
> at org.assertj.core.internal.Failures.failure(Failures.java:125)
> at
> org.assertj.core.internal.CommonValidations.checkSizes(CommonValidations.java:124)
> at org.assertj.core.internal.Maps.assertHasSize(Maps.java:179)
> at
> org.assertj.core.api.AbstractMapAssert.hasSize(AbstractMapAssert.java:259)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$5(AuthExpirationDUnitTest.java:199)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9749) CI failure: AuthExpirationDUnitTest sees EntryDestroyedException
Bill Burcham created GEODE-9749:
---
Summary: CI failure: AuthExpirationDUnitTest sees
EntryDestroyedException
Key: GEODE-9749
URL: https://issues.apache.org/jira/browse/GEODE-9749
Project: Geode
Issue Type: Bug
Components: security
Affects Versions: 1.15.0
Reporter: Bill Burcham
{noformat}
AuthExpirationDUnitTest >
registeredInterest_slowReAuth_policyKeys_durableClient FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$586/1671380377.run in
VM 0 running on Host
heavy-lifter-7e6fdcdb-51cc-5806-8b5c-ced329b97430.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
at
org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(AuthExpirationDUnitTest.java:197)
Caused by:
org.apache.geode.cache.EntryDestroyedException: key0
at
org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62)
at
org.apache.geode.internal.cache.NonTXEntry.getKey(NonTXEntry.java:81)
at java.util.AbstractMap.putAll(AbstractMap.java:281)
at java.util.TreeMap.putAll(TreeMap.java:327)
at java.util.TreeMap.(TreeMap.java:185)
at
org.assertj.core.presentation.StandardRepresentation.toSortedMapIfPossible(StandardRepresentation.java:702)
at
org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:464)
at
org.assertj.core.presentation.StandardRepresentation.toStringOf(StandardRepresentation.java:236)
at
org.assertj.core.error.MessageFormatter.asText(MessageFormatter.java:78)
at
org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:69)
at
org.assertj.core.error.MessageFormatter.format(MessageFormatter.java:62)
at
org.assertj.core.error.BasicErrorMessageFactory.create(BasicErrorMessageFactory.java:107)
at
org.assertj.core.internal.Failures.assertionErrorMessage(Failures.java:144)
at org.assertj.core.internal.Failures.failure(Failures.java:125)
at
org.assertj.core.internal.CommonValidations.checkSizes(CommonValidations.java:124)
at org.assertj.core.internal.Maps.assertHasSize(Maps.java:179)
at
org.assertj.core.api.AbstractMapAssert.hasSize(AbstractMapAssert.java:259)
at
org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$5(AuthExpirationDUnitTest.java:199)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9746) CI failure: QueryConfigurationServiceConstraintsDistributedTest failed to find authenticated user
[
https://issues.apache.org/jira/browse/GEODE-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9746:
Affects Version/s: 1.15.0
> CI failure: QueryConfigurationServiceConstraintsDistributedTest failed to
> find authenticated user
> -
>
> Key: GEODE-9746
> URL: https://issues.apache.org/jira/browse/GEODE-9746
> Project: Geode
> Issue Type: Bug
> Components: cq, tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> QueryConfigurationServiceConstraintsDistributedTest >
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(regionShortcut=PARTITION,
> operation=UPDATE, executeWithInitialResults=false) FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$510/1355827984.run
> in VM -1 running on Host
> heavy-lifter-39bbef6e-f2bb-59eb-9580-46e00f8bbd78.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.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:196)
> Caused by:
> org.apache.geode.cache.query.CqException: Failed to find the
> authenticated user.
> at
> org.apache.geode.cache.query.cq.internal.ClientCQImpl.executeCqOnRedundantsAndPrimary(ClientCQImpl.java:425)
> at
> org.apache.geode.cache.query.cq.internal.ClientCQImpl.execute(ClientCQImpl.java:271)
> at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.createClientCq(QueryConfigurationServiceConstraintsDistributedTest.java:329)
> at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$1c5e1405$1(QueryConfigurationServiceConstraintsDistributedTest.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:628)
> ... 2 more
> Caused by:
> org.apache.geode.security.AuthenticationRequiredException: Failed
> to find the authenticated user.
> at
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:124)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:259)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:254)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:240)
> at
> org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.lambda$cmdExecute$0(ExecuteCQ61.java:138)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1082)
> at
> org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.cmdExecute(ExecuteCQ61.java:137)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:184)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:865)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1051)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1314)
> at
>
[jira] [Commented] (GEODE-9748) CI failure: LuceneClientSecurityPostProcessingDUnitTest sees UnknownSessionException
[
https://issues.apache.org/jira/browse/GEODE-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430171#comment-17430171
]
Geode Integration commented on GEODE-9748:
--
Seen in [distributed-test-openjdk8
#2108|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2108]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634355917/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634355917/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> CI failure: LuceneClientSecurityPostProcessingDUnitTest sees
> UnknownSessionException
>
>
> Key: GEODE-9748
> URL: https://issues.apache.org/jira/browse/GEODE-9748
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> LuceneClientSecurityPostProcessingDUnitTest > verifyPostProcessing FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm3.log' at line 367
> [fatal 2021/10/16 02:02:52.677 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.UnknownSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.UnknownSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy35.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2708)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2652)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:424)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:227)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:200)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> 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:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:90)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:685)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:206)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:156)
> at
>
[jira] [Updated] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
[
https://issues.apache.org/jira/browse/GEODE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9747:
Affects Version/s: 1.15.0
> CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of
> exception
> ---
>
> Key: GEODE-9747
> URL: https://issues.apache.org/jira/browse/GEODE-9747
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> May be the same issue as GEODE-7030 but it's hard to tell since that other
> ticket is short on details.
> {noformat}
> PersistentPartitionedRegionDistributedTest >
> cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
> in VM 0 running on Host
> heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.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.partitioned.PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> 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.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9748) CI failure: LuceneClientSecurityPostProcessingDUnitTest sees UnknownSessionException
[
https://issues.apache.org/jira/browse/GEODE-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430170#comment-17430170
]
Bill Burcham commented on GEODE-9748:
-
GEODE-9651 happens in the same test method but the stack trace differs.
> CI failure: LuceneClientSecurityPostProcessingDUnitTest sees
> UnknownSessionException
>
>
> Key: GEODE-9748
> URL: https://issues.apache.org/jira/browse/GEODE-9748
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> LuceneClientSecurityPostProcessingDUnitTest > verifyPostProcessing FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm3.log' at line 367
> [fatal 2021/10/16 02:02:52.677 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.UnknownSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.UnknownSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy35.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2708)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2652)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:424)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:227)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:200)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> 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:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:90)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:685)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:206)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:156)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:390)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.waitUntilFlushed(LuceneServiceImpl.java:668)
> at
>
[jira] [Updated] (GEODE-9748) CI failure: LuceneClientSecurityPostProcessingDUnitTest sees UnknownSessionException
[
https://issues.apache.org/jira/browse/GEODE-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9748:
-
Labels: needsTriage (was: )
> CI failure: LuceneClientSecurityPostProcessingDUnitTest sees
> UnknownSessionException
>
>
> Key: GEODE-9748
> URL: https://issues.apache.org/jira/browse/GEODE-9748
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> LuceneClientSecurityPostProcessingDUnitTest > verifyPostProcessing FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm3.log' at line 367
> [fatal 2021/10/16 02:02:52.677 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.UnknownSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.UnknownSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy35.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2708)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2652)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:424)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:227)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:200)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> 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:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:90)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:685)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:206)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:156)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:390)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.waitUntilFlushed(LuceneServiceImpl.java:668)
> at
> org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest.startClient(LuceneClientSecurityPostProcessingDUnitTest.java:178)
> at
>
[jira] [Created] (GEODE-9748) CI failure: LuceneClientSecurityPostProcessingDUnitTest sees UnknownSessionException
Bill Burcham created GEODE-9748:
---
Summary: CI failure: LuceneClientSecurityPostProcessingDUnitTest
sees UnknownSessionException
Key: GEODE-9748
URL: https://issues.apache.org/jira/browse/GEODE-9748
Project: Geode
Issue Type: Bug
Components: lucene
Affects Versions: 1.15.0
Reporter: Bill Burcham
{noformat}
LuceneClientSecurityPostProcessingDUnitTest > verifyPostProcessing FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm3.log' at line 367
[fatal 2021/10/16 02:02:52.677 UTC
tid=33] Serialization filter is rejecting class
org.apache.shiro.session.UnknownSessionException
java.io.InvalidClassException:
org.apache.shiro.session.UnknownSessionException
at
org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
at com.sun.proxy.$Proxy35.checkInput(Unknown Source)
at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
at
org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2708)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2652)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
at
org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
at
org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
at
org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
at
org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
at
org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:424)
at
org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:227)
at
org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:200)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
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:757)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
at
org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:90)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:685)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:206)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:156)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:390)
at
org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
at
org.apache.geode.cache.lucene.internal.LuceneServiceImpl.waitUntilFlushed(LuceneServiceImpl.java:668)
at
org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest.startClient(LuceneClientSecurityPostProcessingDUnitTest.java:178)
at
org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest.lambda$verifyPostProcessing$4d5d1fc8$1(LuceneClientSecurityPostProcessingDUnitTest.java:80)
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] [Commented] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
[
https://issues.apache.org/jira/browse/GEODE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430169#comment-17430169
]
Geode Integration commented on GEODE-9747:
--
Seen in [distributed-test-openjdk8
#2113|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2113]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634363654/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634363654/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of
> exception
> ---
>
> Key: GEODE-9747
> URL: https://issues.apache.org/jira/browse/GEODE-9747
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> May be the same issue as GEODE-7030 but it's hard to tell since that other
> ticket is short on details.
> {noformat}
> PersistentPartitionedRegionDistributedTest >
> cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
> in VM 0 running on Host
> heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.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.partitioned.PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> 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.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
[
https://issues.apache.org/jira/browse/GEODE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9747:
-
Labels: needsTriage (was: )
> CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of
> exception
> ---
>
> Key: GEODE-9747
> URL: https://issues.apache.org/jira/browse/GEODE-9747
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> May be the same issue as GEODE-7030 but it's hard to tell since that other
> ticket is short on details.
> {noformat}
> PersistentPartitionedRegionDistributedTest >
> cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
> in VM 0 running on Host
> heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.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.partitioned.PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> 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.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
Bill Burcham created GEODE-9747:
---
Summary: CI failure: PersistentPartitionedRegionDistributedTest
sees wrong kind of exception
Key: GEODE-9747
URL: https://issues.apache.org/jira/browse/GEODE-9747
Project: Geode
Issue Type: Bug
Components: core, tests
Reporter: Bill Burcham
May be the same issue as GEODE-7030 but it's hard to tell since that other
ticket is short on details.
{noformat}
PersistentPartitionedRegionDistributedTest >
cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
in VM 0 running on Host
heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.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.partitioned.PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
Caused by:
org.opentest4j.AssertionFailedError:
Expecting value to be true but was false
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.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9746) CI failure: QueryConfigurationServiceConstraintsDistributedTest failed to find authenticated user
[
https://issues.apache.org/jira/browse/GEODE-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430161#comment-17430161
]
Geode Integration commented on GEODE-9746:
--
Seen in [distributed-test-openjdk8
#2122|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2122]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634372626/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634372626/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> CI failure: QueryConfigurationServiceConstraintsDistributedTest failed to
> find authenticated user
> -
>
> Key: GEODE-9746
> URL: https://issues.apache.org/jira/browse/GEODE-9746
> Project: Geode
> Issue Type: Bug
> Components: cq, tests
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> QueryConfigurationServiceConstraintsDistributedTest >
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(regionShortcut=PARTITION,
> operation=UPDATE, executeWithInitialResults=false) FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$510/1355827984.run
> in VM -1 running on Host
> heavy-lifter-39bbef6e-f2bb-59eb-9580-46e00f8bbd78.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.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:196)
> Caused by:
> org.apache.geode.cache.query.CqException: Failed to find the
> authenticated user.
> at
> org.apache.geode.cache.query.cq.internal.ClientCQImpl.executeCqOnRedundantsAndPrimary(ClientCQImpl.java:425)
> at
> org.apache.geode.cache.query.cq.internal.ClientCQImpl.execute(ClientCQImpl.java:271)
> at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.createClientCq(QueryConfigurationServiceConstraintsDistributedTest.java:329)
> at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$1c5e1405$1(QueryConfigurationServiceConstraintsDistributedTest.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:628)
> ... 2 more
> Caused by:
> org.apache.geode.security.AuthenticationRequiredException: Failed
> to find the authenticated user.
> at
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:124)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:259)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:254)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:240)
> at
> org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.lambda$cmdExecute$0(ExecuteCQ61.java:138)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1082)
> at
> org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.cmdExecute(ExecuteCQ61.java:137)
> at
>
[jira] [Updated] (GEODE-9746) CI failure: QueryConfigurationServiceConstraintsDistributedTest failed to find authenticated user
[
https://issues.apache.org/jira/browse/GEODE-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9746:
-
Labels: needsTriage (was: )
> CI failure: QueryConfigurationServiceConstraintsDistributedTest failed to
> find authenticated user
> -
>
> Key: GEODE-9746
> URL: https://issues.apache.org/jira/browse/GEODE-9746
> Project: Geode
> Issue Type: Bug
> Components: cq, tests
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> QueryConfigurationServiceConstraintsDistributedTest >
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(regionShortcut=PARTITION,
> operation=UPDATE, executeWithInitialResults=false) FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$510/1355827984.run
> in VM -1 running on Host
> heavy-lifter-39bbef6e-f2bb-59eb-9580-46e00f8bbd78.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.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:196)
> Caused by:
> org.apache.geode.cache.query.CqException: Failed to find the
> authenticated user.
> at
> org.apache.geode.cache.query.cq.internal.ClientCQImpl.executeCqOnRedundantsAndPrimary(ClientCQImpl.java:425)
> at
> org.apache.geode.cache.query.cq.internal.ClientCQImpl.execute(ClientCQImpl.java:271)
> at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.createClientCq(QueryConfigurationServiceConstraintsDistributedTest.java:329)
> at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$1c5e1405$1(QueryConfigurationServiceConstraintsDistributedTest.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:628)
> ... 2 more
> Caused by:
> org.apache.geode.security.AuthenticationRequiredException: Failed
> to find the authenticated user.
> at
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:124)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:259)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:254)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:240)
> at
> org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.lambda$cmdExecute$0(ExecuteCQ61.java:138)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1082)
> at
> org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.cmdExecute(ExecuteCQ61.java:137)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:184)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:865)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1051)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1314)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
[jira] [Created] (GEODE-9746) CI failure: QueryConfigurationServiceConstraintsDistributedTest failed to find authenticated user
Bill Burcham created GEODE-9746:
---
Summary: CI failure:
QueryConfigurationServiceConstraintsDistributedTest failed to find
authenticated user
Key: GEODE-9746
URL: https://issues.apache.org/jira/browse/GEODE-9746
Project: Geode
Issue Type: Bug
Components: cq, tests
Reporter: Bill Burcham
{noformat}
QueryConfigurationServiceConstraintsDistributedTest >
cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(regionShortcut=PARTITION,
operation=UPDATE, executeWithInitialResults=false) FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$510/1355827984.run
in VM -1 running on Host
heavy-lifter-39bbef6e-f2bb-59eb-9580-46e00f8bbd78.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.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:196)
Caused by:
org.apache.geode.cache.query.CqException: Failed to find the
authenticated user.
at
org.apache.geode.cache.query.cq.internal.ClientCQImpl.executeCqOnRedundantsAndPrimary(ClientCQImpl.java:425)
at
org.apache.geode.cache.query.cq.internal.ClientCQImpl.execute(ClientCQImpl.java:271)
at
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.createClientCq(QueryConfigurationServiceConstraintsDistributedTest.java:329)
at
org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$1c5e1405$1(QueryConfigurationServiceConstraintsDistributedTest.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:628)
... 2 more
Caused by:
org.apache.geode.security.AuthenticationRequiredException: Failed
to find the authenticated user.
at
org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:124)
at
org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:259)
at
org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:254)
at
org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:240)
at
org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.lambda$cmdExecute$0(ExecuteCQ61.java:138)
at java.lang.Iterable.forEach(Iterable.java:75)
at
java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1082)
at
org.apache.geode.cache.query.cq.internal.command.ExecuteCQ61.cmdExecute(ExecuteCQ61.java:137)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:184)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:865)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1051)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1314)
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$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at java.lang.Thread.run(Thread.java:748)
701 tests
[jira] [Resolved] (GEODE-9658) CI Failure: AuthExpirationDUnitTest > newClient_registeredInterest_slowReAuth_policyNone_durableClient failed due to
[
https://issues.apache.org/jira/browse/GEODE-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-9658.
Fix Version/s: 1.15.0
Resolution: Fixed
> CI Failure: AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient failed due
> to
> -
>
> Key: GEODE-9658
> URL: https://issues.apache.org/jira/browse/GEODE-9658
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> AuthExpirationDUnitTest >
> newClient_registeredInterest_slowReAuth_policyNone_durableClient[10240.0.0]
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$756/0x0001007c6440.run
> in VM 0 running on Host
> heavy-lifter-4baf3206-8afb-569f-b74b-b22341f348ed.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.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.newClient_registeredInterest_slowReAuth_policyNone_durableClient(AuthExpirationDUnitTest.java:629)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.security.AuthExpirationDUnitTest that uses
> org.apache.geode.cache.Region
> Expected size: 100 but was: 95 in:
> ["key93",
>...
> "key55"] within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> 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:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$newClient_registeredInterest_slowReAuth_policyNone_durableClient$bb17a952$2(AuthExpirationDUnitTest.java:631)
> Caused by:
> java.lang.AssertionError:
> Expected size: 100 but was: 95 in:
> ["key93",
>...
> "key55"]
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$17(AuthExpirationDUnitTest.java:632)
> 1502 tests completed, 1 failed, 110 skipped
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0526/test-results/upgradeTest/1632961901/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0526/test-artifacts/1632961901/upgradetestfiles-openjdk11-1.15.0-build.0526.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430158#comment-17430158 ] Geode Integration commented on GEODE-8644: -- Seen in [distributed-test-openjdk8 #2127|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2127] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634373580/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634373580/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz]. > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430156#comment-17430156
]
Geode Integration commented on GEODE-8616:
--
Seen in [distributed-test-openjdk8
#2169|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2169]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634408163/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634408163/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1
>Reporter: Donal Evans
>Priority: Major
> Labels: GeodeOperationAPI, flaky-test
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430154#comment-17430154 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2105|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2105] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634356637/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634356637/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430155#comment-17430155 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2109|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2109] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634356036/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634356036/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430152#comment-17430152 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2141|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2141] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634388792/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634388792/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430150#comment-17430150 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2186|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2186] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634423720/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634423720/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9604) Fix test in MSetDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430149#comment-17430149
]
ASF subversion and git services commented on GEODE-9604:
Commit 3860c2f2c23bf3396b19cf078743f776935c5e06 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3860c2f ]
GEODE-9604: Use AvailablePortHelper in MSetDUnitTest (#7011)
- This test was strangely flaky and seemed to be suffering from some
kind of cross-test pollution when multiple tests were running in
parallel. When stopping and restarting VMs it seems imperative to
always reuse the same ports.
> Fix test in MSetDUnitTest
> -
>
> Key: GEODE-9604
> URL: https://issues.apache.org/jira/browse/GEODE-9604
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The tests {{testMSet_crashDoesNotLeaveInconsistencies}} and
> {{testMSetnx_crashDoesNotLeaveInconsistencies}} in {{MSetDunitTest}} and
> {{MSetnxDUnitTest}} respectively, do not pass under stress and will
> occasionally fail. This may be due to a product issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430148#comment-17430148 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #288|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/288] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0595/test-results/distributedTest/1634293882/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0595/test-artifacts/1634293882/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430142#comment-17430142 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #289|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/289] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0595/test-results/distributedTest/1634322309/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0595/test-artifacts/1634322309/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8109) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansOnServerAreUnaffectedByLocatorCrash failed with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham resolved GEODE-8109.
-
Resolution: Duplicate
> CI failure: JMXMBeanReconnectDUnitTest >
> serverMXBeansOnServerAreUnaffectedByLocatorCrash failed with
> ConditionTimeoutException
> ---
>
> Key: GEODE-8109
> URL: https://issues.apache.org/jira/browse/GEODE-8109
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barrett Oglesby
>Priority: Major
>
> This test fails due to GEODE-7739. Enter new failures against that ticket.
> DistributedTestOpenJDK8 build 157:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/157
> Failed with:
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverMXBeansOnServerAreUnaffectedByLocatorCrash FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.JMXMBeanReconnectDUnitTest$$Lambda$343/845984545.call
> in VM -1 running on Host e4f9524803d1 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.setUp(JMXMBeanReconnectDUnitTest.java:189)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest [GemFire mbeans on
> locator2]
> Expecting:
> <[GemFire:type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
> GemFire:type=Member,member=server1,
> GemFire:service=Manager,type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator2,
> GemFire:type=Member,member=locator2,
> GemFire:service=Region,name=/region1,type=Member,member=server1,
> GemFire:service=FileUploader,type=Distributed,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
> GemFire:service=Manager,type=Member,member=locator2,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=System,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=Region,name=/region1,type=Distributed]>
> to contain:
> <[GemFire:type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=Manager,type=Member,member=locator1,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> but could not find:
>
> <[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 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:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.lambda$setUp$515fd116$3(JMXMBeanReconnectDUnitTest.java:190)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:607)
> ... 2 more
> Caused by:
> java.lang.AssertionError: [GemFire mbeans on locator2]
> Expecting:
> <[GemFire:type=Member,member=locator1,
>
>
[jira] [Resolved] (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
]
Bill Burcham resolved GEODE-7710.
-
Resolution: Duplicate
> 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
>Assignee: 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.3.4#803005)
[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
]
Bill Burcham updated GEODE-7710:
Description:
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*.
was:
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*.
> 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
>Assignee: 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.3.4#803005)
[jira] [Updated] (GEODE-8109) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansOnServerAreUnaffectedByLocatorCrash failed with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8109:
Description:
This test fails due to GEODE-7739. Enter new failures against that ticket.
DistributedTestOpenJDK8 build 157:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/157
Failed with:
{noformat}
org.apache.geode.management.JMXMBeanReconnectDUnitTest >
serverMXBeansOnServerAreUnaffectedByLocatorCrash FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.JMXMBeanReconnectDUnitTest$$Lambda$343/845984545.call
in VM -1 running on Host e4f9524803d1 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
at
org.apache.geode.management.JMXMBeanReconnectDUnitTest.setUp(JMXMBeanReconnectDUnitTest.java:189)
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.management.JMXMBeanReconnectDUnitTest [GemFire mbeans on
locator2]
Expecting:
<[GemFire:type=Member,member=locator1,
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
GemFire:type=Member,member=server1,
GemFire:service=Manager,type=Member,member=locator1,
GemFire:service=Locator,type=Member,member=locator2,
GemFire:type=Member,member=locator2,
GemFire:service=Region,name=/region1,type=Member,member=server1,
GemFire:service=FileUploader,type=Distributed,
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
GemFire:service=Manager,type=Member,member=locator2,
GemFire:service=Locator,type=Member,member=locator1,
GemFire:service=System,type=Distributed,
GemFire:service=AccessControl,type=Distributed,
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
GemFire:service=Region,name=/region1,type=Distributed]>
to contain:
<[GemFire:type=Member,member=locator1,
GemFire:service=Locator,type=Member,member=locator1,
GemFire:service=Manager,type=Member,member=locator1,
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
but could not find:
<[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
within 5 minutes.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
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:895)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
at
org.apache.geode.management.JMXMBeanReconnectDUnitTest.lambda$setUp$515fd116$3(JMXMBeanReconnectDUnitTest.java:190)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:607)
... 2 more
Caused by:
java.lang.AssertionError: [GemFire mbeans on locator2]
Expecting:
<[GemFire:type=Member,member=locator1,
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
GemFire:type=Member,member=server1,
GemFire:service=Manager,type=Member,member=locator1,
GemFire:service=Locator,type=Member,member=locator2,
GemFire:type=Member,member=locator2,
GemFire:service=Region,name=/region1,type=Member,member=server1,
GemFire:service=FileUploader,type=Distributed,
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
GemFire:service=Manager,type=Member,member=locator2,
GemFire:service=Locator,type=Member,member=locator1,
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430135#comment-17430135
]
Geode Integration commented on GEODE-8191:
--
Seen in [distributed-test-openjdk8
#2111|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2111]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634365221/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634365221/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.15.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 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:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430132#comment-17430132
]
Geode Integration commented on GEODE-8191:
--
Seen in [distributed-test-openjdk8
#2191|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2191]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634429210/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634429210/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.15.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 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:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430133#comment-17430133
]
Geode Integration commented on GEODE-8191:
--
Seen in [distributed-test-openjdk8
#2136|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2136]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-results/distributedTest/1634381225/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0595/test-artifacts/1634381225/distributedtestfiles-openjdk8-1.15.0-build.0595.tgz].
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.15.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 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:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430131#comment-17430131 ] Geode Integration commented on GEODE-6183: -- Seen in [windows-core-integration-test-openjdk8 #281|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk8/builds/281] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0593/test-results/integrationTest/1634274123/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0593/test-artifacts/1634274123/windows-coreintegrationtestfiles-openjdk8-1.15.0-build.0593.tgz]. > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7572) BENCHMARK FAILED: org.apache.geode.benchmark.tests.PartitionedPutAllLongBenchmark average latency is 5% worse than baseline.
[ https://issues.apache.org/jira/browse/GEODE-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430130#comment-17430130 ] Geode Integration commented on GEODE-7572: -- Seen in [benchmark-base #287|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/287]. > BENCHMARK FAILED: > org.apache.geode.benchmark.tests.PartitionedPutAllLongBenchmark average > latency is 5% worse than baseline. > > > Key: GEODE-7572 > URL: https://issues.apache.org/jira/browse/GEODE-7572 > Project: Geode > Issue Type: Bug > Components: benchmarks, ci >Reporter: Ernest Burghardt >Priority: Major > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/7] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/8] > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9745) geode-for-redis stats expose unbranded names
[ https://issues.apache.org/jira/browse/GEODE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9745: -- Labels: pull-request-available (was: ) > geode-for-redis stats expose unbranded names > > > Key: GEODE-9745 > URL: https://issues.apache.org/jira/browse/GEODE-9745 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > The stats for geode-for-redis when seen in an external tool (like vsd) are > named "redisStats". They should instead be "geodeForRedisStats". Also the > type name is very non-standard and too wordy "statsForServergeodeForRedis". > It should just be "GeodeForRedisStats". > The description also has some old terminology "Statistics for a Geode server > compatible with Redis". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-9656: - Labels: (was: needsTriage) > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Priority: Major > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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 ] Dick Cavender updated GEODE-9744: - Labels: needsTriage (was: ) > 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: needsTriage > > 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.3.4#803005)
[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 ] Dick Cavender updated GEODE-9744: - Labels: (was: needsTriage) > 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 > > 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.3.4#803005)
[jira] [Updated] (GEODE-9696) CI Failure: ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9696:
Description:
Link:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/247]
Stacktrace:
{noformat}
ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$474/0x000100416040.call
in VM 1 running on Host
heavy-lifter-f0dce14c-1683-56fa-bb43-d93a0d2513d8.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.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:646)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:100)
Caused by:
java.lang.AssertionError: Got unexpected exception when starting peer
at org.apache.geode.test.dunit.Assert.fail(Assert.java:66)
at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:221)
at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:186)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:73)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:49)
at
org.apache.geode.security.ClientAuthenticationTestCase.lambda$doTestCredentialsForNotifications$41bb60fa$1(ClientAuthenticationTestCase.java:647)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at jdk.internal.reflect.GeneratedMethodAccessor232.invoke(Unknown
Source)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:829)
Caused by:
org.apache.geode.GemFireConfigException: Problem configuring
membership services
at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
at
[jira] [Updated] (GEODE-9696) CI Failure: ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9696:
Description:
Link:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/247]
Stacktrace:
{noformat}
ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$474/0x000100416040.call
in VM 1 running on Host
heavy-lifter-f0dce14c-1683-56fa-bb43-d93a0d2513d8.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.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:646)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:100)
Caused by: java.lang.AssertionError: Got unexpected exception
when starting peer at
org.apache.geode.test.dunit.Assert.fail(Assert.java:66) at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:221)
at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:186)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:73)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:49)
at
org.apache.geode.security.ClientAuthenticationTestCase.lambda$doTestCredentialsForNotifications$41bb60fa$1(ClientAuthenticationTestCase.java:647)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at jdk.internal.reflect.GeneratedMethodAccessor232.invoke(Unknown
Source) at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566) at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at sun.rmi.transport.Transport$1.run(Transport.java:200) at
sun.rmi.transport.Transport$1.run(Transport.java:197) at
java.security.AccessController.doPrivileged(Native Method) at
sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:829) Caused by:
org.apache.geode.GemFireConfigException: Problem configuring membership
services at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
at
[jira] [Updated] (GEODE-9696) CI Failure: ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9696:
Description:
Link:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/247]
Stacktrace:
{noformat}
ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$474/0x000100416040.call
in VM 1 running on Host
heavy-lifter-f0dce14c-1683-56fa-bb43-d93a0d2513d8.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.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:646)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:100)
Caused by: java.lang.AssertionError: Got unexpected exception
when starting peer at
org.apache.geode.test.dunit.Assert.fail(Assert.java:66) at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:221)
at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:186)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:73)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:49)
at
org.apache.geode.security.ClientAuthenticationTestCase.lambda$doTestCredentialsForNotifications$41bb60fa$1(ClientAuthenticationTestCase.java:647)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at jdk.internal.reflect.GeneratedMethodAccessor232.invoke(Unknown
Source) at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566) at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at sun.rmi.transport.Transport$1.run(Transport.java:200) at
sun.rmi.transport.Transport$1.run(Transport.java:197) at
java.security.AccessController.doPrivileged(Native Method) at
sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:829) Caused by:
org.apache.geode.GemFireConfigException: Problem configuring membership
services at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
at
[jira] [Updated] (GEODE-9696) CI Failure: ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9696:
Description:
Link:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/247]
Stacktrace:
{noformat}
ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$474/0x000100416040.call
in VM 1 running on Host
heavy-lifter-f0dce14c-1683-56fa-bb43-d93a0d2513d8.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.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:646)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:100)
Caused by: java.lang.AssertionError: Got unexpected exception
when starting peer at
org.apache.geode.test.dunit.Assert.fail(Assert.java:66) at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:221)
at
org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:186)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:73)
at
org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:49)
at
org.apache.geode.security.ClientAuthenticationTestCase.lambda$doTestCredentialsForNotifications$41bb60fa$1(ClientAuthenticationTestCase.java:647)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at jdk.internal.reflect.GeneratedMethodAccessor232.invoke(Unknown
Source) at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566) at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at sun.rmi.transport.Transport$1.run(Transport.java:200) at
sun.rmi.transport.Transport$1.run(Transport.java:197) at
java.security.AccessController.doPrivileged(Native Method) at
sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:829) Caused by:
org.apache.geode.GemFireConfigException: Problem configuring membership
services at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
at
[jira] [Updated] (GEODE-9745) geode-for-redis stats expose unbranded names
[ https://issues.apache.org/jira/browse/GEODE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9745: Affects Version/s: 1.15.0 > geode-for-redis stats expose unbranded names > > > Key: GEODE-9745 > URL: https://issues.apache.org/jira/browse/GEODE-9745 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > > The stats for geode-for-redis when seen in an external tool (like vsd) are > named "redisStats". They should instead be "geodeForRedisStats". Also the > type name is very non-standard and too wordy "statsForServergeodeForRedis". > It should just be "GeodeForRedisStats". > The description also has some old terminology "Statistics for a Geode server > compatible with Redis". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9745) geode-for-redis stats expose unbranded names
[ https://issues.apache.org/jira/browse/GEODE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9745: Labels: (was: needsTriage) > geode-for-redis stats expose unbranded names > > > Key: GEODE-9745 > URL: https://issues.apache.org/jira/browse/GEODE-9745 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > > The stats for geode-for-redis when seen in an external tool (like vsd) are > named "redisStats". They should instead be "geodeForRedisStats". Also the > type name is very non-standard and too wordy "statsForServergeodeForRedis". > It should just be "GeodeForRedisStats". > The description also has some old terminology "Statistics for a Geode server > compatible with Redis". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9745) geode-for-redis stats expose unbranded names
[ https://issues.apache.org/jira/browse/GEODE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-9745: --- Assignee: Darrel Schneider > geode-for-redis stats expose unbranded names > > > Key: GEODE-9745 > URL: https://issues.apache.org/jira/browse/GEODE-9745 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > The stats for geode-for-redis when seen in an external tool (like vsd) are > named "redisStats". They should instead be "geodeForRedisStats". Also the > type name is very non-standard and too wordy "statsForServergeodeForRedis". > It should just be "GeodeForRedisStats". > The description also has some old terminology "Statistics for a Geode server > compatible with Redis". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9745) geode-for-redis stats expose unbranded names
Darrel Schneider created GEODE-9745: --- Summary: geode-for-redis stats expose unbranded names Key: GEODE-9745 URL: https://issues.apache.org/jira/browse/GEODE-9745 Project: Geode Issue Type: Bug Components: redis Reporter: Darrel Schneider The stats for geode-for-redis when seen in an external tool (like vsd) are named "redisStats". They should instead be "geodeForRedisStats". Also the type name is very non-standard and too wordy "statsForServergeodeForRedis". It should just be "GeodeForRedisStats". The description also has some old terminology "Statistics for a Geode server compatible with Redis". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9745) geode-for-redis stats expose unbranded names
[ https://issues.apache.org/jira/browse/GEODE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9745: - Labels: needsTriage (was: ) > geode-for-redis stats expose unbranded names > > > Key: GEODE-9745 > URL: https://issues.apache.org/jira/browse/GEODE-9745 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > The stats for geode-for-redis when seen in an external tool (like vsd) are > named "redisStats". They should instead be "geodeForRedisStats". Also the > type name is very non-standard and too wordy "statsForServergeodeForRedis". > It should just be "GeodeForRedisStats". > The description also has some old terminology "Statistics for a Geode server > compatible with Redis". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9645) MultiUserAuth: DataSerializerRecoveryListener is called without auth information. Promptly fails
[
https://issues.apache.org/jira/browse/GEODE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-9645.
Fix Version/s: 1.15.0
Resolution: Fixed
The code will not send DataSerializer registration notifications when using
multiuser authentication.
> MultiUserAuth: DataSerializerRecoveryListener is called without auth
> information. Promptly fails
>
>
> Key: GEODE-9645
> URL: https://issues.apache.org/jira/browse/GEODE-9645
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> When multiuserSecureModeEnabled is enabled, a user may register a
> DataSerializer. When endpoint manager detects a new endpoint, it will attempt
> to register the data serializers with other machines. This is a problem was
> there is no authentication information in the background process to
> authenticate. Hence the error seen below.
>
> {noformat}
> [warn 2021/09/27 18:03:02.804 PDT tid=0x62]
> DataSerializerRecoveryTask - Error recovering dataSerializers:
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations
> when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:816)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:40)
>
> at
> org.apache.geode.cache.client.internal.DataSerializerRecoveryListener$RecoveryTask.run2(DataSerializerRecoveryListener.java:116)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1337)
>
> 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){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9604) Fix test in MSetDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9604.
---
Fix Version/s: 1.15.0
Assignee: Jens Deppe
Resolution: Fixed
> Fix test in MSetDUnitTest
> -
>
> Key: GEODE-9604
> URL: https://issues.apache.org/jira/browse/GEODE-9604
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The tests {{testMSet_crashDoesNotLeaveInconsistencies}} and
> {{testMSetnx_crashDoesNotLeaveInconsistencies}} in {{MSetDunitTest}} and
> {{MSetnxDUnitTest}} respectively, do not pass under stress and will
> occasionally fail. This may be due to a product issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9724) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9724: - Component/s: serialization > CI Failure: > RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] > FAILED > --- > > Key: GEODE-9724 > URL: https://issues.apache.org/jira/browse/GEODE-9724 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.14.1 >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$1.run > in VM 2 running on Host 05a785bb07ad 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.rollingupgrade.RollingUpgradeDUnitTest.rollLocatorToCurrent(RollingUpgradeDUnitTest.java:370) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable(RollingUpgradeRollServersOnReplicatedRegion_dataserializable.java:24) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.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
[jira] [Updated] (GEODE-9723) Add test to cover transaction based operations when re-authentication happens.
[ https://issues.apache.org/jira/browse/GEODE-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9723: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > Add test to cover transaction based operations when re-authentication happens. > -- > > Key: GEODE-9723 > URL: https://issues.apache.org/jira/browse/GEODE-9723 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > add test scenario for when a transaction has multiple operations, what would > happen when auth expired in the middle of a transaction. Would the > transaction continue if re-auth succeeds? Would the resources be cleared up > with re-auth failed? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9604) Fix test in MSetDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9604:
--
Labels: pull-request-available (was: )
> Fix test in MSetDUnitTest
> -
>
> Key: GEODE-9604
> URL: https://issues.apache.org/jira/browse/GEODE-9604
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> The tests {{testMSet_crashDoesNotLeaveInconsistencies}} and
> {{testMSetnx_crashDoesNotLeaveInconsistencies}} in {{MSetDunitTest}} and
> {{MSetnxDUnitTest}} respectively, do not pass under stress and will
> occasionally fail. This may be due to a product issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9632:
--
Labels: pull-request-available (was: )
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.13.1, 1.14.0
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard character(%), there is no results
> for the query despite of there are some entries that meet the condition we
> are checking.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '342234525745'"
> Result : true
> Limit : 100
> Rows: 1
> Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '34223452574%'"
> Result : true
> Limit : 100
> Rows: 0
> Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
> As we are using indexes to have a better performance of executing a query it
> first need to check how many entries has that field which we are looking for.
> It stores it in index results and then check how many of them meet condition
> we defined in our query.
> The problem is that there is parameter INDEX_THRESHOLD_SIZE which default
> value is 100. If there is a lot of entries in the region it will write just
> first 100 entries that is found.
> This parameter can be changed while starting servers by adding
> *-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
> value than the limit in the query is, it will overwrite it. So there should
> be some changes to take this attribute into account.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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 ] lujie updated GEODE-9744: - Summary: bug like CVE-2020-8908 (was: bug CVE-2020-8908) > 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: needsTriage > > 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.3.4#803005)
[jira] [Updated] (GEODE-9744) bug CVE-2020-8908
[ https://issues.apache.org/jira/browse/GEODE-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] lujie updated GEODE-9744: - Summary: bug CVE-2020-8908 (was: like CVE-2020-8908) > bug 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: needsTriage > > 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.3.4#803005)
[jira] [Updated] (GEODE-9744) like CVE-2020-8908
[ https://issues.apache.org/jira/browse/GEODE-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] lujie updated GEODE-9744: - Summary: like CVE-2020-8908 (was: fix CVE-2020-8908) > 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: needsTriage > > 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.3.4#803005)
[jira] [Created] (GEODE-9744) fix CVE-2020-8908
lujie created GEODE-9744: Summary: fix CVE-2020-8908 Key: GEODE-9744 URL: https://issues.apache.org/jira/browse/GEODE-9744 Project: Geode Issue Type: Bug Reporter: lujie 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.3.4#803005)
[jira] [Updated] (GEODE-9744) fix CVE-2020-8908
[ https://issues.apache.org/jira/browse/GEODE-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9744: - Labels: needsTriage (was: ) > fix 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: needsTriage > > 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.3.4#803005)
