[jira] [Commented] (GEODE-8340) Enforce Switch compiler warnings as errors
[ https://issues.apache.org/jira/browse/GEODE-8340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186851#comment-17186851 ] ASF GitHub Bot commented on GEODE-8340: --- moleske commented on pull request #625: URL: https://github.com/apache/geode-native/pull/625#issuecomment-683194871 Per conversation with @pdxcodemonkey on the [asf slack](https://the-asf.slack.com/archives/C4RJQAQJF/p1598649633002500?thread_ts=1598634493.001700=C4RJQAQJF), went ahead and create [JIRA-8468](https://issues.apache.org/jira/browse/GEODE-8468) for enhancements to replace the couple of places with large enum switch statements with better control structures. I put the "GoodForNewContributors" label on it since I think this might be doable with only knowledge of control structures and less of internal of geode native, but feel free to take label off if you think it is more complex. And also update the description in the Jira if I missed something or it is unclear 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Enforce Switch compiler warnings as errors > -- > > Key: GEODE-8340 > URL: https://issues.apache.org/jira/browse/GEODE-8340 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Given I compile the code without exempting no-switch-enum and > no-implicit-fallthrough and no-covered-switch-default > Then it should compile > Note - was marked as a todo, seems reasonable to tackle all these at once -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8468) Review use of switch statements with enums
[ https://issues.apache.org/jira/browse/GEODE-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Oleske updated GEODE-8468: -- Labels: GoodForNewContributors (was: ) > Review use of switch statements with enums > -- > > Key: GEODE-8468 > URL: https://issues.apache.org/jira/browse/GEODE-8468 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: GoodForNewContributors > > We should check our usage of switch statements with enums > Before we add more enums > Because readability is important > Notes: While working on GEODE-8340, it was determined that some of the > places where a switch statement over enums was used were cases where a switch > statement was not the best control structure. The goal here is prevent a > long unwieldy list of switch statements. There are a lot of places to > review, so it will probably be easiest to do this over several PRs, which may > require several stories. The places listed below does not mean all of them > need to be fixed, but they should all be reviewed for improvement. For > further context, check out the comments on the [pr for > 8340|https://github.com/apache/geode-native/pull/625] > cppcache/integration-test/testThinClientCq.cpp at line 156ish > cppcache/integration-test/testThinClientCq.cpp at line 220ish > cppcache/integration-test/testThinClientCqDurable.cpp at line 125ish > cppcache/integration-test/testThinClientSecurityCQAuthorizationMU.cppline > 119ish > cppcache/integration-test/testThinClientSecurityDurableCQAuthorizationMU.cpp > at line 1229ish > cppcache/integration/test/SimpleCqListener.cpp at line 43ish > cppcache/src/CqQueryImpl.cpp at line 548ish > cppcache/src/CqService.cpp at line 71ish > cppcache/src/LRUAction.cpp at line 47ish > cppcache/src/LocalRegion.cpp at line 2586ish > cppcache/src/LocalRegion.cpp at line 2639ish > cppcache/src/LocalRegion.cpp at line 2696ish > cppcache/src/LocalRegion.cpp at line 2715ish > cppcache/src/LocalRegion.cpp at line 2781ish > cppcache/src/PdxInstanceImpl.cpp at line 247ish > cppcache/src/PdxInstanceImpl.cpp at line 485ish > cppcache/src/PdxInstanceImpl.cpp at line 667ish > cppcache/src/PdxInstanceImpl.cpp at line 1136ish > cppcache/src/SerializationRegistry.cpp at line 182ish > cppcache/src/SerializationRegistry.cpp at line 259ish > cppcache/src/SerializationRegistry.cpp at line 626ish > cppcache/src/SerializationRegistry.cpp at line 703ish > cppcache/src/TcrConnection.cpp at line 1194ish > cppcache/src/TcrMessage.cpp at line 1015ish > tests/cpp/fwklib/IpcHandler.cpp at line 231ish > tests/cpp/security/XmlAuthzCredentialGenerator.hpp at line 107ish > tests/cpp/security/XmlAuthzCredentialGenerator.hpp at line 162ish -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8447) Pulse should localize “java.util.Date” in the displayed query result
[ https://issues.apache.org/jira/browse/GEODE-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8447: Fix Version/s: 1.12.1 > Pulse should localize “java.util.Date” in the displayed query result > > > Key: GEODE-8447 > URL: https://issues.apache.org/jira/browse/GEODE-8447 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.12.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0 > > Attachments: CreatedOn-lastUpdated.JPG, Date-GF96.JPG > > > In previous versions of Geode, Pulse used to show Dates in localized string, > now it's not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8456) upgrade Shiro to 1.6.0
[ https://issues.apache.org/jira/browse/GEODE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8456: Fix Version/s: 1.12.1 > upgrade Shiro to 1.6.0 > -- > > Key: GEODE-8456 > URL: https://issues.apache.org/jira/browse/GEODE-8456 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0 > > > Our current Shiro version (1.5.3) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8468) Review use of switch statements with enums
Michael Oleske created GEODE-8468: - Summary: Review use of switch statements with enums Key: GEODE-8468 URL: https://issues.apache.org/jira/browse/GEODE-8468 Project: Geode Issue Type: Improvement Components: native client Reporter: Michael Oleske We should check our usage of switch statements with enums Before we add more enums Because readability is important Notes: While working on GEODE-8340, it was determined that some of the places where a switch statement over enums was used were cases where a switch statement was not the best control structure. The goal here is prevent a long unwieldy list of switch statements. There are a lot of places to review, so it will probably be easiest to do this over several PRs, which may require several stories. The places listed below does not mean all of them need to be fixed, but they should all be reviewed for improvement. For further context, check out the comments on the [pr for 8340|https://github.com/apache/geode-native/pull/625] cppcache/integration-test/testThinClientCq.cpp at line 156ish cppcache/integration-test/testThinClientCq.cpp at line 220ish cppcache/integration-test/testThinClientCqDurable.cpp at line 125ish cppcache/integration-test/testThinClientSecurityCQAuthorizationMU.cppline 119ish cppcache/integration-test/testThinClientSecurityDurableCQAuthorizationMU.cpp at line 1229ish cppcache/integration/test/SimpleCqListener.cpp at line 43ish cppcache/src/CqQueryImpl.cpp at line 548ish cppcache/src/CqService.cpp at line 71ish cppcache/src/LRUAction.cpp at line 47ish cppcache/src/LocalRegion.cpp at line 2586ish cppcache/src/LocalRegion.cpp at line 2639ish cppcache/src/LocalRegion.cpp at line 2696ish cppcache/src/LocalRegion.cpp at line 2715ish cppcache/src/LocalRegion.cpp at line 2781ish cppcache/src/PdxInstanceImpl.cpp at line 247ish cppcache/src/PdxInstanceImpl.cpp at line 485ish cppcache/src/PdxInstanceImpl.cpp at line 667ish cppcache/src/PdxInstanceImpl.cpp at line 1136ish cppcache/src/SerializationRegistry.cpp at line 182ish cppcache/src/SerializationRegistry.cpp at line 259ish cppcache/src/SerializationRegistry.cpp at line 626ish cppcache/src/SerializationRegistry.cpp at line 703ish cppcache/src/TcrConnection.cpp at line 1194ish cppcache/src/TcrMessage.cpp at line 1015ish tests/cpp/fwklib/IpcHandler.cpp at line 231ish tests/cpp/security/XmlAuthzCredentialGenerator.hpp at line 107ish tests/cpp/security/XmlAuthzCredentialGenerator.hpp at line 162ish -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8456) upgrade Shiro to 1.6.0
[ https://issues.apache.org/jira/browse/GEODE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186848#comment-17186848 ] ASF subversion and git services commented on GEODE-8456: Commit 881a0abff3cd8fc3968a4899c0b68d8d390b4caa in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=881a0ab ] GEODE-8456: bump Shiro to 1.6.0 (#5477) (cherry picked from commit 06174302b2c255fa6da8572fe7444df5dd1b2767) > upgrade Shiro to 1.6.0 > -- > > Key: GEODE-8456 > URL: https://issues.apache.org/jira/browse/GEODE-8456 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Our current Shiro version (1.5.3) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8467) server fails to notify of a ForcedDisconnect and fails to tear down the cache
Bruce J Schuchardt created GEODE-8467:
-
Summary: server fails to notify of a ForcedDisconnect and fails to
tear down the cache
Key: GEODE-8467
URL: https://issues.apache.org/jira/browse/GEODE-8467
Project: Geode
Issue Type: Bug
Components: membership
Affects Versions: 1.12.0, 1.11.0, 1.10.0, 1.13.0, 1.14.0
Reporter: Bruce J Schuchardt
A test having auto-reconnect enabled failed while restarting a server and hung.
The restarting server was building its cache when it was kicked out of the
cluster due to very high load on the test machine. Membership initiated a
forced-disconnect
{noformat}
[fatal 2020/08/22 00:51:04.508 PDT tid=0x23]
Membership service failure: Member isn't responding to heartbeat requests
org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
Member isn't responding to heartbeat requests
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
{noformat}
and then logged that it was generating a description of the cache
{noformat}
[info 2020/08/22 00:51:05.933 PDT tid=0x23]
generating XML to rebuild the cache after reconnect completes {noformat}
but it never logged completion of this step and never forked a thread to tear
down the cache. Any exception thrown by XML generation would have been caught
by JGroups code, which logs the problem at a WARNING level. We have JGroups
logging set to FATAL level so you wouldn't see the issue.
We need to add exception handling around XML generation and, if detected,
disable reconnect attempts and have the server shut down.
The bug isn't easy to hit. I've run the test that failed over 5000 times
without encountering it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8467) server fails to notify of a ForcedDisconnect and fails to tear down the cache
[
https://issues.apache.org/jira/browse/GEODE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-8467:
-
Assignee: Bruce J Schuchardt
> server fails to notify of a ForcedDisconnect and fails to tear down the cache
> -
>
> Key: GEODE-8467
> URL: https://issues.apache.org/jira/browse/GEODE-8467
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> A test having auto-reconnect enabled failed while restarting a server and
> hung. The restarting server was building its cache when it was kicked out of
> the cluster due to very high load on the test machine. Membership initiated
> a forced-disconnect
> {noformat}
> [fatal 2020/08/22 00:51:04.508 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> Membership service failure: Member isn't responding to heartbeat requests
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> {noformat}
>
> and then logged that it was generating a description of the cache
> {noformat}
> [info 2020/08/22 00:51:05.933 PDT receiver,rs-GEM-3035-PG2231-2a2i3large-hydra-client-25-42721> tid=0x23]
> generating XML to rebuild the cache after reconnect completes {noformat}
>
> but it never logged completion of this step and never forked a thread to tear
> down the cache. Any exception thrown by XML generation would have been
> caught by JGroups code, which logs the problem at a WARNING level. We have
> JGroups logging set to FATAL level so you wouldn't see the issue.
> We need to add exception handling around XML generation and, if detected,
> disable reconnect attempts and have the server shut down.
> The bug isn't easy to hit. I've run the test that failed over 5000 times
> without encountering it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8117) ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186804#comment-17186804
]
Jianxia Chen commented on GEODE-8117:
-
Reproduced again:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/415
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0311/test-results/integrationTest/1598644956/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0311/test-artifacts/1598644956/windows-coreintegrationtestfiles-OpenJDK11-1.14.0-build.0311.tgz
> ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile fails
> intermittently
>
>
> Key: GEODE-8117
> URL: https://issues.apache.org/jira/browse/GEODE-8117
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase
> expected:<[online]> but was:<[not responding]> 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.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:211)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:190)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:201)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:131)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:127)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile(ServerLauncherRemoteIntegrationTest.java:91)
> Caused by: org.junit.ComparisonFailure: expected:<[online]> but was:<[not
> responding]>
> at
> jdk.internal.reflect.GeneratedConstructorAccessor25.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(ServerLauncherRemoteIntegrationTestCase.java:213)
> at
> org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ... 1 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8109) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansOnServerAreUnaffectedByLocatorCrash failed with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186776#comment-17186776
]
Jianxia Chen commented on GEODE-8109:
-
Failed again:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/450
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0312/test-results/distributedTest/1598638468/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0312/test-artifacts/1598638468/distributedtestfiles-OpenJDK8-1.14.0-build.0312.tgz
> 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
>
> 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
[jira] [Commented] (GEODE-8447) Pulse should localize “java.util.Date” in the displayed query result
[ https://issues.apache.org/jira/browse/GEODE-8447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186762#comment-17186762 ] ASF subversion and git services commented on GEODE-8447: Commit ceacdbf0d06a9d8f2868eace7d86424a48e6e435 in geode's branch refs/heads/support/1.12 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ceacdbf ] GEODE-8447: QueryResultFormatter should show dates in localized strings (#5469) (cherry picked from commit 6ca548f8f81a60853d4b49def20d6eb69432bf24) * support java.util.Date, java.sql.Date and java.time.* date objects in the formatter > Pulse should localize “java.util.Date” in the displayed query result > > > Key: GEODE-8447 > URL: https://issues.apache.org/jira/browse/GEODE-8447 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.12.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > Attachments: CreatedOn-lastUpdated.JPG, Date-GF96.JPG > > > In previous versions of Geode, Pulse used to show Dates in localized string, > now it's not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8466) Create a ClassLoaderService to abstract away dealing with the default ClassLoader directly
[ https://issues.apache.org/jira/browse/GEODE-8466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-8466: Assignee: Udo Kohlmeyer > Create a ClassLoaderService to abstract away dealing with the default > ClassLoader directly > -- > > Key: GEODE-8466 > URL: https://issues.apache.org/jira/browse/GEODE-8466 > Project: Geode > Issue Type: New Feature > Components: core >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > With the addition of ClassLoader isolation using JBoss Modules GEODE-8067, > the manner in which we interact with the ClassLoader needs to change. > An abstraction is required around the default functions like > `findResourceAsStream`, `loadClass` and `loadService`. > As these features will behave differently between different ClassLoader > implementations, it is best to have a single service that will expose that > functionality in a transparent manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8466) Create a ClassLoaderService to abstract away dealing with the default ClassLoader directly
Udo Kohlmeyer created GEODE-8466: Summary: Create a ClassLoaderService to abstract away dealing with the default ClassLoader directly Key: GEODE-8466 URL: https://issues.apache.org/jira/browse/GEODE-8466 Project: Geode Issue Type: New Feature Components: core Reporter: Udo Kohlmeyer With the addition of ClassLoader isolation using JBoss Modules GEODE-8067, the manner in which we interact with the ClassLoader needs to change. An abstraction is required around the default functions like `findResourceAsStream`, `loadClass` and `loadService`. As these features will behave differently between different ClassLoader implementations, it is best to have a single service that will expose that functionality in a transparent manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8463) server's log filled with SSLException: Tag mismatch!
[
https://issues.apache.org/jira/browse/GEODE-8463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186641#comment-17186641
]
ASF subversion and git services commented on GEODE-8463:
Commit 20a35ece18054e96eccda70c65a015f4af26b4c7 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=20a35ec ]
GEODE-8463: server's log filled with SSLException: Tag mismatch! (#5482)
This disables the use of TLSv1.3 selection if "any" is specified as the
protocol and throws an exception if TLSv1.3 is requested in a JVM older
than Java 11. Most Java 8 implementations do not support TLSv1.3 - this
is currently only an issue with Oracle's 1.8.0_261 and above.
> server's log filled with SSLException: Tag mismatch!
>
>
> Key: GEODE-8463
> URL: https://issues.apache.org/jira/browse/GEODE-8463
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In a TLS test using the latest Oracle JDK8 server logs filled with these
> messages:
> {noformat}
> [info 2020/08/10 17:09:19.204 PDT rs-GEM-2886-FD2236a0i32xlarge-hydra-client-1(bridgegemfire4_host1_27404:27404):41003
> shared ordered uid=7 local port=41284
> remote port=37024> tid=0x6c] P2P message reader@26dd073d io exception for
> rs-GEM-2886-FD2236a0i32xlarge-hydra-client-1(bridgegemfire4_host1_27404:27404):41003(uid=7)
> javax.net.ssl.SSLException: Tag mismatch!
> at sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:327)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:270)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:265)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:119)
> at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:594)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:549)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:413)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:392)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:272)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2727)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1621)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1458)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.AEADBadTagException: Tag mismatch!
> at
> com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:620)
> at
> com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1116)
> at
> com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1053)
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853)
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
> at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826)
> at javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730)
> at javax.crypto.Cipher.doFinal(Cipher.java:2463)
> at
> sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1880)
> at
> sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:110)
> {noformat}
>
> The protocol and cipher were both set to "any".
> We determined that this was selecting TLSv1.3, which was only recently
> introduced as an available protocol in Oracle's JDK8. If TLSv1.2 is
> specified instead of "any" things work fine.
> The problem does not occur with Geode v1.13 unless you request TLSv1.3 with
> Oracle JDK8. We were using 1.8.0_261.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8463) server's log filled with SSLException: Tag mismatch!
[
https://issues.apache.org/jira/browse/GEODE-8463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8463.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> server's log filled with SSLException: Tag mismatch!
>
>
> Key: GEODE-8463
> URL: https://issues.apache.org/jira/browse/GEODE-8463
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> In a TLS test using the latest Oracle JDK8 server logs filled with these
> messages:
> {noformat}
> [info 2020/08/10 17:09:19.204 PDT rs-GEM-2886-FD2236a0i32xlarge-hydra-client-1(bridgegemfire4_host1_27404:27404):41003
> shared ordered uid=7 local port=41284
> remote port=37024> tid=0x6c] P2P message reader@26dd073d io exception for
> rs-GEM-2886-FD2236a0i32xlarge-hydra-client-1(bridgegemfire4_host1_27404:27404):41003(uid=7)
> javax.net.ssl.SSLException: Tag mismatch!
> at sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:327)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:270)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:265)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:119)
> at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:594)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:549)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:413)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:392)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:272)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2727)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1621)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1458)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.AEADBadTagException: Tag mismatch!
> at
> com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:620)
> at
> com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1116)
> at
> com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1053)
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853)
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
> at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826)
> at javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730)
> at javax.crypto.Cipher.doFinal(Cipher.java:2463)
> at
> sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1880)
> at
> sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:110)
> {noformat}
>
> The protocol and cipher were both set to "any".
> We determined that this was selecting TLSv1.3, which was only recently
> introduced as an available protocol in Oracle's JDK8. If TLSv1.2 is
> specified instead of "any" things work fine.
> The problem does not occur with Geode v1.13 unless you request TLSv1.3 with
> Oracle JDK8. We were using 1.8.0_261.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8463) server's log filled with SSLException: Tag mismatch!
[
https://issues.apache.org/jira/browse/GEODE-8463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186640#comment-17186640
]
ASF GitHub Bot commented on GEODE-8463:
---
bschuchardt merged pull request #5482:
URL: https://github.com/apache/geode/pull/5482
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> server's log filled with SSLException: Tag mismatch!
>
>
> Key: GEODE-8463
> URL: https://issues.apache.org/jira/browse/GEODE-8463
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> In a TLS test using the latest Oracle JDK8 server logs filled with these
> messages:
> {noformat}
> [info 2020/08/10 17:09:19.204 PDT rs-GEM-2886-FD2236a0i32xlarge-hydra-client-1(bridgegemfire4_host1_27404:27404):41003
> shared ordered uid=7 local port=41284
> remote port=37024> tid=0x6c] P2P message reader@26dd073d io exception for
> rs-GEM-2886-FD2236a0i32xlarge-hydra-client-1(bridgegemfire4_host1_27404:27404):41003(uid=7)
> javax.net.ssl.SSLException: Tag mismatch!
> at sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:327)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:270)
> at sun.security.ssl.TransportContext.fatal(TransportContext.java:265)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:119)
> at sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:594)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:549)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:413)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:392)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:272)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2727)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1621)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1458)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.AEADBadTagException: Tag mismatch!
> at
> com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:620)
> at
> com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1116)
> at
> com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1053)
> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853)
> at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
> at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826)
> at javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730)
> at javax.crypto.Cipher.doFinal(Cipher.java:2463)
> at
> sun.security.ssl.SSLCipher$T13GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1880)
> at
> sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
> at
> sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:110)
> {noformat}
>
> The protocol and cipher were both set to "any".
> We determined that this was selecting TLSv1.3, which was only recently
> introduced as an available protocol in Oracle's JDK8. If TLSv1.2 is
> specified instead of "any" things work fine.
> The problem does not occur with Geode v1.13 unless you request TLSv1.3 with
> Oracle JDK8. We were using 1.8.0_261.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8458) Rebuild GemFireVersion.properties on build-flag changes
[ https://issues.apache.org/jira/browse/GEODE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186632#comment-17186632 ] ASF subversion and git services commented on GEODE-8458: Commit d9d13100ae11e2eba8a6428fad29007388680b43 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d9d1310 ] GEODE-8458: Use build metadata properties as task inputs (#5480) GEODE-8458: Use build metadata properties as task inputs * Rebuilds GemFireVersion.properties on Git repo or property changes * version * HEAD sha * build user * java version * productName * etc * Drops the 'Build-Date' field from GemFireVersion.properties * This changes output of `gfsh version --full` * Source commit-date is still available, as is source-SHA * Removes `Build-Date` from tests and pulse > Rebuild GemFireVersion.properties on build-flag changes > --- > > Key: GEODE-8458 > URL: https://issues.apache.org/jira/browse/GEODE-8458 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > GemFireVersion.properties is a resource holding information about the product > and build metadata. It is possible to set these values for the first time > using Gradle property flags like '-Pversion=1.2.3-build.456'. On subsequent > runs, the property file should be re-built if those values have changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8458) Rebuild GemFireVersion.properties on build-flag changes
[ https://issues.apache.org/jira/browse/GEODE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186631#comment-17186631 ] ASF subversion and git services commented on GEODE-8458: Commit d9d13100ae11e2eba8a6428fad29007388680b43 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d9d1310 ] GEODE-8458: Use build metadata properties as task inputs (#5480) GEODE-8458: Use build metadata properties as task inputs * Rebuilds GemFireVersion.properties on Git repo or property changes * version * HEAD sha * build user * java version * productName * etc * Drops the 'Build-Date' field from GemFireVersion.properties * This changes output of `gfsh version --full` * Source commit-date is still available, as is source-SHA * Removes `Build-Date` from tests and pulse > Rebuild GemFireVersion.properties on build-flag changes > --- > > Key: GEODE-8458 > URL: https://issues.apache.org/jira/browse/GEODE-8458 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > GemFireVersion.properties is a resource holding information about the product > and build metadata. It is possible to set these values for the first time > using Gradle property flags like '-Pversion=1.2.3-build.456'. On subsequent > runs, the property file should be re-built if those values have changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8426) Enforce warning no-shorten-64-to-32
[
https://issues.apache.org/jira/browse/GEODE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-8426.
-
Resolution: Fixed
> Enforce warning no-shorten-64-to-32
> ---
>
> Key: GEODE-8426
> URL: https://issues.apache.org/jira/browse/GEODE-8426
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Oleske
>Assignee: Michael Oleske
>Priority: Major
> Labels: pull-request-available
>
> remove {{-Wno-shorten-64-to-32}} since it looks like it was already fixed by
> others
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8426) Enforce warning no-shorten-64-to-32
[
https://issues.apache.org/jira/browse/GEODE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender updated GEODE-8426:
Fix Version/s: 1.14.0
> Enforce warning no-shorten-64-to-32
> ---
>
> Key: GEODE-8426
> URL: https://issues.apache.org/jira/browse/GEODE-8426
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Oleske
>Assignee: Michael Oleske
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> remove {{-Wno-shorten-64-to-32}} since it looks like it was already fixed by
> others
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8426) Enforce warning no-shorten-64-to-32
[
https://issues.apache.org/jira/browse/GEODE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender closed GEODE-8426.
---
> Enforce warning no-shorten-64-to-32
> ---
>
> Key: GEODE-8426
> URL: https://issues.apache.org/jira/browse/GEODE-8426
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Michael Oleske
>Assignee: Michael Oleske
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> remove {{-Wno-shorten-64-to-32}} since it looks like it was already fixed by
> others
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8458) Rebuild GemFireVersion.properties on build-flag changes
[ https://issues.apache.org/jira/browse/GEODE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186627#comment-17186627 ] ASF subversion and git services commented on GEODE-8458: Commit d9d13100ae11e2eba8a6428fad29007388680b43 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d9d1310 ] GEODE-8458: Use build metadata properties as task inputs (#5480) GEODE-8458: Use build metadata properties as task inputs * Rebuilds GemFireVersion.properties on Git repo or property changes * version * HEAD sha * build user * java version * productName * etc * Drops the 'Build-Date' field from GemFireVersion.properties * This changes output of `gfsh version --full` * Source commit-date is still available, as is source-SHA * Removes `Build-Date` from tests and pulse > Rebuild GemFireVersion.properties on build-flag changes > --- > > Key: GEODE-8458 > URL: https://issues.apache.org/jira/browse/GEODE-8458 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > GemFireVersion.properties is a resource holding information about the product > and build metadata. It is possible to set these values for the first time > using Gradle property flags like '-Pversion=1.2.3-build.456'. On subsequent > runs, the property file should be re-built if those values have changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8454) dotnetsession SSL test broken after removal of cryptoimpl.dll
[
https://issues.apache.org/jira/browse/GEODE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender closed GEODE-8454.
---
> dotnetsession SSL test broken after removal of cryptoimpl.dll
> -
>
> Key: GEODE-8454
> URL: https://issues.apache.org/jira/browse/GEODE-8454
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> Failure output:
> {code:java}
> SessionStateStoreIntegrationTests.SessionStateWithSsl [FAIL]
> 16:06:56 System.IO.FileNotFoundException : cryptoImpl.dll was not found
> at C:\pivotal-gemfire-native\bin {code}
> Looks like the same issue we had with the dotnet example build - just need to
> stop looking for cryptoimpl, and things should work normally.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8458) Rebuild GemFireVersion.properties on build-flag changes
[ https://issues.apache.org/jira/browse/GEODE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186628#comment-17186628 ] ASF subversion and git services commented on GEODE-8458: Commit d9d13100ae11e2eba8a6428fad29007388680b43 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d9d1310 ] GEODE-8458: Use build metadata properties as task inputs (#5480) GEODE-8458: Use build metadata properties as task inputs * Rebuilds GemFireVersion.properties on Git repo or property changes * version * HEAD sha * build user * java version * productName * etc * Drops the 'Build-Date' field from GemFireVersion.properties * This changes output of `gfsh version --full` * Source commit-date is still available, as is source-SHA * Removes `Build-Date` from tests and pulse > Rebuild GemFireVersion.properties on build-flag changes > --- > > Key: GEODE-8458 > URL: https://issues.apache.org/jira/browse/GEODE-8458 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > GemFireVersion.properties is a resource holding information about the product > and build metadata. It is possible to set these values for the first time > using Gradle property flags like '-Pversion=1.2.3-build.456'. On subsequent > runs, the property file should be re-built if those values have changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8454) dotnetsession SSL test broken after removal of cryptoimpl.dll
[
https://issues.apache.org/jira/browse/GEODE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-8454.
-
Resolution: Not A Bug
> dotnetsession SSL test broken after removal of cryptoimpl.dll
> -
>
> Key: GEODE-8454
> URL: https://issues.apache.org/jira/browse/GEODE-8454
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> Failure output:
> {code:java}
> SessionStateStoreIntegrationTests.SessionStateWithSsl [FAIL]
> 16:06:56 System.IO.FileNotFoundException : cryptoImpl.dll was not found
> at C:\pivotal-gemfire-native\bin {code}
> Looks like the same issue we had with the dotnet example build - just need to
> stop looking for cryptoimpl, and things should work normally.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8454) dotnetsession SSL test broken after removal of cryptoimpl.dll
[
https://issues.apache.org/jira/browse/GEODE-8454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186626#comment-17186626
]
Blake Bender commented on GEODE-8454:
-
Closing - nothing to see here, .net session state provider is not a Geode
project. Oops.
> dotnetsession SSL test broken after removal of cryptoimpl.dll
> -
>
> Key: GEODE-8454
> URL: https://issues.apache.org/jira/browse/GEODE-8454
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> Failure output:
> {code:java}
> SessionStateStoreIntegrationTests.SessionStateWithSsl [FAIL]
> 16:06:56 System.IO.FileNotFoundException : cryptoImpl.dll was not found
> at C:\pivotal-gemfire-native\bin {code}
> Looks like the same issue we had with the dotnet example build - just need to
> stop looking for cryptoimpl, and things should work normally.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8458) Rebuild GemFireVersion.properties on build-flag changes
[ https://issues.apache.org/jira/browse/GEODE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton reassigned GEODE-8458: -- Assignee: Robert Houghton > Rebuild GemFireVersion.properties on build-flag changes > --- > > Key: GEODE-8458 > URL: https://issues.apache.org/jira/browse/GEODE-8458 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > GemFireVersion.properties is a resource holding information about the product > and build metadata. It is possible to set these values for the first time > using Gradle property flags like '-Pversion=1.2.3-build.456'. On subsequent > runs, the property file should be re-built if those values have changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8458) Rebuild GemFireVersion.properties on build-flag changes
[ https://issues.apache.org/jira/browse/GEODE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-8458. Fix Version/s: 1.14.0 Resolution: Fixed > Rebuild GemFireVersion.properties on build-flag changes > --- > > Key: GEODE-8458 > URL: https://issues.apache.org/jira/browse/GEODE-8458 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > GemFireVersion.properties is a resource holding information about the product > and build metadata. It is possible to set these values for the first time > using Gradle property flags like '-Pversion=1.2.3-build.456'. On subsequent > runs, the property file should be re-built if those values have changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8458) Rebuild GemFireVersion.properties on build-flag changes
[ https://issues.apache.org/jira/browse/GEODE-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186624#comment-17186624 ] ASF GitHub Bot commented on GEODE-8458: --- rhoughton-pivot merged pull request #5480: URL: https://github.com/apache/geode/pull/5480 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Rebuild GemFireVersion.properties on build-flag changes > --- > > Key: GEODE-8458 > URL: https://issues.apache.org/jira/browse/GEODE-8458 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > GemFireVersion.properties is a resource holding information about the product > and build metadata. It is possible to set these values for the first time > using Gradle property flags like '-Pversion=1.2.3-build.456'. On subsequent > runs, the property file should be re-built if those values have changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[
https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186590#comment-17186590
]
ASF GitHub Bot commented on GEODE-7672:
---
jinmeiliao commented on a change in pull request #5436:
URL: https://github.com/apache/geode/pull/5436#discussion_r479359658
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/cache/query/partitioned/PRClearQueryIndexDUnitTest.java
##
@@ -0,0 +1,369 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.cache.query.partitioned;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.SERIALIZABLE_OBJECT_FILTER;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.junit.rules.VMProvider.invokeInEveryMember;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.IntStream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ServerOperationException;
+import org.apache.geode.cache.query.Index;
+import org.apache.geode.cache.query.IndexStatistics;
+import org.apache.geode.cache.query.Query;
+import org.apache.geode.cache.query.QueryService;
+import org.apache.geode.cache.query.SelectResults;
+import org.apache.geode.cache.query.data.City;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.test.dunit.AsyncInvocation;
+import org.apache.geode.test.dunit.DUnitBlackboard;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.rules.ClientCacheRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+
+public class PRClearQueryIndexDUnitTest {
+ public static final String MUMBAI_QUERY = "select * from /cities c where
c.name = 'MUMBAI'";
+ public static final String ID_10_QUERY = "select * from /cities c where c.id
= 10";
+ @ClassRule
+ public static ClusterStartupRule cluster = new ClusterStartupRule(4, true);
+
+ private static MemberVM server1;
+ private static MemberVM server2;
+
+ private static DUnitBlackboard blackboard;
+
+ @Rule
+ public ClientCacheRule clientCacheRule = new ClientCacheRule();
+
+ @Rule
+ public ExecutorServiceRule executor = ExecutorServiceRule.builder().build();
+
+ private ClientCache clientCache;
+ private Region cities;
+
+ // class test setup. set up the servers, regions and indexes on the servers
+ @BeforeClass
+ public static void beforeClass() {
+int locatorPort = ClusterStartupRule.getDUnitLocatorPort();
+server1 = cluster.startServerVM(1, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+server2 = cluster.startServerVM(2, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+
+server1.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ // create indexes
+ QueryService queryService = cache.getQueryService();
+ queryService.createKeyIndex("cityId", "c.id", "/cities c");
+ queryService.createIndex("cityName", "c.name", "/cities c");
+ assertThat(cache.getQueryService().getIndexes(region))
+ .extracting(Index::getName).containsExactlyInAnyOrder("cityId",
"cityName");
+});
+
+server2.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ assertThat(cache.getQueryService().getIndexes(region))
+
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[
https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186588#comment-17186588
]
ASF GitHub Bot commented on GEODE-7672:
---
jinmeiliao commented on a change in pull request #5436:
URL: https://github.com/apache/geode/pull/5436#discussion_r479357437
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/cache/query/partitioned/PRClearQueryIndexDUnitTest.java
##
@@ -0,0 +1,369 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.cache.query.partitioned;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.SERIALIZABLE_OBJECT_FILTER;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.junit.rules.VMProvider.invokeInEveryMember;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.IntStream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ServerOperationException;
+import org.apache.geode.cache.query.Index;
+import org.apache.geode.cache.query.IndexStatistics;
+import org.apache.geode.cache.query.Query;
+import org.apache.geode.cache.query.QueryService;
+import org.apache.geode.cache.query.SelectResults;
+import org.apache.geode.cache.query.data.City;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.test.dunit.AsyncInvocation;
+import org.apache.geode.test.dunit.DUnitBlackboard;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.rules.ClientCacheRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+
+public class PRClearQueryIndexDUnitTest {
+ public static final String MUMBAI_QUERY = "select * from /cities c where
c.name = 'MUMBAI'";
+ public static final String ID_10_QUERY = "select * from /cities c where c.id
= 10";
+ @ClassRule
+ public static ClusterStartupRule cluster = new ClusterStartupRule(4, true);
+
+ private static MemberVM server1;
+ private static MemberVM server2;
+
+ private static DUnitBlackboard blackboard;
+
+ @Rule
+ public ClientCacheRule clientCacheRule = new ClientCacheRule();
+
+ @Rule
+ public ExecutorServiceRule executor = ExecutorServiceRule.builder().build();
+
+ private ClientCache clientCache;
+ private Region cities;
+
+ // class test setup. set up the servers, regions and indexes on the servers
+ @BeforeClass
+ public static void beforeClass() {
+int locatorPort = ClusterStartupRule.getDUnitLocatorPort();
+server1 = cluster.startServerVM(1, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+server2 = cluster.startServerVM(2, s ->
s.withConnectionToLocator(locatorPort)
+.withProperty(SERIALIZABLE_OBJECT_FILTER,
"org.apache.geode.cache.query.data.*")
+.withRegion(RegionShortcut.PARTITION, "cities"));
+
+server1.invoke(() -> {
+ Cache cache = ClusterStartupRule.getCache();
+ Region region = cache.getRegion("cities");
+ // create indexes
+ QueryService queryService = cache.getQueryService();
+ queryService.createKeyIndex("cityId", "c.id", "/cities c");
+ queryService.createIndex("cityName", "c.name", "/cities c");
Review comment:
I believe even with just one iteration, it's still a range index. There
are only 2 kinds of index now: range or key. Hash is deprecated.
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
[jira] [Resolved] (GEODE-8436) Several threads calling PdxInstanceFactory::create() causes seg fault
[
https://issues.apache.org/jira/browse/GEODE-8436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes resolved GEODE-8436.
-
Resolution: Fixed
> Several threads calling PdxInstanceFactory::create() causes seg fault
> -
>
> Key: GEODE-8436
> URL: https://issues.apache.org/jira/browse/GEODE-8436
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
> Attachments: main.cpp
>
>
> I have seen a problem when "PdxInstanceFactory::create()" is called by
> several threads that are registering the same new pdx type.
> The core is produced here:
> {code}
> void PdxInstanceImpl::toDataMutable(PdxWriter& writer) {
>auto pt = getPdxType();
>std::vector>* pdxFieldList =
>pt->getPdxFieldTypes();
> {code}
> The problem is that "getPdxType()" returns nullptr, so in the next line,
> there is segmentation fault when calling "pt->getPdxFieldTypes()".
> The issue can be reproduced using the attached client, and executing it using
> 8 threads. This is the stack got in gdb:
> {code}
> #0 apache::geode::client::PdxType::getPdxFieldTypes (this=0x0) at
> /home/alb3rtobr/CLionProjects/Nordix/geode-native/cppcache/src/PdxType.hpp:178
> #1 0x7f43dc4651b7 in
> apache::geode::client::PdxInstanceImpl::toDataMutable (this=0x7f43c0001600,
> writer=...) at
> /home/alb3rtobr/CLionProjects/Nordix/geode-native/cppcache/src/PdxInstanceImpl.cpp:1336
> #2 0x7f43dc4650fd in apache::geode::client::PdxInstanceImpl::toData
> (this=0x7f43c0001600, writer=...) at
> /home/alb3rtobr/CLionProjects/Nordix/geode-native/cppcache/src/PdxInstanceImpl.cpp:1327
> #3 0x7f43dc444971 in apache::geode::client::PdxHelper::serializePdx
> (output=..., pdxObject=warning: RTTI symbol not found for class
> 'std::_Sp_counted_ptr_inplace std::allocator,
> (__gnu_cxx::_Lock_policy)2>'
> warning: RTTI symbol not found for class
> 'std::_Sp_counted_ptr_inplace std::allocator,
> (__gnu_cxx::_Lock_policy)2>'
> std::shared_ptr (use count 3, weak
> count 0) = {...})
> at
> /home/alb3rtobr/CLionProjects/Nordix/geode-native/cppcache/src/PdxHelper.cpp:77
> #4 0x7f43dc44b4bc in apache::geode::client::PdxInstanceFactory::create
> (this=0x7f43c7ffecc8) at
> /home/alb3rtobr/CLionProjects/Nordix/geode-native/cppcache/src/PdxInstanceFactory.cpp:53
> #5 0x0040de2f in doPut () at
> /home/alb3rtobr/CLionProjects/dummy-client/main.cpp:60
> #6 0x00427767 in std::__invoke_impl
> (__f=@0x2561aa8: 0x40d860 ) at
> /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/invoke.h:60
> #7 0x004276fd in std::__invoke (__fn=@0x2561aa8:
> 0x40d860 ) at
> /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/invoke.h:95
> #8 0x004276d5 in std::thread::_Invoker
> >::_M_invoke<0ul> (this=0x2561aa8) at
> /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/thread:234
> #9 0x004276a5 in std::thread::_Invoker
> >::operator() (this=0x2561aa8) at
> /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/thread:243
> #10 0x00427589 in
> std::thread::_State_impl >
> >::_M_run (this=0x2561aa0)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
