[jira] [Commented] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420038#comment-17420038 ] Xiaojian Zhou commented on GEODE-9636: -- The NoClassDefFoundError is due to other lucene jar is uplift to 7.1.0, but one component did not. I have a fix. > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-9636: Assignee: Xiaojian Zhou > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9640) When cluster shut down completely and restarted, new operations may be lost on client
[ https://issues.apache.org/jira/browse/GEODE-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9640: -- Labels: GeodeOperationAPI needsTriage pull-request-available (was: GeodeOperationAPI needsTriage) > When cluster shut down completely and restarted, new operations may be lost > on client > - > > Key: GEODE-9640 > URL: https://issues.apache.org/jira/browse/GEODE-9640 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > > In Geode, client keeps track of events received based on EventID. If > duplicate events received from server, they are thrown away. > The current EventID takes parts of membership ID information, and it seems > not adequate enough if whole cluster is down. (The coordinator is down and > member viewId will start from 0 again.) This can lead to same event ids are > generated, and cause client miss CQ events, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9640) When cluster shut down completely and restarted, new operations may be lost on client
[ https://issues.apache.org/jira/browse/GEODE-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-9640: Labels: GeodeOperationAPI needsTriage (was: needsTriage) > When cluster shut down completely and restarted, new operations may be lost > on client > - > > Key: GEODE-9640 > URL: https://issues.apache.org/jira/browse/GEODE-9640 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, needsTriage > > In Geode, client keeps track of events received based on EventID. If > duplicate events received from server, they are thrown away. > The current EventID takes parts of membership ID information, and it seems > not adequate enough if whole cluster is down. (The coordinator is down and > member viewId will start from 0 again.) This can lead to same event ids are > generated, and cause client miss CQ events, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9640) When cluster shut down completely and restarted, new operations may be lost on client
[ https://issues.apache.org/jira/browse/GEODE-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-9640: --- Assignee: Eric Shu > When cluster shut down completely and restarted, new operations may be lost > on client > - > > Key: GEODE-9640 > URL: https://issues.apache.org/jira/browse/GEODE-9640 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > In Geode, client keeps track of events received based on EventID. If > duplicate events received from server, they are thrown away. > The current EventID takes parts of membership ID information, and it seems > not adequate enough if whole cluster is down. (The coordinator is down and > member viewId will start from 0 again.) This can lead to same event ids are > generated, and cause client miss CQ events, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9640) When cluster shut down completely and restarted, new operations may be lost on client
[ https://issues.apache.org/jira/browse/GEODE-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-9640: Summary: When cluster shut down completely and restarted, new operations may be lost on client (was: When cluster shut down completely and restarted, some operations may be lost on client) > When cluster shut down completely and restarted, new operations may be lost > on client > - > > Key: GEODE-9640 > URL: https://issues.apache.org/jira/browse/GEODE-9640 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > In Geode, client keeps track of events received based on EventID. If > duplicate events received from server, they are thrown away. > The current EventID takes parts of membership ID information, and it seems > not adequate enough if whole cluster is down. (The coordinator is down and > member viewId will start from 0 again.) This can lead to same event ids are > generated, and cause client miss CQ events, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9640) When cluster shut down completely and restarted, some operations may be lost on client
[ https://issues.apache.org/jira/browse/GEODE-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9640: - Labels: needsTriage (was: ) > When cluster shut down completely and restarted, some operations may be lost > on client > -- > > Key: GEODE-9640 > URL: https://issues.apache.org/jira/browse/GEODE-9640 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > In Geode, client keeps track of events received based on EventID. If > duplicate events received from server, they are thrown away. > The current EventID takes parts of membership ID information, and it seems > not adequate enough if whole cluster is down. (The coordinator is down and > member viewId will start from 0 again.) This can lead to same event ids are > generated, and cause client miss CQ events, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9640) When cluster shut down completely and restarted, some operations may be lost on client
Eric Shu created GEODE-9640: --- Summary: When cluster shut down completely and restarted, some operations may be lost on client Key: GEODE-9640 URL: https://issues.apache.org/jira/browse/GEODE-9640 Project: Geode Issue Type: Bug Components: client/server Reporter: Eric Shu In Geode, client keeps track of events received based on EventID. If duplicate events received from server, they are thrown away. The current EventID takes parts of membership ID information, and it seems not adequate enough if whole cluster is down. (The coordinator is down and member viewId will start from 0 again.) This can lead to same event ids are generated, and cause client miss CQ events, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8840) implement redis RENAMENX command
[ https://issues.apache.org/jira/browse/GEODE-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Zoerner reassigned GEODE-8840: --- Assignee: Eric Zoerner > implement redis RENAMENX command > > > Key: GEODE-8840 > URL: https://issues.apache.org/jira/browse/GEODE-8840 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > > Note: see implementation of SETNX, RENAME > Notes relating to [the now-closed > PR|[https://github.com/apache/geode/pull/5915]]: Currently there's a race > condition between when the new key's existence is checked, and the old key is > renamed. It's possible for two RENAMENX operations, on separate threads, > renaming to the SAME new key, to BOTH succeed. At most one should succeed. > The existing DUNIT test illustrates this problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419946#comment-17419946
]
ASF subversion and git services commented on GEODE-9486:
Commit ba81c3670d85dbb4451030e2c4acb11ca8aef9da in geode's branch
refs/heads/support/1.14 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ba81c36 ]
GEODE-9486: Fix validate-serializable-objects (#6823)
Rename DistributedSystemService to SanctionedSerializablesService and
remove unused init(DistributedSystem).
Move SanctionedSerializablesService to geode-serialization.
Implement SanctionedSerializablesService in both geode-core and
geode-management to remove special case for each in
InternalDataSerializer.
Fix sanctioned serializables support in geode-management and
geode-apis-compatible-with-redis.
Add sanctioned serializables support to geode-serialization and
geode-pulse.
Add sanctioned serializables support to geode-junit and geode-dunit
to simplify writing tests for validate-serializable-objects and prevent
having to list out DUnit Rules and other test framework classes when
validate-serializable-objects is enabled.
Use ExecutorServiceRule and reformat json strings in
RestRegionAPIIntegrationTest.
Reorganize QueryCommandDUnitTestBase.
Use InvalidClassException instead of Exception in
ObjectInputStreamFilterWrapper fatal log message.
Improve assertion messages in ResourceUtils.
Move loadSanctionedSerializablesServices and loadClassNames to
new SanctionedSerializables in geode-serialization.
Exclude Pulse GemFireAuthentication from sanctioned serializables.
Add SerializationTest Category to all AnalyzeSerializables integration
tests.
Tidy up SANCTIONED_SERIALIZABLES_DEPENDENCIES_PATTERN.
Convert to AssertJ and use BeforeClass in
InternalDataSerializerSerializationAcceptlistTest.
Note: If Git or GitHub is showing invalid file renames in the diffs, you
may need to pull the branch locally and configure diff.renameLimit to
something lower than the default value of 50.
(cherry picked from commit acbd0ff3c37a5e1fe3018d3f7288df385159ac4c)
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419947#comment-17419947
]
ASF subversion and git services commented on GEODE-9486:
Commit 14582d05ed0032f5315313e3d29c1773b7bf0f53 in geode's branch
refs/heads/support/1.14 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=14582d0 ]
GEODE-9486: Improve AnalyzeSerializables integration tests (#6878)
Allow geode modules to have an AnalyzeSerializables integration
test without implementing SanctionedSerializablesService.
Improve debugging information for AnalyzeSerializables integration
tests:
- Provide new failure message when no SanctionedSerializablesService
exists.
- Create ANALYZE_SERIALIZABLES.md to provide detailed instructions for
failures involving AnalyzeSerializables integration tests.
- Reference ANALYZE_SERIALIZABLES.md in failure messages.
Remove geode-serialization and geode-common jars from geode-pulse
.war file:
- Change getModuleClass() to return Optional.
- Delete PulseSanctionedSerializablesService and its resources.
- Change geode-pulse dependency on geode-serialization to be for
integrationTest only.
(cherry picked from commit 7bd1d73dcd02712a10e5c3f2ac5ac0522923bf9e)
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender updated GEODE-9634: Affects Version/s: 1.15.0 > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Major > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender updated GEODE-9634: Priority: Blocker (was: Major) > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Blocker > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9637) Disable Wan serialization test pending fix from Geode
[ https://issues.apache.org/jira/browse/GEODE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-9637. - Resolution: Fixed > Disable Wan serialization test pending fix from Geode > - > > Key: GEODE-9637 > URL: https://issues.apache.org/jira/browse/GEODE-9637 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > GEODE-9634 is currently breaking our Wan serialization test. This test is > fairly obscure and does something no one would ever do in production, so > while we wait for a bug fix from Geode, it's a fairly safe thing to simply > disable our failing test. This will get the CI pipeline back to green until > Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419926#comment-17419926 ] ASF subversion and git services commented on GEODE-9634: Commit b1b4f5a00c77610aa306a0dba7b5ead2c215cd7f in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=b1b4f5a ] GEODE-9637: Disable Wan deserialization test (#870) - Just want a green CI until GEODE-9634 is resolved. Co-authored-by: Blake Bender > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Blake Bender >Priority: Major > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9637) Disable Wan serialization test pending fix from Geode
[ https://issues.apache.org/jira/browse/GEODE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419925#comment-17419925 ] ASF subversion and git services commented on GEODE-9637: Commit b1b4f5a00c77610aa306a0dba7b5ead2c215cd7f in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=b1b4f5a ] GEODE-9637: Disable Wan deserialization test (#870) - Just want a green CI until GEODE-9634 is resolved. Co-authored-by: Blake Bender > Disable Wan serialization test pending fix from Geode > - > > Key: GEODE-9637 > URL: https://issues.apache.org/jira/browse/GEODE-9637 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > GEODE-9634 is currently breaking our Wan serialization test. This test is > fairly obscure and does something no one would ever do in production, so > while we wait for a bug fix from Geode, it's a fairly safe thing to simply > disable our failing test. This will get the CI pipeline back to green until > Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-9637) Disable Wan serialization test pending fix from Geode
[ https://issues.apache.org/jira/browse/GEODE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-9637. --- > Disable Wan serialization test pending fix from Geode > - > > Key: GEODE-9637 > URL: https://issues.apache.org/jira/browse/GEODE-9637 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > GEODE-9634 is currently breaking our Wan serialization test. This test is > fairly obscure and does something no one would ever do in production, so > while we wait for a bug fix from Geode, it's a fairly safe thing to simply > disable our failing test. This will get the CI pipeline back to green until > Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9637) Disable Wan serialization test pending fix from Geode
[ https://issues.apache.org/jira/browse/GEODE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419927#comment-17419927 ] ASF GitHub Bot commented on GEODE-9637: --- pdxcodemonkey merged pull request #870: URL: https://github.com/apache/geode-native/pull/870 -- 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 > Disable Wan serialization test pending fix from Geode > - > > Key: GEODE-9637 > URL: https://issues.apache.org/jira/browse/GEODE-9637 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > GEODE-9634 is currently breaking our Wan serialization test. This test is > fairly obscure and does something no one would ever do in production, so > while we wait for a bug fix from Geode, it's a fairly safe thing to simply > disable our failing test. This will get the CI pipeline back to green until > Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9639) Make native client compatible with C++20
Matthew Reddington created GEODE-9639: - Summary: Make native client compatible with C++20 Key: GEODE-9639 URL: https://issues.apache.org/jira/browse/GEODE-9639 Project: Geode Issue Type: Improvement Components: native client Reporter: Matthew Reddington There are standard library components that were removed in C++20, making our library incompatible. Luckily, our use of deleted components are minimal and replaceable without breaking API backward compatibility, but it will disrupt ABI compatibility. The outcome needs to be tested against MSVC2017/v141 and MSVC2019/v142, including examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9273) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable > testRollServersOnReplicatedRegion_dataserializable[from_v1.12.2] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419914#comment-17419914
]
Geode Integration commented on GEODE-9273:
--
Seen in [upgrade-test-openjdk8
#216|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/216]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0511/test-results/upgradeTest/1632506820/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0511/test-artifacts/1632506820/upgradetestfiles-openjdk8-1.15.0-build.0511.tgz].
> CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable >
> testRollServersOnReplicatedRegion_dataserializable[from_v1.12.2] FAILED
> --
>
> Key: GEODE-9273
> URL: https://issues.apache.org/jira/browse/GEODE-9273
> Project: Geode
> Issue Type: Test
> Components: serialization
>Reporter: Owen Nichols
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable
> > testRollServersOnReplicatedRegion_dataserializable[from_v1.12.2] 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-vm2.log' at line 780
> [fatal 2021/05/12 22:53:45.831 GMT tid=115] Uncaught
> exception in thread Thread[FederatingManager6,5,RMI Runtime]
> org.apache.geode.management.ManagementException:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Abandoned because shutdown is in progress
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:486)
> at
> org.apache.geode.management.internal.FederatingManager$AddMemberTask.call(FederatingManager.java:596)
> at
> org.apache.geode.management.internal.FederatingManager.lambda$addMember$1(FederatingManager.java:199)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Abandoned because shutdown is in progress
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:866)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor.initializeRegion(CreateRegionProcessor.java:115)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1161)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1092)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.InternalRegionFactory.create(InternalRegionFactory.java:78)
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:429)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8192) Redis MSET command needs to be atomic
[ https://issues.apache.org/jira/browse/GEODE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419912#comment-17419912 ] ASF subversion and git services commented on GEODE-8192: Commit db60e0e06b41ae3b37335bf29e2e9c3c3691b863 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=db60e0e ] GEODE-8192: Make Radish MSET command atomic (#6862) - Replace SynchronizedStripedCoordinator with LockingStripedCoordinator which locks against a list of locks instead of recurisively locking. - Perform the MSET operation within a transacation. This will avoid partial results in the case of a server shutdown. - Add DUnit tests to repeatedly crash the primary server while performing concurrent MSETs. > Redis MSET command needs to be atomic > - > > Key: GEODE-8192 > URL: https://issues.apache.org/jira/browse/GEODE-8192 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > Labels: pull-request-available > > All of the supported and unsupported redis string commands (for the 1.14 > release) that need to be atomic now are except for MSET. > Note that MGET does not need to be atomic. > To make MSET atomic it could do something like RENAME does to lock multiple > keys in a manner that prevent a distributed deadlock. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419901#comment-17419901 ] Geode Integration commented on GEODE-9638: -- Seen in [windows-unit-test-openjdk8 #206|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0511/test-results/test/1632501282/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0511/test-artifacts/1632501282/windows-unittestfiles-openjdk8-1.15.0-build.0511.tgz]. > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: flaky, needsTriage > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
Darrel Schneider created GEODE-9638: --- Summary: CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently Key: GEODE-9638 URL: https://issues.apache.org/jira/browse/GEODE-9638 Project: Geode Issue Type: Bug Components: core Reporter: Darrel Schneider org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName FAILED java.nio.file.DirectoryNotEmptyException: C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) at java.nio.file.Files.delete(Files.java:1126) at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) at org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) at org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) at org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) at org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) see: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9638: - Labels: needsTriage (was: ) > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9638: Labels: flaky needsTriage (was: needsTriage) > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: flaky, needsTriage > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9637) Disable Wan serialization test pending fix from Geode
[ https://issues.apache.org/jira/browse/GEODE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender reassigned GEODE-9637: --- Assignee: Blake Bender > Disable Wan serialization test pending fix from Geode > - > > Key: GEODE-9637 > URL: https://issues.apache.org/jira/browse/GEODE-9637 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > GEODE-9634 is currently breaking our Wan serialization test. This test is > fairly obscure and does something no one would ever do in production, so > while we wait for a bug fix from Geode, it's a fairly safe thing to simply > disable our failing test. This will get the CI pipeline back to green until > Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9636: - Labels: GeodeOperationAPI blocks-1.15.0 (was: GeodeOperationAPI) > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9637) Disable Wan serialization test pending fix from Geode
[ https://issues.apache.org/jira/browse/GEODE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9637: -- Labels: pull-request-available (was: ) > Disable Wan serialization test pending fix from Geode > - > > Key: GEODE-9637 > URL: https://issues.apache.org/jira/browse/GEODE-9637 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > GEODE-9634 is currently breaking our Wan serialization test. This test is > fairly obscure and does something no one would ever do in production, so > while we wait for a bug fix from Geode, it's a fairly safe thing to simply > disable our failing test. This will get the CI pipeline back to green until > Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9637) Disable Wan serialization test pending fix from Geode
[ https://issues.apache.org/jira/browse/GEODE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419898#comment-17419898 ] ASF GitHub Bot commented on GEODE-9637: --- pdxcodemonkey opened a new pull request #870: URL: https://github.com/apache/geode-native/pull/870 - Just want a green CI until GEODE-9634 is resolved. -- 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 > Disable Wan serialization test pending fix from Geode > - > > Key: GEODE-9637 > URL: https://issues.apache.org/jira/browse/GEODE-9637 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Priority: Major > > GEODE-9634 is currently breaking our Wan serialization test. This test is > fairly obscure and does something no one would ever do in production, so > while we wait for a bug fix from Geode, it's a fairly safe thing to simply > disable our failing test. This will get the CI pipeline back to green until > Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9637) Disable Wan serialization test pending fix from Geode
Blake Bender created GEODE-9637: --- Summary: Disable Wan serialization test pending fix from Geode Key: GEODE-9637 URL: https://issues.apache.org/jira/browse/GEODE-9637 Project: Geode Issue Type: Task Components: native client Reporter: Blake Bender GEODE-9634 is currently breaking our Wan serialization test. This test is fairly obscure and does something no one would ever do in production, so while we wait for a bug fix from Geode, it's a fairly safe thing to simply disable our failing test. This will get the CI pipeline back to green until Geode merges their change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9636: - Labels: GeodeOperationAPI (was: ) > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9630: - Labels: blocks-1.15.0 (was: blocks-1.15.0 needsTriage) > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > Labels: blocks-1.15.0 > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9630: - Labels: blocks-1.15.0 needsTriage (was: blocks-1.15.0) > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > Labels: blocks-1.15.0, needsTriage > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9480) KnownVersions class has 1.13.1 listed as the version for ordinal 121, but it should be 1.13.2
[ https://issues.apache.org/jira/browse/GEODE-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9480: - Labels: blocks-1.14.0 pull-request-available (was: blocks-1.14.0 needsTriage pull-request-available) > KnownVersions class has 1.13.1 listed as the version for ordinal 121, but it > should be 1.13.2 > - > > Key: GEODE-9480 > URL: https://issues.apache.org/jira/browse/GEODE-9480 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.13.5, 1.14.0, 1.15.0 > > > KnownVersion.java on develop and Version.java in the support/1.13 branch have > 1.13.1 listed as the version in which the protocol ordinal changed to 121. > However, 1.13.1 doesn't actually use that ordinal, it reports itself as using > protocol ordinal 120 (the same as 1.13.0). > This file should be changed to indicate that 1.13.2 is actually the version > in which the protocol changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9480) KnownVersions class has 1.13.1 listed as the version for ordinal 121, but it should be 1.13.2
[ https://issues.apache.org/jira/browse/GEODE-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9480: - Labels: blocks-1.14.0 needsTriage pull-request-available (was: blocks-1.14.0 pull-request-available) > KnownVersions class has 1.13.1 listed as the version for ordinal 121, but it > should be 1.13.2 > - > > Key: GEODE-9480 > URL: https://issues.apache.org/jira/browse/GEODE-9480 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: blocks-1.14.0, needsTriage, pull-request-available > Fix For: 1.13.5, 1.14.0, 1.15.0 > > > KnownVersion.java on develop and Version.java in the support/1.13 branch have > 1.13.1 listed as the version in which the protocol ordinal changed to 121. > However, 1.13.1 doesn't actually use that ordinal, it reports itself as using > protocol ordinal 120 (the same as 1.13.0). > This file should be changed to indicate that 1.13.2 is actually the version > in which the protocol changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-4181) Update to JUnit 5.x
[ https://issues.apache.org/jira/browse/GEODE-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419876#comment-17419876 ] ASF subversion and git services commented on GEODE-4181: Commit 1d6eef3511926d2a235b6c34577c7b3c0417ecd6 in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1d6eef3 ] GEODE-4181: Migrate uses of JUnitParamsRunner (#6890) Migrate all uses of `JUnitParamsRunner` to use a new runner that can be made compatible with JUnit 5. PROBLEM We want to upgrade Geode to use JUnit 5. JUnit 5 includes a test engine called JUnit Vintage, which it uses to run JUnit 4 tests. JUnit Vintage interacts with test runners differently than JUnit 4 did. `JUnitParamsRunner` is incompatible with JUnit Vintage in several ways: - When `JUnitParamsRunner` describes parameterized tests, it discards the `@Category` annotation that JUnit Vintage uses to filter tests by category. - When JUnit Vintage asks `JUnitParamsRunner` to filter tests by name, the runner fails to apply the filter to parameterized tests. The net result is that when JUnit Vintage tries to filter tests by category, `JUnitParamsRunner` runs every parameterized test, including tests that lack the category. This affects the Windows Gfsh distributed test job in particular, causing it to run 900 tests instead of the desired 200. Numerous of the extra 700 tests fail on Windows. This problem prevents us from upgrading to JUnit 5. `JUnitParamsRunner` is no longer maintained. It will not be made compatible with JUnit Vintage. Approximately 140 test classes use `JUnitParamsRunner`. To upgrade to JUnit 5, we will have to migrate all of these tests to use a runner compatible with JUnit Vintage. SOLUTION The solution involves two steps: 1. Migrate every existing use of `JUnitParamsRunner` to instead use a new `GeodeParamsRunner` that behaves identically to `JUnitParamsRunner`. 2. Upgrade Geode to use JUnit 5. This PR implements step 1. This PR implements a "dummy" version of `GeodeParamsRunner` that behaves identically to `JUnitParamsRunner`. Its only purpose is to allow migrating approximately 140 test classes to use the new runner name. I will implement step 2 in a later PR. This will include re-implementing `GeodeParamsRunner` to be compatible with JUnit 5. (I have verified the viability of this via a spike.) Separating the "migrate the tests" and "upgrade JUnit" steps into separate PRs makes each PR much more focused and much easier to review. > Update to JUnit 5.x > --- > > Key: GEODE-4181 > URL: https://issues.apache.org/jira/browse/GEODE-4181 > Project: Geode > Issue Type: Improvement > Components: general, tests >Reporter: Patrick Rhomberg >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > In addition to the expected benefits that come with new versions, updating to > JUnit 5.x should allow us to remove the workaround required in GEODE-1350 / > GEODE-4122. > If migration guides are to be believed, migration from JUnit 4.x to 5.x in > and of itself should not be difficult. However, interaction with Mockito and > PowerMock appears to be significantly different and will require > investigation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9566) Geode for Redis No Longer Experimental
[ https://issues.apache.org/jira/browse/GEODE-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419859#comment-17419859 ] ASF subversion and git services commented on GEODE-9566: Commit 09c01c8817705fec58e98ab5f06fa1650dbfa644 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=09c01c8 ] GEODE-9566: Radish is not experimental (#6897) > Geode for Redis No Longer Experimental > -- > > Key: GEODE-9566 > URL: https://issues.apache.org/jira/browse/GEODE-9566 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > Geode for Redis is no longer experimental. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9566) Geode for Redis No Longer Experimental
[ https://issues.apache.org/jira/browse/GEODE-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9566. --- Assignee: Jens Deppe Resolution: Fixed > Geode for Redis No Longer Experimental > -- > > Key: GEODE-9566 > URL: https://issues.apache.org/jira/browse/GEODE-9566 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > Geode for Redis is no longer experimental. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419842#comment-17419842 ] Geode Integration commented on GEODE-9636: -- Seen in [test-examples #243|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243]. > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419843#comment-17419843 ] Geode Integration commented on GEODE-9636: -- Seen in [test-examples #243.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243.1]. > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419844#comment-17419844 ] Geode Integration commented on GEODE-9636: -- Seen in [test-examples #244|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/244]. > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
Darrel Schneider created GEODE-9636: --- Summary: CI failure: NoClassDefFoundError in lucene examples Key: GEODE-9636 URL: https://issues.apache.org/jira/browse/GEODE-9636 Project: Geode Issue Type: Bug Components: lucene Reporter: Darrel Schneider The lucene examples have started failing (3 runs in a row) with the following exceptions: org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > serializerReturnsSingleDocument FAILED java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 Caused by: java.lang.ClassNotFoundException at TrainStopSerializerTest.java:30 org.apache.geode_examples.luceneSpatial.SpatialHelperTest > queryFindsADocumentThatWasAdded FAILED java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 The first failed run was: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9635) After gw sender is started with --clean queue, new received events are discarded
[ https://issues.apache.org/jira/browse/GEODE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-9635: --- Assignee: Mario Ivanac > After gw sender is started with --clean queue, new received events are > discarded > > > Key: GEODE-9635 > URL: https://issues.apache.org/jira/browse/GEODE-9635 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > After GW senders are startde with --clean queue option, new received events > are discarded until queue region buckets are initialized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9635) After gw sender is started with --clean queue, new received events are discarded
Mario Ivanac created GEODE-9635: --- Summary: After gw sender is started with --clean queue, new received events are discarded Key: GEODE-9635 URL: https://issues.apache.org/jira/browse/GEODE-9635 Project: Geode Issue Type: Bug Components: wan Affects Versions: 1.14.0 Reporter: Mario Ivanac After GW senders are startde with --clean queue option, new received events are discarded until queue region buckets are initialized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender updated GEODE-9634: Component/s: wan > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Blake Bender >Priority: Major > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
Blake Bender created GEODE-9634: --- Summary: Wan replication between clusters on localhost broken by change to IP lookup Key: GEODE-9634 URL: https://issues.apache.org/jira/browse/GEODE-9634 Project: Geode Issue Type: Bug Reporter: Blake Bender This was the fix for GEODE-8955 (PR #6045). Here's a description from the start of the Slack discussion thread: "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN replication between two clusters on localhost. I get the ridiculous nature of WAN over localhost. Is it intentional that localhost is replaced with a local interface IP by the changes made in the PR? The result is a test in the geode-native pipeline does not work anymore since one site can’t see the other since the locators are bound to localhost but trying to connection to each other on a non-localhost IP address. Did we run into this same issue on any of our Java based tests?" Need to determine if this is desired behavior or not. If not, the old behavior should be restored. If so, geode native team needs a JIRA ticket to fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9580) CI failure in DistributedAckPersistentRegionCCEDUnitTest > testNBRegionInvalidationDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419837#comment-17419837
]
Geode Integration commented on GEODE-9580:
--
Seen on support/1.12 in [distributed-test-openjdk8
#45|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk8/builds/45]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0284/test-results/distributedTest/1632334501/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0284/test-artifacts/1632334501/distributedtestfiles-openjdk8-1.12.5-build.0284.tgz].
> CI failure in DistributedAckPersistentRegionCCEDUnitTest >
> testNBRegionInvalidationDuringGetInitialImage
>
>
> Key: GEODE-9580
> URL: https://issues.apache.org/jira/browse/GEODE-9580
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.5
>Reporter: Bill Burcham
>Priority: Major
>
> CI/test failure in DistributedAckPersistentRegionCCEDUnitTest >
> testNBRegionInvalidationDuringGetInitialImage
> {code:java}
> Caused by: org.junit.ComparisonFailure: [Expected value for 84 to be null,
> but was [B@6c223a2e] expected: but was:<[66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419831#comment-17419831
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#208|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/208].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Updated] (GEODE-9479) Document correct start up order in WAN setups
[ https://issues.apache.org/jira/browse/GEODE-9479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9479: -- Labels: pull-request-available (was: ) > Document correct start up order in WAN setups > - > > Key: GEODE-9479 > URL: https://issues.apache.org/jira/browse/GEODE-9479 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > > I recently had to deal with an issue which root cause was the incorrect start > up order of a region an a receiver ([mail > thread|https://markmail.org/thread/qq32z5hducjoqndz]) > The correct order is: > - Senders > - Region > - Receivers > I have not been able to find this info in the user guide. I think a good > place could be the "Timing of Connections" sub-chapter on the "Overview of > Multi-site Caching" chapter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9479) Document correct start up order in WAN setups
[ https://issues.apache.org/jira/browse/GEODE-9479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-9479: --- Assignee: Alberto Bustamante Reyes > Document correct start up order in WAN setups > - > > Key: GEODE-9479 > URL: https://issues.apache.org/jira/browse/GEODE-9479 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > > I recently had to deal with an issue which root cause was the incorrect start > up order of a region an a receiver ([mail > thread|https://markmail.org/thread/qq32z5hducjoqndz]) > The correct order is: > - Senders > - Region > - Receivers > I have not been able to find this info in the user guide. I think a good > place could be the "Timing of Connections" sub-chapter on the "Overview of > Multi-site Caching" chapter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9633) Region and gateway receiver init order may cause a hang
Alberto Bustamante Reyes created GEODE-9633:
---
Summary: Region and gateway receiver init order may cause a hang
Key: GEODE-9633
URL: https://issues.apache.org/jira/browse/GEODE-9633
Project: Geode
Issue Type: Bug
Reporter: Alberto Bustamante Reyes
This ticket has been created as suggested on [the dev
list|https://markmail.org/thread/qq32z5hducjoqndz].
-
I have been analyzing an issue that occurs in the following scenario:
1) I start two Geode clusters (cluster1 & cluster2) with one locator and two
servers each.
Both clusters host a partitioned region called "testregion", which is replicated
using a parallel gateway sender and a gateway receiver.
( These are [the gfsh
files|https://gist.github.com/alb3rtobr/e230623255632937fa68265f31e97f3a] I
have been using for creating the clusters)
2) I run a client connected to cluster2 performing operations on testregion.
3) cluster1 is stopped and all persistent data is deleted. And then, I create
cluster1 again.
4) At this point, the command to create "testregion" get stuck.
After checking the thread stack and the code, I found that the problem is the
following.
This thread is trapped on an infinite loop waiting for a bucket primary election
at "PartitionedRegion.waitForNoStorageOrPrimary":
{code}
"Function Execution Processor4" tid=0x55
java.lang.Thread.State: TIMED_WAITING
at java.base@11.0.11/java.lang.Object.wait(Native Method)
- waiting on org.apache.geode.internal.cache.BucketAdvisor@28be7ae0
at
app//org.apache.geode.internal.cache.BucketAdvisor.waitForPrimaryMember(BucketAdvisor.java:1433)
at
app//org.apache.geode.internal.cache.BucketAdvisor.waitForNewPrimary(BucketAdvisor.java:825)
at
app//org.apache.geode.internal.cache.BucketAdvisor.getPrimary(BucketAdvisor.java:794)
at
app//org.apache.geode.internal.cache.partitioned.RegionAdvisor.getPrimaryMemberForBucket(RegionAdvisor.java:1032)
at
app//org.apache.geode.internal.cache.PartitionedRegion.getBucketPrimary(PartitionedRegion.java:9081)
at
app//org.apache.geode.internal.cache.PartitionedRegion.waitForNoStorageOrPrimary(PartitionedRegion.java:3249)
at
app//org.apache.geode.internal.cache.PartitionedRegion.getNodeForBucketWrite(PartitionedRegion.java:3234)
at
app//org.apache.geode.internal.cache.PartitionedRegion.shadowPRWaitForBucketRecovery(PartitionedRegion.java:10110)
at
app//org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:564)
at
app//org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:443)
at
app//org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
at
app//org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
at
app//org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1177)
at
app//org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3050)
at
app//org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2910)
at
app//org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2894)
at
app//org.apache.geode.cache.RegionFactory.create(RegionFactory.java:773)
{code}
After creating testregion, the sender queue partitioned region is created. While
that region buckets are recovered the command is trapped on an infinite loop
waiting for a primary bucket election at
PartitionedRegion.waitForNoStorageOrPrimary.
This seems to be a known issue because in
PartitionedRegion.getNodeForBucketWrite, there is the following command before
calling waitForNoStorageOrPrimary (and the command has been there since Geode's
first commit!) :
{code}
// Possible race with loss of redundancy at this point.
// This loop can possibly create a soft hang if no primary is ever selected.
// This is preferable to returning null since it will prevent obtaining the
// bucket lock for bucket creation.
return waitForNoStorageOrPrimary(bucketId, "write");
{code}
Any idea about why the primary bucket is not elected?
It seems the failure is related with the fact that "testregion" is receiving
updates from the receiver before the "create region" command has finished. If
the test is repeated without traffic on cluster2 or if I create the cluster1's
receiver after creating "testregion", this problem is not happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (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
]
Mario Kevo reassigned GEODE-9632:
-
Assignee: Mario Kevo
> 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
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard characters the Results field in
> QueryTrace is 100, but should be 0 as there is no attribute with that value
> or something similar.
> 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 8.95536 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 'something%'"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 17.171972 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
>
> {color:#1d1c1d}When we are using it without range index we got this:{color}
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE 'something%'"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 14049.559 ms; indexesUsed(0){code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9632) Wrong output for the range query with wildcard character
Mario Kevo created GEODE-9632:
-
Summary: 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
Reporter: Mario Kevo
We are using a range index on an attribute that is defined as HashMap.
The problem is when we are using wildcard characters the Results field in
QueryTrace is 100, but should be 0 as there is no attribute with that value or
something similar.
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 8.95536 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 'something%'"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 17.171972 ms; indexesUsed(1):index1(Results:
100)
{code}
{color:#1d1c1d}When we are using it without range index we got this:{color}
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE 'something%'"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 14049.559 ms; indexesUsed(0){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
