[jira] [Assigned] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-8442:
-
Assignee: Mario Kevo
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.geode.internal.cache.ForceReattemptException:
> PartitionResponse got remote CacheClosedException
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForC
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[
https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230336#comment-17230336
]
ASF GitHub Bot commented on GEODE-8700:
---
gaussianrecurrence commented on a change in pull request #691:
URL: https://github.com/apache/geode-native/pull/691#discussion_r521793026
##
File path: cppcache/include/geode/AttributesMutator.hpp
##
@@ -190,6 +191,22 @@ class APACHE_GEODE_EXPORT AttributesMutator {
*/
void setCacheWriter(const std::string& libpath,
const std::string& factoryFuncName);
+
+ /** Sets partition resolver writer for region. The previous partition
resolver
+ * will be replaced with resolver.
+ * @param resolver PartitionResolver
+ */
+ void setPartitionResolver(std::shared_ptr resolver);
+
+ /** Sets cache writer for region. The previous partition resolver will be
+ * replaced with the one created using the factory function provided in
+ * the given library.
+ * @param library_path path of the library containing partition resolver
+ * factory function.
+ * @param function factory function for creating a partition resolver.
+ */
+ void setPartitionResolver(const std::string& library_path,
Review comment:
Indeed, I don't actually need the library one. Good catch :) will remove
it!
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
> Add the ability to change the partition resolver
>
>
> Key: GEODE-8700
> URL: https://issues.apache.org/jira/browse/GEODE-8700
> Project: Geode
> Issue Type: New Feature
> Components: native client
>Affects Versions: 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS A* native client contributor
> *I WANT* to be able to mutate partition resolver
> *SO THAT* I don't need to create a shared library to specify one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[
https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230335#comment-17230335
]
ASF GitHub Bot commented on GEODE-8700:
---
pivotal-jbarrett commented on a change in pull request #691:
URL: https://github.com/apache/geode-native/pull/691#discussion_r521791548
##
File path: cppcache/include/geode/AttributesMutator.hpp
##
@@ -190,6 +191,22 @@ class APACHE_GEODE_EXPORT AttributesMutator {
*/
void setCacheWriter(const std::string& libpath,
const std::string& factoryFuncName);
+
+ /** Sets partition resolver writer for region. The previous partition
resolver
+ * will be replaced with resolver.
+ * @param resolver PartitionResolver
+ */
+ void setPartitionResolver(std::shared_ptr resolver);
+
+ /** Sets cache writer for region. The previous partition resolver will be
+ * replaced with the one created using the factory function provided in
+ * the given library.
+ * @param library_path path of the library containing partition resolver
+ * factory function.
+ * @param function factory function for creating a partition resolver.
+ */
+ void setPartitionResolver(const std::string& library_path,
Review comment:
Unless this is explicitly needed by your use case, and I really hope it
isn't, let's avoid expanding on this API to load things from arbitrary
libraries.
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
> Add the ability to change the partition resolver
>
>
> Key: GEODE-8700
> URL: https://issues.apache.org/jira/browse/GEODE-8700
> Project: Geode
> Issue Type: New Feature
> Components: native client
>Affects Versions: 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS A* native client contributor
> *I WANT* to be able to mutate partition resolver
> *SO THAT* I don't need to create a shared library to specify one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8607) Add new API for getting oldest tombstone age.
[ https://issues.apache.org/jira/browse/GEODE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230332#comment-17230332 ] ASF subversion and git services commented on GEODE-8607: Commit b027331aa47e51c492c9a2aab414b6abfb69bd51 in geode's branch refs/heads/support/1.12 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b027331 ] GEODE-8607: Adding some test API to get oldest tombstone (#5623) (#5733) - Adding some test API to get oldest tombstone timestamp - Adding some test API for getting the oldest tombstone (cherry picked from commit eb91e9517f579c005c7b69937b8cfced7d3cc37e) (cherry picked from commit 3890db1cd755dfbbd28816055fab2a3f34385542) > Add new API for getting oldest tombstone age. > - > > Key: GEODE-8607 > URL: https://issues.apache.org/jira/browse/GEODE-8607 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > It would be handy in diagnosing certain issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8607) Add new API for getting oldest tombstone age.
[ https://issues.apache.org/jira/browse/GEODE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230331#comment-17230331 ] ASF subversion and git services commented on GEODE-8607: Commit b027331aa47e51c492c9a2aab414b6abfb69bd51 in geode's branch refs/heads/support/1.12 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b027331 ] GEODE-8607: Adding some test API to get oldest tombstone (#5623) (#5733) - Adding some test API to get oldest tombstone timestamp - Adding some test API for getting the oldest tombstone (cherry picked from commit eb91e9517f579c005c7b69937b8cfced7d3cc37e) (cherry picked from commit 3890db1cd755dfbbd28816055fab2a3f34385542) > Add new API for getting oldest tombstone age. > - > > Key: GEODE-8607 > URL: https://issues.apache.org/jira/browse/GEODE-8607 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > It would be handy in diagnosing certain issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230323#comment-17230323 ] ASF GitHub Bot commented on GEODE-8700: --- gaussianrecurrence commented on pull request #691: URL: https://github.com/apache/geode-native/pull/691#issuecomment-72530 Maybe @moleske @pivotal-jbarrett @mreddington @pdxcodemonkey you could throw some comments? Thanks! 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 > Add the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8685) Exporting data causes a ClassNotFoundException
[
https://issues.apache.org/jira/browse/GEODE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8685:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> Exporting data causes a ClassNotFoundException
> --
>
> Key: GEODE-8685
> URL: https://issues.apache.org/jira/browse/GEODE-8685
> Project: Geode
> Issue Type: Task
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Anthony Baker
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> See
> [https://lists.apache.org/thread.html/rfa4fc47eb4cb4e75c39d7cb815416bebf2ec233d4db24e37728e922e%40%3Cuser.geode.apache.org%3E.]
>
> Report is that exporting data whose values are Classes defined in a deployed
> jar result in a ClassNotFound exception:
> {noformat}
> [error 2020/10/30 08:54:29.317 PDT tid=0x41]
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> java.io.IOException: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter.export(WindowedExporter.java:106)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.exportOnMember(RegionSnapshotServiceImpl.java:361)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:161)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:146)
> at
> org.apache.geode.management.internal.cli.functions.ExportDataFunction.executeFunction(ExportDataFunction.java:62)
> at
> org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:442)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:377)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter$WindowedExportCollector.setException(WindowedExporter.java:383)
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter$WindowedExportCollector.addResult(WindowedExporter.java:346)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultSender.lastResult(PartitionedRegionFunctionResultSender.java:195)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.handleException(AbstractExecution.java:502)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:353)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.lambda$executeFunctionOnLocalPRNode$0(AbstractExecution.java:273)
> ... 6 more
> Caused by: org.apache.geode.SerializationException: A ClassNotFoundException
> was thrown while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2046)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2032)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:135)
> at
> org.apache.geode.internal.cache.EntrySnapshot.getRawValue(EntrySnapshot.java:111)
> at
> org.apache.geode.internal.cache.EntrySnapshot.getRawValue(EntrySnapshot.java:99)
> at
> org.apache.geode.internal.cache.EntrySnapshot.getValue(EntrySnapshot.java:129)
>
[jira] [Commented] (GEODE-8685) Exporting data causes a ClassNotFoundException
[
https://issues.apache.org/jira/browse/GEODE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230320#comment-17230320
]
ASF GitHub Bot commented on GEODE-8685:
---
dschneider-pivotal opened a new pull request #5735:
URL: https://github.com/apache/geode/pull/5735
Modified test to fail if it attempts to deserialize values during export.
Fixed product export code to no longer deserialize and test now passes.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
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
> Exporting data causes a ClassNotFoundException
> --
>
> Key: GEODE-8685
> URL: https://issues.apache.org/jira/browse/GEODE-8685
> Project: Geode
> Issue Type: Task
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Anthony Baker
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI
>
> See
> [https://lists.apache.org/thread.html/rfa4fc47eb4cb4e75c39d7cb815416bebf2ec233d4db24e37728e922e%40%3Cuser.geode.apache.org%3E.]
>
> Report is that exporting data whose values are Classes defined in a deployed
> jar result in a ClassNotFound exception:
> {noformat}
> [error 2020/10/30 08:54:29.317 PDT tid=0x41]
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> java.io.IOException: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter.export(WindowedExporter.java:106)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.exportOnMember(RegionSnapshotServiceImpl.java:361)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:161)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:146)
> at
> org.apache.geode.management.internal.cli.functions.ExportDataFunction.executeFunction(ExportDataFunction.java:62)
> at
> org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:442)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:377)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> at
>
[jira] [Commented] (GEODE-8607) Add new API for getting oldest tombstone age.
[ https://issues.apache.org/jira/browse/GEODE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230316#comment-17230316 ] ASF subversion and git services commented on GEODE-8607: Commit 3890db1cd755dfbbd28816055fab2a3f34385542 in geode's branch refs/heads/support/1.13 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3890db1 ] GEODE-8607: Adding some test API to get oldest tombstone (#5623) (#5733) - Adding some test API to get oldest tombstone timestamp - Adding some test API for getting the oldest tombstone (cherry picked from commit eb91e9517f579c005c7b69937b8cfced7d3cc37e) > Add new API for getting oldest tombstone age. > - > > Key: GEODE-8607 > URL: https://issues.apache.org/jira/browse/GEODE-8607 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > It would be handy in diagnosing certain issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8607) Add new API for getting oldest tombstone age.
[ https://issues.apache.org/jira/browse/GEODE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230314#comment-17230314 ] ASF subversion and git services commented on GEODE-8607: Commit 3890db1cd755dfbbd28816055fab2a3f34385542 in geode's branch refs/heads/support/1.13 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3890db1 ] GEODE-8607: Adding some test API to get oldest tombstone (#5623) (#5733) - Adding some test API to get oldest tombstone timestamp - Adding some test API for getting the oldest tombstone (cherry picked from commit eb91e9517f579c005c7b69937b8cfced7d3cc37e) > Add new API for getting oldest tombstone age. > - > > Key: GEODE-8607 > URL: https://issues.apache.org/jira/browse/GEODE-8607 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > It would be handy in diagnosing certain issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-7884:
Fix Version/s: 1.12.1
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> 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.12.1, 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:156)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5038)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1637)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1624)
> {noformat}
> Logs show this same thread hitting an IllegalStateException when trying to
> send a message:
> {noformat}
> (edited)
> [fatal 2020/03/10 23:13:08.441 PDT tid=0x67] While pushing message <>
> to recipients: <>
> java.lang.IllegalStateException: Task already scheduled or cancelled
> at java.util.Timer.sched(Timer.java:401)
> at java.util.Timer.schedule(Timer.java:193)
> at org.apache.geode.internal.SystemTimer.schedule(SystemTimer.java:347)
> at
> org.apache.geode.internal.tcp.Connection.scheduleAckTimeouts(Connection.java:1956)
> at
> org.apache.geode.internal.tcp.MsgStreamer.reserveConnections(MsgStreamer.java:225)
> at
> org.apache.geode.internal.tcp.MsgStreamerList.reserveConnections(MsgStreamerList.java:51)
>
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230313#comment-17230313
]
ASF GitHub Bot commented on GEODE-8623:
---
Bill commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521740981
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -0,0 +1,73 @@
+/*
+ * 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.internal;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+import java.util.function.Predicate;
+import java.util.function.Supplier;
+
+/**
+ * Utility class for retrying operations.
+ */
+public class Retry {
+
+ interface Clock {
+long nanoTime();
+ }
+
+ private static class SteadyClock implements Clock {
+@Override
+public long nanoTime() {
+ return System.nanoTime();
+}
+ }
+
+ private static final SteadyClock steadyClock = new SteadyClock();
+
+ /**
+ * Try the supplier function until the predicate is true or timeout occurs.
+ *
+ * @param supplier to execute until predicate is true or times out
+ * @param predicate to test for retry
+ * @param timeout to retry for
+ * @param timeUnit to retry for
+ * @param type of return value
+ * @return value from supplier after it passes predicate or times out.
+ */
+ public static T tryFor(final Supplier supplier, final Predicate
predicate,
+ final long timeout, final TimeUnit timeUnit) throws TimeoutException {
+return tryFor(supplier, predicate, timeout, timeUnit, steadyClock);
+ }
+
+ static T tryFor(final Supplier supplier, final Predicate predicate,
+ final long timeout, final TimeUnit timeUnit, final Clock clock)
+ throws TimeoutException {
+long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+
+T value;
+do {
+ value = supplier.get();
+ if (predicate.test(value)) {
+return value;
+ }
+} while (clock.nanoTime() < until);
Review comment:
This is a hot loop unless `supplier` or `predicate` sleeps. On the one
hand that's cool because it leave sleeping outside this class. On the other
hand, um, it might be nice to have this structured to not have a hot loop by
default.
Similar to the way the `Clock` implementation is injected, a sleeper could
be injected, if you wanted to do that, maybe you could:
```
@FunctionalInterface
public interface Sleeper {
void sleep() throw InterruptedException;
}
```
and after `predicate` evaluates to `false`:
```
sleeper.sleep(...)
```
Where the sleep time comes from parameters the way `timeout` et al. do now.
Note that some sophistication could be added to clamp the sleep time so as
to try and not overflow `until` by too much. Then again, that might turn into a
fools errand.
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
try {
- inetAddress =
InetAddress.getByAddress(InetAddress.getLocalHost().getAddress());
- if (inetAddress.isLoopbackAddress()) {
-InetAddress ipv4Fallback = null;
-InetAddress ipv6Fallback = null;
-// try to find a non-loopback
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230300#comment-17230300
]
ASF GitHub Bot commented on GEODE-8623:
---
pivotal-jbarrett commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521719226
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
Review comment:
There is a test that already asserts the retry behavior outside the
context of the thing being retried. Testing this method specifically must be an
integration test since it requires the use of a resolver and DNS. There are
several tests that are tangentially dependent on this method given that nothing
in Geode starts if this method returns `UnknownHostException`.
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(Mana
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230299#comment-17230299
]
ASF GitHub Bot commented on GEODE-8623:
---
pivotal-jbarrett commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521717339
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
try {
- inetAddress =
InetAddress.getByAddress(InetAddress.getLocalHost().getAddress());
- if (inetAddress.isLoopbackAddress()) {
-InetAddress ipv4Fallback = null;
-InetAddress ipv6Fallback = null;
-// try to find a non-loopback address
-Set myInterfaces = getMyAddresses();
-boolean preferIPv6 = useIPv6Addresses;
-String lhName = null;
-for (InetAddress addr : myInterfaces) {
- if (addr.isLoopbackAddress() || addr.isAnyLocalAddress() || lhName
!= null) {
-break;
- }
- boolean ipv6 = addr instanceof Inet6Address;
- boolean ipv4 = addr instanceof Inet4Address;
- if ((preferIPv6 && ipv6) || (!preferIPv6 && ipv4)) {
-String addrName = reverseDNS(addr);
-if (inetAddress.isLoopbackAddress()) {
- inetAddress = addr;
- lhName = addrName;
-} else if (addrName != null) {
- inetAddress = addr;
- lhName = addrName;
+ return tryFor(() -> {
+InetAddress inetAddress = null;
+try {
+ inetAddress =
InetAddress.getByAddress(InetAddress.getLocalHost().getAddress());
+ if (inetAddress.isLoopbackAddress()) {
+InetAddress ipv4Fallback = null;
+InetAddress ipv6Fallback = null;
+// try to find a non-loopback address
+Set myInterfaces = getMyAddresses();
+boolean preferIPv6 = useIPv6Addresses;
+String lhName = null;
+for (InetAddress addr : myInterfaces) {
+ if (addr.isLoopbackAddress() || addr.isAnyLocalAddress() ||
lhName != null) {
+break;
+ }
+ boolean ipv6 = addr instanceof Inet6Address;
+ boolean ipv4 = addr instanceof Inet4Address;
+ if ((preferIPv6 && ipv6) || (!preferIPv6 && ipv4)) {
+String addrName = reverseDNS(addr);
+if (inetAddress.isLoopbackAddress()) {
+ inetAddress = addr;
+ lhName = addrName;
+} else if (addrName != null) {
+ inetAddress = addr;
+ lhName = addrName;
+}
+ } else {
+if (preferIPv6 && ipv4 && ipv4Fallback == null) {
+ ipv4Fallback = addr;
+} else if (!preferIPv6 && ipv6 && ipv6Fallback == null) {
+ ipv6Fallback = addr;
+}
+ }
}
- } else {
-if (preferIPv6 && ipv4 && ipv4Fallback == null) {
- ipv4Fallback = addr;
-} else if (!preferIPv6 && ipv6 && ipv6Fallback == null) {
- ipv6Fallback = addr;
+// vanilla Ubuntu installations will have a usable IPv6 address
when
+// running as a guest OS on an IPv6-enabled machine. We also look
for
+// the alternative IPv4 configuration.
+if (inetAddress.isLoopbackAddress()) {
+ if (ipv4Fallback != null) {
+inetAddress = ipv4Fallback;
+useIPv6Addresses = false;
+ } else if (ipv6Fallback != null) {
+inetAddress = ipv6Fallback;
+useIPv6Addresses = true;
+ }
}
}
+} catch (UnknownHostException ignored) {
}
-// vanilla Ubuntu installations will have a usable IPv6 address when
-// running as a guest OS on an IPv6-enabled machine. We also look for
-// the alternative IPv4 configuration.
-if (inetAddress.isLoopbackAddress()) {
- if (ipv4Fallback !=
[jira] [Comment Edited] (GEODE-8685) Exporting data causes a ClassNotFoundException
[
https://issues.apache.org/jira/browse/GEODE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230293#comment-17230293
]
Darrel Schneider edited comment on GEODE-8685 at 11/11/20, 11:42 PM:
-
Why is the value being deserialized at all?
_The following is based on code on the develop branch (post 1.13)._
In this particular case is is because the Entry instances being iterated over
are instances of EntrySnapshot (only used by partitioned regions) instead of
NonTXEntry instances.
This code would have saved us and passed the serialized CachedDeserializable
to "convertToBytes" if the entry had been a NonTXEntry:
{code:java}
public SnapshotRecord(LocalRegion region, Entry entry) throws
IOException {
key = BlobHelper.serializeToBlob(entry.getKey());
if (entry instanceof NonTXEntry && region != null) {
@Released
Object v =
((NonTXEntry)
entry).getRegionEntry().getValueOffHeapOrDiskWithoutFaultIn(region);
try {
value = convertToBytes(v);
} finally {
OffHeapHelper.release(v);
}
} else {
value = convertToBytes(entry.getValue());
}
}
{code}
But because it was an EntrySnapshot it goes down to the else and just call
entry.getValue() which on an EntrySnapshot always returns the deserialized
value. This is the getValue() call we see fail because the class is not found.
I could not find any evidence that we have changed the code that iterates the
region entries or that we changed the implementation of the entry iteration on
a partitioned region. It looks like it has used EntrySnapshot instances since
geode existed. We probably have export tests for partitioned regions but they
may not check that the value is not being deserialized.
It would be rather easy to add a method on EntrySnapshot that exposes the
CachedDeserializable and pass that to convertToBytes which already does the
right thing with a CachedDeserializable.
was (Author: dschneider):
Why is the value being deserialized at all?
In this particular case is is because the Entry instances being iterated over
are instances of EntrySnapshot (only used by partitioned regions) instead of
NonTXEntry instances.
This code would have saved us and passed the serialized CachedDeserializable to
"convertToBytes" if the entry had been a NonTXEntry:
{code:java}
public SnapshotRecord(LocalRegion region, Entry entry) throws
IOException {
key = BlobHelper.serializeToBlob(entry.getKey());
if (entry instanceof NonTXEntry && region != null) {
@Released
Object v =
((NonTXEntry)
entry).getRegionEntry().getValueOffHeapOrDiskWithoutFaultIn(region);
try {
value = convertToBytes(v);
} finally {
OffHeapHelper.release(v);
}
} else {
value = convertToBytes(entry.getValue());
}
}
{code}
But because it was an EntrySnapshot it goes down to the else and just call
entry.getValue() which on an EntrySnapshot always returns the deserialized
value. This is the getValue() call we see fail because the class is not found.
I could not find any evidence that we have changed the code that iterates the
region entries or that we changed the implementation of the entry iteration on
a partitioned region. It looks like it has used EntrySnapshot instances since
geode existed. We probably have export tests for partitioned regions but they
may not check that the value is not being deserialized.
It would be rather easy to add a method on EntrySnapshot that exposes the
CachedDeserializable and pass that to convertToBytes which already does the
right thing with a CachedDeserializable.
> Exporting data causes a ClassNotFoundException
> --
>
> Key: GEODE-8685
> URL: https://issues.apache.org/jira/browse/GEODE-8685
> Project: Geode
> Issue Type: Task
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Anthony Baker
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI
>
> See
> [https://lists.apache.org/thread.html/rfa4fc47eb4cb4e75c39d7cb815416bebf2ec233d4db24e37728e922e%40%3Cuser.geode.apache.org%3E.]
>
> Report is that exporting data whose values are Classes defined in a deployed
> jar result in a ClassNotFound exception:
> {noformat}
> [error 2020/10/30 08:54:29.317 PDT tid=0x41]
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> java.io.IOException: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
>
[jira] [Commented] (GEODE-8685) Exporting data causes a ClassNotFoundException
[
https://issues.apache.org/jira/browse/GEODE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230293#comment-17230293
]
Darrel Schneider commented on GEODE-8685:
-
Why is the value being deserialized at all?
In this particular case is is because the Entry instances being iterated over
are instances of EntrySnapshot (only used by partitioned regions) instead of
NonTXEntry instances.
This code would have saved us and passed the serialized CachedDeserializable to
"convertToBytes" if the entry had been a NonTXEntry:
{code:java}
public SnapshotRecord(LocalRegion region, Entry entry) throws
IOException {
key = BlobHelper.serializeToBlob(entry.getKey());
if (entry instanceof NonTXEntry && region != null) {
@Released
Object v =
((NonTXEntry)
entry).getRegionEntry().getValueOffHeapOrDiskWithoutFaultIn(region);
try {
value = convertToBytes(v);
} finally {
OffHeapHelper.release(v);
}
} else {
value = convertToBytes(entry.getValue());
}
}
{code}
But because it was an EntrySnapshot it goes down to the else and just call
entry.getValue() which on an EntrySnapshot always returns the deserialized
value. This is the getValue() call we see fail because the class is not found.
I could not find any evidence that we have changed the code that iterates the
region entries or that we changed the implementation of the entry iteration on
a partitioned region. It looks like it has used EntrySnapshot instances since
geode existed. We probably have export tests for partitioned regions but they
may not check that the value is not being deserialized.
It would be rather easy to add a method on EntrySnapshot that exposes the
CachedDeserializable and pass that to convertToBytes which already does the
right thing with a CachedDeserializable.
> Exporting data causes a ClassNotFoundException
> --
>
> Key: GEODE-8685
> URL: https://issues.apache.org/jira/browse/GEODE-8685
> Project: Geode
> Issue Type: Task
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Anthony Baker
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI
>
> See
> [https://lists.apache.org/thread.html/rfa4fc47eb4cb4e75c39d7cb815416bebf2ec233d4db24e37728e922e%40%3Cuser.geode.apache.org%3E.]
>
> Report is that exporting data whose values are Classes defined in a deployed
> jar result in a ClassNotFound exception:
> {noformat}
> [error 2020/10/30 08:54:29.317 PDT tid=0x41]
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> java.io.IOException: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter.export(WindowedExporter.java:106)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.exportOnMember(RegionSnapshotServiceImpl.java:361)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:161)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:146)
> at
> org.apache.geode.management.internal.cli.functions.ExportDataFunction.executeFunction(ExportDataFunction.java:62)
> at
> org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:442)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:377)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNo
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230283#comment-17230283
]
ASF GitHub Bot commented on GEODE-8623:
---
demery-pivotal commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521693520
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
Review comment:
If you want to test, you can create an overload that takes suppliers,
functions, and predicates to call instead of calling static methods, then mock
those things to drive the desired test conditions. Then `resolveLocalHost()`
could simply call the overloaded one, passing references to the static methods,
and we would leave that untested.
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
>
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230279#comment-17230279
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521690818
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
try {
- inetAddress =
InetAddress.getByAddress(InetAddress.getLocalHost().getAddress());
- if (inetAddress.isLoopbackAddress()) {
-InetAddress ipv4Fallback = null;
-InetAddress ipv6Fallback = null;
-// try to find a non-loopback address
-Set myInterfaces = getMyAddresses();
-boolean preferIPv6 = useIPv6Addresses;
-String lhName = null;
-for (InetAddress addr : myInterfaces) {
- if (addr.isLoopbackAddress() || addr.isAnyLocalAddress() || lhName
!= null) {
-break;
- }
- boolean ipv6 = addr instanceof Inet6Address;
- boolean ipv4 = addr instanceof Inet4Address;
- if ((preferIPv6 && ipv6) || (!preferIPv6 && ipv4)) {
-String addrName = reverseDNS(addr);
-if (inetAddress.isLoopbackAddress()) {
- inetAddress = addr;
- lhName = addrName;
-} else if (addrName != null) {
- inetAddress = addr;
- lhName = addrName;
+ return tryFor(() -> {
+InetAddress inetAddress = null;
+try {
+ inetAddress =
InetAddress.getByAddress(InetAddress.getLocalHost().getAddress());
+ if (inetAddress.isLoopbackAddress()) {
+InetAddress ipv4Fallback = null;
+InetAddress ipv6Fallback = null;
+// try to find a non-loopback address
+Set myInterfaces = getMyAddresses();
+boolean preferIPv6 = useIPv6Addresses;
+String lhName = null;
+for (InetAddress addr : myInterfaces) {
+ if (addr.isLoopbackAddress() || addr.isAnyLocalAddress() ||
lhName != null) {
+break;
+ }
+ boolean ipv6 = addr instanceof Inet6Address;
+ boolean ipv4 = addr instanceof Inet4Address;
+ if ((preferIPv6 && ipv6) || (!preferIPv6 && ipv4)) {
+String addrName = reverseDNS(addr);
+if (inetAddress.isLoopbackAddress()) {
+ inetAddress = addr;
+ lhName = addrName;
+} else if (addrName != null) {
+ inetAddress = addr;
+ lhName = addrName;
+}
+ } else {
+if (preferIPv6 && ipv4 && ipv4Fallback == null) {
+ ipv4Fallback = addr;
+} else if (!preferIPv6 && ipv6 && ipv6Fallback == null) {
+ ipv6Fallback = addr;
+}
+ }
}
- } else {
-if (preferIPv6 && ipv4 && ipv4Fallback == null) {
- ipv4Fallback = addr;
-} else if (!preferIPv6 && ipv6 && ipv6Fallback == null) {
- ipv6Fallback = addr;
+// vanilla Ubuntu installations will have a usable IPv6 address
when
+// running as a guest OS on an IPv6-enabled machine. We also look
for
+// the alternative IPv4 configuration.
+if (inetAddress.isLoopbackAddress()) {
+ if (ipv4Fallback != null) {
+inetAddress = ipv4Fallback;
+useIPv6Addresses = false;
+ } else if (ipv6Fallback != null) {
+inetAddress = ipv6Fallback;
+useIPv6Addresses = true;
+ }
}
}
+} catch (UnknownHostException ignored) {
}
-// vanilla Ubuntu installations will have a usable IPv6 address when
-// running as a guest OS on an IPv6-enabled machine. We also look for
-// the alternative IPv4 configuration.
-if (inetAddress.isLoopbackAddress()) {
- if (ipv4Fallback != null)
[jira] [Created] (GEODE-8702) Add StringPrefixPartitionResolver
Mario Salazar de Torres created GEODE-8702: -- Summary: Add StringPrefixPartitionResolver Key: GEODE-8702 URL: https://issues.apache.org/jira/browse/GEODE-8702 Project: Geode Issue Type: New Feature Components: native client Affects Versions: 1.13.0 Reporter: Mario Salazar de Torres *AS A* native client contributor *I WANT* to have StringPrefixPartitionResolver implemented *SO THAT* so I can just use it as for the Java API is done -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230275#comment-17230275
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521683541
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
Review comment:
that method has to be a static method and we have to use powermock to
mock a static method. We are trying to steer away from using power mock as far
as I understand.
There are tests for Retry.
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:131)
> ... 14 more
> [error 2020/09/30 19:50:21.
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230272#comment-17230272
]
ASF GitHub Bot commented on GEODE-8664:
---
jdeppe-pivotal commented on a change in pull request #5725:
URL: https://github.com/apache/geode/pull/5725#discussion_r521679443
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionImpl.java
##
@@ -181,9 +181,9 @@ public void start() {
throw new GemFireSecurityException(e.getMessage(),
e);
} catch (MembershipConfigurationException e) {
- throw new GemFireConfigException(e.getMessage());
+ throw new GemFireConfigException(e.getMessage(), e.getCause());
Review comment:
The actual _message_ (string) would be duplicated, but that's OK. You
wouldn't be losing part of the full stack trace however. It's not a big deal
since you're typically only concerned with the root cause, but it's always
better to leave information which may be helpful for debugging.
And, yes your example `throw` is what I'd suggest. That's also what happens
just a few lines higher up.
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
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.inte
[jira] [Commented] (GEODE-8431) Geode Native Client user guide: Update Connection Pools topic
[ https://issues.apache.org/jira/browse/GEODE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230265#comment-17230265 ] Dave Barnes commented on GEODE-8431: C++ docs updated as part of GEODE-8593 pull request: [https://github.com/apache/geode-native/pull/675] .NET docs updated as part of GEODE-8593 pull request: https://github.com/apache/geode-native/pull/689 > Geode Native Client user guide: Update Connection Pools topic > - > > Key: GEODE-8431 > URL: https://issues.apache.org/jira/browse/GEODE-8431 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > The "Using Connection Pools" topic needs updating, in both the .NET and C++ > versions of the user guide: > * Check for up-to-date explanations of connection pools, load balancing, and > configuring for high-availability > * Verify that examples reflect current names and syntax -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8700: -- Labels: pull-request-available (was: ) > Add the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230264#comment-17230264 ] ASF GitHub Bot commented on GEODE-8700: --- gaussianrecurrence opened a new pull request #691: URL: https://github.com/apache/geode-native/pull/691 - Added setPartitionResolver method to region's attribute mutator, so the partition resolver can be changed after the region has been created. - Added UT to verify that PR is correctly changed. 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 > Add the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8701) CI failure: DeltaPropagationStatsDUnitTest.testC2SDeltaPropagationCleanStats fails with AssertionError
Kirk Lund created GEODE-8701:
Summary: CI failure:
DeltaPropagationStatsDUnitTest.testC2SDeltaPropagationCleanStats fails with
AssertionError
Key: GEODE-8701
URL: https://issues.apache.org/jira/browse/GEODE-8701
Project: Geode
Issue Type: Bug
Components: regions, tests
Reporter: Kirk Lund
{noformat}
> Task :geode-core:distributedTest
org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest >
testC2SDeltaPropagationCleanStats FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest$$Lambda$446/0x000100d1c040.run
in VM 0 running on Host 125a44116b1b with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
at
org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest.testC2SDeltaPropagationCleanStats(DeltaPropagationStatsDUnitTest.java:282)
Caused by:
java.lang.AssertionError: Bug #49539: stats do not match, expected
messageNotQueuedOriginator: 2551, actual: 2552 expected:<2551> but was:<2552>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:647)
at
org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest.verifyCCPStatsBug49539(DeltaPropagationStatsDUnitTest.java:506)
at
org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest.lambda$testC2SDeltaPropagationCleanStats$c7abd768$1(DeltaPropagationStatsDUnitTest.java:282)
8719 tests completed, 1 failed, 452 skipped
{noformat}{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-={noformat}
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0480/test-results/distributedTest/1605125153/
{noformat}=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-={noformat}
{noformat}
Test report artifacts from this job are available at:
{noformat}
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0480/test-artifacts/1605125153/distributedtestfiles-OpenJDK11-1.14.0-build.0480.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8701) CI failure: DeltaPropagationStatsDUnitTest.testC2SDeltaPropagationCleanStats fails with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230263#comment-17230263
]
Geode Integration commented on GEODE-8701:
--
Seen in [DistributedTestOpenJDK11
#583|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/583]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0480/test-results/distributedTest/1605125153/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0480/test-artifacts/1605125153/distributedtestfiles-OpenJDK11-1.14.0-build.0480.tgz].
> CI failure: DeltaPropagationStatsDUnitTest.testC2SDeltaPropagationCleanStats
> fails with AssertionError
> --
>
> Key: GEODE-8701
> URL: https://issues.apache.org/jira/browse/GEODE-8701
> Project: Geode
> Issue Type: Bug
> Components: regions, tests
>Reporter: Kirk Lund
>Priority: Major
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest >
> testC2SDeltaPropagationCleanStats FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest$$Lambda$446/0x000100d1c040.run
> in VM 0 running on Host 125a44116b1b with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest.testC2SDeltaPropagationCleanStats(DeltaPropagationStatsDUnitTest.java:282)
> Caused by:
> java.lang.AssertionError: Bug #49539: stats do not match, expected
> messageNotQueuedOriginator: 2551, actual: 2552 expected:<2551> but was:<2552>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at
> org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest.verifyCCPStatsBug49539(DeltaPropagationStatsDUnitTest.java:506)
> at
> org.apache.geode.internal.cache.DeltaPropagationStatsDUnitTest.lambda$testC2SDeltaPropagationCleanStats$c7abd768$1(DeltaPropagationStatsDUnitTest.java:282)
> 8719 tests completed, 1 failed, 452 skipped
> {noformat}{noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-={noformat}
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0480/test-results/distributedTest/1605125153/
> {noformat}=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-={noformat}
> {noformat}
> Test report artifacts from this job are available at:
> {noformat}
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0480/test-artifacts/1605125153/distributedtestfiles-OpenJDK11-1.14.0-build.0480.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-8700: -- Assignee: Mario Salazar de Torres > Add the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230261#comment-17230261 ] Geode Integration commented on GEODE-6183: -- Seen in [WindowsCoreIntegrationTestOpenJDK11 #563|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/563] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0475/test-results/integrationTest/1605064127/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0475/test-artifacts/1605064127/windows-coreintegrationtestfiles-OpenJDK11-1.14.0-build.0475.tgz]. > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230251#comment-17230251
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521657109
##
File path:
geode-common/src/main/java/org/apache/geode/annotations/internal/SuppressDeprecationForBackwardsCompatibilityTesting.java
##
@@ -0,0 +1,46 @@
+/*
+ * 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.annotations.internal;
+
+import static java.lang.annotation.ElementType.CONSTRUCTOR;
+import static java.lang.annotation.ElementType.FIELD;
+import static java.lang.annotation.ElementType.LOCAL_VARIABLE;
+import static java.lang.annotation.ElementType.METHOD;
+import static java.lang.annotation.ElementType.PACKAGE;
+import static java.lang.annotation.ElementType.PARAMETER;
+import static java.lang.annotation.ElementType.TYPE;
+
+import java.lang.annotation.Documented;
+import java.lang.annotation.Retention;
+import java.lang.annotation.RetentionPolicy;
+import java.lang.annotation.Target;
+
+/**
+ * Indicates suppression of deprecation warning because the element is
required for backwards
+ * compatibility testing. The element being suppressed should have a
+ * {@link DeprecatedButRequiredForBackwardsCompatibilityTesting} annotation.
+ *
+ * Should be paired with {@link SuppressWarnings}("deprecation") to actually
suppress warning.
+ */
+@Documented
+@Retention(RetentionPolicy.SOURCE)
+@Target(value = {CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE,
PARAMETER, TYPE})
+public @interface SuppressDeprecationForBackwardsCompatibilityTesting {
Review comment:
i wonder if we can get rid of this annotation by just not using the
deprecated method in the tests. I searched for the usage, there are only two
places that uses `SocketCreator.getLocalhost`
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.int
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230248#comment-17230248
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521657109
##
File path:
geode-common/src/main/java/org/apache/geode/annotations/internal/SuppressDeprecationForBackwardsCompatibilityTesting.java
##
@@ -0,0 +1,46 @@
+/*
+ * 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.annotations.internal;
+
+import static java.lang.annotation.ElementType.CONSTRUCTOR;
+import static java.lang.annotation.ElementType.FIELD;
+import static java.lang.annotation.ElementType.LOCAL_VARIABLE;
+import static java.lang.annotation.ElementType.METHOD;
+import static java.lang.annotation.ElementType.PACKAGE;
+import static java.lang.annotation.ElementType.PARAMETER;
+import static java.lang.annotation.ElementType.TYPE;
+
+import java.lang.annotation.Documented;
+import java.lang.annotation.Retention;
+import java.lang.annotation.RetentionPolicy;
+import java.lang.annotation.Target;
+
+/**
+ * Indicates suppression of deprecation warning because the element is
required for backwards
+ * compatibility testing. The element being suppressed should have a
+ * {@link DeprecatedButRequiredForBackwardsCompatibilityTesting} annotation.
+ *
+ * Should be paired with {@link SuppressWarnings}("deprecation") to actually
suppress warning.
+ */
+@Documented
+@Retention(RetentionPolicy.SOURCE)
+@Target(value = {CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE,
PARAMETER, TYPE})
+public @interface SuppressDeprecationForBackwardsCompatibilityTesting {
Review comment:
i wonder if we can get rid of this annotation by just not using the
deprecated method in the tests. I searched for the usage, there are only two
places that uses `SocketCreator.getLocalhost`
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.int
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230244#comment-17230244
]
ASF GitHub Bot commented on GEODE-8623:
---
dschneider-pivotal commented on a change in pull request #5680:
URL: https://github.com/apache/geode/pull/5680#discussion_r521647616
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
Review comment:
Could you add some type of test for the new "resolveLocalHost" method?
If you had this method call a local method that then calls
InetAddress.getLocalHost you could then mock that method and control when it
would throw UnknownHostException to show that this new code will do retries.
##
File path:
geode-common/src/main/java/org/apache/geode/internal/inet/LocalHostUtil.java
##
@@ -54,70 +59,80 @@
private static final boolean useLinkLocalAddresses =
Boolean.getBoolean(USE_LINK_LOCAL_ADDRESSES_PROPERTY);
- /**
- * we cache localHost to avoid bug #40619, access-violation in native code
- */
- private static final InetAddress localHost;
-
/**
* all classes should use this variable to determine whether to use IPv4 or
IPv6 addresses
*/
@MakeNotStatic
private static boolean useIPv6Addresses =
!Boolean.getBoolean("java.net.preferIPv4Stack")
&& Boolean.getBoolean("java.net.preferIPv6Addresses");
- static {
-InetAddress inetAddress = null;
+ /**
+ * Resolves local host. Will retry if resolution fails.
+ *
+ * @return local host if resolved otherwise null.
+ */
+ private static InetAddress resolveLocalHost() {
try {
- inetAddress =
InetAddress.getByAddress(InetAddress.getLocalHost().getAddress());
- if (inetAddress.isLoopbackAddress()) {
-InetAddress ipv4Fallback = null;
-InetAddress ipv6Fallback = null;
-// try to find a non-loopback address
-Set myInterfaces = getMyAddresses();
-boolean preferIPv6 = useIPv6Addresses;
-String lhName = null;
-for (InetAddress addr : myInterfaces) {
- if (addr.isLoopbackAddress() || addr.isAnyLocalAddress() || lhName
!= null) {
-break;
- }
- boolean ipv6 = addr instanceof Inet6Address;
- boolean ipv4 = addr instanceof Inet4Address;
- if ((preferIPv6 && ipv6) || (!preferIPv6 && ipv4)) {
-String addrName = reverseDNS(addr);
-if (inetAddress.isLoopbackAddress()) {
- inetAddress = addr;
- lhName = addrName;
-} else if (addrName != null) {
- inetAddress = addr;
- lhName = addrName;
+ return tryFor(() -> {
+InetAddress inetAddress = null;
+try {
+ inetAddress =
InetAddress.getByAddress(InetAddress.getLocalHost().getAddress());
+ if (inetAddress.isLoopbackAddress()) {
+InetAddress ipv4Fallback = null;
+InetAddress ipv6Fallback = null;
+// try to find a non-loopback address
+Set myInterfaces = getMyAddresses();
+boolean preferIPv6 = useIPv6Addresses;
+String lhName = null;
+for (InetAddress addr : myInterfaces) {
+ if (addr.isLoopbackAddress() || addr.isAnyLocalAddress() ||
lhName != null) {
+break;
+ }
+ boolean ipv6 = addr instanceof Inet6Address;
+ boolean ipv4 = addr instanceof Inet4Address;
+ if ((preferIPv6 && ipv6) || (!preferIPv6 && ipv4)) {
+String addrName = reverseDNS(addr);
+if (inetAddress.isLoopbackAddress()) {
+ inetAddress = addr;
+ lhName = addrName;
+} else if (addrName != null) {
+ inetAddress = addr;
+ lhName = addrName;
+}
+ } else {
+if (preferIPv6 && ipv4 && ipv4Fallback == null) {
+ ipv4Fallback = addr;
+} else if (!preferIPv6 && ipv6 && ipv6Fallback == null) {
+ ipv6
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[
https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230234#comment-17230234
]
ASF GitHub Bot commented on GEODE-8694:
---
sabbey37 commented on a change in pull request #5732:
URL: https://github.com/apache/geode/pull/5732#discussion_r521637555
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/GeodeServerRunTest.java
##
@@ -29,7 +28,8 @@
public static GeodeRedisServerRule server = new GeodeRedisServerRule();
@Test
- @Ignore("This is a no-op test to conveniently run redis api for geode server
for local development/testing purposes")
Review comment:
This should be ignored (and is why the Integration Tests timed out).
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
> Use fork of Redis in Gemfire org to run Redis tests in CI
> -
>
> Key: GEODE-8694
> URL: https://issues.apache.org/jira/browse/GEODE-8694
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Helena Bales
>Priority: Trivial
> Labels: pull-request-available
>
> Currently, we are using a contributor's personal fork of Redis to run tests
> against Geode Redis in CI. This should be switched to the fork of Redis in
> the Gemfire org. Ideally, we will eventually be able to run tests from the
> root Redis repo (currently we are unable to since we are not implementing all
> the necessary commands).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230233#comment-17230233 ] ASF GitHub Bot commented on GEODE-8694: --- sabbey37 commented on a change in pull request #5732: URL: https://github.com/apache/geode/pull/5732#discussion_r521640333 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -19,12 +19,14 @@ cd .. -# We are currently using a personal fork for this repo because our code does not implement all +# We are currently using a patched version of this repo because our code does not implement all # Redis commands. Once all commands needed to run relevant test files are implemented, we hope to -# use Redis's repo instead. -git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +# use Redis's repo without a patch. +git clone --config transfer.fsckObjects=false https://github.com/redis/redis.git +cp geode-redis/src/acceptanceTest/resources/0001-configure-redis-tests.patch redis cd redis git checkout tests-geode-redis Review comment: Correct me if I'm missing something, but I don't think the `tests-geode-redis` branch is in the `redis` repo. I guess we could check out the `5.0` branch. Have you tried this sequence locally with a fresh clone of the `redis` repo that doesn't have any local branches/branches from other forks? 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230230#comment-17230230 ] ASF GitHub Bot commented on GEODE-8694: --- sabbey37 commented on a change in pull request #5732: URL: https://github.com/apache/geode/pull/5732#discussion_r521640333 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -19,12 +19,14 @@ cd .. -# We are currently using a personal fork for this repo because our code does not implement all +# We are currently using a patched version of this repo because our code does not implement all # Redis commands. Once all commands needed to run relevant test files are implemented, we hope to -# use Redis's repo instead. -git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +# use Redis's repo without a patch. +git clone --config transfer.fsckObjects=false https://github.com/redis/redis.git +cp geode-redis/src/acceptanceTest/resources/0001-configure-redis-tests.patch redis cd redis git checkout tests-geode-redis Review comment: Correct me if I'm missing something, but I don't think this branch is in the `redis` repo. I guess we could check out the 5.0 branch. Have you tried this sequence locally with a fresh clone of the `redis` repo that doesn't have any local branches/branches from other forks? 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230229#comment-17230229 ] ASF GitHub Bot commented on GEODE-8694: --- sabbey37 commented on a change in pull request #5732: URL: https://github.com/apache/geode/pull/5732#discussion_r521637229 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -49,8 +51,8 @@ failCount=0 --redis-port=6379 \ --redis-bind-address=127.0.0.1 -./runtest --host 127.0.0.1 --port 6379 --single unit/type/set --single unit/expire \ ---single unit/type/hash --single unit/type/string --single unit/type/srandmember \ +./runtest --host 127.0.0.1 --port 6380 --single unit/type/set --single unit/expire \ Review comment: We should change this port back to 6379 (since the Geode Redis server without a password is started on `6379`, which is why we get the error `Executing test client: NOAUTH Authentication required` in the RedisTests) 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230228#comment-17230228
]
ASF GitHub Bot commented on GEODE-8593:
---
davebarnes97 commented on pull request #689:
URL: https://github.com/apache/geode-native/pull/689#issuecomment-725664685
> In general I like simplification of our docs by removing sections
(particularly for seldom used features). However, we should consider adding a
link to an Appendix: Other Features (or similar) or a link to other documents
that discuss those features.
@mmartell I get it, but I think it's beyond the scope of this PR. This PR
does add a "Configuring Pools" topic that did not appear in the previous
version, but that was a side-effect of changing the connection pool code in all
the examples.
I welcome suggestions regarding topics that should be added. Feel free to
contact me directly or open a JIRA ticket with a list so your ideas don't get
lost. Thanks!
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
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230227#comment-17230227 ] ASF GitHub Bot commented on GEODE-8694: --- sabbey37 commented on a change in pull request #5732: URL: https://github.com/apache/geode/pull/5732#discussion_r521637229 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -49,8 +51,8 @@ failCount=0 --redis-port=6379 \ --redis-bind-address=127.0.0.1 -./runtest --host 127.0.0.1 --port 6379 --single unit/type/set --single unit/expire \ ---single unit/type/hash --single unit/type/string --single unit/type/srandmember \ +./runtest --host 127.0.0.1 --port 6380 --single unit/type/set --single unit/expire \ Review comment: We should change this port back to 6379 (since the Geode Redis server without a password is started on `6379`) 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230225#comment-17230225 ] ASF GitHub Bot commented on GEODE-8694: --- sabbey37 commented on a change in pull request #5732: URL: https://github.com/apache/geode/pull/5732#discussion_r521640333 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -19,12 +19,14 @@ cd .. -# We are currently using a personal fork for this repo because our code does not implement all +# We are currently using a patched version of this repo because our code does not implement all # Redis commands. Once all commands needed to run relevant test files are implemented, we hope to -# use Redis's repo instead. -git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +# use Redis's repo without a patch. +git clone --config transfer.fsckObjects=false https://github.com/redis/redis.git +cp geode-redis/src/acceptanceTest/resources/0001-configure-redis-tests.patch redis cd redis git checkout tests-geode-redis Review comment: Correct me if I'm missing something, but I don't think this branch is in the `redis` repo. I guess we could check out the 5.0 branch. Have you tried this sequence locally? 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230221#comment-17230221 ] ASF GitHub Bot commented on GEODE-8694: --- sabbey37 commented on a change in pull request #5732: URL: https://github.com/apache/geode/pull/5732#discussion_r521637229 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -49,8 +51,8 @@ failCount=0 --redis-port=6379 \ --redis-bind-address=127.0.0.1 -./runtest --host 127.0.0.1 --port 6379 --single unit/type/set --single unit/expire \ ---single unit/type/hash --single unit/type/string --single unit/type/srandmember \ +./runtest --host 127.0.0.1 --port 6380 --single unit/type/set --single unit/expire \ Review comment: We should change this port back to 6379 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[
https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230220#comment-17230220
]
ASF GitHub Bot commented on GEODE-8694:
---
sabbey37 commented on a change in pull request #5732:
URL: https://github.com/apache/geode/pull/5732#discussion_r521637229
##
File path: ci/scripts/execute_redis_tests.sh
##
@@ -49,8 +51,8 @@ failCount=0
--redis-port=6379 \
--redis-bind-address=127.0.0.1
-./runtest --host 127.0.0.1 --port 6379 --single unit/type/set --single
unit/expire \
---single unit/type/hash --single unit/type/string --single
unit/type/srandmember \
+./runtest --host 127.0.0.1 --port 6380 --single unit/type/set --single
unit/expire \
Review comment:
We should change this back to 6379
##
File path:
geode-redis/src/commonTest/java/org/apache/geode/redis/GeodeRedisServerRule.java
##
@@ -43,7 +43,7 @@ public GeodeRedisServerRule() {
@Override
protected void before() {
cache = cacheFactory.create();
-server = new GeodeRedisServer("localhost", 0, (InternalCache) cache);
+server = new GeodeRedisServer("localhost", 6380, (InternalCache) cache);
Review comment:
Change this back to `0`
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/GeodeServerRunTest.java
##
@@ -29,7 +28,8 @@
public static GeodeRedisServerRule server = new GeodeRedisServerRule();
@Test
- @Ignore("This is a no-op test to conveniently run redis api for geode server
for local development/testing purposes")
Review comment:
This should be ignored.
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
> Use fork of Redis in Gemfire org to run Redis tests in CI
> -
>
> Key: GEODE-8694
> URL: https://issues.apache.org/jira/browse/GEODE-8694
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Helena Bales
>Priority: Trivial
> Labels: pull-request-available
>
> Currently, we are using a contributor's personal fork of Redis to run tests
> against Geode Redis in CI. This should be switched to the fork of Redis in
> the Gemfire org. Ideally, we will eventually be able to run tests from the
> root Redis repo (currently we are unable to since we are not implementing all
> the necessary commands).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230212#comment-17230212
]
ASF subversion and git services commented on GEODE-7884:
Commit 6fec62ff7b4b6ebc4f0f8079fcd67a2b0c3919b0 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fec62f ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
(cherry picked from commit 2d2a3f80bd5053749963889c1898df48e9aa0be7)
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> 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.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataVie
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230211#comment-17230211
]
ASF subversion and git services commented on GEODE-7884:
Commit 6fec62ff7b4b6ebc4f0f8079fcd67a2b0c3919b0 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fec62f ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
(cherry picked from commit 2d2a3f80bd5053749963889c1898df48e9aa0be7)
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> 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.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataVie
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230210#comment-17230210
]
ASF subversion and git services commented on GEODE-7884:
Commit 6fec62ff7b4b6ebc4f0f8079fcd67a2b0c3919b0 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fec62f ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
(cherry picked from commit 2d2a3f80bd5053749963889c1898df48e9aa0be7)
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> 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.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataVie
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230209#comment-17230209
]
ASF subversion and git services commented on GEODE-7884:
Commit 6fec62ff7b4b6ebc4f0f8079fcd67a2b0c3919b0 in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fec62f ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
(cherry picked from commit 2d2a3f80bd5053749963889c1898df48e9aa0be7)
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> 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.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataVie
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230208#comment-17230208
]
ASF GitHub Bot commented on GEODE-7884:
---
Bill merged pull request #5731:
URL: https://github.com/apache/geode/pull/5731
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 hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> 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.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:156)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5038)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1637)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1624)
> {noformat}
> Logs show this same thread hitting an IllegalStateException when trying to
> send a message:
> {noformat}
> (edited)
> [fatal 2020/03/10 23:13:08.441 PDT tid=0x67] While pushing message <>
> to recipients: <>
> java.lang.IllegalStateException: Task already scheduled or cancelled
> at java.util.Timer.sched(Timer.java:401)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230198#comment-17230198 ] ASF GitHub Bot commented on GEODE-8694: --- nonbinaryprogrammer commented on pull request #5732: URL: https://github.com/apache/geode/pull/5732#issuecomment-725639515 > the failure in the Redis PR check is probably because the PR pipeline picked up only part of your change (the port number in the rule) but not the other half (this is intentional for security reasons). Once merged all should be well. Thanks for the context, Owen! 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230194#comment-17230194 ] ASF GitHub Bot commented on GEODE-8694: --- onichols-pivotal commented on pull request #5732: URL: https://github.com/apache/geode/pull/5732#issuecomment-725635504 the failure in the Redis PR check is probably because the PR pipeline picked up only part of your change (the port number in the rule) but not the other half (this is intentional for security reasons). Once merged all should be well. 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230182#comment-17230182 ] ASF GitHub Bot commented on GEODE-8694: --- nonbinaryprogrammer opened a new pull request #5732: URL: https://github.com/apache/geode/pull/5732 use the redis/redis repo's test with a patch containing changes to tests that fail on unimplemented commands when testing geode-redis. Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey resolved GEODE-8692.
Fix Version/s: 1.14.0
Resolution: Fixed
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization}} if buckets have
> been initialized at that point.
> Code where {{ArrayIndexOutOfBoundsException}} might be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization():}}
> {code:java}
> for (int i = 0; i < buckets.length; i++) {
> BucketAdvisor ba = buckets[i].getBucketAdvisor();
> int serial = qbp.serials[i]; <<< Exception thrown here
> if (serial != ILLEGAL_SERIAL) {
> ba.removeIdWithSerial(qbp.memberId, serial, qbp.destroyed);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-7884:
--
Labels: pull-request-available (was: )
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> 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.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:156)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5038)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1637)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1624)
> {noformat}
> Logs show this same thread hitting an IllegalStateException when trying to
> send a message:
> {noformat}
> (edited)
> [fatal 2020/03/10 23:13:08.441 PDT tid=0x67] While pushing message <>
> to recipients: <>
> java.lang.IllegalStateException: Task already scheduled or cancelled
> at java.util.Timer.sched(Timer.java:401)
> at java.util.Timer.schedule(Timer.java:193)
> at org.apache.geode.internal.SystemTimer.schedule(SystemTimer.java:347)
> at
> org.apache.geode.internal.tcp.Connection.scheduleAckTimeouts(Connection.java:1956)
> at
> org.apache.geode.internal.tcp.MsgStreamer.reserveConnections(MsgStreamer.java:225)
> at
> org.apache.geode.internal.tcp.MsgStreamerList.reserveConnections(MsgStreamerLis
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230173#comment-17230173
]
ASF GitHub Bot commented on GEODE-7884:
---
Bill opened a new pull request #5731:
URL: https://github.com/apache/geode/pull/5731
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
(cherry picked from commit 2d2a3f80bd5053749963889c1898df48e9aa0be7)
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
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 hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegi
[jira] [Created] (GEODE-8700) Add the ability to change the partition resolver
Mario Salazar de Torres created GEODE-8700: -- Summary: Add the ability to change the partition resolver Key: GEODE-8700 URL: https://issues.apache.org/jira/browse/GEODE-8700 Project: Geode Issue Type: New Feature Components: native client Affects Versions: 1.13.0 Reporter: Mario Salazar de Torres *AS A* native client contributor *I WANT* to be able to mutate partition resolver *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8685) Exporting data causes a ClassNotFoundException
[
https://issues.apache.org/jira/browse/GEODE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-8685:
Assignee: Darrel Schneider
> Exporting data causes a ClassNotFoundException
> --
>
> Key: GEODE-8685
> URL: https://issues.apache.org/jira/browse/GEODE-8685
> Project: Geode
> Issue Type: Task
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Anthony Baker
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI
>
> See
> [https://lists.apache.org/thread.html/rfa4fc47eb4cb4e75c39d7cb815416bebf2ec233d4db24e37728e922e%40%3Cuser.geode.apache.org%3E.]
>
> Report is that exporting data whose values are Classes defined in a deployed
> jar result in a ClassNotFound exception:
> {noformat}
> [error 2020/10/30 08:54:29.317 PDT tid=0x41]
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> java.io.IOException: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter.export(WindowedExporter.java:106)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.exportOnMember(RegionSnapshotServiceImpl.java:361)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:161)
> at
> org.apache.geode.internal.cache.snapshot.RegionSnapshotServiceImpl.save(RegionSnapshotServiceImpl.java:146)
> at
> org.apache.geode.management.internal.cli.functions.ExportDataFunction.executeFunction(ExportDataFunction.java:62)
> at
> org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:442)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:377)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.SerializationException: A ClassNotFoundException was thrown
> while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter$WindowedExportCollector.setException(WindowedExporter.java:383)
> at
> org.apache.geode.internal.cache.snapshot.WindowedExporter$WindowedExportCollector.addResult(WindowedExporter.java:346)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultSender.lastResult(PartitionedRegionFunctionResultSender.java:195)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.handleException(AbstractExecution.java:502)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:353)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.lambda$executeFunctionOnLocalPRNode$0(AbstractExecution.java:273)
> ... 6 more
> Caused by: org.apache.geode.SerializationException: A ClassNotFoundException
> was thrown while trying to deserialize cached value.
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2046)
> at
> org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:2032)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getDeserializedValue(VMCachedDeserializable.java:135)
> at
> org.apache.geode.internal.cache.EntrySnapshot.getRawValue(EntrySnapshot.java:111)
> at
> org.apache.geode.internal.cache.EntrySnapshot.getRawValue(EntrySnapshot.java:99)
> at
> org.apache.geode.internal.cache.EntrySnapshot.getValue(EntrySnapshot.java:129)
> at
> org.apache.geode.internal.cache.snapshot.SnapshotP
[jira] [Resolved] (GEODE-8683) maximum-time-between-pings parameter in GatewayReceiver creation does not have any effect
[ https://issues.apache.org/jira/browse/GEODE-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8683. - Fix Version/s: 1.14.0 Resolution: Fixed > maximum-time-between-pings parameter in GatewayReceiver creation does not > have any effect > - > > Key: GEODE-8683 > URL: https://issues.apache.org/jira/browse/GEODE-8683 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The maximum-time-between-pings parameter than can be set at gateway sender > creation has no effect, i.e. the value used as maximum time between pings for > gateway sender connections to the gateway receiver is either the default > value (6) or the one set on the server where the receiver is running. > The reason is that the ClientHealthMonitor is a server-side singleton that > monitors the health of all clients. The value set for this parameter in the > ClientHealthMonitor is first set when the server is started and the first > Acceptor is created. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230133#comment-17230133
]
ASF subversion and git services commented on GEODE-8692:
Commit c99087aeb19abfb5bbd57036349870a6d784df1a in geode's branch
refs/heads/develop from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c99087a ]
GEODE-8692: ArrayIndexOutOfBoundsException may be thrown in
RegionAdvisor.processProfilesQueuedDuringInitialization (#5722)
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization}} if buckets have
> been initialized at that point.
> Code where {{ArrayIndexOutOfBoundsException}} might be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization():}}
> {code:java}
> for (int i = 0; i < buckets.length; i++) {
> BucketAdvisor ba = buckets[i].getBucketAdvisor();
> int serial = qbp.serials[i]; <<< Exception thrown here
> if (serial != ILLEGAL_SERIAL) {
> ba.removeIdWithSerial(qbp.memberId, serial, qbp.destroyed);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230132#comment-17230132
]
ASF subversion and git services commented on GEODE-8692:
Commit c99087aeb19abfb5bbd57036349870a6d784df1a in geode's branch
refs/heads/develop from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c99087a ]
GEODE-8692: ArrayIndexOutOfBoundsException may be thrown in
RegionAdvisor.processProfilesQueuedDuringInitialization (#5722)
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization}} if buckets have
> been initialized at that point.
> Code where {{ArrayIndexOutOfBoundsException}} might be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization():}}
> {code:java}
> for (int i = 0; i < buckets.length; i++) {
> BucketAdvisor ba = buckets[i].getBucketAdvisor();
> int serial = qbp.serials[i]; <<< Exception thrown here
> if (serial != ILLEGAL_SERIAL) {
> ba.removeIdWithSerial(qbp.memberId, serial, qbp.destroyed);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230130#comment-17230130
]
ASF GitHub Bot commented on GEODE-8692:
---
sabbey37 merged pull request #5722:
URL: https://github.com/apache/geode/pull/5722
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
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization}} if buckets have
> been initialized at that point.
> Code where {{ArrayIndexOutOfBoundsException}} might be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization():}}
> {code:java}
> for (int i = 0; i < buckets.length; i++) {
> BucketAdvisor ba = buckets[i].getBucketAdvisor();
> int serial = qbp.serials[i]; <<< Exception thrown here
> if (serial != ILLEGAL_SERIAL) {
> ba.removeIdWithSerial(qbp.memberId, serial, qbp.destroyed);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8431) Geode Native Client user guide: Update Connection Pools topic
[ https://issues.apache.org/jira/browse/GEODE-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-8431: -- Assignee: Dave Barnes > Geode Native Client user guide: Update Connection Pools topic > - > > Key: GEODE-8431 > URL: https://issues.apache.org/jira/browse/GEODE-8431 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > The "Using Connection Pools" topic needs updating, in both the .NET and C++ > versions of the user guide: > * Check for up-to-date explanations of connection pools, load balancing, and > configuring for high-availability > * Verify that examples reflect current names and syntax -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8286: - Issue Type: Bug (was: Improvement) > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Bug > Components: configuration, general, management >Reporter: John Blum >Priority: Critical > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Issue Type: Bug (was: Improvement)
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Bug
> Components: docs, querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Priority: Major (was: Minor)
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Bug
> Components: docs, querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Major
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8257) The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON Objects
[
https://issues.apache.org/jira/browse/GEODE-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8257:
-
Priority: Critical (was: Major)
> The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON
> Objects
> ---
>
> Key: GEODE-8257
> URL: https://issues.apache.org/jira/browse/GEODE-8257
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> When Jackson has be configured to be explicit about the types contained in
> the JSON document, Geode's {{ObjectMapper}} configuration fails to handle the
> type metadata properly.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L621-L663]
> for an example test case illustrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Issue Type: Bug (was: Improvement)
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Minor
> Labels: JSON-PDX
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[
https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8256:
-
Priority: Critical (was: Major)
> The Jackson ObjectMapper used by a PdxInstance does not properly handle Java
> 8 Types
>
>
> Key: GEODE-8256
> URL: https://issues.apache.org/jira/browse/GEODE-8256
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
> [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
> not properly configured.
> Specifically, it cannot handle *Java 8* types since these types are not
> included in Jackson 2, by default, primarily because Jackson 2 is based on
> Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle
> Java 8 types, when configured properly with extension modules.
> To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
> {{PdxInstance}} implementation, violates the _Open/Closed_ software design
> principle, so there is literally no way to modify (i.e. override/extend) the
> configuration of the {{ObjectMapper}} as required by the application.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
> for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8255) JSONFormatter does not properly generate the @type metadata field
[
https://issues.apache.org/jira/browse/GEODE-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8255:
-
Priority: Critical (was: Major)
> JSONFormatter does not properly generate the @type metadata field
> -
>
> Key: GEODE-8255
> URL: https://issues.apache.org/jira/browse/GEODE-8255
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> The Apache Geode
> [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]
> class is not symmetric.
> While it can parse JSON content and properly resolve JSON Objects as POJOs
> (from {{PdxInstance.getObject()}} when the {{@type}} metadata field is
> present in the JSON content, the {{JSONFormatter}} does not properly set the
> {{@type}} metadata field, particularly when a {{PdxInstance}} has a valid
> class name as determined by
> [PdxInstance.getClassName()|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html#getClassName--].
> A test case illustrating this issue can be found
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L546-L580].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230083#comment-17230083
]
ASF GitHub Bot commented on GEODE-8664:
---
gaussianrecurrence commented on a change in pull request #5725:
URL: https://github.com/apache/geode/pull/5725#discussion_r521490111
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionImpl.java
##
@@ -181,9 +181,9 @@ public void start() {
throw new GemFireSecurityException(e.getMessage(),
e);
} catch (MembershipConfigurationException e) {
- throw new GemFireConfigException(e.getMessage());
+ throw new GemFireConfigException(e.getMessage(), e.getCause());
Review comment:
Wouldn't the message then be duplicated? I am asking out of ignorance :S
I mean probably it should be something like:
```java
throw new GemFireConfigException("Configuration exception while starting up
distribution", e);
```
?
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
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.in
[jira] [Commented] (GEODE-8684) Setting a session's maxInactiveInterval does not work when the commit valve is disabled
[
https://issues.apache.org/jira/browse/GEODE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230084#comment-17230084
]
ASF subversion and git services commented on GEODE-8684:
Commit ba8f9015530af10c3e9d1df1e73524bdc6c8a3cc in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ba8f901 ]
GEODE-8684: Setting a session's maxInactiveInterval does not work when the
commit valve is disabled (#5724)
Co-Authored-by: Jens Deppe
Co-Authored-by: Sarah Abbey
> Setting a session's maxInactiveInterval does not work when the commit valve
> is disabled
> ---
>
> Key: GEODE-8684
> URL: https://issues.apache.org/jira/browse/GEODE-8684
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> I was using the {{CommandServlet}}, in an external test, and noticed that
> when the commit valve is disabled, attempting to set the session's
> maxInactiveInterval does not cause the session's maxInactiveInterval to be
> changed and it remains at the default.
> My setup consisted of 2 Geode servers and a single Tomcat instance (9.0.39).
> I was checking the sessions with the following gfsh query:
> {code:java}
> query --query="select e.key,e.value.maxInactiveInterval from
> /gemfire_modules_sessions.entries as e
> {code}
> My {{context.xml}} includes the following:
> {code:xml}
>className="org.apache.geode.modules.session.catalina.Tomcat8DeltaSessionManager"
> enableLocalCache="false"
> enableCommitValve="false"
> regionAttributesId="PARTITION_REDUNDANT"
> />
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8684) Setting a session's maxInactiveInterval does not work when the commit valve is disabled
[
https://issues.apache.org/jira/browse/GEODE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230082#comment-17230082
]
ASF subversion and git services commented on GEODE-8684:
Commit ba8f9015530af10c3e9d1df1e73524bdc6c8a3cc in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ba8f901 ]
GEODE-8684: Setting a session's maxInactiveInterval does not work when the
commit valve is disabled (#5724)
Co-Authored-by: Jens Deppe
Co-Authored-by: Sarah Abbey
> Setting a session's maxInactiveInterval does not work when the commit valve
> is disabled
> ---
>
> Key: GEODE-8684
> URL: https://issues.apache.org/jira/browse/GEODE-8684
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> I was using the {{CommandServlet}}, in an external test, and noticed that
> when the commit valve is disabled, attempting to set the session's
> maxInactiveInterval does not cause the session's maxInactiveInterval to be
> changed and it remains at the default.
> My setup consisted of 2 Geode servers and a single Tomcat instance (9.0.39).
> I was checking the sessions with the following gfsh query:
> {code:java}
> query --query="select e.key,e.value.maxInactiveInterval from
> /gemfire_modules_sessions.entries as e
> {code}
> My {{context.xml}} includes the following:
> {code:xml}
>className="org.apache.geode.modules.session.catalina.Tomcat8DeltaSessionManager"
> enableLocalCache="false"
> enableCommitValve="false"
> regionAttributesId="PARTITION_REDUNDANT"
> />
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Priority: Major (was: Critical)
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> As an application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}}
> Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to
> store objects in PDX serialized format, then Geode will throw an
> inappropriate {{Exception}}:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
> purposes.
> Some find it hard to imagine why an application would want to do this, store
> PDX instead of POJOs. However, consider the fact that my application might
> be part of a larger Microservices architecture that communicate via a RESTful
> interfaces. They pass JSON back and forth, which might either be complex or
> unstructured. Either way, it is possible I don't have or don't want to
> create POJOs (types) matching the JSON that my Microservice consumes. I
> simply want access to certain bits of information which PDX is adequately
> suited for. These client LOCAL Regions might even be temporary. When
> connected, I might even want to share this data (or aggregated data) with
> Native Clients which most certainly won't have Java types matching the JSON
> content, raw or summarized.
> EXPECTED:
> As a developer using Apache Geode, I expected to be able to develop
> (primarily) {{ClientCache}} applicati
[jira] [Updated] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
[ https://issues.apache.org/jira/browse/GEODE-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8254: - Issue Type: Bug (was: Improvement) > JSONFormatter cannot parse JSON Arrays > -- > > Key: GEODE-8254 > URL: https://issues.apache.org/jira/browse/GEODE-8254 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0 >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > The Apache Geode > [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] > class is not capable of parsing/processing JSON Arrays, making it less than > adequate to process JSON documents and content. > This leaves the responsibility and burden on the user, which requires the > user to inspect the individual array elements. > A test case reproducing this issue can be found > [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. > The matching JSON document is > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. > JSON Arrays are a very common JSON data type, as > [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8684) Setting a session's maxInactiveInterval does not work when the commit valve is disabled
[
https://issues.apache.org/jira/browse/GEODE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230080#comment-17230080
]
ASF GitHub Bot commented on GEODE-8684:
---
jdeppe-pivotal merged pull request #5724:
URL: https://github.com/apache/geode/pull/5724
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
> Setting a session's maxInactiveInterval does not work when the commit valve
> is disabled
> ---
>
> Key: GEODE-8684
> URL: https://issues.apache.org/jira/browse/GEODE-8684
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> I was using the {{CommandServlet}}, in an external test, and noticed that
> when the commit valve is disabled, attempting to set the session's
> maxInactiveInterval does not cause the session's maxInactiveInterval to be
> changed and it remains at the default.
> My setup consisted of 2 Geode servers and a single Tomcat instance (9.0.39).
> I was checking the sessions with the following gfsh query:
> {code:java}
> query --query="select e.key,e.value.maxInactiveInterval from
> /gemfire_modules_sessions.entries as e
> {code}
> My {{context.xml}} includes the following:
> {code:xml}
>className="org.apache.geode.modules.session.catalina.Tomcat8DeltaSessionManager"
> enableLocalCache="false"
> enableCommitValve="false"
> regionAttributesId="PARTITION_REDUNDANT"
> />
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Priority: Critical (was: Major)
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> As an application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}}
> Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to
> store objects in PDX serialized format, then Geode will throw an
> inappropriate {{Exception}}:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
> purposes.
> Some find it hard to imagine why an application would want to do this, store
> PDX instead of POJOs. However, consider the fact that my application might
> be part of a larger Microservices architecture that communicate via a RESTful
> interfaces. They pass JSON back and forth, which might either be complex or
> unstructured. Either way, it is possible I don't have or don't want to
> create POJOs (types) matching the JSON that my Microservice consumes. I
> simply want access to certain bits of information which PDX is adequately
> suited for. These client LOCAL Regions might even be temporary. When
> connected, I might even want to share this data (or aggregated data) with
> Native Clients which most certainly won't have Java types matching the JSON
> content, raw or summarized.
> EXPECTED:
> As a developer using Apache Geode, I expected to be able to develop
> (primarily) {{ClientCache}} applic
[jira] [Updated] (GEODE-7797) Deprecate old Apache Geode logging properties
[
https://issues.apache.org/jira/browse/GEODE-7797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7797:
-
Priority: Minor (was: Major)
> Deprecate old Apache Geode logging properties
> -
>
> Key: GEODE-7797
> URL: https://issues.apache.org/jira/browse/GEODE-7797
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Minor
>
> The old Apache Geode logging properties (e.g. `log-level`) no longer have any
> effect. Effectively, these properties are rendered useless as of Apache
> Geode {{1.9.2}} since the logging capabilities in Apache Geode was properly
> separated and modularized in Apache Geode {{1.9.2}}, between Log4j API usage
> vs. using Log4j, and specifically, {{log4j-core}}, as a logging provider,
> which as been encapsulated in the new {{geode-log4j}} module.
> Apache Geode properties that effectively useless are:
> * {{log-diskspace-limit}}
> * {{log-file}}
> * {{log-file-size-limit}}
> * {{log-level}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230075#comment-17230075
]
ASF GitHub Bot commented on GEODE-8664:
---
jdeppe-pivotal commented on a change in pull request #5725:
URL: https://github.com/apache/geode/pull/5725#discussion_r521485764
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionImpl.java
##
@@ -181,9 +181,9 @@ public void start() {
throw new GemFireSecurityException(e.getMessage(),
e);
} catch (MembershipConfigurationException e) {
- throw new GemFireConfigException(e.getMessage());
+ throw new GemFireConfigException(e.getMessage(), e.getCause());
Review comment:
You should just use the exception here instead of `e.getCause()`
otherwise you're discarding one of the stack frames in the exception chain.
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionImpl.java
##
@@ -181,9 +181,9 @@ public void start() {
throw new GemFireSecurityException(e.getMessage(),
e);
} catch (MembershipConfigurationException e) {
- throw new GemFireConfigException(e.getMessage());
+ throw new GemFireConfigException(e.getMessage(), e.getCause());
} catch (MemberStartupException e) {
- throw new SystemConnectException(e.getMessage());
+ throw new SystemConnectException(e.getMessage(), e.getCause());
Review comment:
Ditto
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
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.
[jira] [Updated] (GEODE-7382) ReflectionBasedAutoSerializer should use the greediest domain object constructor it can find to satisfy the values of the domain object
[ https://issues.apache.org/jira/browse/GEODE-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7382: - Summary: ReflectionBasedAutoSerializer should use the greediest domain object constructor it can find to satisfy the values of the domain object (was: ReflectionBasedAutoSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object) > ReflectionBasedAutoSerializer should use the greediest domain object > constructor it can find to satisfy the values of the domain object > --- > > Key: GEODE-7382 > URL: https://issues.apache.org/jira/browse/GEODE-7382 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Major > > ... Regardless of whether or not... > 1. There exists a public, no-arg constructor or NOT (since a default, public, > no-arg constructor is not required in Java). > 2. And whether or not that constructor is public or not (which also does not > matter in Java) > 3. And simply because constructors provide initialization safety that setters > and field injection simply cannot as specified by the JVM spec. > Also, consider what happens when the object class type is _immutable_. That > is, all object initialization must happen through a constructor since the > object is immutable, which are inherently Thread-safe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7376) AsyncEventQueueFactory.pauseEventDispatching() & AsyncEventQueue.resumeEventDispatching() is missing from the API Javadoc
[
https://issues.apache.org/jira/browse/GEODE-7376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7376:
-
Priority: Minor (was: Major)
> AsyncEventQueueFactory.pauseEventDispatching() &
> AsyncEventQueue.resumeEventDispatching() is missing from the API Javadoc
> -
>
> Key: GEODE-7376
> URL: https://issues.apache.org/jira/browse/GEODE-7376
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: John Blum
>Priority: Minor
>
> The {{AsyncEventQueueFactory.pauseEventDispatching()}} is present in the
> Pivotal GemFire API Javadoc here:
> http://gemfire-98-javadocs.docs.pivotal.io/org/apache/geode/cache/asyncqueue/AsyncEventQueueFactory.html#pauseEventDispatching--
> The {{AsyncEventQueue.resumeEventDispatching()}} is present in the Pivotal
> GemFire API Javadoc here:
> http://gemfire-98-javadocs.docs.pivotal.io/org/apache/geode/cache/asyncqueue/AsyncEventQueue.html#resumeEventDispatching--
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7382) ReflectionBasedAutoSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object
[ https://issues.apache.org/jira/browse/GEODE-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7382: - Summary: ReflectionBasedAutoSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object (was: ReflectionBasedSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object) > ReflectionBasedAutoSerializer should consider using the greediest application > domain object type constructor it can find to satisfy the values of the > domain object > --- > > Key: GEODE-7382 > URL: https://issues.apache.org/jira/browse/GEODE-7382 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Major > > ... Regardless of whether or not... > 1. There exists a public, no-arg constructor or NOT (since a default, public, > no-arg constructor is not required in Java). > 2. And whether or not that constructor is public or not (which also does not > matter in Java) > 3. And simply because constructors provide initialization safety that setters > and field injection simply cannot as specified by the JVM spec. > Also, consider what happens when the object class type is _immutable_. That > is, all object initialization must happen through a constructor since the > object is immutable, which are inherently Thread-safe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-2083) Geode should call Declarable.init() when the SecurityManager component implements Declarable.
[
https://issues.apache.org/jira/browse/GEODE-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-2083:
-
Issue Type: Bug (was: Improvement)
> Geode should call Declarable.init() when the SecurityManager component
> implements Declarable.
> -
>
> Key: GEODE-2083
> URL: https://issues.apache.org/jira/browse/GEODE-2083
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.0.0-incubating
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Major
> Labels: affects-spring
>
> Though, going forward (i.e. post {{1.0.0-incubating}}), there will be
> multiple ways to configure Apache Geode's {{SecurityManager}} implementation
> in effect, for instance, and most notably, [GEODE-2030], in addition to the
> Geode {{security-manager}} (System) property, it would be highly valuable if
> Apache Geode called
> [Declarable.init()|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/cache/Declarable.html#init-java.util.Properties-]
> on the custom, application-specific, Geode-based {{SecurityManager}}
> implementation providing the custom, application-specific, Geode-based
> [SecurityManager|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html]
> implementation implemented the Geode
> [Declarable|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/cache/Declarable.html]
> interface.
> This would be especially beneficial in situations where any post-construction
> initialization logic needed to be invoked after the constructor, particularly
> where the custom {{SecurityManager}} **this** reference needs to be accessed
> by other classes/components in the {{init()}} method outside the
> {{SecurityManager}} instance, which if done from/within a constructor during
> construction would allow the **this** reference to escape (not good in a
> multi-threaded environment).
> This is also useful in situations where the GemFire {{security-manager}}
> (System) property is still being used, as I suspect will be the case in some
> situations/environments.
> Tracing this through, the {{IntegratedSecurityService}} [delegates
> |https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java#L335]
> to the {{SecurityService.getObjectOfTypeFromClass(..)}} method. This
> [method|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java#L67-L91]
> (along with [similar supporting
> methods|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java#L93-L129])
> could Introspect the class type and determine whether the custom,
> application-specific, Geode-based {{SecurityManager}} implementation
> implements the {{Declarable}} interface, invoking the {{init()}} method
> before returning, if it does.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-167) Leverage the @ConditionalIgnore annotation and corresponding JUnit Rule to setup conditional test exclusions in the test suite based on timestamp or complex condition imp
[
https://issues.apache.org/jira/browse/GEODE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum reassigned GEODE-167:
---
Assignee: (was: John Blum)
> Leverage the @ConditionalIgnore annotation and corresponding JUnit Rule to
> setup conditional test exclusions in the test suite based on timestamp or
> complex condition implemented with IgnoreCondition.
>
>
> Key: GEODE-167
> URL: https://issues.apache.org/jira/browse/GEODE-167
> Project: Geode
> Issue Type: Improvement
> Components: general
> Environment: Apache Geode test infrastructure
>Reporter: John Blum
>Priority: Minor
> Labels: ApacheGeode, ConditionalIgnore, Test, UnitTest
> Attachments: ConditionalIgnoreRule.java, ConditionalIgnoreRule.java,
> DefaultIgnoreCondition.java, IgnoreCondition.java,
> IgnoreConditionEvaluationException.java
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> Make use of the {{@ConditionalIgnore}} annotation and corresponding JUnit
> {{ConditionalIgnoreRule}} to ignore tests on a case-by-case basis using a
> specific set of criteria (a.k.a. {{IgnoreCondition}}).
> This could be used for instance to ignore offending tests causing failure or
> hangs in the test suite downstream or to conditional ignore a test based on
> specific environmental/context requirements.
> See attached source code for reference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-126) Provide pre-canned Geode Functions out-of-the-box for useful, common Geode operations.
[
https://issues.apache.org/jira/browse/GEODE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-126:
Priority: Minor (was: Major)
> Provide pre-canned Geode Functions out-of-the-box for useful, common Geode
> operations.
> --
>
> Key: GEODE-126
> URL: https://issues.apache.org/jira/browse/GEODE-126
> Project: Geode
> Issue Type: Improvement
> Components: functions
>Affects Versions: 1.0.0-incubating
> Environment: Apache Geode + Cache Clients
>Reporter: John Blum
>Priority: Minor
> Labels: ApacheGeode, Canned, Functions, Out-of-the-Box,
> affects-spring, docs
>
> There were many useful _Geode_
> [Function(s)|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/cache/execute/Function.java]
> created to implement many of _Geode's_ features.
> For instance, _Gfsh_ commands were nearly all implemented with _Geode_
> [Functions|https://github.com/apache/incubator-geode/tree/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions].
> Some of these {{Functions}} should be provided out-of-the-box, as pre-canned
> {{Functions}} that users can use and documented as such.
> One good +example+ of such a {{Function}} is the _Gfsh's_ {{list functions}}
> command {{Function}}...
> [ListFunctionFunction|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/ListFunctionFunction.java].
> There are many more like
> [ListFunctionFunction|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/ListFunctionFunction.java]
> that would be equally useful to provide in a non-internal API, supported by
> Geode out-of-the-box.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8699) Expose the OQL Parser as a public API
John Blum created GEODE-8699: Summary: Expose the OQL Parser as a public API Key: GEODE-8699 URL: https://issues.apache.org/jira/browse/GEODE-8699 Project: Geode Issue Type: Wish Components: querying Reporter: John Blum This is a request to have the OQL Parser API used by Apache Geode under the hood be exposed as a public API, consumable by Frameworks and Tooling. While applications may not have a need to use the OQL Parser API, Frameworks and Tooling most certainly do. For instance, Spring Data for Apache Geode (SDG) is currently parsing and generating OQL queries in the Spring Data Repository infrastructure. Currently, there is no easy way to consistently parse or generate OQL statements given the API to parse OQL is "internal". This leaves Framework and Tool designers to have to either 1) create a Grammar for OQL and generating a Parser using JavaCC or ANTLR (thereby reinventing the wheel) or 2) resorting to a poor mans recursive descent parser or using simple REGEX and String parsing/concatenation. #1 is dangerous if Geode's Grammar for OQL ever changes. #2 is error prone at best. Please consider making the OQL Parser API along with the model for the OQL query components (e.g. projection, predicates, etc) public. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8684) Setting a session's maxInactiveInterval does not work when the commit valve is disabled
[
https://issues.apache.org/jira/browse/GEODE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230045#comment-17230045
]
ASF GitHub Bot commented on GEODE-8684:
---
sabbey37 commented on a change in pull request #5724:
URL: https://github.com/apache/geode/pull/5724#discussion_r520697519
##
File path:
geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Tomcat9CachingClientServerValveDisabledTest.java
##
@@ -0,0 +1,28 @@
+/*
+ * 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.session.tests;
+
+import static
org.apache.geode.session.tests.ContainerInstall.ConnectionType.CACHING_CLIENT_SERVER;
+import static
org.apache.geode.session.tests.TomcatInstall.TomcatVersion.TOMCAT9;
+
+import java.util.function.IntSupplier;
+
+public class Tomcat9CachingClientServerValveDisabledTest extends
TomcatClientServerTest {
Review comment:
Is there any value in adding a ValveDisabled test for other versions of
Tomcat?
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
> Setting a session's maxInactiveInterval does not work when the commit valve
> is disabled
> ---
>
> Key: GEODE-8684
> URL: https://issues.apache.org/jira/browse/GEODE-8684
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> I was using the {{CommandServlet}}, in an external test, and noticed that
> when the commit valve is disabled, attempting to set the session's
> maxInactiveInterval does not cause the session's maxInactiveInterval to be
> changed and it remains at the default.
> My setup consisted of 2 Geode servers and a single Tomcat instance (9.0.39).
> I was checking the sessions with the following gfsh query:
> {code:java}
> query --query="select e.key,e.value.maxInactiveInterval from
> /gemfire_modules_sessions.entries as e
> {code}
> My {{context.xml}} includes the following:
> {code:xml}
>className="org.apache.geode.modules.session.catalina.Tomcat8DeltaSessionManager"
> enableLocalCache="false"
> enableCommitValve="false"
> regionAttributesId="PARTITION_REDUNDANT"
> />
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230041#comment-17230041
]
ASF GitHub Bot commented on GEODE-8692:
---
sabbey37 commented on a change in pull request #5722:
URL: https://github.com/apache/geode/pull/5722#discussion_r521449133
##
File path:
geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/RegionAdvisorJUnitTest.java
##
@@ -0,0 +1,72 @@
+/*
+ * 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.internal.cache.partitioned;
+
+import static
org.apache.geode.distributed.internal.DistributionAdvisor.ILLEGAL_SERIAL;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+import org.junit.Before;
+import org.junit.Test;
+
+import org.apache.geode.cache.PartitionAttributes;
+import org.apache.geode.cache.RegionAttributes;
+import org.apache.geode.distributed.internal.DistributionManager;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.BucketAdvisor;
+import org.apache.geode.internal.cache.PartitionedRegion;
+import org.apache.geode.internal.cache.ProxyBucketRegion;
+
+public class RegionAdvisorJUnitTest {
+
+ private PartitionedRegion partitionedRegion;
+ private RegionAdvisor regionAdvisor;
+ private final int[] serials = new int[] {ILLEGAL_SERIAL, ILLEGAL_SERIAL,
ILLEGAL_SERIAL};
+
+ @Before
+ public void setUp() throws Exception {
+partitionedRegion = mock(PartitionedRegion.class);
+regionAdvisor = new RegionAdvisor(partitionedRegion);
+ }
+
+ @Test
+ public void
getBucketSerials_shouldReturnAnArrayOfIllegalSerials_whenBucketsAreNull() {
+RegionAttributes regionAttributes = mock(RegionAttributes.class);
+PartitionAttributes partitionAttributes = mock(PartitionAttributes.class);
+when(partitionedRegion.getAttributes()).thenReturn(regionAttributes);
+
when(regionAttributes.getPartitionAttributes()).thenReturn(partitionAttributes);
+when(partitionAttributes.getTotalNumBuckets()).thenReturn(3);
+
+assertThat(regionAdvisor.getBucketSerials()).containsExactly(serials);
+ }
+
+ @Test
+ public void
processProfilesQueuedDuringInitialization_shouldNotThrowIndexOutOfBoundsException()
{
+RegionAdvisor.QueuedBucketProfile qbp =
+new
RegionAdvisor.QueuedBucketProfile(mock(InternalDistributedMember.class),
serials, true);
+DistributionManager distributionManager = mock(DistributionManager.class);
+
when(regionAdvisor.getDistributionManager()).thenReturn(distributionManager);
+when(distributionManager.isCurrentMember(any())).thenReturn(true);
+regionAdvisor.preInitQueue.add(qbp);
+
+ProxyBucketRegion pbr = mock(ProxyBucketRegion.class);
+when(pbr.getBucketAdvisor()).thenReturn(mock(BucketAdvisor.class));
+regionAdvisor.buckets = new ProxyBucketRegion[] {pbr, pbr, pbr};
+
+regionAdvisor.processProfilesQueuedDuringInitialization();
Review comment:
I just added that verification!
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
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{Regio
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229952#comment-17229952 ] ASF GitHub Bot commented on GEODE-7309: --- mkevo edited a comment on pull request #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-725401895 Hi @nabarunnag , It passed a long period from your last comment. Is it still valid? Do you fixed your internal test cases? Can I go on with resolving conflicts and merging this PR? 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 > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229951#comment-17229951 ] ASF GitHub Bot commented on GEODE-7309: --- mkevo commented on pull request #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-725401895 Hi @nabarunnag , It passed a long period from your last comment. Is it still valid? Do you fixed your internal test cases? Can I go on with fixing conflicts and merging this PR? 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 > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8293) activeCQCount has negative value
[
https://issues.apache.org/jira/browse/GEODE-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229948#comment-17229948
]
ASF GitHub Bot commented on GEODE-8293:
---
mkevo commented on pull request #5620:
URL: https://github.com/apache/geode/pull/5620#issuecomment-725400814
Hi @kohlmu-pivotal ,
Do you agree with changes?
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
> activeCQCount has negative value
>
>
> Key: GEODE-8293
> URL: https://issues.apache.org/jira/browse/GEODE-8293
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> In case you have more than one server in the system and you close CQ there
> will be negative value of active cqs.
> The problem is when you started more than one server and execute cq on it. In
> that case we got incCqsActive on one server, but when it is closed we have
> decCqsActive on both servers.
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide MetricsCategory | Metric | Value
> | | -
> query| activeCQCount| 1
> | queryRequestRate | 0.0
> {code}
> After cq is closed or stopped:
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8614) Provide an specific client-side exception for server LowMemoryException
[
https://issues.apache.org/jira/browse/GEODE-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229881#comment-17229881
]
ASF GitHub Bot commented on GEODE-8614:
---
gaussianrecurrence commented on pull request #688:
URL: https://github.com/apache/geode-native/pull/688#issuecomment-725326241
Maybe @moleske @pivotal-jbarrett @mreddington @pdxcodemonkey you could throw
some comments?
Thanks!
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
> Provide an specific client-side exception for server LowMemoryException
> ---
>
> Key: GEODE-8614
> URL: https://issues.apache.org/jira/browse/GEODE-8614
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS AN* native client contributor
> *I WANT* to have a client-side exception for LowMemoryException
> *SO THAT* I can nofity accordingly from the client-side upon server
> memory-depletion.
> —
> *Additional information*
> This is the callstack of the LowMemoryException:
> {noformat}
> [error 2020/10/13 09:54:14.401405 UTC 140522117220352] Region::put: An
> exception (org.apache.geode.cache.LowMemoryException: PartitionedRegion:
> /part_a cannot process operation on key foo|0 because members
> [192.168.240.14(dms-server-1:1):41000] are running low on memory
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.checkIfBucketSick(RegionAdvisor.java:482)
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkIfAboveThreshold(PartitionedRegion.java:2278)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2982)
> at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2212)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5573)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5533)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5212)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:411)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834) ) happened at remote
> server.
> {noformat}
> Idea would be to modify *ThinClientRegion::handleServerException* in order to
> return a new error and later on, map it to a new created exception
> *Suggestions*
> The new exception could be called:
> * CacheServerLowMemoryException
> * ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229880#comment-17229880 ] ASF GitHub Bot commented on GEODE-8537: --- gaussianrecurrence commented on pull request #687: URL: https://github.com/apache/geode-native/pull/687#issuecomment-725326162 Maybe @moleske @pivotal-jbarrett @mreddington @pdxcodemonkey you could throw some comments? Thanks! 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 > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8320) SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents is failiing
[
https://issues.apache.org/jira/browse/GEODE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez resolved GEODE-8320.
--
Fix Version/s: 1.14.0
Resolution: Fixed
> SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
> is failiing
> ---
>
> Key: GEODE-8320
> URL: https://issues.apache.org/jira/browse/GEODE-8320
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.14.0
>
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> 11:55:01
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$134/1929719983.run
> in VM 2 running on Host 249227cf2774 with 8 VMs
> 11:55:01
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 11:55:01
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined
> as a lambda expression in org.apache.geode.internal.cache.wan.WANTestBase
> that uses int, intorg.apache.geode.cache.Region Expected region entries:
> 2 but actual entries: 1 present region keyset [7435200, <*
> Intentionally cut out by Jira submitter *> 8851200] expected:<2> but
> was:<1> within 5 minutes.
> 11:55:01
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 11:55:01
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 11:55:01
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.WANTestBase.validateRegionSize(WANTestBase.java:2942)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.lambda$testReplicatedSerialPropagationHAWithGroupTransactionEvents$bb17a952$8(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> java.lang.AssertionError: Expected region entries: 2 but actual entries:
> 1 present region keyset [7435200, <*Intentionally cut out by Jira
> submitter*> ] expected:<2> but was:<1>
> 12:31:11
> {noformat}
>
>
>
>
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-results/distributedTest/1593463337/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-artifacts/1593463337/distributedtestfiles-OpenJDK8-1.14.0-build.0193.tgz
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8698) Remove TcrPoolEndPoint::registerDM unnecessary DM lock
Mario Salazar de Torres created GEODE-8698: -- Summary: Remove TcrPoolEndPoint::registerDM unnecessary DM lock Key: GEODE-8698 URL: https://issues.apache.org/jira/browse/GEODE-8698 Project: Geode Issue Type: Bug Components: native client Affects Versions: 1.13.0, 1.12.0 Reporter: Mario Salazar de Torres Within TcrPoolEndPoint::registerDM, there is a lock for the DM connection queue mutex, which is not really necessary given that, as stated before, having a hard restriction on the connection number is not a must. Problem with this lock is that if any of the pool endpoints fails, connections are on hold while this endpoint is restored. One of the examples I've seen is that whenever a server goes down, and a pool with subscription enabled tries to re-open the subscription connection, all of the threads get locked due to this, even if they are not connecting to the server which is failing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8553) Reduce ThinClientLocatorHelper lock time
[ https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229859#comment-17229859 ] ASF GitHub Bot commented on GEODE-8553: --- gaussianrecurrence commented on pull request #660: URL: https://github.com/apache/geode-native/pull/660#issuecomment-725303579 Sorry to bother you again, it has been quite a long time since this had any feedback. Is there anything else you would like me to do in order to get this ready? Thanks! 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 > Reduce ThinClientLocatorHelper lock time > > > Key: GEODE-8553 > URL: https://issues.apache.org/jira/browse/GEODE-8553 > Project: Geode > Issue Type: Improvement > Components: native client >Affects Versions: 1.12.0, 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > During my troublshootings, I've seen that locking m_locatorLock for the whole > scope of the class function members might cause some inter-locks. > Problem here and in many other places of the NC is that networking operations > are performed while a mutex is locked. Therefore if *thread A* takes longer > than expected in performing its network operation, it might block another one > which does not requires any resource of the first *thread A*. Hence, the > inter-lock. > This improvement is the first one of a series regarding to lock scope > reduction when it comes with code regarding networking in NC. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8687) Durable client is continuously re-registering CQs on all servers when event de-serialization fails causing resource exhaustion on servers
[
https://issues.apache.org/jira/browse/GEODE-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8687:
--
Labels: pull-request-available (was: )
> Durable client is continuously re-registering CQs on all servers when event
> de-serialization fails causing resource exhaustion on servers
> --
>
> Key: GEODE-8687
> URL: https://issues.apache.org/jira/browse/GEODE-8687
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.13.0
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Attachments: deserialzationFault.log
>
>
> When ReflectionBasedAutoSerializer is wrongly/not set it results with
> serialization exception on client at the reception of the CQ events.
> Serialization exception isn't logged which is misleading, and is hard to find
> that actually ReflectionBasedAutoSerializer isn't set correctly. Only log
> that can be seen is that client/servers subscription connections are closed
> due to EOF. This is because client destroys subscriptions connections
> intentionally, but doesn't log reason (PdxSerializationException) that led to
> this. It would be good that serialization exceptions are logged as error or
> warn.
> Client destroys subscription connection and perform server fail-over whenever
> serialization issue occurs. Additionally when subscription connection for
> particular server fails multiple times then this server is put in deny list
> for 10 seconds (this is configurable with {{ping-interval}}). After 10s
> expire the server is removed from list and it is available for subscription
> connection which will be destroyed again due serialization issue. This will
> go indefinitely and approx. every 10s in this case the client subscribes to
> each servers at least once. Due to serialization issue events aren't sent to
> client and remain in subscription queues.
> Whenever connection fails due to serialization issue and client is not
> durable then subscription queue is closed and events are lost.
> The biggest problem arises when client is durable. This is because
> subscription queue remains on server for configurable period of time (e.g.
> 300s) waiting for client to reconnect. When client perform fail-over to
> another server it will create new subscription queue using initial image from
> old queue that is currently paused. This means that all events from old queue
> will be transferred to new subscription queue hosted by the current primary
> server. This will happen on all servers and all of them will have copy of the
> queue even subscription redundancy isn't configured. The problem here is that
> client will periodically (every 10s in this case) establish connection to
> each servers, so configured timeout (e.g. 300s) will never expire, but it
> will be renewed each time client is registered. This could cause a lots of
> problems since memory and disk usage (if overflow on queue is configured)
> will increase on all servers.
> You can find in attached logs for the problematic case with durable client :
> vm0 -> locator
> vm1, vm2 -> servers
> vm3 -> durable client with enabled subscription handling CQ
> events
> vm4 -> client generating traffic that should trigger registered
> CQ
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8687) Durable client is continuously re-registering CQs on all servers when event de-serialization fails causing resource exhaustion on servers
[
https://issues.apache.org/jira/browse/GEODE-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229837#comment-17229837
]
ASF GitHub Bot commented on GEODE-8687:
---
jvarenina opened a new pull request #5730:
URL: https://github.com/apache/geode/pull/5730
* Improves handling of PdxSerializationException on client at the reception
of events from subscription queue
* Faulty behavior: At the reception of event for which
PdxSerializationException is thrown the client would always shutdown
CacheClientUpdater, destroy subscription queue connection
and try to perform failover to other server in cluster
* Behaviour with this fix: At the reception of event that provoke
PdxSerializationException client will only log the exception
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] Does `gradlew build` run cleanly?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
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
> Durable client is continuously re-registering CQs on all servers when event
> de-serialization fails causing resource exhaustion on servers
> --
>
> Key: GEODE-8687
> URL: https://issues.apache.org/jira/browse/GEODE-8687
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.13.0
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Attachments: deserialzationFault.log
>
>
> When ReflectionBasedAutoSerializer is wrongly/not set it results with
> serialization exception on client at the reception of the CQ events.
> Serialization exception isn't logged which is misleading, and is hard to find
> that actually ReflectionBasedAutoSerializer isn't set correctly. Only log
> that can be seen is that client/servers subscription connections are closed
> due to EOF. This is because client destroys subscriptions connections
> intentionally, but doesn't log reason (PdxSerializationException) that led to
> this. It would be good that serialization exceptions are logged as error or
> warn.
> Client destroys subscription connection and perform server fail-over whenever
> serialization issue occurs. Additionally when subscription connection for
> particular server fails multiple times then this server is put in deny list
> for 10 seconds (this is configurable with {{ping-interval}}). After 10s
> expire the server is removed from list and it is available for subscription
> connection which will be destroyed again due serialization issue. This will
> go indefinitely and approx. every 10s in this case the client subscribes to
> each servers at least once. Due to serialization issue events aren't sent to
> client and remain in subscription queues.
> Whenever connection fails due to serialization issue and client is not
> durable then subscription queue is closed and events are lost.
> The biggest problem arises when client is durable. This is because
> subscription queue remains on server for configurable period of time (e.g.
> 300s) waiting for client to reconnect. When client perform fail-over to
> another server it will create new subscription queue using initial image from
> old queue that is currently paused. This means that all events from old queue
> will be transferred to new subscription queue hosted by the current primary
> server. This will happen on all servers and all of them will have copy of the
> queue even subscription redundancy isn't configured. The problem here is that
> client will periodically (every 10s in this
[jira] [Updated] (GEODE-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[ https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8693: -- Labels: pull-request-available (was: ) > C++ native client Function.execute() with onServers does not throw exception > if one of the servers goes down while executing the function. > -- > > Key: GEODE-8693 > URL: https://issues.apache.org/jira/browse/GEODE-8693 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > According to the Apache Geode Native C++ API documentation, the > FunctionService.onServers() function will throw an Exception if one of the > servers goes down while dispatching or executing the function on the server. > Nevertheless, currently no exception is thrown in that case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[ https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229819#comment-17229819 ] ASF GitHub Bot commented on GEODE-8693: --- albertogpz opened a new pull request #690: URL: https://github.com/apache/geode-native/pull/690 …cute with onServers When a function is executed by using onServers, if one of the servers goes down while the function is executed, no exception is thrown (despite what the Native C++ API documentation says). The reason was that when an IO error was detected when calling a function on a server, the FunctionService::execute() function instead of returning the IO error returned no error. With this change this function now returns the IO error which translates in a NotConnectedException thrown. 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 > C++ native client Function.execute() with onServers does not throw exception > if one of the servers goes down while executing the function. > -- > > Key: GEODE-8693 > URL: https://issues.apache.org/jira/browse/GEODE-8693 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > According to the Apache Geode Native C++ API documentation, the > FunctionService.onServers() function will throw an Exception if one of the > servers goes down while dispatching or executing the function on the server. > Nevertheless, currently no exception is thrown in that case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
