[jira] [Resolved] (GEODE-8401) User Guide - incorrect method name on "forced disconnect" page
[ https://issues.apache.org/jira/browse/GEODE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-8401. Fix Version/s: 1.14.0 Resolution: Fixed > User Guide - incorrect method name on "forced disconnect" page > -- > > Key: GEODE-8401 > URL: https://issues.apache.org/jira/browse/GEODE-8401 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Alert reader Barry Oglesby noticed: > [https://geode.apache.org/docs/guide/112/managing/member-reconnect.html] > > has: > Cache.waitForReconnect(long, TimeUnit) > It should be: > Cache.waitUntilReconnected(long, TimeUnit) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8401) User Guide - incorrect method name on "forced disconnect" page
[ https://issues.apache.org/jira/browse/GEODE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171201#comment-17171201 ] ASF GitHub Bot commented on GEODE-8401: --- davebarnes97 merged pull request #5423: URL: https://github.com/apache/geode/pull/5423 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 - incorrect method name on "forced disconnect" page > -- > > Key: GEODE-8401 > URL: https://issues.apache.org/jira/browse/GEODE-8401 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > Alert reader Barry Oglesby noticed: > [https://geode.apache.org/docs/guide/112/managing/member-reconnect.html] > > has: > Cache.waitForReconnect(long, TimeUnit) > It should be: > Cache.waitUntilReconnected(long, TimeUnit) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8401) User Guide - incorrect method name on "forced disconnect" page
[ https://issues.apache.org/jira/browse/GEODE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171202#comment-17171202 ] ASF subversion and git services commented on GEODE-8401: Commit a13d72c5cb1541991564ea00bda09e5c1f9d9c8d in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a13d72c ] GEODE-8401: User Guide - incorrect method name on "forced disconnect" page (#5423) > User Guide - incorrect method name on "forced disconnect" page > -- > > Key: GEODE-8401 > URL: https://issues.apache.org/jira/browse/GEODE-8401 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > Alert reader Barry Oglesby noticed: > [https://geode.apache.org/docs/guide/112/managing/member-reconnect.html] > > has: > Cache.waitForReconnect(long, TimeUnit) > It should be: > Cache.waitUntilReconnected(long, TimeUnit) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171196#comment-17171196 ] ASF GitHub Bot commented on GEODE-8394: --- agingade opened a new pull request #5424: URL: https://github.com/apache/geode/pull/5424 This change rewinds the message part on command failure. Without this during retry on failure, the message (Part) is sent from the place where it was previously failed, instead of starting from the beginning, causing it to transmit partial data. 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: - [Y] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [Y] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [Y] Is your initial contribution a single, squashed commit? - [Y] Does `gradlew build` run cleanly? - [Y] Have you written or updated unit tests to verify your changes? - [NA] 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 > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8394) Client sends partial data during retry
[ https://issues.apache.org/jira/browse/GEODE-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8394: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > Client sends partial data during retry > -- > > Key: GEODE-8394 > URL: https://issues.apache.org/jira/browse/GEODE-8394 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When executing the command, java client sends the command in the form of > message (Parts). If there is a failure during the send, it retries number of > times based on the retry-attempt setting. > If there is a failure in the first attempt due to Exception (IOException, > EOFException - read timeout); during the second attempt the client is sending > partial data, instead of the complete data. > This could be reproduced by setting a small read-timeout and large object > (Put). > Because of this, the put from client succeeds by creating partial data on the > server cache. Since the data is stored in serialized form, there is no > exception thrown during put() operation, giving an impression that put > operation is successful. > The workaround for now is to have large read-timeout setting; while trying to > send a large object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8404) Simplify port reservation in tests
[
https://issues.apache.org/jira/browse/GEODE-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8404:
--
Labels: GeodeOperationAPI (was: )
> Simplify port reservation in tests
> --
>
> Key: GEODE-8404
> URL: https://issues.apache.org/jira/browse/GEODE-8404
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> {{AvailablePort}}, {{AvailablePortHelper}}, and {{UniquePortSupplier}}
> implement a variety of complex mechanisms to reserve ports for use in the
> product and in tests.
> This complexity is unnecessary in cases where the chosen port need not be
> restricted to a specified range. Most of the ports allocated for tests have
> no such range restrictions, and so can rely on the OS to allocate available
> ports simply, directly, and efficiently.
> In particular:
> {{AvailablePort}} implements two methods to reserve only those ports that are
> a multiple of a given modulus. These methods are implemented badly, so that
> each call can render many ports unavailable before finding one that satisfies
> the constraints. These methods are not used in Geode or in tests, so I will
> remove them rather than fixing them.
> {{AvailablePortHelper}} (used only in tests) attempts to reduce the number of
> unavailable ports it tests by partitioning the available ports among VMS, and
> by storing state in a global static variable. In almost all cases, this
> mechanism can be replaced by letting the OS choose available ports.
> {{UniquePortSupplier}} (used only in tests) remembers every port it allocates
> and will not allocate the same port twice. This mechanism has the fatal
> limitation that uniqueness is guaranteed only among uses of the same
> {{UniquePortSupplier}} instance. This mechanism can be replaced by letting
> the OS choose available ports.
> {{AvailablePort.Keeper}} retains a port reservation until the caller is ready
> to bind to the port. {{Keeper}}'s use within {{AvailablePort}} is
> unnecessary. Its use in tests is limited to only a few instances. I will try
> to make those instances unnecessary. If it turns out that some tests require
> holding onto a reservation beyond its "natural" ({{TIME_WAIT}}) duration, I
> will move {{Keeper}} to into the {{geode-junit}} module, near (or inside)
> {{AvailablePortHelper}}.
> Once this complexity is reduced to its necessary minimum, I will refactor
> these classes (safely, with additional tests to cover currently untested
> features) to remove duplication and make the remaining code clearer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8404) Simplify port reservation in tests
[
https://issues.apache.org/jira/browse/GEODE-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-8404:
-
Assignee: Dale Emery
> Simplify port reservation in tests
> --
>
> Key: GEODE-8404
> URL: https://issues.apache.org/jira/browse/GEODE-8404
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> {{AvailablePort}}, {{AvailablePortHelper}}, and {{UniquePortSupplier}}
> implement a variety of complex mechanisms to reserve ports for use in the
> product and in tests.
> This complexity is unnecessary in cases where the chosen port need not be
> restricted to a specified range. Most of the ports allocated for tests have
> no such range restrictions, and so can rely on the OS to allocate available
> ports simply, directly, and efficiently.
> In particular:
> {{AvailablePort}} implements two methods to reserve only those ports that are
> a multiple of a given modulus. These methods are implemented badly, so that
> each call can render many ports unavailable before finding one that satisfies
> the constraints. These methods are not used in Geode or in tests, so I will
> remove them rather than fixing them.
> {{AvailablePortHelper}} (used only in tests) attempts to reduce the number of
> unavailable ports it tests by partitioning the available ports among VMS, and
> by storing state in a global static variable. In almost all cases, this
> mechanism can be replaced by letting the OS choose available ports.
> {{UniquePortSupplier}} (used only in tests) remembers every port it allocates
> and will not allocate the same port twice. This mechanism has the fatal
> limitation that uniqueness is guaranteed only among uses of the same
> {{UniquePortSupplier}} instance. This mechanism can be replaced by letting
> the OS choose available ports.
> {{AvailablePort.Keeper}} retains a port reservation until the caller is ready
> to bind to the port. {{Keeper}}'s use within {{AvailablePort}} is
> unnecessary. Its use in tests is limited to only a few instances. I will try
> to make those instances unnecessary. If it turns out that some tests require
> holding onto a reservation beyond its "natural" ({{TIME_WAIT}}) duration, I
> will move {{Keeper}} to into the {{geode-junit}} module, near (or inside)
> {{AvailablePortHelper}}.
> Once this complexity is reduced to its necessary minimum, I will refactor
> these classes (safely, with additional tests to cover currently untested
> features) to remove duplication and make the remaining code clearer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8404) Simplify port reservation in tests
Dale Emery created GEODE-8404:
-
Summary: Simplify port reservation in tests
Key: GEODE-8404
URL: https://issues.apache.org/jira/browse/GEODE-8404
Project: Geode
Issue Type: Test
Components: tests
Reporter: Dale Emery
{{AvailablePort}}, {{AvailablePortHelper}}, and {{UniquePortSupplier}}
implement a variety of complex mechanisms to reserve ports for use in the
product and in tests.
This complexity is unnecessary in cases where the chosen port need not be
restricted to a specified range. Most of the ports allocated for tests have no
such range restrictions, and so can rely on the OS to allocate available ports
simply, directly, and efficiently.
In particular:
{{AvailablePort}} implements two methods to reserve only those ports that are a
multiple of a given modulus. These methods are implemented badly, so that each
call can render many ports unavailable before finding one that satisfies the
constraints. These methods are not used in Geode or in tests, so I will remove
them rather than fixing them.
{{AvailablePortHelper}} (used only in tests) attempts to reduce the number of
unavailable ports it tests by partitioning the available ports among VMS, and
by storing state in a global static variable. In almost all cases, this
mechanism can be replaced by letting the OS choose available ports.
{{UniquePortSupplier}} (used only in tests) remembers every port it allocates
and will not allocate the same port twice. This mechanism has the fatal
limitation that uniqueness is guaranteed only among uses of the same
{{UniquePortSupplier}} instance. This mechanism can be replaced by letting the
OS choose available ports.
{{AvailablePort.Keeper}} retains a port reservation until the caller is ready
to bind to the port. {{Keeper}}'s use within {{AvailablePort}} is unnecessary.
Its use in tests is limited to only a few instances. I will try to make those
instances unnecessary. If it turns out that some tests require holding onto a
reservation beyond its "natural" ({{TIME_WAIT}}) duration, I will move
{{Keeper}} to into the {{geode-junit}} module, near (or inside)
{{AvailablePortHelper}}.
Once this complexity is reduced to its necessary minimum, I will refactor these
classes (safely, with additional tests to cover currently untested features) to
remove duplication and make the remaining code clearer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8401) User Guide - incorrect method name on "forced disconnect" page
[ https://issues.apache.org/jira/browse/GEODE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8401: -- Labels: pull-request-available (was: ) > User Guide - incorrect method name on "forced disconnect" page > -- > > Key: GEODE-8401 > URL: https://issues.apache.org/jira/browse/GEODE-8401 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > Alert reader Barry Oglesby noticed: > [https://geode.apache.org/docs/guide/112/managing/member-reconnect.html] > > has: > Cache.waitForReconnect(long, TimeUnit) > It should be: > Cache.waitUntilReconnected(long, TimeUnit) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8401) User Guide - incorrect method name on "forced disconnect" page
[ https://issues.apache.org/jira/browse/GEODE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171167#comment-17171167 ] ASF GitHub Bot commented on GEODE-8401: --- davebarnes97 opened a new pull request #5423: URL: https://github.com/apache/geode/pull/5423 … page `Cache.waitForReconnect(long, TimeUnit)` should be `Cache.waitUntilReconnected(long, TimeUnit)` 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 - incorrect method name on "forced disconnect" page > -- > > Key: GEODE-8401 > URL: https://issues.apache.org/jira/browse/GEODE-8401 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > Alert reader Barry Oglesby noticed: > [https://geode.apache.org/docs/guide/112/managing/member-reconnect.html] > > has: > Cache.waitForReconnect(long, TimeUnit) > It should be: > Cache.waitUntilReconnected(long, TimeUnit) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8197) Embedded Pulse fails to start with custom log4j2.xml
[
https://issues.apache.org/jira/browse/GEODE-8197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171159#comment-17171159
]
Alexander Murmann commented on GEODE-8197:
--
[~klund] Can this be closed now?
> Embedded Pulse fails to start with custom log4j2.xml
>
>
> Key: GEODE-8197
> URL: https://issues.apache.org/jira/browse/GEODE-8197
> Project: Geode
> Issue Type: Bug
> Components: logging, pulse
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
>
> Starting a Locator with a custom log4j2.xml referencing Geode appenders or
> converters fails to correctly start embedded Pulse web application.
> {noformat}
> [info 2020/05/28 10:51:51.954 PDT tid=1] Adding webapp /pulse
> 2020-05-28 10:51:53,328 main ERROR Unable to invoke factory method in class
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender for element
> GeodeAlert: java.lang.IllegalStateException: No factory method found for
> class org.apache.geode.alerting.log4j.internal.impl.AlertAppender
> java.lang.IllegalStateException: No factory method found for class
> org.apache.geode.alerting.log4j.internal.impl.AlertAppender
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.findFactoryMethod(PluginBuilder.java:234)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:134)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:1002)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:942)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:934)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:552)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:241)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:288)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:618)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:691)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:138)
> at
> org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:39)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:48)
> at
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:40)
> at
> org.apache.logging.log4j.jcl.LogFactoryImpl.getInstance(LogFactoryImpl.java:55)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:655)
> at
> org.springframework.web.filter.GenericFilterBean.(GenericFilterBean.java:86)
> at
> org.springframework.web.filter.DelegatingFilterProxy.(DelegatingFilterProxy.java:107)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2520)
> at
> org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1284)
> at
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:118)
> at
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
> at
> org.eclipse.jetty.servlet.ServletHandler.initi
[jira] [Commented] (GEODE-6663) conserve-sockets=false can cause buffer fragmentation
[ https://issues.apache.org/jira/browse/GEODE-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171153#comment-17171153 ] Alexander Murmann commented on GEODE-6663: -- [~dschneider]Looks like you made a change, but it's unclear if it's merged and if it addresses the issue in its entirety. Can this be closed? > conserve-sockets=false can cause buffer fragmentation > - > > Key: GEODE-6663 > URL: https://issues.apache.org/jira/browse/GEODE-6663 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Darrel Schneider >Priority: Major > Labels: performance > > When conserve-sockets is set to false it enables an optimization called > direct ack. This optimization allows the reply message to be sent directly > back to the requestor on the same socket it sent to request. But the way the > reply is read (see Connection.readAck) can cause small direct ByteBuffer > instances to be created and added to the queue in the Buffers class. These > small buffers can then cause future allocations from the queue to be slower > because the small ones are removed and and added back to the end of the queue. > I think it would be better for readAck to allocate one of this fixed size: > "this.owner.getConduit().tcpBufferSize" instead of basing it off of the reply > message size. > That would keep the all the ones in Buffers the same size. > It is possible that the "inputBuffer" owned by Connection could be used. But > Bruce had this warning regard it: "Be careful about using the Connection's > input buffer. I had so much trouble with multi-threaded access to that > buffer that I decided not to use it in MsgReader." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6316) When socket is closed in proxy, should ping to verify its connection status
[ https://issues.apache.org/jira/browse/GEODE-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171151#comment-17171151 ] Alexander Murmann commented on GEODE-6316: -- [~zhouxj] This is still open years later. In the PR is a mysterious reference to other alternatives. Should this be closed? > When socket is closed in proxy, should ping to verify its connection status > --- > > Key: GEODE-6316 > URL: https://issues.apache.org/jira/browse/GEODE-6316 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > When client's socket was closed, the server's socket.isConnected() will still > be true if there's no msg is sent to it. > > So to verify if a proxy is still alive, we should ping it. > > The original checking code "if (staleClientProxy.isConnected() && > staleClientProxy.getSocket().isConnected())" was introduced in GEODE-1183. > While the idea of GEODE-1183 is still valid, this checking logic is not > mature. When a client's socket is closed, and it tried to reconnect, it could > fail with > "A previous connection attempt from this client is still being processed:" > and cannot connect. > > The fix is to send a PING msg to an existing proxy. If failed, the PING msg > will automatically close the proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6255) ManagementListener may deadlock with Cache close
[
https://issues.apache.org/jira/browse/GEODE-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann resolved GEODE-6255.
--
Resolution: Fixed
looks like a PR addressed this already
> ManagementListener may deadlock with Cache close
>
>
> Key: GEODE-6255
> URL: https://issues.apache.org/jira/browse/GEODE-6255
> Project: Geode
> Issue Type: Bug
> Components: management, regions
>Affects Versions: 1.0.0-incubating.M1, 1.0.0-incubating.M2,
> 1.0.0-incubating.M3, 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available, swat
> Attachments: ManagementListenerDeadlockRegressionTest.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Attached is ManagementListenerDeadlockRegressionTest.java which consistently
> reproduces this deadlock.
> The only combinations of code paths I can find that has the potential to hit
> this deadlock is:
> * Thread-1 is invoking Cache.close()
> * Thread-2 is invoking Region creation for a persistent Region that will use
> the default Disk Store which has not yet been created
> This is a product deadlock that was discovered by analyzing a dunit hang
> (GEODE-6232).
> {noformat}
> Java stack information for the threads listed above:
> ===
> "Distributed system shutdown hook":
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1348)
> - waiting to lock <0x0006c010d508> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.lambda$static$0(InternalDistributedSystem.java:2328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$$Lambda$6/1645228084.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> {noformat}
> "pool-1-thread-2":
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.removeRoot(GemFireCacheImpl.java:3577)
> - waiting to lock <0x000773583c28> (a java.util.HashMap)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6333)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1755)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6255)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2242)
> at
> org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:430)
> at
> org.apache.geode.management.internal.ManagementResourceRepo.destroyLocalMonitoringRegion(ManagementResourceRepo.java:73)
> at
> org.apache.geode.management.internal.LocalManager.cleanUpResources(LocalManager.java:260)
> at
> org.apache.geode.management.internal.LocalManager.stopManager(LocalManager.java:388)
> at
> org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:239)
> - locked <0x00077361b900> (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:737)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:119)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2127)
> - locked <0x0006c010d508> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1966)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1956)
> at
> org.apache.geode.internal.cache.persistence.CreateDestroyRegionRegressionTest.closeCache(CreateDestroyRegionRegressionTest.java:119)
> at
> org.apache.geode.internal.cache.persistence.CreateDestroyRegionRegressionTest.lambda$hang$1(CreateDestroyRegionRegressionTest.java:93)
> at
> org.apache.geode.internal.cache.persistence.CreateDestroyRegionRegressionTest$$Lambda$3/1456208737.run(Unknown
> Source)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.la
[jira] [Resolved] (GEODE-6100) LogConsumer is creating instability in suspect string detection
[
https://issues.apache.org/jira/browse/GEODE-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann resolved GEODE-6100.
--
Resolution: Fixed
looks like a PR addressed this already
> LogConsumer is creating instability in suspect string detection
> ---
>
> Key: GEODE-6100
> URL: https://issues.apache.org/jira/browse/GEODE-6100
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> (Original ticket title: CI:
> CacheClientNotifierDUnitTest.testNormalClient2MultipleCacheServer failed with
> suspect strings)
> Failure at:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/163
> Failed with message:
> {noformat}
> org.apache.geode.internal.cache.wan.CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3689
> /hom[warn 2018/11/27 21:24:25.124 UTC
> tid=179] Cache Client
> Updater Thread on ef956df2d60b(376):41003 port 28307
> (ef956df2d60b:28307): Caught following exception while attempting to create a
> server-to-client communication socket and will exit:
> org.apache.geode.cache.client.ServerRefusedConnectionException: inet_addr hostname>:28307 refused connection: A previous connection
> attempt from this client is still being processed:
> identity(172.17.0.8(381:loner):47756:85080f57,connection=1
> {noformat}
> Results viewable at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.198/test-results/distributedTest/1543356956/
> Artifacts available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.198/test-artifacts/1543356956/distributedtestfiles-OpenJDK8-1.9.0-build.198.tgz
> Possibly related to GEODE-5595 per the comment by Ken Howe, insofar as his
> comment also includes the same suspect string. Also quite possibly
> unrelated. You, dear reader, can find out!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6098) Uniform assert statements as rest of the class DistributedMemberLock
[
https://issues.apache.org/jira/browse/GEODE-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann resolved GEODE-6098.
--
Resolution: Fixed
looks like a PR addressed this already
> Uniform assert statements as rest of the class DistributedMemberLock
>
>
> Key: GEODE-6098
> URL: https://issues.apache.org/jira/browse/GEODE-6098
> Project: Geode
> Issue Type: Bug
>Reporter: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Change
> {code}
> Assert.assertTrue(locked, "Failed to lock " + toString());
> {code}
> to
> {code}
> Assert.assertTrue(locked, "Failed to lock " + this);
> {code}
>
> like in the rest of the files
> {code}
> Assert.assertTrue(locked, "Failed to lockInterruptibly " + this);
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6097) Using primitive datatypes instead of boxed when possible
[ https://issues.apache.org/jira/browse/GEODE-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-6097. -- Resolution: Fixed looks like a PR addressed this already > Using primitive datatypes instead of boxed when possible > > > Key: GEODE-6097 > URL: https://issues.apache.org/jira/browse/GEODE-6097 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > * LGTM fix. > * Improves performance and prevents superfluous allocation of objects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6028) Remove unnecessary comparison checks in the code.
[ https://issues.apache.org/jira/browse/GEODE-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-6028. -- Resolution: Fixed looks like a PR addressed this already > Remove unnecessary comparison checks in the code. > - > > Key: GEODE-6028 > URL: https://issues.apache.org/jira/browse/GEODE-6028 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Remove unnecessary checks in the code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5981) Remove operations on null, de-referenced objects
[ https://issues.apache.org/jira/browse/GEODE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5981. -- Resolution: Fixed looks like a PR addressed this already > Remove operations on null, de-referenced objects > > > Key: GEODE-5981 > URL: https://issues.apache.org/jira/browse/GEODE-5981 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > We should not invoked methods on objects that are de referenced and hence may > lead to NPEs. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5983) Compare boxed primitives using equals() rather than ==
[ https://issues.apache.org/jira/browse/GEODE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5983. -- Resolution: Fixed looks like a PR addressed this already > Compare boxed primitives using equals() rather than == > -- > > Key: GEODE-5983 > URL: https://issues.apache.org/jira/browse/GEODE-5983 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > Files affected: > [DistributedCacheOperation.java|https://lgtm.com/projects/g/apache/incubator-geode/snapshot/8c3d7f0677a5c6d167d1927ebb2e8056b67086fe/files/geode-core/src/main/java/org/apache/geode/internal/cache/DistributedCacheOperation.java] > [SqlHandler.java|https://lgtm.com/projects/g/apache/incubator-geode/snapshot/8c3d7f0677a5c6d167d1927ebb2e8056b67086fe/files/geode-connectors/src/main/java/org/apache/geode/connectors/jdbc/internal/SqlHandler.java] > [RegionFunctionArgs.java|https://lgtm.com/projects/g/apache/incubator-geode/snapshot/8c3d7f0677a5c6d167d1927ebb2e8056b67086fe/files/geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/RegionFunctionArgs.java] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5980) Remove collections from the code that are not used.
[ https://issues.apache.org/jira/browse/GEODE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5980. -- Resolution: Fixed looks like a PR addressed this already > Remove collections from the code that are not used. > --- > > Key: GEODE-5980 > URL: https://issues.apache.org/jira/browse/GEODE-5980 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > There are a couple of collections that are initialized and populated but are > never accessed. Those need to be removed. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5982) synchronize both the getters and setters for cacheWriter and cacheLoader
[ https://issues.apache.org/jira/browse/GEODE-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5982. -- Resolution: Fixed looks like a PR addressed this already > synchronize both the getters and setters for cacheWriter and cacheLoader > > > Key: GEODE-5982 > URL: https://issues.apache.org/jira/browse/GEODE-5982 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > In the current code for AbstractRegion.java, the getters are not protected > however the the setters are synchronized. > Both getters and setters must be synchronized for cacheLoader and cacheWriter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5976) Prevent conversion of string to bytes multiple times
[ https://issues.apache.org/jira/browse/GEODE-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5976. -- Resolution: Fixed looks like a PR addressed this already. > Prevent conversion of string to bytes multiple times > > > Key: GEODE-5976 > URL: https://issues.apache.org/jira/browse/GEODE-5976 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Prevent the conversion of string to bytes multiple times when equals is > called on > ByteArrayWrapper and a string value. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5975) Fix type mismatch on container mismatch
[ https://issues.apache.org/jira/browse/GEODE-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5975. -- Resolution: Fixed looks like a PR addressed this already > Fix type mismatch on container mismatch > --- > > Key: GEODE-5975 > URL: https://issues.apache.org/jira/browse/GEODE-5975 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Calling container access methods such as Collections.contains or Map.get with > an object of a type that is incompatible with the corresponding container > element type is unlikely to return true. > > Affected files: > [ManagementResourceRepo.java|https://lgtm.com/projects/g/apache/incubator-geode/snapshot/8c3d7f0677a5c6d167d1927ebb2e8056b67086fe/files/geode-core/src/main/java/org/apache/geode/management/internal/ManagementResourceRepo.java] > [RegionProvider.java|https://lgtm.com/projects/g/apache/incubator-geode/snapshot/8c3d7f0677a5c6d167d1927ebb2e8056b67086fe/files/geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5852) Adding 1.7.0 to rolling / BC tests
[ https://issues.apache.org/jira/browse/GEODE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5852. -- Resolution: Fixed looks like a PR addressed this already > Adding 1.7.0 to rolling / BC tests > -- > > Key: GEODE-5852 > URL: https://issues.apache.org/jira/browse/GEODE-5852 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > As Apache Geode 1.7.0 has been released we are adding it as an old version in > geode-old-versions project's build.gradle file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6950) Locator can't start if a lot of clients already started
[ https://issues.apache.org/jira/browse/GEODE-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6950: -- Labels: pull-request-available (was: ) > Locator can't start if a lot of clients already started > --- > > Key: GEODE-6950 > URL: https://issues.apache.org/jira/browse/GEODE-6950 > Project: Geode > Issue Type: Bug > Components: core, membership >Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.12.0 >Reporter: Eugene Nedzvetsky >Assignee: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Attachments: 1.log > > > Locator can't start if a few hundred clients already started. > Steps to reproduce: > 1. Start Locator > 2. Start 300 Geode clients > 3. Stop Locator > 4. Start Locator again > Observe 100% CPU load and after some time Locator app crashes with timeout > exceptions in the log. > The problem is in the method > org.apache.geode.distributed.internal.InternalLocator.PrimaryHandler#processRequest > handlerMapping doesn't have handlers for LocatorListRequest and > ClientConnectionRequest requests on Locator startup and in this case work > code part with condition 'if(giveup == 0)'(InternalLocator:1185) > Pause Thread.sleep(1000) works only on the first iteration and after that > giveup>0 and CPU just spends resources on cycle execution without any pauses. > Call Thread.sleep(1000) should be after if(giveup>0) condition block. It > will be called on each iteration in this case. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6950) Locator can't start if a lot of clients already started
[ https://issues.apache.org/jira/browse/GEODE-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171132#comment-17171132 ] ASF GitHub Bot commented on GEODE-6950: --- bschuchardt opened a new pull request #5422: URL: https://github.com/apache/geode/pull/5422 The ticket had a suggested fix for the locator's hot loop and I've implemented that. I modified PrimaryHandler to make the issue testable and added a couple of other tests for registered and fallback request handlers. 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 > Locator can't start if a lot of clients already started > --- > > Key: GEODE-6950 > URL: https://issues.apache.org/jira/browse/GEODE-6950 > Project: Geode > Issue Type: Bug > Components: core, membership >Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.12.0 >Reporter: Eugene Nedzvetsky >Assignee: Bruce J Schuchardt >Priority: Major > Attachments: 1.log > > > Locator can't start if a few hundred clients already started. > Steps to reproduce: > 1. Start Locator > 2. Start 300 Geode clients > 3. Stop Locator > 4. Start Locator again > Observe 100% CPU load and after some time Locator app crashes with timeout > exceptions in the log. > The problem is in the method > org.apache.geode.distributed.internal.InternalLocator.PrimaryHandler#processRequest > handlerMapping doesn't have handlers for LocatorListRequest and > ClientConnectionRequest requests on Locator startup and in this case work > code part with condition 'if(giveup == 0)'(InternalLocator:1185) > Pause Thread.sleep(1000) works only on the first iteration and after that > giveup>0 and CPU just spends resources on cycle execution without any pauses. > Call Thread.sleep(1000) should be after if(giveup>0) condition block. It > will be called on each iteration in this case. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5761) jsonassert has incompatible transitive dependency on android-json
[ https://issues.apache.org/jira/browse/GEODE-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5761. -- Resolution: Fixed Looks like a PR addressed this a long time ago > jsonassert has incompatible transitive dependency on android-json > - > > Key: GEODE-5761 > URL: https://issues.apache.org/jira/browse/GEODE-5761 > Project: Geode > Issue Type: Bug > Components: build, tests >Reporter: Kirk Lund >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > The fix for GEODE-5696 added geode-junit dependency on > org.skyscreamer:jsonassert which brings in a transitive dependency on > com.vaadin.external.google:android-json which is incompatible with geode-json. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5318) create defined index does not update cluster config if methods are invoked in the from clause
[
https://issues.apache.org/jira/browse/GEODE-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann resolved GEODE-5318.
--
Resolution: Fixed
Looks like a fix was merged over 2 years ago
> create defined index does not update cluster config if methods are invoked in
> the from clause
> -
>
> Key: GEODE-5318
> URL: https://issues.apache.org/jira/browse/GEODE-5318
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> +*Steps to reproduce the issue.*+
> # start locator
> # start server
> # create region
> # define index as "define index --name=index --region="Member.entrySet"
> --expression="value.getId" "
> # create defined indexes
> This is will result in a failure causing no updates to the cluster config for
> the newly created indexes, even though the indexes are created. +_*So when a
> server is restarted , it won't recreate these indexes.*_+
> +*Cause of the problem:*+
> We try to extract the region name to update the cluster config from the
> index's "from clause".
> We end up getting .entrySet . But there are no region named as
> such so no updates to the cluster config.
>
> +*Solution*+
> Use the fix for GEODE-2764 where we can extract the proper region name from
> the "from clause"
> *problematic code:*
> {code:java}
> RegionConfig region =
> config.findRegionConfiguration(index.getFromClause());{code}
> *fix:*
> {code:java}
> String regionPath = getValidRegionName(index.getFromClause(), config);
> RegionConfig regionConfig = config.findRegionConfiguration(regionPath);{code}
> +*Example:*+
> Below we can see an complete execution in gfsh which leads to this failure.
> Including the failure to update the config and inability of the server to
> recreate the index after being restarted.
> {noformat}
> _ __
> / _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / / / /
> /__/_/ /__/_/ /_/ 1.8.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator
> Starting a Geode Locator in
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/bin/untie-happy-can...
>
> Locator in
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/bin/untie-happy-can
> on 10.0.0.40[10334] as untie-happy-can is currently online.
> Process ID: 29310
> Uptime: 4 seconds
> Geode Version: 1.8.0-SNAPSHOT
> Java Version: 1.8.0_161
> Log File:
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/bin/untie-happy-can/untie-happy-can.log
> JVM Arguments: -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.8.0-SNAPSHOT.jar:/home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> Successfully connected to: JMX Manager [host=10.0.0.40, port=1099]
> Cluster configuration service is up and running.
> gfsh>start server
> Starting a Geode Server in
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/bin/fix-vast-kilo...
> ...
> Server in
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/bin/fix-vast-kilo
> on 10.0.0.40[40404] as fix-vast-kilo is currently online.
> Process ID: 29498
> Uptime: 2 seconds
> Geode Version: 1.8.0-SNAPSHOT
> Java Version: 1.8.0_161
> Log File:
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/bin/fix-vast-kilo/fix-vast-kilo.log
> JVM Arguments: -Dgemfire.default.locators=10.0.0.40[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.8.0-SNAPSHOT.jar:/home/nabarun/Documents/codeWork/dev2/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
> gfsh>create region --name=Member --type=PARTITION
> Member | Status
> - | ---
> fix-vast-kilo | Region "/Membe
[jira] [Resolved] (GEODE-5262) Race condition in RemoteGfManagerAgent between removeMember and disconnect methods yields NPE
[ https://issues.apache.org/jira/browse/GEODE-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann resolved GEODE-5262. -- Resolution: Fixed Looks like this was fixed in a PR two years ago > Race condition in RemoteGfManagerAgent between removeMember and disconnect > methods yields NPE > - > > Key: GEODE-5262 > URL: https://issues.apache.org/jira/browse/GEODE-5262 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > When removeMemember is called after disconnect, we would sometimes get this > stacktrace: > > at > org.apache.geode.internal.admin.remote.RemoteGfManagerAgent.removeMember(RemoteGfManagerAgent.java:680) > at > org.apache.geode.internal.admin.remote.RemoteGfManagerAgent$MyMembershipListener.memberDeparted(RemoteGfManagerAgent.java:1402) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8401) User Guide - incorrect method name on "forced disconnect" page
[ https://issues.apache.org/jira/browse/GEODE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-8401: -- Assignee: Dave Barnes > User Guide - incorrect method name on "forced disconnect" page > -- > > Key: GEODE-8401 > URL: https://issues.apache.org/jira/browse/GEODE-8401 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > Alert reader Barry Oglesby noticed: > [https://geode.apache.org/docs/guide/112/managing/member-reconnect.html] > > has: > Cache.waitForReconnect(long, TimeUnit) > It should be: > Cache.waitUntilReconnected(long, TimeUnit) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-6950) Locator can't start if a lot of clients already started
[ https://issues.apache.org/jira/browse/GEODE-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reassigned GEODE-6950: - Assignee: Bruce J Schuchardt > Locator can't start if a lot of clients already started > --- > > Key: GEODE-6950 > URL: https://issues.apache.org/jira/browse/GEODE-6950 > Project: Geode > Issue Type: Bug > Components: core, membership >Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.12.0 >Reporter: Eugene Nedzvetsky >Assignee: Bruce J Schuchardt >Priority: Major > Attachments: 1.log > > > Locator can't start if a few hundred clients already started. > Steps to reproduce: > 1. Start Locator > 2. Start 300 Geode clients > 3. Stop Locator > 4. Start Locator again > Observe 100% CPU load and after some time Locator app crashes with timeout > exceptions in the log. > The problem is in the method > org.apache.geode.distributed.internal.InternalLocator.PrimaryHandler#processRequest > handlerMapping doesn't have handlers for LocatorListRequest and > ClientConnectionRequest requests on Locator startup and in this case work > code part with condition 'if(giveup == 0)'(InternalLocator:1185) > Pause Thread.sleep(1000) works only on the first iteration and after that > giveup>0 and CPU just spends resources on cycle execution without any pauses. > Call Thread.sleep(1000) should be after if(giveup>0) condition block. It > will be called on each iteration in this case. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8403) gfsh connect uses marketing version instead of serialization version in compatibility check
[
https://issues.apache.org/jira/browse/GEODE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8403:
Description:
After GEODE-8331 {{ConnectCommand.connect()}} uses the result from
{{OperationInvoker.getRemoteVersion()}}, the "marketing" version string derived
from {{GemFireVersion.getGemFireVersion()}}, to determine compatibility (with
the remote Geode system.)
This is wrong because the purpose of that marketing version string is to carry
version info for products derived from Geode. Those product versions do not, in
general, correspond to Geode product versions.
{{GemFireVersion.getGemFireVersion()}} might return values like:
* {{Apache Geode 1.10}}
* {{Pivotal GemFire 9.5}}
* {{Ampool Active Data Store 1.0}}
For compatibility purposes between Geode components, serialization version
{{Version.CURRENT}} (soon to be {{KnownVersion.CURRENT}}) should be used.
The marketing version is set during a build via Gradle
{{-Pversion= -PgeodeVersion=}}. Unfortunately, PR
pipeline builds do not have those properties set. As a result, such a build
will run with marketing version "0.0.0".
Since {{ConnectCommand.connect()}} fails (with an error message: {{Cannot use a
0.0.0 gfsh client to connect to a 0.0.0 cluster}} for any remote (marketing)
version below 1.10 (9.9) gfsh connect won't work on these PR pipeline builds,
when connecting to a locator running the same build.
It would be nice if we could fix this by having {{ConnectCommand.connect()}}
probe the remote version via
{{OperationInvoker.getRemoteGeodeSerializationVersion()}} instead of
{{OperationInvoker.getRemoteVersion()}}. But unfortunately,
{{getRemoteGeodeSerializationVersion()}} was introduced in 1.12 (in
GEODE-5194)—it's not present in [1.10,1.12). So the solution isn't so simple.
When this story is complete {{ConnectCommand.connect()}} will use this
algorithm to determine compatibility with the remote system:
1. try {{getRemoteGeodeSerializationVersion()}} and if it succeeds use that for
the version comparison
2. if that doesn't work, fall back to {{OperationInvoker.getRemoteVersion()}}
This will allow a gfsh built via the PR pipeline to connect to Geode locators
built in the same build. For testing with older Geode versions we can rely on
those old versions to have been built with {{-Pversion=
-PgeodeVersion=}} or to be 1.12-or-newer (and so, to support
{{getRemoteGeodeSerializationVersion()}})
was:
After GEODE-8331 {{ConnectCommand.connect()}} uses the result from
{{OperationInvoker.getRemoteVersion()}}, the "marketing" version string, to
determine compatibility (with the remote Geode system.)
This is wrong because the purpose of that marketing version string is to carry
version info for products derived from Geode. Those product versions do not, in
general, correspond to Geode product versions. For compatibility purposes
between Geode components, serialization version {{Version.CURRENT}} (soon to be
{{KnownVersion.CURRENT}}) should be used.
The marketing version is set during a build via Gradle
{{-Pversion= -PgeodeVersion=}}. Unfortunately, PR
pipeline builds do not have those properties set. As a result, such a build
will run with marketing version "0.0.0".
Since {{ConnectCommand.connect()}} fails (with an error message: {{Cannot use a
0.0.0 gfsh client to connect to a 0.0.0 cluster}} for any remote (marketing)
version below 1.10 (9.9) gfsh connect won't work on these PR pipeline builds,
when connecting to a locator running the same build.
It would be nice if we could fix this by having {{ConnectCommand.connect()}}
probe the remote version via
{{OperationInvoker.getRemoteGeodeSerializationVersion()}} instead of
{{OperationInvoker.getRemoteVersion()}}. But unfortunately,
{{getRemoteGeodeSerializationVersion()}} was introduced in 1.12 (in
GEODE-5194)—it's not present in [1.10,1.12). So the solution isn't so simple.
When this story is complete {{ConnectCommand.connect()}} will use this
algorithm to determine compatibility with the remote system:
1. try {{getRemoteGeodeSerializationVersion()}} and if it succeeds use that for
the version comparison
2. if that doesn't work, fall back to {{OperationInvoker.getRemoteVersion()}}
This will allow a gfsh built via the PR pipeline to connect to Geode locators
built in the same build. For testing with older Geode versions we can rely on
those old versions to have been built with {{-Pversion=
-PgeodeVersion=}} or to be 1.12-or-newer (and so, to support
{{getRemoteGeodeSerializationVersion()}})
> gfsh connect uses marketing version instead of serialization version in
> compatibility check
> ---
>
> Key: GEODE-8403
> URL: https://issues.apache.org/jira/browse/GEODE-8403
> Project: Geode
> Issue Type: Bug
>
[jira] [Updated] (GEODE-8403) gfsh connect uses marketing version instead of serialization version in compatibility check
[
https://issues.apache.org/jira/browse/GEODE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8403:
Affects Version/s: 1.14.0
1.13.0
1.12.1
> gfsh connect uses marketing version instead of serialization version in
> compatibility check
> ---
>
> Key: GEODE-8403
> URL: https://issues.apache.org/jira/browse/GEODE-8403
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.12.1, 1.13.0, 1.14.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: GeodeOperationAPI
>
> After GEODE-8331 {{ConnectCommand.connect()}} uses the result from
> {{OperationInvoker.getRemoteVersion()}}, the "marketing" version string, to
> determine compatibility (with the remote Geode system.)
> This is wrong because the purpose of that marketing version string is to
> carry version info for products derived from Geode. Those product versions do
> not, in general, correspond to Geode product versions. For compatibility
> purposes between Geode components, serialization version {{Version.CURRENT}}
> (soon to be {{KnownVersion.CURRENT}}) should be used.
> The marketing version is set during a build via Gradle
> {{-Pversion= -PgeodeVersion=}}. Unfortunately, PR
> pipeline builds do not have those properties set. As a result, such a build
> will run with marketing version "0.0.0".
> Since {{ConnectCommand.connect()}} fails (with an error message: {{Cannot use
> a 0.0.0 gfsh client to connect to a 0.0.0 cluster}} for any remote
> (marketing) version below 1.10 (9.9) gfsh connect won't work on these PR
> pipeline builds, when connecting to a locator running the same build.
> It would be nice if we could fix this by having {{ConnectCommand.connect()}}
> probe the remote version via
> {{OperationInvoker.getRemoteGeodeSerializationVersion()}} instead of
> {{OperationInvoker.getRemoteVersion()}}. But unfortunately,
> {{getRemoteGeodeSerializationVersion()}} was introduced in 1.12 (in
> GEODE-5194)—it's not present in [1.10,1.12). So the solution isn't so simple.
> When this story is complete {{ConnectCommand.connect()}} will use this
> algorithm to determine compatibility with the remote system:
> 1. try {{getRemoteGeodeSerializationVersion()}} and if it succeeds use that
> for the version comparison
> 2. if that doesn't work, fall back to {{OperationInvoker.getRemoteVersion()}}
> This will allow a gfsh built via the PR pipeline to connect to Geode locators
> built in the same build. For testing with older Geode versions we can rely on
> those old versions to have been built with {{-Pversion=
> -PgeodeVersion=}} or to be 1.12-or-newer (and so, to support
> {{getRemoteGeodeSerializationVersion()}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8403) gfsh connect uses marketing version instead of serialization version in compatibility check
[
https://issues.apache.org/jira/browse/GEODE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8403:
Labels: GeodeOperationAPI (was: )
> gfsh connect uses marketing version instead of serialization version in
> compatibility check
> ---
>
> Key: GEODE-8403
> URL: https://issues.apache.org/jira/browse/GEODE-8403
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Bill Burcham
>Priority: Major
> Labels: GeodeOperationAPI
>
> After GEODE-8331 {{ConnectCommand.connect()}} uses the result from
> {{OperationInvoker.getRemoteVersion()}}, the "marketing" version string, to
> determine compatibility (with the remote Geode system.)
> This is wrong because the purpose of that marketing version string is to
> carry version info for products derived from Geode. Those product versions do
> not, in general, correspond to Geode product versions. For compatibility
> purposes between Geode components, serialization version {{Version.CURRENT}}
> (soon to be {{KnownVersion.CURRENT}}) should be used.
> The marketing version is set during a build via Gradle
> {{-Pversion= -PgeodeVersion=}}. Unfortunately, PR
> pipeline builds do not have those properties set. As a result, such a build
> will run with marketing version "0.0.0".
> Since {{ConnectCommand.connect()}} fails (with an error message: {{Cannot use
> a 0.0.0 gfsh client to connect to a 0.0.0 cluster}} for any remote
> (marketing) version below 1.10 (9.9) gfsh connect won't work on these PR
> pipeline builds, when connecting to a locator running the same build.
> It would be nice if we could fix this by having {{ConnectCommand.connect()}}
> probe the remote version via
> {{OperationInvoker.getRemoteGeodeSerializationVersion()}} instead of
> {{OperationInvoker.getRemoteVersion()}}. But unfortunately,
> {{getRemoteGeodeSerializationVersion()}} was introduced in 1.12 (in
> GEODE-5194)—it's not present in [1.10,1.12). So the solution isn't so simple.
> When this story is complete {{ConnectCommand.connect()}} will use this
> algorithm to determine compatibility with the remote system:
> 1. try {{getRemoteGeodeSerializationVersion()}} and if it succeeds use that
> for the version comparison
> 2. if that doesn't work, fall back to {{OperationInvoker.getRemoteVersion()}}
> This will allow a gfsh built via the PR pipeline to connect to Geode locators
> built in the same build. For testing with older Geode versions we can rely on
> those old versions to have been built with {{-Pversion=
> -PgeodeVersion=}} or to be 1.12-or-newer (and so, to support
> {{getRemoteGeodeSerializationVersion()}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8403) gfsh connect uses marketing version instead of serialization version in compatibility check
Bill Burcham created GEODE-8403:
---
Summary: gfsh connect uses marketing version instead of
serialization version in compatibility check
Key: GEODE-8403
URL: https://issues.apache.org/jira/browse/GEODE-8403
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Bill Burcham
After GEODE-8331 {{ConnectCommand.connect()}} uses the result from
{{OperationInvoker.getRemoteVersion()}}, the "marketing" version string, to
determine compatibility (with the remote Geode system.)
This is wrong because the purpose of that marketing version string is to carry
version info for products derived from Geode. Those product versions do not, in
general, correspond to Geode product versions. For compatibility purposes
between Geode components, serialization version {{Version.CURRENT}} (soon to be
{{KnownVersion.CURRENT}}) should be used.
The marketing version is set during a build via Gradle
{{-Pversion= -PgeodeVersion=}}. Unfortunately, PR
pipeline builds do not have those properties set. As a result, such a build
will run with marketing version "0.0.0".
Since {{ConnectCommand.connect()}} fails (with an error message: {{Cannot use a
0.0.0 gfsh client to connect to a 0.0.0 cluster}} for any remote (marketing)
version below 1.10 (9.9) gfsh connect won't work on these PR pipeline builds,
when connecting to a locator running the same build.
It would be nice if we could fix this by having {{ConnectCommand.connect()}}
probe the remote version via
{{OperationInvoker.getRemoteGeodeSerializationVersion()}} instead of
{{OperationInvoker.getRemoteVersion()}}. But unfortunately,
{{getRemoteGeodeSerializationVersion()}} was introduced in 1.12 (in
GEODE-5194)—it's not present in [1.10,1.12). So the solution isn't so simple.
When this story is complete {{ConnectCommand.connect()}} will use this
algorithm to determine compatibility with the remote system:
1. try {{getRemoteGeodeSerializationVersion()}} and if it succeeds use that for
the version comparison
2. if that doesn't work, fall back to {{OperationInvoker.getRemoteVersion()}}
This will allow a gfsh built via the PR pipeline to connect to Geode locators
built in the same build. For testing with older Geode versions we can rely on
those old versions to have been built with {{-Pversion=
-PgeodeVersion=}} or to be 1.12-or-newer (and so, to support
{{getRemoteGeodeSerializationVersion()}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8344) Deserialization error in multisite conf using CQs and C++ client
[ https://issues.apache.org/jira/browse/GEODE-8344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170946#comment-17170946 ] ASF GitHub Bot commented on GEODE-8344: --- alb3rtobr commented on pull request #628: URL: https://github.com/apache/geode-native/pull/628#issuecomment-668701694 Sorry for the late answer, I have been on vacation. I have changed the PR to draft because Im still working on the tests. I have added some functionality to the integration test framework in order to reproduce configure two clusters to reproduce the error, but I still have a problem with a disk access exception when configuring gateway senders. 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 > Deserialization error in multisite conf using CQs and C++ client > > > Key: GEODE-8344 > URL: https://issues.apache.org/jira/browse/GEODE-8344 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > Im creating this ticket after this conversation in the dev list, so there is > more information here: http://markmail.org/thread/u65gmb7zoxlpcqss > h3. Setup: > - Two sites > - CQs configured > - Using C++ client > h3. Problem: > It is observed that while CQ events from local site (the one that the client > is connected to) are received, the one originated in remote servers are > missing. > After debugging it was observed there is an error in the logs, trying to > deserialize fixedID = -135. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8344) Deserialization error in multisite conf using CQs and C++ client
[ https://issues.apache.org/jira/browse/GEODE-8344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8344: -- Labels: pull-request-available (was: ) > Deserialization error in multisite conf using CQs and C++ client > > > Key: GEODE-8344 > URL: https://issues.apache.org/jira/browse/GEODE-8344 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Im creating this ticket after this conversation in the dev list, so there is > more information here: http://markmail.org/thread/u65gmb7zoxlpcqss > h3. Setup: > - Two sites > - CQs configured > - Using C++ client > h3. Problem: > It is observed that while CQ events from local site (the one that the client > is connected to) are received, the one originated in remote servers are > missing. > After debugging it was observed there is an error in the logs, trying to > deserialize fixedID = -135. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8382) Run Redis tests against Redis API for Geode
[ https://issues.apache.org/jira/browse/GEODE-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170918#comment-17170918 ] ASF GitHub Bot commented on GEODE-8382: --- onichols-pivotal commented on a change in pull request #5416: URL: https://github.com/apache/geode/pull/5416#discussion_r465158361 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -0,0 +1,51 @@ +#!/usr/bin/env bash + +# +# 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. + +cd .. +git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +cd redis +git checkout tests-geode-redis + +JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64" \ Review comment: If Robert were around today he might know a way to get it from gradle's testJVM property when gradle invokes the redis script, but this might work too. 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 > Run Redis tests against Redis API for Geode > --- > > Key: GEODE-8382 > URL: https://issues.apache.org/jira/browse/GEODE-8382 > Project: Geode > Issue Type: New Feature > Components: ci, redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We would like to run Redis's tests against Redis API for Geode. Tests will > run a separate job in the PR and main pipelines. It has been included in the > 'tests' jinja variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8382) Run Redis tests against Redis API for Geode
[ https://issues.apache.org/jira/browse/GEODE-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170917#comment-17170917 ] ASF GitHub Bot commented on GEODE-8382: --- onichols-pivotal commented on a change in pull request #5416: URL: https://github.com/apache/geode/pull/5416#discussion_r465158361 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -0,0 +1,51 @@ +#!/usr/bin/env bash + +# +# 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. + +cd .. +git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +cd redis +git checkout tests-geode-redis + +JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64" \ Review comment: If Robert were around today he might know a way to get it from gradle's testJVM property when gradle invokes the redis script, but this works too. 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 > Run Redis tests against Redis API for Geode > --- > > Key: GEODE-8382 > URL: https://issues.apache.org/jira/browse/GEODE-8382 > Project: Geode > Issue Type: New Feature > Components: ci, redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We would like to run Redis's tests against Redis API for Geode. Tests will > run a separate job in the PR and main pipelines. It has been included in the > 'tests' jinja variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6564) Clearing a replicated region with expiration causes a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-6564:
Fix Version/s: 1.13.0
> Clearing a replicated region with expiration causes a memory leak
> -
>
> Key: GEODE-6564
> URL: https://issues.apache.org/jira/browse/GEODE-6564
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barrett Oglesby
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.0, 1.14.0
>
>
> Clearing a replicated region with expiration causes a memory leak
> Both the RegionEntries and EntryExpiryTasks are still live after loading
> entries into the region and then clearing it.
> Server Startup:
> {noformat}
> num #instances #bytes class name
> --
> 1: 29856 2797840 [C
> 4: 2038 520600 [B
> Total 187711 10089624
> {noformat}
> Load 100 entries with 600k payload (representing a session):
> {noformat}
> num #instances #bytes class name
> --
> 1: 2496 60666440 [B
> 2: 30157 2828496 [C
> 73: 100 7200
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 93: 100 4800 org.apache.geode.internal.cache.EntryExpiryTask
> Total 190737 70240472
> {noformat}
> Clear region:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2398 60505944 [B
> 2: 30448 2849456 [C
> 74: 100 7200
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 100: 100 4800 org.apache.geode.internal.cache.EntryExpiryTask
> Total 192199 70373048
> {noformat}
> Load and clear another 100 entries:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2503 120511688 [B
> 2: 30506 2854384 [C
> 46: 200 14400
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 61: 200 9600 org.apache.geode.internal.cache.EntryExpiryTask
> Total 193272 130421432
> {noformat}
> Load and clear another 100 entries:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2600 180517240 [B
> 2: 30562 2859584 [C
> 33: 300 21600
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 47: 300 14400 org.apache.geode.internal.cache.EntryExpiryTask
> Total 194310 190468176
> {noformat}
> A heap dump shows the VersionedStatsRegionEntryHeapStringKey1 instances are
> referenced by the DistributedRegion entryExpiryTasks:
> {noformat}
> --> org.apache.geode.internal.cache.DistributedRegion@0x76adbbb88 (816 bytes)
> (field entryExpiryTasks:)
> --> java.util.concurrent.ConcurrentHashMap@0x76adbc028 (100 bytes) (field
> table:)
> --> [Ljava.util.concurrent.ConcurrentHashMap$Node;@0x76ee85358 (4112 bytes)
> (Element 276 of [Ljava.util.concurrent.ConcurrentHashMap$Node;@0x76ee85358:)
> --> java.util.concurrent.ConcurrentHashMap$Node@0x76edc4e20 (44 bytes) (field
> next:)
> --> java.util.concurrent.ConcurrentHashMap$Node@0x76edc32f0 (44 bytes) (field
> key:)
> -->
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1@0x76edc3210
> (86 bytes)
> {noformat}
> LocalRegion.cancelAllEntryExpiryTasks is called when the region is cleared:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1333)
> at
> org.apache.geode.internal.cache.LocalRegion.cancelAllEntryExpiryTasks(LocalRegion.java:8202)
> at
> org.apache.geode.internal.cache.LocalRegion.clearRegionLocally(LocalRegion.java:9094)
> at
> org.apache.geode.internal.cache.DistributedRegion.cmnClearRegion(DistributedRegion.java:1962)
> at
> org.apache.geode.internal.cache.LocalRegion.basicClear(LocalRegion.java:8998)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicClear(DistributedRegion.java:1939)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgeClear(LocalRegion.java:8988)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ClearRegion.cmdExecute(ClearRegion.java:123)
> {noformat}
> But it doesn't clear the entryExpiryTasks map:
> {noformat}
> LocalRegion.clearRegionLocally before cancelAllEntryExpiryTasks
> entryExpiryTasks=100
> LocalRegion.clearRegionLocally after cancelAllEntryExpiryTasks
> entryExpiryTasks=100
> {noformat}
> As a test, I added this call to the bottom of the cancelAllEntryExpiryTasks
> method:
> {noformat}
> this.entryExpiryTasks.clear();
> {noformat}
> This addressed the leak:
> {noformat}
> Server Startup: Total 182414 9855616
> Load/Clear 1: Total 191049 10315832
> Load/Clear 2: Total 191978 10329664
> Load/Clear 3: Total 192638 10360360
> {noformat}
> As a work-around,
[jira] [Commented] (GEODE-8382) Run Redis tests against Redis API for Geode
[ https://issues.apache.org/jira/browse/GEODE-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170908#comment-17170908 ] ASF GitHub Bot commented on GEODE-8382: --- sabbeyPivotal commented on a change in pull request #5416: URL: https://github.com/apache/geode/pull/5416#discussion_r465148577 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -0,0 +1,51 @@ +#!/usr/bin/env bash + +# +# 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. + +cd .. +git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +cd redis +git checkout tests-geode-redis + +JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64" \ Review comment: Just pushed an update to execute_tests.sh that sets the JAVA_TEST_PATH variable so it's accessible inside the execute_redis_tests script. It passes here: https://concourse.gemfire-ci.info/teams/developer/pipelines/sabbeypivotal-new-pr-pr/jobs/RedisTestOpenJDK11/builds/6 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 > Run Redis tests against Redis API for Geode > --- > > Key: GEODE-8382 > URL: https://issues.apache.org/jira/browse/GEODE-8382 > Project: Geode > Issue Type: New Feature > Components: ci, redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We would like to run Redis's tests against Redis API for Geode. Tests will > run a separate job in the PR and main pipelines. It has been included in the > 'tests' jinja variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6564) Clearing a replicated region with expiration causes a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-6564:
Fix Version/s: 1.12.1
> Clearing a replicated region with expiration causes a memory leak
> -
>
> Key: GEODE-6564
> URL: https://issues.apache.org/jira/browse/GEODE-6564
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barrett Oglesby
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> Clearing a replicated region with expiration causes a memory leak
> Both the RegionEntries and EntryExpiryTasks are still live after loading
> entries into the region and then clearing it.
> Server Startup:
> {noformat}
> num #instances #bytes class name
> --
> 1: 29856 2797840 [C
> 4: 2038 520600 [B
> Total 187711 10089624
> {noformat}
> Load 100 entries with 600k payload (representing a session):
> {noformat}
> num #instances #bytes class name
> --
> 1: 2496 60666440 [B
> 2: 30157 2828496 [C
> 73: 100 7200
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 93: 100 4800 org.apache.geode.internal.cache.EntryExpiryTask
> Total 190737 70240472
> {noformat}
> Clear region:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2398 60505944 [B
> 2: 30448 2849456 [C
> 74: 100 7200
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 100: 100 4800 org.apache.geode.internal.cache.EntryExpiryTask
> Total 192199 70373048
> {noformat}
> Load and clear another 100 entries:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2503 120511688 [B
> 2: 30506 2854384 [C
> 46: 200 14400
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 61: 200 9600 org.apache.geode.internal.cache.EntryExpiryTask
> Total 193272 130421432
> {noformat}
> Load and clear another 100 entries:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2600 180517240 [B
> 2: 30562 2859584 [C
> 33: 300 21600
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 47: 300 14400 org.apache.geode.internal.cache.EntryExpiryTask
> Total 194310 190468176
> {noformat}
> A heap dump shows the VersionedStatsRegionEntryHeapStringKey1 instances are
> referenced by the DistributedRegion entryExpiryTasks:
> {noformat}
> --> org.apache.geode.internal.cache.DistributedRegion@0x76adbbb88 (816 bytes)
> (field entryExpiryTasks:)
> --> java.util.concurrent.ConcurrentHashMap@0x76adbc028 (100 bytes) (field
> table:)
> --> [Ljava.util.concurrent.ConcurrentHashMap$Node;@0x76ee85358 (4112 bytes)
> (Element 276 of [Ljava.util.concurrent.ConcurrentHashMap$Node;@0x76ee85358:)
> --> java.util.concurrent.ConcurrentHashMap$Node@0x76edc4e20 (44 bytes) (field
> next:)
> --> java.util.concurrent.ConcurrentHashMap$Node@0x76edc32f0 (44 bytes) (field
> key:)
> -->
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1@0x76edc3210
> (86 bytes)
> {noformat}
> LocalRegion.cancelAllEntryExpiryTasks is called when the region is cleared:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1333)
> at
> org.apache.geode.internal.cache.LocalRegion.cancelAllEntryExpiryTasks(LocalRegion.java:8202)
> at
> org.apache.geode.internal.cache.LocalRegion.clearRegionLocally(LocalRegion.java:9094)
> at
> org.apache.geode.internal.cache.DistributedRegion.cmnClearRegion(DistributedRegion.java:1962)
> at
> org.apache.geode.internal.cache.LocalRegion.basicClear(LocalRegion.java:8998)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicClear(DistributedRegion.java:1939)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgeClear(LocalRegion.java:8988)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ClearRegion.cmdExecute(ClearRegion.java:123)
> {noformat}
> But it doesn't clear the entryExpiryTasks map:
> {noformat}
> LocalRegion.clearRegionLocally before cancelAllEntryExpiryTasks
> entryExpiryTasks=100
> LocalRegion.clearRegionLocally after cancelAllEntryExpiryTasks
> entryExpiryTasks=100
> {noformat}
> As a test, I added this call to the bottom of the cancelAllEntryExpiryTasks
> method:
> {noformat}
> this.entryExpiryTasks.clear();
> {noformat}
> This addressed the leak:
> {noformat}
> Server Startup: Total 182414 9855616
> Load/Clear 1: Total 191049 10315832
> Load/Clear 2: Total 191978 10329664
> Load/Clear 3: Total 192638 10360360
> {noformat}
> As a work-
[jira] [Commented] (GEODE-6564) Clearing a replicated region with expiration causes a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170906#comment-17170906
]
ASF subversion and git services commented on GEODE-6564:
Commit 94f0859c1de2d6f92fa1bf67707701d58dbfa315 in geode's branch
refs/heads/support/1.13 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=94f0859 ]
GEODE-6564: fix entryExpiryTasks leak (#5419)
(cherry picked from commit 53abb22cd295441f8794e15550b72ec81113ec05)
> Clearing a replicated region with expiration causes a memory leak
> -
>
> Key: GEODE-6564
> URL: https://issues.apache.org/jira/browse/GEODE-6564
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barrett Oglesby
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Clearing a replicated region with expiration causes a memory leak
> Both the RegionEntries and EntryExpiryTasks are still live after loading
> entries into the region and then clearing it.
> Server Startup:
> {noformat}
> num #instances #bytes class name
> --
> 1: 29856 2797840 [C
> 4: 2038 520600 [B
> Total 187711 10089624
> {noformat}
> Load 100 entries with 600k payload (representing a session):
> {noformat}
> num #instances #bytes class name
> --
> 1: 2496 60666440 [B
> 2: 30157 2828496 [C
> 73: 100 7200
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 93: 100 4800 org.apache.geode.internal.cache.EntryExpiryTask
> Total 190737 70240472
> {noformat}
> Clear region:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2398 60505944 [B
> 2: 30448 2849456 [C
> 74: 100 7200
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 100: 100 4800 org.apache.geode.internal.cache.EntryExpiryTask
> Total 192199 70373048
> {noformat}
> Load and clear another 100 entries:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2503 120511688 [B
> 2: 30506 2854384 [C
> 46: 200 14400
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 61: 200 9600 org.apache.geode.internal.cache.EntryExpiryTask
> Total 193272 130421432
> {noformat}
> Load and clear another 100 entries:
> {noformat}
> num #instances #bytes class name
> --
> 1: 2600 180517240 [B
> 2: 30562 2859584 [C
> 33: 300 21600
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1
> 47: 300 14400 org.apache.geode.internal.cache.EntryExpiryTask
> Total 194310 190468176
> {noformat}
> A heap dump shows the VersionedStatsRegionEntryHeapStringKey1 instances are
> referenced by the DistributedRegion entryExpiryTasks:
> {noformat}
> --> org.apache.geode.internal.cache.DistributedRegion@0x76adbbb88 (816 bytes)
> (field entryExpiryTasks:)
> --> java.util.concurrent.ConcurrentHashMap@0x76adbc028 (100 bytes) (field
> table:)
> --> [Ljava.util.concurrent.ConcurrentHashMap$Node;@0x76ee85358 (4112 bytes)
> (Element 276 of [Ljava.util.concurrent.ConcurrentHashMap$Node;@0x76ee85358:)
> --> java.util.concurrent.ConcurrentHashMap$Node@0x76edc4e20 (44 bytes) (field
> next:)
> --> java.util.concurrent.ConcurrentHashMap$Node@0x76edc32f0 (44 bytes) (field
> key:)
> -->
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryHeapStringKey1@0x76edc3210
> (86 bytes)
> {noformat}
> LocalRegion.cancelAllEntryExpiryTasks is called when the region is cleared:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1333)
> at
> org.apache.geode.internal.cache.LocalRegion.cancelAllEntryExpiryTasks(LocalRegion.java:8202)
> at
> org.apache.geode.internal.cache.LocalRegion.clearRegionLocally(LocalRegion.java:9094)
> at
> org.apache.geode.internal.cache.DistributedRegion.cmnClearRegion(DistributedRegion.java:1962)
> at
> org.apache.geode.internal.cache.LocalRegion.basicClear(LocalRegion.java:8998)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicClear(DistributedRegion.java:1939)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgeClear(LocalRegion.java:8988)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ClearRegion.cmdExecute(ClearRegion.java:123)
> {noformat}
> But it doesn't clear the entryExpiryTasks map:
> {noformat}
> LocalRegion.clearRegionLocally before cancelAllEntryExpiryTasks
> entryExpiryTasks=100
> LocalRegion.clearRegionLocally after cancelAllEntryExpiryTasks
> entryExpiryTasks=100
> {noformat}
> As a test, I added this c
[jira] [Created] (GEODE-8402) Move the Dockerfile to use Debian instead of Alpine
Brent Driskill created GEODE-8402: - Summary: Move the Dockerfile to use Debian instead of Alpine Key: GEODE-8402 URL: https://issues.apache.org/jira/browse/GEODE-8402 Project: Geode Issue Type: Bug Components: build Reporter: Brent Driskill OpenJDK dropped support for Alpine last May due to the incompatibility issues between musl and glibc. See commit: [https://github.com/docker-library/openjdk/commit/3eb0351b208d739fac35345c85e3c6237c2114ec#diff-17b0a72d5a10e24142544a9dbc8effcb] Geode is still pointed at the alpine version which has not received any updates in a year: [https://github.com/apache/geode/blob/develop/docker/Dockerfile]. This has lead to the Java version missing the security patches for the last year. The FROM should be migrated to "openjdk:8-jre-slim" and the relevant installation steps switched to support Debian. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8382) Run Redis tests against Redis API for Geode
[ https://issues.apache.org/jira/browse/GEODE-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170834#comment-17170834 ] ASF GitHub Bot commented on GEODE-8382: --- sabbeyPivotal commented on a change in pull request #5416: URL: https://github.com/apache/geode/pull/5416#discussion_r464665951 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -0,0 +1,51 @@ +#!/usr/bin/env bash + +# +# 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. + +cd .. +git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +cd redis +git checkout tests-geode-redis + +JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64" \ Review comment: I updated this, but I'm wondering if we'll have access to the JAVA_TEST_PATH variable in this script? Attempting to check it now... 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 > Run Redis tests against Redis API for Geode > --- > > Key: GEODE-8382 > URL: https://issues.apache.org/jira/browse/GEODE-8382 > Project: Geode > Issue Type: New Feature > Components: ci, redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We would like to run Redis's tests against Redis API for Geode. Tests will > run a separate job in the PR and main pipelines. It has been included in the > 'tests' jinja variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
