[jira] [Created] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
Alberto Bustamante Reyes created GEODE-8565:
---
Summary: c++ client tries to connect to down server until IO error
is thrown
Key: GEODE-8565
URL: https://issues.apache.org/jira/browse/GEODE-8565
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Alberto Bustamante Reyes
This ticket is an improvement over GEODE-8231:
{quote}If a C++ client connected to a cluster is sending operations to a
partitioned region and one of the server goes down, the client keeps trying to
send operations to the down server. This can be observed in the logs by a
continuous flow of lines containing: "IO error in handshake with endpoint..."
{quote}
After that improvement, the c++ client removes the metadata info of the failing
server once the "IO error in handshake" is received.
But it has been observed that before that error is received, "timeout error"
can be returned. So the client will try to reconnect until the "IO error in
handshake" is received.
This ticket aims to extend the GEODE-8231 solution so the client removes the
server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205368#comment-17205368
]
ASF GitHub Bot commented on GEODE-8565:
---
alb3rtobr opened a new pull request #662:
URL: https://github.com/apache/geode-native/pull/662
This ticket is an improvement over GEODE-8231:
> If a C++ client connected to a cluster is sending operations to a
partitioned region and one of the server goes down, the client keeps trying to
send operations to the down server. This can be observed in the logs by a
continuous flow of lines containing: "IO error in handshake with endpoint..."
After that improvement, the c++ client removes the metadata info of the
failing server once the "IO error in handshake" is received.
But it has been observed that before that error is received, "timeout error"
can be returned. So the client will try to reconnect until the "IO error in
handshake" is received.
This ticket aims to extend the GEODE-8231 solution so the client removes the
server metadata information when a timeout is received.
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++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Priority: Major
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8565:
--
Labels: pull-request-available (was: )
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes reassigned GEODE-8565:
---
Assignee: Alberto Bustamante Reyes
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7845) Rollingupgrade should not conflict with the new ClearPRMessage
[ https://issues.apache.org/jira/browse/GEODE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205408#comment-17205408 ] ASF GitHub Bot commented on GEODE-7845: --- jujoramos commented on pull request #5577: URL: https://github.com/apache/geode/pull/5577#issuecomment-702042335 @mhansonp: just FYI, I have an old [PR](https://github.com/apache/geode/pull/5393) opened (draft as the feature is not yet implemented) to test the backward compatibility of the `clear` operation, it might be useful for your current work. 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 > Rollingupgrade should not conflict with the new ClearPRMessage > --- > > Key: GEODE-7845 > URL: https://issues.apache.org/jira/browse/GEODE-7845 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Mark Hanson >Priority: Major > Labels: GeodeCommons, pull-request-available > > PartitionedRegion clear introduced a new ClearPRMessage. In case of doing > rolling upgrade, the user called PR.clear. The new ClearPRMessage should not > fail. It should not be sent to the old members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8555) SimpleDiskRegionJunitTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-8555:
---
Priority: Minor (was: Major)
> SimpleDiskRegionJunitTest fails on Windows
> --
>
> Key: GEODE-8555
> URL: https://issues.apache.org/jira/browse/GEODE-8555
> Project: Geode
> Issue Type: Test
> Components: core
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Updating Junit to 4.13, one test failed on Windows due to failure to delete
> some temporary test files.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/455
> {code:java}
> org.apache.geode.internal.cache.SimpleDiskRegionJUnitTest > testBasicClose
> FAILED
> java.lang.AssertionError: Exception in createOverflowOnly due to
> java.lang.IllegalStateException: The region "/testRegion" has been persisted
> to disk so it can not be recreated on the same disk store without
> persistence. Either destroy the persistent region, recreate it as overflow
> and persistent, or create the overflow only region on a different disk store.
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.internal.cache.SimpleDiskRegionJUnitTest.testBasicClose(SimpleDiskRegionJUnitTest.java:75)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8555) SimpleDiskRegionJunitTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-8555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey resolved GEODE-8555.
Fix Version/s: 1.14.0
Resolution: Fixed
> SimpleDiskRegionJunitTest fails on Windows
> --
>
> Key: GEODE-8555
> URL: https://issues.apache.org/jira/browse/GEODE-8555
> Project: Geode
> Issue Type: Test
> Components: core
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Assignee: Sarah Abbey
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Updating Junit to 4.13, one test failed on Windows due to failure to delete
> some temporary test files.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/455
> {code:java}
> org.apache.geode.internal.cache.SimpleDiskRegionJUnitTest > testBasicClose
> FAILED
> java.lang.AssertionError: Exception in createOverflowOnly due to
> java.lang.IllegalStateException: The region "/testRegion" has been persisted
> to disk so it can not be recreated on the same disk store without
> persistence. Either destroy the persistent region, recreate it as overflow
> and persistent, or create the overflow only region on a different disk store.
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.internal.cache.SimpleDiskRegionJUnitTest.testBasicClose(SimpleDiskRegionJUnitTest.java:75)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8548) ACE_Inet_Addr takes too long in reverse DNS resolution
[
https://issues.apache.org/jira/browse/GEODE-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205560#comment-17205560
]
ASF GitHub Bot commented on GEODE-8548:
---
pdxcodemonkey merged pull request #659:
URL: https://github.com/apache/geode-native/pull/659
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
> ACE_Inet_Addr takes too long in reverse DNS resolution
> --
>
> Key: GEODE-8548
> URL: https://issues.apache.org/jira/browse/GEODE-8548
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: connections, pull-request-available
>
> Whenever TcpConn::connect is called, a system call to *get_host_name* is made
> in order to obtain reverse resolution for the connection address, right here:
> {code:cpp}
> void TcpConn::connect() {
> using apache::geode::internal::chrono::duration::to_string;
> ACE_OS::signal(SIGPIPE, SIG_IGN); // Ignore broken pipe
> LOGFINER(std::string("Connecting plain socket stream to ") +
>inetAddress_.get_host_name() + ":" +
>std::to_string(inetAddress_.get_port_number()) + " waiting " +
>to_string(timeout_));
> ···
> {code}
> get_host_name executes getnameinfo underlying and the thing is that depending
> on your system configuration in the case of the address not having a reverse
> resolution entry it might take a long period. In my case it takes 10 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8548) ACE_Inet_Addr takes too long in reverse DNS resolution
[
https://issues.apache.org/jira/browse/GEODE-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205561#comment-17205561
]
ASF subversion and git services commented on GEODE-8548:
Commit 6122245ddf0c55fd1e07ae1daae25d67db7889be in geode-native's branch
refs/heads/develop from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=6122245 ]
GEODE-8548: Avoid hostname resolution in TcpConn (#659)
- Calling get_host_name() in TcpConn::connect involves a system call that
might take several seconds to complete.
- So endpoint is stored instead upon TcpConn construction and used later
instead of making the system call.
- (pdxcodemonkey) Note that the call in question was buried in use of a LOG*
macro, which is not best practice
> ACE_Inet_Addr takes too long in reverse DNS resolution
> --
>
> Key: GEODE-8548
> URL: https://issues.apache.org/jira/browse/GEODE-8548
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: connections, pull-request-available
>
> Whenever TcpConn::connect is called, a system call to *get_host_name* is made
> in order to obtain reverse resolution for the connection address, right here:
> {code:cpp}
> void TcpConn::connect() {
> using apache::geode::internal::chrono::duration::to_string;
> ACE_OS::signal(SIGPIPE, SIG_IGN); // Ignore broken pipe
> LOGFINER(std::string("Connecting plain socket stream to ") +
>inetAddress_.get_host_name() + ":" +
>std::to_string(inetAddress_.get_port_number()) + " waiting " +
>to_string(timeout_));
> ···
> {code}
> get_host_name executes getnameinfo underlying and the thing is that depending
> on your system configuration in the case of the address not having a reverse
> resolution entry it might take a long period. In my case it takes 10 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8566) Redis native tests should not also stand up a Geode server
Jens Deppe created GEODE-8566:
-
Summary: Redis native tests should not also stand up a Geode server
Key: GEODE-8566
URL: https://issues.apache.org/jira/browse/GEODE-8566
Project: Geode
Issue Type: Test
Components: redis
Reporter: Jens Deppe
Our native acceptance tests currently extend from the integration tests and
both classes have a {{@ClassRule}} that results in both a native (container)
instance and a Geode instance starting up. Mostly not a problem except for
{{PubSubNativeAcceptanceTest}} which was not testing against native redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8566) Redis native tests should not also stand up a Geode server
[
https://issues.apache.org/jira/browse/GEODE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205573#comment-17205573
]
ASF GitHub Bot commented on GEODE-8566:
---
jdeppe-pivotal opened a new pull request #5584:
URL: https://github.com/apache/geode/pull/5584
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
> Redis native tests should not also stand up a Geode server
> --
>
> Key: GEODE-8566
> URL: https://issues.apache.org/jira/browse/GEODE-8566
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Our native acceptance tests currently extend from the integration tests and
> both classes have a {{@ClassRule}} that results in both a native (container)
> instance and a Geode instance starting up. Mostly not a problem except for
> {{PubSubNativeAcceptanceTest}} which was not testing against native redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8566) Redis native tests should not also stand up a Geode server
[
https://issues.apache.org/jira/browse/GEODE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8566:
--
Labels: pull-request-available (was: )
> Redis native tests should not also stand up a Geode server
> --
>
> Key: GEODE-8566
> URL: https://issues.apache.org/jira/browse/GEODE-8566
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Our native acceptance tests currently extend from the integration tests and
> both classes have a {{@ClassRule}} that results in both a native (container)
> instance and a Geode instance starting up. Mostly not a problem except for
> {{PubSubNativeAcceptanceTest}} which was not testing against native redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8548) ACE_Inet_Addr takes too long in reverse DNS resolution
[
https://issues.apache.org/jira/browse/GEODE-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres resolved GEODE-8548.
Resolution: Done
> ACE_Inet_Addr takes too long in reverse DNS resolution
> --
>
> Key: GEODE-8548
> URL: https://issues.apache.org/jira/browse/GEODE-8548
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: connections, pull-request-available
>
> Whenever TcpConn::connect is called, a system call to *get_host_name* is made
> in order to obtain reverse resolution for the connection address, right here:
> {code:cpp}
> void TcpConn::connect() {
> using apache::geode::internal::chrono::duration::to_string;
> ACE_OS::signal(SIGPIPE, SIG_IGN); // Ignore broken pipe
> LOGFINER(std::string("Connecting plain socket stream to ") +
>inetAddress_.get_host_name() + ":" +
>std::to_string(inetAddress_.get_port_number()) + " waiting " +
>to_string(timeout_));
> ···
> {code}
> get_host_name executes getnameinfo underlying and the thing is that depending
> on your system configuration in the case of the address not having a reverse
> resolution entry it might take a long period. In my case it takes 10 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8548) ACE_Inet_Addr takes too long in reverse DNS resolution
[
https://issues.apache.org/jira/browse/GEODE-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres closed GEODE-8548.
--
> ACE_Inet_Addr takes too long in reverse DNS resolution
> --
>
> Key: GEODE-8548
> URL: https://issues.apache.org/jira/browse/GEODE-8548
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: connections, pull-request-available
>
> Whenever TcpConn::connect is called, a system call to *get_host_name* is made
> in order to obtain reverse resolution for the connection address, right here:
> {code:cpp}
> void TcpConn::connect() {
> using apache::geode::internal::chrono::duration::to_string;
> ACE_OS::signal(SIGPIPE, SIG_IGN); // Ignore broken pipe
> LOGFINER(std::string("Connecting plain socket stream to ") +
>inetAddress_.get_host_name() + ":" +
>std::to_string(inetAddress_.get_port_number()) + " waiting " +
>to_string(timeout_));
> ···
> {code}
> get_host_name executes getnameinfo underlying and the thing is that depending
> on your system configuration in the case of the address not having a reverse
> resolution entry it might take a long period. In my case it takes 10 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8558) Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is a newline after query or sql comments before the query line
[ https://issues.apache.org/jira/browse/GEODE-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205591#comment-17205591 ] ASF GitHub Bot commented on GEODE-8558: --- jinmeiliao merged pull request #5571: URL: https://github.com/apache/geode/pull/5571 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 > Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is > a newline after query or sql comments before the query line > > > Key: GEODE-8558 > URL: https://issues.apache.org/jira/browse/GEODE-8558 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > > Setting the JVM MBean attribute QueryResultSetLimit to limit the query result > set (e.g. 2 here with my small local cluster) and it seems working, however, > in the pulse query textbox, if you have a carriage-return/newline after query > line or let's say a commented text/query before the actual query, it's > returning all the entries and the setting is not effective anymore. And if > this could also affect the queries running with commented text coming from > function execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8558) Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is a newline after query or sql comments before the query line
[ https://issues.apache.org/jira/browse/GEODE-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205595#comment-17205595 ] ASF subversion and git services commented on GEODE-8558: Commit 2485e57707d8f4535bbf9a3e5f5926a26421ca20 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2485e57 ] GEODE-8558: query input by users should trim newlines and comments. (#5571) > Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is > a newline after query or sql comments before the query line > > > Key: GEODE-8558 > URL: https://issues.apache.org/jira/browse/GEODE-8558 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > > Setting the JVM MBean attribute QueryResultSetLimit to limit the query result > set (e.g. 2 here with my small local cluster) and it seems working, however, > in the pulse query textbox, if you have a carriage-return/newline after query > line or let's say a commented text/query before the actual query, it's > returning all the entries and the setting is not effective anymore. And if > this could also affect the queries running with commented text coming from > function execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8558) Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is a newline after query or sql comments before the query line
[ https://issues.apache.org/jira/browse/GEODE-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205593#comment-17205593 ] ASF subversion and git services commented on GEODE-8558: Commit 2485e57707d8f4535bbf9a3e5f5926a26421ca20 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2485e57 ] GEODE-8558: query input by users should trim newlines and comments. (#5571) > Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is > a newline after query or sql comments before the query line > > > Key: GEODE-8558 > URL: https://issues.apache.org/jira/browse/GEODE-8558 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > > Setting the JVM MBean attribute QueryResultSetLimit to limit the query result > set (e.g. 2 here with my small local cluster) and it seems working, however, > in the pulse query textbox, if you have a carriage-return/newline after query > line or let's say a commented text/query before the actual query, it's > returning all the entries and the setting is not effective anymore. And if > this could also affect the queries running with commented text coming from > function execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205603#comment-17205603
]
ASF subversion and git services commented on GEODE-8533:
Commit a099fa361b6820343f47dac6a44bc63cbb754396 in geode's branch
refs/heads/develop from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a099fa3 ]
GEODE-8533: Docs - compaction-threshold mechanism description are wrong (#5549)
* GEODE-8533: User Guide - compaction-threshold is properly described as
percentage of live data, below which an OpLog is marked for compaction
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205600#comment-17205600
]
ASF GitHub Bot commented on GEODE-8533:
---
davebarnes97 merged pull request #5549:
URL: https://github.com/apache/geode/pull/5549
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
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205604#comment-17205604
]
ASF subversion and git services commented on GEODE-8533:
Commit a099fa361b6820343f47dac6a44bc63cbb754396 in geode's branch
refs/heads/develop from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a099fa3 ]
GEODE-8533: Docs - compaction-threshold mechanism description are wrong (#5549)
* GEODE-8533: User Guide - compaction-threshold is properly described as
percentage of live data, below which an OpLog is marked for compaction
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205609#comment-17205609
]
ASF subversion and git services commented on GEODE-8533:
Commit 09bccd5cc70a874c479f353724bbd01feaaa7015 in geode's branch
refs/heads/support/1.13 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=09bccd5 ]
GEODE-8533: Docs - compaction-threshold mechanism description are wrong (#5549)
* GEODE-8533: User Guide - compaction-threshold is properly described as
percentage of live data, below which an OpLog is marked for compaction
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205610#comment-17205610
]
ASF subversion and git services commented on GEODE-8533:
Commit 09bccd5cc70a874c479f353724bbd01feaaa7015 in geode's branch
refs/heads/support/1.13 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=09bccd5 ]
GEODE-8533: Docs - compaction-threshold mechanism description are wrong (#5549)
* GEODE-8533: User Guide - compaction-threshold is properly described as
percentage of live data, below which an OpLog is marked for compaction
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205612#comment-17205612
]
ASF subversion and git services commented on GEODE-8533:
Commit 49ffb064912f9a0e8532f9897be1252204f6b0af in geode's branch
refs/heads/support/1.12 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=49ffb06 ]
GEODE-8533: Docs - compaction-threshold mechanism description are wrong (#5549)
* GEODE-8533: User Guide - compaction-threshold is properly described as
percentage of live data, below which an OpLog is marked for compaction
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205611#comment-17205611
]
ASF subversion and git services commented on GEODE-8533:
Commit 49ffb064912f9a0e8532f9897be1252204f6b0af in geode's branch
refs/heads/support/1.12 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=49ffb06 ]
GEODE-8533: Docs - compaction-threshold mechanism description are wrong (#5549)
* GEODE-8533: User Guide - compaction-threshold is properly described as
percentage of live data, below which an OpLog is marked for compaction
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7671) Partitioned Region clear operations can occur successfully during GII
[
https://issues.apache.org/jira/browse/GEODE-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205619#comment-17205619
]
ASF GitHub Bot commented on GEODE-7671:
---
jinmeiliao commented on a change in pull request #5512:
URL: https://github.com/apache/geode/pull/5512#discussion_r498324202
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ClearGIIDUnitTest.java
##
@@ -0,0 +1,542 @@
+/*
+ * 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;
+
+import static org.apache.geode.cache.RegionShortcut.PARTITION;
+import static org.apache.geode.cache.RegionShortcut.REPLICATE;
+import static
org.apache.geode.internal.cache.InitialImageOperation.getGIITestHookForCheckingPurpose;
+import static org.apache.geode.test.dunit.rules.ClusterStartupRule.getCache;
+import static
org.apache.geode.test.dunit.rules.ClusterStartupRule.getClientCache;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.junit.Assert.fail;
+
+import java.io.Serializable;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.concurrent.CountDownLatch;
+
+import org.apache.logging.log4j.LogManager;
+import org.apache.logging.log4j.Logger;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheException;
+import org.apache.geode.cache.PartitionAttributesFactory;
+import org.apache.geode.cache.PartitionedRegionPartialClearException;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionFactory;
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.cache.client.ClientRegionShortcut;
+import org.apache.geode.cache.query.Index;
+import org.apache.geode.cache.query.IndexStatistics;
+import org.apache.geode.cache.query.QueryService;
+import org.apache.geode.distributed.internal.ClusterDistributionManager;
+import org.apache.geode.distributed.internal.DistributionMessage;
+import org.apache.geode.distributed.internal.DistributionMessageObserver;
+import org.apache.geode.test.awaitility.GeodeAwaitility;
+import org.apache.geode.test.dunit.Assert;
+import org.apache.geode.test.dunit.AsyncInvocation;
+import org.apache.geode.test.dunit.SerializableRunnable;
+import org.apache.geode.test.dunit.WaitCriterion;
+import org.apache.geode.test.dunit.rules.ClientVM;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+
+
+@RunWith(Parameterized.class)
+public class ClearGIIDUnitTest implements Serializable {
+
+
+ protected static final String REGION_NAME = "testPR";
+ protected static final String INDEX_NAME = "testIndex";
+ protected static final int TOTAL_BUCKET_NUM = 10;
+ protected static final int REDUNDANT_COPIES = 1;
+ protected static final int DATA_SIZE = 100;
+ protected static final int NUM_SERVERS = 2;
+
+ @Parameterized.Parameter(0)
+ public RegionShortcut regionShortcut;
+
+ protected int locatorPort;
+ protected MemberVM locator;
+ protected MemberVM[] dataStores;
Review comment:
probably rename this to serverVMs would be more appropriate
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ClearGIIDUnitTest.java
##
@@ -0,0 +1,542 @@
+/*
+ * 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, WITHOU
[jira] [Commented] (GEODE-8564) UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove()
[ https://issues.apache.org/jira/browse/GEODE-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205650#comment-17205650 ] ASF subversion and git services commented on GEODE-8564: Commit 357e91e2ce745d7ee81bf2847422f4f312b16a17 in geode's branch refs/heads/support/1.13 from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=357e91e ] GEODE-8564: Updated CopyOnWriteHashSet's iterator implementation to (#5583) support iterator.remove(). Updated JCAManagedConnection to not use iterator.remove(). It will now collect all items to remove and then use the CopyOnWriteHashSet removeAll functionality to avoid unnecessary intermediary collection creations. (cherry picked from commit 66bcce8bb27d1fae4a115517ef39cadcd2189aa8) > UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove() > -- > > Key: GEODE-8564 > URL: https://issues.apache.org/jira/browse/GEODE-8564 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.0, 1.13.0 >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > JCAManagedConnection uses a CopyOnWriteHashSet. > When using the collections iterator.remove() an > `UnsupportedOperationException` is thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8564) UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove()
[ https://issues.apache.org/jira/browse/GEODE-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205658#comment-17205658 ] ASF subversion and git services commented on GEODE-8564: Commit 5bac21fd431a9a89f6f58887a2fa6cb714cc238b in geode's branch refs/heads/support/1.12 from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5bac21f ] GEODE-8564: Updated CopyOnWriteHashSet's iterator implementation to (#5583) support iterator.remove(). Updated JCAManagedConnection to not use iterator.remove(). It will now collect all items to remove and then use the CopyOnWriteHashSet removeAll functionality to avoid unnecessary intermediary collection creations. (cherry picked from commit 66bcce8bb27d1fae4a115517ef39cadcd2189aa8) > UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove() > -- > > Key: GEODE-8564 > URL: https://issues.apache.org/jira/browse/GEODE-8564 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.0, 1.13.0 >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > JCAManagedConnection uses a CopyOnWriteHashSet. > When using the collections iterator.remove() an > `UnsupportedOperationException` is thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205660#comment-17205660
]
ASF GitHub Bot commented on GEODE-8533:
---
davebarnes97 opened a new pull request #5585:
URL: https://github.com/apache/geode/pull/5585
One more garbage vs. non-garbage clarification, and added a link to making
current oplog eligible for compaction by forcing oplog rotation
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
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8564) UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove()
[ https://issues.apache.org/jira/browse/GEODE-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8564: Fix Version/s: 1.13.1 1.14.0 1.12.1 > UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove() > -- > > Key: GEODE-8564 > URL: https://issues.apache.org/jira/browse/GEODE-8564 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.0, 1.13.0 >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.1 > > > JCAManagedConnection uses a CopyOnWriteHashSet. > When using the collections iterator.remove() an > `UnsupportedOperationException` is thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8564) UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove()
[ https://issues.apache.org/jira/browse/GEODE-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8564. - Resolution: Fixed > UnsupportedOperationException thrown on CopyOnWriteHashSet.iterator().remove() > -- > > Key: GEODE-8564 > URL: https://issues.apache.org/jira/browse/GEODE-8564 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.0, 1.13.0 >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.1 > > > JCAManagedConnection uses a CopyOnWriteHashSet. > When using the collections iterator.remove() an > `UnsupportedOperationException` is thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205709#comment-17205709 ] ASF GitHub Bot commented on GEODE-7864: --- lgtm-com[bot] commented on pull request #5582: URL: https://github.com/apache/geode/pull/5582#issuecomment-702293516 This pull request **fixes 59 alerts** when merging db9a023aa2fae3b9760de42d0fe45b2398665d0b into a099fa361b6820343f47dac6a44bc63cbb754396 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-2abc24aa50d9bc0690a903e43069ce6646335c99) **fixed alerts:** * 55 for Potential input resource leak * 4 for Potential output resource leak 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 > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 13h 10m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8159) Cache boost dependency for CI, builds
[ https://issues.apache.org/jira/browse/GEODE-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-8159. --- > Cache boost dependency for CI, builds > - > > Key: GEODE-8159 > URL: https://issues.apache.org/jira/browse/GEODE-8159 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Blake Bender >Assignee: Jacob Barrett >Priority: Major > Fix For: 1.14.0 > > > Boost has monthly bandwidth caps for downloads, which means if they hit their > cap we can't run CI again until the first of the month. It would benefit > both us and the boost folks greatly if we were to simply set up a job that > downloads boost, say, once per day and caches it in a storage bucket that we > own, then have our builds all retrieve it from there. -- 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=17205733#comment-17205733
]
ASF GitHub Bot commented on GEODE-8553:
---
pdxcodemonkey commented on a change in pull request #660:
URL: https://github.com/apache/geode-native/pull/660#discussion_r498430003
##
File path: cppcache/src/ThinClientLocatorHelper.hpp
##
@@ -60,20 +63,23 @@ class ThinClientLocatorHelper {
std::vector >& servers,
const std::string& serverGrp);
int32_t getCurLocatorsNum() {
-return static_cast(m_locHostPort.size());
+return static_cast(m_Locators.size());
}
GfErrType updateLocators(const std::string& serverGrp = "");
private:
+ std::vector getLocators() const;
Connector* createConnection(Connector*& conn, const char* hostname,
int32_t port,
std::chrono::microseconds waitSeconds,
int32_t maxBuffSizePool = 0);
- std::mutex m_locatorLock;
- std::vector m_locHostPort;
+
+ /**
+ * Data members
+ */
+ mutable std::mutex m_locatorLock;
Review comment:
shared_mutex seems like a good call, from my reading of it. Or go with
what you have, if you prefer a minimal change.
Just to be clear with respect to getLocators, I wasn't suggesting we remove
the const qualifier from the method. I was just curious if that is why the
mutex needed to be mutable. Your answer is perfectly fine and quite thorough,
so leave the mutex variable as mutable, and I'll resolve this conversation.
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] [Commented] (GEODE-8129) Write SNI test that drops proxy and restarts proxy
[
https://issues.apache.org/jira/browse/GEODE-8129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205735#comment-17205735
]
ASF GitHub Bot commented on GEODE-8129:
---
pdxcodemonkey commented on a change in pull request #658:
URL: https://github.com/apache/geode-native/pull/658#discussion_r498431745
##
File path: cppcache/acceptance-test/SNITest.cpp
##
@@ -174,4 +175,53 @@ TEST_F(SNITest, connectWithoutProxyFails) {
cache.close();
}
+TEST_F(SNITest, dropSNIProxyTest) {
+ const auto clientTruststore =
+ (clientSslKeysDir / boost::filesystem::path("/truststore_sni.pem"));
+
+ auto cache = CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "SNITest.log")
+ .set("ssl-enabled", "true")
+ .set("ssl-truststore", clientTruststore.string())
+ .create();
+
+ auto portString = runDockerCommand("docker port haproxy");
+ auto portNumber = parseProxyPort(portString);
+
+ cache.getPoolManager()
+ .createFactory()
+ .setSniProxy("localhost", portNumber)
+ .addLocator("locator-maeve", 10334)
+ .create("pool");
+
+ auto region = cache.createRegionFactory(RegionShortcut::PROXY)
+.setPoolName("pool")
+.create("jellyfish");
+
+ auto systemRVal = std::system("docker pause haproxy");
+ if (systemRVal == -1) {
+BOOST_LOG_TRIVIAL(error) << "std::system returned: " << systemRVal;
Review comment:
Meh - fine, it's just test code. If we ever need to debug it, we can
figure out where BOOST_LOG_TRIVIAL output goes.
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
> Write SNI test that drops proxy and restarts proxy
> ---
>
> Key: GEODE-8129
> URL: https://issues.apache.org/jira/browse/GEODE-8129
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Ernest Burghardt
>Priority: Major
> Labels: pull-request-available
>
> This test is similar to GEODE-8128 - only capability to parse `docker ps` and
> store the hostPort in advance of dropping proxy, this allows the proxy to be
> restarted with the same port mapping
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205736#comment-17205736
]
ASF GitHub Bot commented on GEODE-8533:
---
davebarnes97 merged pull request #5585:
URL: https://github.com/apache/geode/pull/5585
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
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205738#comment-17205738
]
ASF subversion and git services commented on GEODE-8533:
Commit ce77067a4fea2303f4db33399450a3df80189e29 in geode's branch
refs/heads/develop from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ce77067 ]
GEODE-8533: Docs - compaction-threshold description refinements (#5585)
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205739#comment-17205739
]
ASF subversion and git services commented on GEODE-8533:
Commit 445f350810a10e7219a83847a9842ff357d8ae4d in geode's branch
refs/heads/support/1.12 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=445f350 ]
GEODE-8533: Docs - compaction-threshold description refinements (#5585)
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205741#comment-17205741
]
ASF subversion and git services commented on GEODE-8533:
Commit d6033762378703d2707dbba81a9fb4844a26d643 in geode's branch
refs/heads/support/1.13 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d603376 ]
GEODE-8533: Docs - compaction-threshold description refinements (#5585)
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8495) Make DUnit launch members in non-conflicting directories [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8495: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > Make DUnit launch members in non-conflicting directories [PERMANENT] > > > Key: GEODE-8495 > URL: https://issues.apache.org/jira/browse/GEODE-8495 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Currently several features of the DUnit framework prevent tests being run in > parallel outside of a docker container: > 1. The DUnitLauncher launches child VMs in subdirectories with standard names > (e.g. vm0, vm1, ...) in the test JVM's working directory. If multiple tests > run in parallel, the child VMs created by each test share these directories. > 2. LocatorStarterRule and ServerStarterRule launch locators and servers in > the test JVM, directly in the test JVM's working directory. If multiple tests > run in parallel, the members started by these rules share these directories. > Each member expects to be the only thing running in its working directory. > When members from different tests share directories, they become confused and > fail. > To allow running tests in parallel outside of docker containers, fix these > and other directory conflict problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8495) Make DUnit launch members in non-conflicting directories [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205742#comment-17205742 ] ASF GitHub Bot commented on GEODE-8495: --- demery-pivotal opened a new pull request #5586: URL: https://github.com/apache/geode/pull/5586 The testClientSubscriptionQueueUsingDefaultDS() test in CacheXml66DUnitTest and its subclasses assumed that the system’s default disk directory is the JVM’s current working directory. This change removes that assumption by making the tests honor the defaultDiskDirs system property. Authored-by: Dale Emery 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 > Make DUnit launch members in non-conflicting directories [PERMANENT] > > > Key: GEODE-8495 > URL: https://issues.apache.org/jira/browse/GEODE-8495 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI > > Currently several features of the DUnit framework prevent tests being run in > parallel outside of a docker container: > 1. The DUnitLauncher launches child VMs in subdirectories with standard names > (e.g. vm0, vm1, ...) in the test JVM's working directory. If multiple tests > run in parallel, the child VMs created by each test share these directories. > 2. LocatorStarterRule and ServerStarterRule launch locators and servers in > the test JVM, directly in the test JVM's working directory. If multiple tests > run in parallel, the members started by these rules share these directories. > Each member expects to be the only thing running in its working directory. > When members from different tests share directories, they become confused and > fail. > To allow running tests in parallel outside of docker containers, fix these > and other directory conflict problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7612) Move statistics and logging implementation into .cpp files
[ https://issues.apache.org/jira/browse/GEODE-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-7612. - Resolution: Fixed No idea why this was reopened - resolving, again. > Move statistics and logging implementation into .cpp files > -- > > Key: GEODE-7612 > URL: https://issues.apache.org/jira/browse/GEODE-7612 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > > As a developer, I would like to minimize the time spent recompiling code that > I haven't modified. One important way to improve this situation in the > native client is to move some of the bazillions of inline methods declared in > headers into .cpp files. A change to one of these methods then triggers a > recompile of just that file, rather than the large number of native client > files that inevitably include the header. > This item covers the above transformation for the internal classes involved > in logging and statistics. While there, we should clean up a couple of other > things that are unnecessary, such as the use of our own `NonCopyable` and > `NonAssignable`, both of which can now easily be accomplished with a standard > C++ 11 mechanism. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7612) Move statistics and logging implementation into .cpp files
[ https://issues.apache.org/jira/browse/GEODE-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-7612. --- > Move statistics and logging implementation into .cpp files > -- > > Key: GEODE-7612 > URL: https://issues.apache.org/jira/browse/GEODE-7612 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > > As a developer, I would like to minimize the time spent recompiling code that > I haven't modified. One important way to improve this situation in the > native client is to move some of the bazillions of inline methods declared in > headers into .cpp files. A change to one of these methods then triggers a > recompile of just that file, rather than the large number of native client > files that inevitably include the header. > This item covers the above transformation for the internal classes involved > in logging and statistics. While there, we should clean up a couple of other > things that are unnecessary, such as the use of our own `NonCopyable` and > `NonAssignable`, both of which can now easily be accomplished with a standard > C++ 11 mechanism. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6650) Update to Boost 1.70.0
[ https://issues.apache.org/jira/browse/GEODE-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-6650. - Fix Version/s: 1.14.0 Resolution: Fixed Not sure why this one was still kicking around open, but we're for sure up to boost 1.73.0 now, so we've definitely upgraded. > Update to Boost 1.70.0 > -- > > Key: GEODE-6650 > URL: https://issues.apache.org/jira/browse/GEODE-6650 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Fix For: 1.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6650) Update to Boost 1.70.0
[ https://issues.apache.org/jira/browse/GEODE-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-6650. --- > Update to Boost 1.70.0 > -- > > Key: GEODE-6650 > URL: https://issues.apache.org/jira/browse/GEODE-6650 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Fix For: 1.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6530) Exception: Failed to add endpoint to pool
[ https://issues.apache.org/jira/browse/GEODE-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-6530. --- > Exception: Failed to add endpoint to pool > -- > > Key: GEODE-6530 > URL: https://issues.apache.org/jira/browse/GEODE-6530 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Fix For: 1.14.0 > > > Not sure if this is a serious bug, but should be investigated. > First stumbled across this when looking at the client logs for Charlie > Black's PCF web app. But I also see this exception in the logs when I run the > Examples. Since the examples do run to completion, this is likely an > innocuous exception. > > Our Examples (at least dotnet-authinit and dotnet-putgetremove) show this > error in the client log: > [error 2019/03/15 05:52:39.410822 Pacific Daylight Time > mmartell-mbpro-win10:4552 2972] Failed to add endpoint 10.118.20.94:40404 to > pool pool > Note: pool is the name of the pool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6530) Exception: Failed to add endpoint to pool
[ https://issues.apache.org/jira/browse/GEODE-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-6530. - Fix Version/s: 1.14.0 Resolution: Fixed This was fixed in the PR for GEODE-7930. The log statement was literally backwards, logging an error on success. > Exception: Failed to add endpoint to pool > -- > > Key: GEODE-6530 > URL: https://issues.apache.org/jira/browse/GEODE-6530 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Fix For: 1.14.0 > > > Not sure if this is a serious bug, but should be investigated. > First stumbled across this when looking at the client logs for Charlie > Black's PCF web app. But I also see this exception in the logs when I run the > Examples. Since the examples do run to completion, this is likely an > innocuous exception. > > Our Examples (at least dotnet-authinit and dotnet-putgetremove) show this > error in the client log: > [error 2019/03/15 05:52:39.410822 Pacific Daylight Time > mmartell-mbpro-win10:4552 2972] Failed to add endpoint 10.118.20.94:40404 to > pool pool > Note: pool is the name of the pool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8533) User Guide - compaction-threshold mechanism descriptions are wrong
[
https://issues.apache.org/jira/browse/GEODE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Barnes resolved GEODE-8533.
Fix Version/s: 1.13.1
1.14.0
1.12.1
Resolution: Fixed
> User Guide - compaction-threshold mechanism descriptions are wrong
> --
>
> Key: GEODE-8533
> URL: https://issues.apache.org/jira/browse/GEODE-8533
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.1
>
>
> Zhengzhi Xu reports:
> The compaction threshold mechanism is misleading in current document.
> CompactionThreshold is percentage of remaining live data in the oplog at
> which an oplog is compactable, while current user document is described as
> percentage of garbage in the oplog like the below:
> --compaction-threshold: Percentage of garbage allowed in the file before it
> is eligible for compaction.
> The correct description is in the API document:
> {code:java}
> DiskStoreFactory setCompactionThreshold(int compactionThreshold) Sets the
> threshold at which an oplog will become compactable. Until it reaches this
> threshold the oplog will not be compacted. The threshold is a percentage in
> the range 0..100. When the amount of live data in an oplog becomes less than
> this percentage then when a compaction is done this garbage will be cleaned
> up freeing up disk space. Garbage is created by entry destroys, entry
> updates, and region destroys. Parameters: compactionThreshold - percentage of
> remaining live data in the oplog at which an oplog is compactable{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8566) Redis native tests should not also stand up a Geode server
[
https://issues.apache.org/jira/browse/GEODE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205802#comment-17205802
]
ASF GitHub Bot commented on GEODE-8566:
---
sabbey37 commented on a change in pull request #5584:
URL: https://github.com/apache/geode/pull/5584#discussion_r498335739
##
File path:
geode-redis/src/acceptanceTest/java/org/apache/geode/redis/internal/executor/pubsub/PubSubNativeRedisAcceptanceTest.java
##
@@ -15,31 +15,14 @@
package org.apache.geode.redis.internal.executor.pubsub;
-
-
-import org.junit.AfterClass;
-import org.junit.BeforeClass;
import org.junit.ClassRule;
-import redis.clients.jedis.Jedis;
import org.apache.geode.NativeRedisTestRule;
-public class PubSubNativeRedisAcceptanceTest extends PubSubIntegrationTest {
+public class PubSubNativeRedisAcceptanceTest extends
AbstractPubSubIntegrationTest {
@ClassRule
public static NativeRedisTestRule redis = new NativeRedisTestRule();
- @BeforeClass
- public static void setUp() {
-subscriber = new Jedis("localhost", redis.getPort(), JEDIS_TIMEOUT);
-publisher = new Jedis("localhost", redis.getPort(), JEDIS_TIMEOUT);
- }
-
- @AfterClass
- public static void tearDown() {
-subscriber.close();
-publisher.close();
- }
-
public int getPort() {
Review comment:
Should `@Override` be added to this method?
##
File path:
geode-redis/src/acceptanceTest/java/org/apache/geode/redis/internal/executor/pubsub/PubSubNativeRedisAcceptanceTest.java
##
@@ -15,31 +15,14 @@
package org.apache.geode.redis.internal.executor.pubsub;
-
-
-import org.junit.AfterClass;
-import org.junit.BeforeClass;
import org.junit.ClassRule;
-import redis.clients.jedis.Jedis;
import org.apache.geode.NativeRedisTestRule;
-public class PubSubNativeRedisAcceptanceTest extends PubSubIntegrationTest {
+public class PubSubNativeRedisAcceptanceTest extends
AbstractPubSubIntegrationTest {
@ClassRule
public static NativeRedisTestRule redis = new NativeRedisTestRule();
- @BeforeClass
- public static void setUp() {
-subscriber = new Jedis("localhost", redis.getPort(), JEDIS_TIMEOUT);
-publisher = new Jedis("localhost", redis.getPort(), JEDIS_TIMEOUT);
- }
-
- @AfterClass
- public static void tearDown() {
-subscriber.close();
-publisher.close();
- }
-
public int getPort() {
Review comment:
Should we add `@Override` to this method?
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/key/AbstractExpireIntegrationTest.java
##
@@ -0,0 +1,339 @@
+/*
+ * 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.redis.internal.executor.key;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+import redis.clients.jedis.Jedis;
+
+import org.apache.geode.test.dunit.rules.RedisPortSupplier;
+
+public abstract class AbstractExpireIntegrationTest implements
RedisPortSupplier {
+
+ private Jedis jedis;
+ private static int REDIS_CLIENT_TIMEOUT = 1000;
Review comment:
This is not related to this PR, but I guess we should go through and
make sure these timeouts are all set to
`Math.toIntExact(GeodeAwaitility.getTimeout().toMillis());` at some point.
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
> Redis native tests should not also stand up a Geode server
> --
>
> Key: GEODE-8566
> URL: https://issues.apache.org/jira/browse/GEODE-8566
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Our native acceptance tests currently extend from the integration tests
[jira] [Updated] (GEODE-8536) StackOverflow can occur when Lucene IndexWriter is unable to be created
[
https://issues.apache.org/jira/browse/GEODE-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8536:
---
Affects Version/s: (was: 1.13.1)
1.12.0
1.13.0
> StackOverflow can occur when Lucene IndexWriter is unable to be created
> ---
>
> Key: GEODE-8536
> URL: https://issues.apache.org/jira/browse/GEODE-8536
> Project: Geode
> Issue Type: Bug
> Components: functions, lucene
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> If, during a call to IndexRepositoryFactory.computeIndexRepository(), an
> IOException is encountered when attempting to construct an IndexWriter, the
> function retry logic will reattempt the execution. This allows transient
> exceptions caused by concurrent modification of the fileAndChunk region to be
> ignored and subsequent executions to succeed (see GEODE-7703). However, if
> the IOException is consistently thrown, the infinitely retrying function can
> cause a StackOverflow:
> {noformat}
> java.lang.StackOverflowError
> at
> org.apache.geode.SystemFailure.startWatchDog(SystemFailure.java:320)
> at
> org.apache.geode.SystemFailure.notifyWatchDog(SystemFailure.java:758)
> at org.apache.geode.SystemFailure.setFailure(SystemFailure.java:813)
> at
> org.apache.geode.SystemFailure.initiateFailure(SystemFailure.java:790)
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2251)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2031)
> at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.toData(PartitionedRegionFunctionStreamingMessage.java:192)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:213)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:137)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1484)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:247)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultWaiter.getPartitionedDataFrom(PartitionedRegionFunctionResultWaiter.java:89)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeOnAllBuckets(PartitionedRegion.java:4079)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3583)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:220)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:359)
> at
> org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.getResultInternal(LocalResultCollectorImpl.java:139)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.getResult(LocalResultCollectorImpl.java:112)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:219)
> at
[jira] [Commented] (GEODE-8566) Redis native tests should not also stand up a Geode server
[
https://issues.apache.org/jira/browse/GEODE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205818#comment-17205818
]
ASF GitHub Bot commented on GEODE-8566:
---
sabbey37 commented on a change in pull request #5584:
URL: https://github.com/apache/geode/pull/5584#discussion_r498501625
##
File path:
geode-redis/src/acceptanceTest/java/org/apache/geode/redis/internal/executor/key/RenameNativeRedisAcceptanceTest.java
##
@@ -14,30 +14,25 @@
*/
package org.apache.geode.redis.internal.executor.key;
-import java.util.Random;
-
-import org.junit.BeforeClass;
import org.junit.ClassRule;
import org.junit.Ignore;
import org.junit.Test;
-import redis.clients.jedis.Jedis;
import org.apache.geode.NativeRedisTestRule;
-public class RenameNativeRedisAcceptanceTest extends RenameIntegrationTest {
+public class RenameNativeRedisAcceptanceTest extends
AbstractRenameIntegrationTest {
+
@ClassRule
public static NativeRedisTestRule redis = new NativeRedisTestRule();
- @BeforeClass
- public static void setUp() {
-rand = new Random();
-jedis = new Jedis("localhost", redis.getPort(), 1000);
-jedis2 = new Jedis("localhost", redis.getPort(), 1000);
-jedis3 = new Jedis("localhost", redis.getPort(), 1000);
+ @Override
+ public int getPort() {
+return redis.getPort();
}
@Override
@Test
@Ignore("native redis does implement renamenx")
public void renamenxIsUnimplemented() {}
+
Review comment:
Should we move this test out of the `AbstractRenameIntegrationTest` file
and into `RenameIntegrationTest` file like the `leakedSubscriptions` test
(which is just in the `SubscriptionsIntegrationTest` file)? Not sure which is
better.
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
> Redis native tests should not also stand up a Geode server
> --
>
> Key: GEODE-8566
> URL: https://issues.apache.org/jira/browse/GEODE-8566
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Our native acceptance tests currently extend from the integration tests and
> both classes have a {{@ClassRule}} that results in both a native (container)
> instance and a Geode instance starting up. Mostly not a problem except for
> {{PubSubNativeAcceptanceTest}} which was not testing against native redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8536) StackOverflow can occur when Lucene IndexWriter is unable to be created
[
https://issues.apache.org/jira/browse/GEODE-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205841#comment-17205841
]
ASF GitHub Bot commented on GEODE-8536:
---
pivotal-eshu commented on a change in pull request #5553:
URL: https://github.com/apache/geode/pull/5553#discussion_r498526815
##
File path:
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/IndexRepositoryFactory.java
##
@@ -44,6 +44,7 @@
private static final Logger logger = LogService.getLogger();
public static final String FILE_REGION_LOCK_FOR_BUCKET_ID =
"FileRegionLockForBucketId:";
public static final String APACHE_GEODE_INDEX_COMPLETE =
"APACHE_GEODE_INDEX_COMPLETE";
+ protected static final int GET_INDEX_WRITER_MAX_ATTEMPTS = 10;
Review comment:
Do you think the number of retries is enough?
Based on the original ticket description, the IOException thrown is caused
by "LuceneEventListener is asynchronously updating the fileAndChunkRegion". Do
we know if the wait is enough for the updating to finish? Is it a problem if
IndexWriter creation needs to wait longer for the resources to be freed?
Do we know "updating the fileAndChunkRegion" usually do not require a minute
to finish, or we actually hit this issue due to different threads keep updating
the fileAndChunkRegion? If so, we can decide the number of attempts and whether
the wait needs to be using different intervals.
If we do not know answers for these, I think this code change is fine to fix
the StackOverflowError.
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
> StackOverflow can occur when Lucene IndexWriter is unable to be created
> ---
>
> Key: GEODE-8536
> URL: https://issues.apache.org/jira/browse/GEODE-8536
> Project: Geode
> Issue Type: Bug
> Components: functions, lucene
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> If, during a call to IndexRepositoryFactory.computeIndexRepository(), an
> IOException is encountered when attempting to construct an IndexWriter, the
> function retry logic will reattempt the execution. This allows transient
> exceptions caused by concurrent modification of the fileAndChunk region to be
> ignored and subsequent executions to succeed (see GEODE-7703). However, if
> the IOException is consistently thrown, the infinitely retrying function can
> cause a StackOverflow:
> {noformat}
> java.lang.StackOverflowError
> at
> org.apache.geode.SystemFailure.startWatchDog(SystemFailure.java:320)
> at
> org.apache.geode.SystemFailure.notifyWatchDog(SystemFailure.java:758)
> at org.apache.geode.SystemFailure.setFailure(SystemFailure.java:813)
> at
> org.apache.geode.SystemFailure.initiateFailure(SystemFailure.java:790)
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2251)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2031)
> at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.toData(PartitionedRegionFunctionStreamingMessage.java:192)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:213)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:137)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1484)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:247)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.intern
[jira] [Resolved] (GEODE-2487) SSL should not require external security library
[ https://issues.apache.org/jira/browse/GEODE-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-2487. - Fix Version/s: 1.14.0 Resolution: Duplicate Resolving as dupe of later issue, because the fix was checked in against that one. > SSL should not require external security library > > > Key: GEODE-2487 > URL: https://issues.apache.org/jira/browse/GEODE-2487 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jacob Barrett >Priority: Major > Fix For: 1.14.0 > > > Geode Native requires that cryptoImpl library be compiled by the end user to > support SSL. The rational for this has been lost but was likely to avoid > either export control, which it does not, or to make dynamic loading of > OpenSSL easier, which I am not sure it does. > Refactor SSL sockets to initialize and use OpenSSL (via ACE_SSL) directly and > remove it from cryptoImpl library. If there is no other purpose for > cryptoImpl library then purge it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-2487) SSL should not require external security library
[ https://issues.apache.org/jira/browse/GEODE-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-2487. --- > SSL should not require external security library > > > Key: GEODE-2487 > URL: https://issues.apache.org/jira/browse/GEODE-2487 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jacob Barrett >Priority: Major > Fix For: 1.14.0 > > > Geode Native requires that cryptoImpl library be compiled by the end user to > support SSL. The rational for this has been lost but was likely to avoid > either export control, which it does not, or to make dynamic loading of > OpenSSL easier, which I am not sure it does. > Refactor SSL sockets to initialize and use OpenSSL (via ACE_SSL) directly and > remove it from cryptoImpl library. If there is no other purpose for > cryptoImpl library then purge it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-2835) Autoboxing unsigned primitives in .NET results in stack overflow.
[
https://issues.apache.org/jira/browse/GEODE-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender closed GEODE-2835.
---
> Autoboxing unsigned primitives in .NET results in stack overflow.
> -
>
> Key: GEODE-2835
> URL: https://issues.apache.org/jira/browse/GEODE-2835
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jacob Barrett
>Priority: Major
> Fix For: 1.13.0
>
>
> When using a PdxSerializer, like ReflectionBasedPdxSerializer that writes
> unsigned primitive types to fields it results in autoboxing those types and
> looping them back to the PdxSerializer. This can result in an infinite
> recursion and stack overflow.
> {noformat}
> Serializer.RegisterPdxSerializer(new ReflectionBasedPdxSerializer());
> region.put("a", new Guid());
> {noformat}
> Guid contains several fields, some of which are {{unsigned char}} which
> autobox to {{System::Byte}}, this gets forwarded back to the auto pdx
> serializer which sees field {{unsigned char m_value}} and autoboxes it again
> to {{System::Byte}} and ..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8567) CI Failure: ConcurrentSerialGatewaySenderOperationsDistributedTest > testRestartSerialGatewaySendersWhilePutting
Owen Nichols created GEODE-8567: --- Summary: CI Failure: ConcurrentSerialGatewaySenderOperationsDistributedTest > testRestartSerialGatewaySendersWhilePutting Key: GEODE-8567 URL: https://issues.apache.org/jira/browse/GEODE-8567 Project: Geode Issue Type: Improvement Components: wan Reporter: Owen Nichols ConcurrentSerialGatewaySenderOperationsDistributedTest > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED seen in [DistributedTestOpenJDK11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/490] #490 > Task :geode-wan:distributedTest org.apache.geode.internal.cache.wan.concurrent.ConcurrentSerialGatewaySenderOperationsDistributedTest > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$490/0x00010094b040.run in VM 5 running on Host 60d64fc07216 with 8 VMs Caused by: org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest that uses org.apache.geode.internal.cache.wan.InternalGatewaySender, org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender statistics unprocessed event map size] expected:<[0]> but was:<[2]> within 5 minutes. Caused by: org.junit.ComparisonFailure: [Sender statistics unprocessed event map size] expected:<[0]> but was:<[2]> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0380/test-results/distributedTest/1601531249/*] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test report artifacts from this job are available at: [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0380/test-artifacts/1601531249/distributedtestfiles-OpenJDK11-1.14.0-build.0380.tgz*] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-2835) Autoboxing unsigned primitives in .NET results in stack overflow.
[
https://issues.apache.org/jira/browse/GEODE-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-2835.
-
Fix Version/s: 1.13.0
Resolution: Duplicate
Resolving as dupe of GEODE-7868, since that's the ticket the fix was checked in
against.
> Autoboxing unsigned primitives in .NET results in stack overflow.
> -
>
> Key: GEODE-2835
> URL: https://issues.apache.org/jira/browse/GEODE-2835
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jacob Barrett
>Priority: Major
> Fix For: 1.13.0
>
>
> When using a PdxSerializer, like ReflectionBasedPdxSerializer that writes
> unsigned primitive types to fields it results in autoboxing those types and
> looping them back to the PdxSerializer. This can result in an infinite
> recursion and stack overflow.
> {noformat}
> Serializer.RegisterPdxSerializer(new ReflectionBasedPdxSerializer());
> region.put("a", new Guid());
> {noformat}
> Guid contains several fields, some of which are {{unsigned char}} which
> autobox to {{System::Byte}}, this gets forwarded back to the auto pdx
> serializer which sees field {{unsigned char m_value}} and autoboxes it again
> to {{System::Byte}} and ..
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-3135) Update to OpenSSL 1.0.2 LTS
[ https://issues.apache.org/jira/browse/GEODE-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-3135. - Fix Version/s: 1.10.0 Resolution: Fixed > Update to OpenSSL 1.0.2 LTS > --- > > Key: GEODE-3135 > URL: https://issues.apache.org/jira/browse/GEODE-3135 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Jacob Barrett >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.10.0 > > > Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 > [https://www.openssl.org/policies/releasestrat.html]. > OpenSSL 1.0.1 has been out of support in 2016. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8568) CI Failure: org.apache.geode.ClusterCommunicationsDUnitTest createEntryAndVerifyUpdate[UNSHARED_CONNECTIONS_WITH_SSL] hung
Owen Nichols created GEODE-8568: --- Summary: CI Failure: org.apache.geode.ClusterCommunicationsDUnitTest createEntryAndVerifyUpdate[UNSHARED_CONNECTIONS_WITH_SSL] hung Key: GEODE-8568 URL: https://issues.apache.org/jira/browse/GEODE-8568 Project: Geode Issue Type: Bug Components: messaging Affects Versions: 1.14.0 Reporter: Owen Nichols Test was reported hung in [DistributedTestOpenJDK8|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/512] #512 Test report artifacts from this job are available at: [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0381/test-artifacts/1601536707/distributedtestfiles-OpenJDK8-1.14.0-build.0381.tgz*] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-3135) Update to OpenSSL 1.0.2 LTS
[ https://issues.apache.org/jira/browse/GEODE-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-3135. --- This appears to be a doc bug only, and the referenced PR (#110) appears to have fixed it. At any rate, this bug is over 3 years old, and both the product code and docs are up to OpenSSL 1.1, so it's hardly relevant. > Update to OpenSSL 1.0.2 LTS > --- > > Key: GEODE-3135 > URL: https://issues.apache.org/jira/browse/GEODE-3135 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Jacob Barrett >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.10.0 > > > Update to OpenSSL 1.0.2 LTS, which has support until end of 2019 > [https://www.openssl.org/policies/releasestrat.html]. > OpenSSL 1.0.1 has been out of support in 2016. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8559) A race could occur during interest registration combined with transactional operations
[
https://issues.apache.org/jira/browse/GEODE-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205865#comment-17205865
]
ASF GitHub Bot commented on GEODE-8559:
---
DonalEvans commented on a change in pull request #5581:
URL: https://github.com/apache/geode/pull/5581#discussion_r498515234
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/FilterProfile.java
##
@@ -1126,27 +1126,75 @@ public FilterRoutingInfo
getFilterRoutingInfoPart1(CacheEvent event, Profile[] p
*/
public FilterRoutingInfo getFilterRoutingInfoPart2(FilterRoutingInfo
part1Info,
CacheEvent event) {
+return getFilterRoutingInfoPart2(part1Info, event, false);
+ }
+
+ public FilterRoutingInfo getFilterRoutingInfoPart2(FilterRoutingInfo
part1Info,
+ CacheEvent event, boolean computeInterestRoutingInfo) {
FilterRoutingInfo result = part1Info;
if (localProfile.hasCacheServer) {
// bug #45520 - CQ events arriving out of order causes result set
// inconsistency, so don't compute routings for events in conflict
boolean isInConflict =
event.getOperation().isEntry() && ((EntryEventImpl)
event).isConcurrencyConflict();
CqService cqService = getCqService(event.getRegion());
- if (!isInConflict && cqService.isRunning()
- && this.region != null /*
- * && !(
this.region.isUsedForPartitionedRegionBucket() || //
- * partitioned region CQ this.region
instanceof PartitionedRegion)
- */) { // processing is done in part 1
+ if (!isInConflict && cqService.isRunning() && region != null) {
if (result == null) {
result = new FilterRoutingInfo();
}
if (logger.isDebugEnabled()) {
logger.debug("getting local cq matches for {}", event);
}
-fillInCQRoutingInfo(event, true, NO_PROFILES, result);
+setLocalCQRoutingInfo(event, result);
}
+ result = setLocalInterestRoutingInfo(event, result,
computeInterestRoutingInfo);
+}
+return result;
+ }
+
+ void setLocalCQRoutingInfo(CacheEvent event, FilterRoutingInfo result) {
+if (isCQRoutingNeeded(event)) {
+ fillInCQRoutingInfo(event, true, NO_PROFILES, result);
+} else {
+ result.setLocalFilterInfo(getLocalFilterInfo(event));
+}
+ }
+
+ boolean isCQRoutingNeeded(CacheEvent event) {
+if (!isTransactionalEvent(event)) {
+ return true;
+}
+FilterInfo localFilterInfo = getLocalFilterInfo(event);
+if (localFilterInfo != null) {
+ return false;
+}
+return true;
Review comment:
This can be simplified to `return localFilterInfo == null;`
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
> A race could occur during interest registration combined with transactional
> operations
> --
>
> Key: GEODE-8559
> URL: https://issues.apache.org/jira/browse/GEODE-8559
> Project: Geode
> Issue Type: Bug
> Components: client queues, transactions
>Affects Versions: 1.1.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
>
> During client interest registration, a region snapshot is taken from server
> and entry operations after the registration should be sent to client via
> Region queue.
> There is a race in transaction implementation. Interested client computation
> is occurred before the transactional operations is applied to the cache
> during commit. This could lead to client does not get the operations through
> region snapshot taken, and the transactional operation is not being sent to
> the client (as the interested clients were computed before hand.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8569) Missing message security footer check in gnmsg
[ https://issues.apache.org/jira/browse/GEODE-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender reassigned GEODE-8569: --- Assignee: Blake Bender > Missing message security footer check in gnmsg > -- > > Key: GEODE-8569 > URL: https://issues.apache.org/jira/browse/GEODE-8569 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > > In an older version of the `gnmsg.py` script, there was a function called > request_requires_security_footer that returned a boolean based on the message > name, indictating whether or not the message needed the security footer in a > server conversation with authentication. In the refactor that moved the > client message decoding into a class, this method was left out, so attempting > to decode messages from a client log that used AuthInitialize will throw an > exception attempting to call this missing function. We need to add this call > to the ClientMessageDecoder class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8569) Missing message security footer check in gnmsg
Blake Bender created GEODE-8569: --- Summary: Missing message security footer check in gnmsg Key: GEODE-8569 URL: https://issues.apache.org/jira/browse/GEODE-8569 Project: Geode Issue Type: Improvement Components: native client Reporter: Blake Bender In an older version of the `gnmsg.py` script, there was a function called request_requires_security_footer that returned a boolean based on the message name, indictating whether or not the message needed the security footer in a server conversation with authentication. In the refactor that moved the client message decoding into a class, this method was left out, so attempting to decode messages from a client log that used AuthInitialize will throw an exception attempting to call this missing function. We need to add this call to the ClientMessageDecoder class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8569) Missing message security footer check in gnmsg
[ https://issues.apache.org/jira/browse/GEODE-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8569: -- Labels: pull-request-available (was: ) > Missing message security footer check in gnmsg > -- > > Key: GEODE-8569 > URL: https://issues.apache.org/jira/browse/GEODE-8569 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > In an older version of the `gnmsg.py` script, there was a function called > request_requires_security_footer that returned a boolean based on the message > name, indictating whether or not the message needed the security footer in a > server conversation with authentication. In the refactor that moved the > client message decoding into a class, this method was left out, so attempting > to decode messages from a client log that used AuthInitialize will throw an > exception attempting to call this missing function. We need to add this call > to the ClientMessageDecoder class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8569) Missing message security footer check in gnmsg
[ https://issues.apache.org/jira/browse/GEODE-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205868#comment-17205868 ] ASF GitHub Bot commented on GEODE-8569: --- pdxcodemonkey opened a new pull request #663: URL: https://github.com/apache/geode-native/pull/663 - This would be called, and thus throw an exception, for client logs using AuthInitialize - Also added NC v10.0.3 to version lookup for regex function dispatcher. Apparently we'd never tried to decode a v10.0.3 log before, go figure @mreddington @davebarnes97 @dihardman @karensmolermiller @alb3rtobr 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 > Missing message security footer check in gnmsg > -- > > Key: GEODE-8569 > URL: https://issues.apache.org/jira/browse/GEODE-8569 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > > In an older version of the `gnmsg.py` script, there was a function called > request_requires_security_footer that returned a boolean based on the message > name, indictating whether or not the message needed the security footer in a > server conversation with authentication. In the refactor that moved the > client message decoding into a class, this method was left out, so attempting > to decode messages from a client log that used AuthInitialize will throw an > exception attempting to call this missing function. We need to add this call > to the ClientMessageDecoder class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8519) Geode Native Client user guide: delete unused sources (round 2)
[ https://issues.apache.org/jira/browse/GEODE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205882#comment-17205882 ] ASF GitHub Bot commented on GEODE-8519: --- davebarnes97 opened a new pull request #664: URL: https://github.com/apache/geode-native/pull/664 Housekeeping: Remove unpublished source files that were, nonetheless, visible via Google search. 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 > Geode Native Client user guide: delete unused sources (round 2) > --- > > Key: GEODE-8519 > URL: https://issues.apache.org/jira/browse/GEODE-8519 > Project: Geode > Issue Type: Bug > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > The geode-native docs directory contains unused sources from the > pre-open-source days. The problem is that while they're not linked to the > user guide's T of C, these out-of-date docs are still included in the manual > build (a quirk of the toolset), where they can be accidentally discovered via > web searches. > These unused files need to be identified and deleted. > GEODE-8388 took care of some of these files. There's another group under > 'preserving data' that need to go. The user guide contains two links on the > Continuous Queries page that will need to be removed. > Also, need to remove a link to Durable Client Messaging from the > "Subscription Properties" page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8519) Geode Native Client user guide: delete unused sources (round 2)
[ https://issues.apache.org/jira/browse/GEODE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8519: -- Labels: pull-request-available (was: ) > Geode Native Client user guide: delete unused sources (round 2) > --- > > Key: GEODE-8519 > URL: https://issues.apache.org/jira/browse/GEODE-8519 > Project: Geode > Issue Type: Bug > Components: docs, native client >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The geode-native docs directory contains unused sources from the > pre-open-source days. The problem is that while they're not linked to the > user guide's T of C, these out-of-date docs are still included in the manual > build (a quirk of the toolset), where they can be accidentally discovered via > web searches. > These unused files need to be identified and deleted. > GEODE-8388 took care of some of these files. There's another group under > 'preserving data' that need to go. The user guide contains two links on the > Continuous Queries page that will need to be removed. > Also, need to remove a link to Durable Client Messaging from the > "Subscription Properties" page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8570) cluster-configuration-dir property has no effect
Dale Emery created GEODE-8570: - Summary: cluster-configuration-dir property has no effect Key: GEODE-8570 URL: https://issues.apache.org/jira/browse/GEODE-8570 Project: Geode Issue Type: Bug Components: configuration Affects Versions: 1.13.0 Reporter: Dale Emery Setting the `cluster-configuration-dir` property has no effect. In two places, `InternalLocator` constructs an `InternalConfigurationPersistenceService`. In each place, it passes the locator's working directory as the persistence service's working directory, regardless of the value of `cluster-configuration-dir`. The use of this property should be deprecated, removed, or fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8570) cluster-configuration-dir property has no effect
[ https://issues.apache.org/jira/browse/GEODE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-8570: -- Labels: GeodeOperationAPI (was: ) > cluster-configuration-dir property has no effect > > > Key: GEODE-8570 > URL: https://issues.apache.org/jira/browse/GEODE-8570 > Project: Geode > Issue Type: Bug > Components: configuration >Affects Versions: 1.13.0 >Reporter: Dale Emery >Priority: Major > Labels: GeodeOperationAPI > > Setting the `cluster-configuration-dir` property has no effect. > In two places, `InternalLocator` constructs an > `InternalConfigurationPersistenceService`. In each place, it passes the > locator's working directory as the persistence service's working directory, > regardless of the value of `cluster-configuration-dir`. > The use of this property should be deprecated, removed, or fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8570) cluster-configuration-dir property has no effect
[
https://issues.apache.org/jira/browse/GEODE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8570:
--
Description:
Setting the {{cluster-configuration-dir}} property has no effect.
In two places, {{InternalLocator}} constructs an
{{InternalConfigurationPersistenceService}}. In each place, it passes the
locator's working directory as the persistence service's working directory,
regardless of the value of {{cluster-configuration-dir}}.
The use of this property should be deprecated, removed, or fixed.
was:
Setting the `cluster-configuration-dir` property has no effect.
In two places, `InternalLocator` constructs an
`InternalConfigurationPersistenceService`. In each place, it passes the
locator's working directory as the persistence service's working directory,
regardless of the value of `cluster-configuration-dir`.
The use of this property should be deprecated, removed, or fixed.
> cluster-configuration-dir property has no effect
>
>
> Key: GEODE-8570
> URL: https://issues.apache.org/jira/browse/GEODE-8570
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.13.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> Setting the {{cluster-configuration-dir}} property has no effect.
> In two places, {{InternalLocator}} constructs an
> {{InternalConfigurationPersistenceService}}. In each place, it passes the
> locator's working directory as the persistence service's working directory,
> regardless of the value of {{cluster-configuration-dir}}.
> The use of this property should be deprecated, removed, or fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205911#comment-17205911 ] ASF GitHub Bot commented on GEODE-7864: --- lgtm-com[bot] commented on pull request #5582: URL: https://github.com/apache/geode/pull/5582#issuecomment-702474858 This pull request **fixes 57 alerts** when merging 3d95be9de361ebcd27d87602737417b1b3c7dd6e into ce77067a4fea2303f4db33399450a3df80189e29 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-a6bc353a59681e82d3bcc9251f3127bcca266339) **fixed alerts:** * 54 for Potential input resource leak * 3 for Potential output resource leak 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 > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 13h 10m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
