[jira] [Created] (GEODE-7177) Move membership's logging dependencies to its own module
Ryan McMahon created GEODE-7177: --- Summary: Move membership's logging dependencies to its own module Key: GEODE-7177 URL: https://issues.apache.org/jira/browse/GEODE-7177 Project: Geode Issue Type: Improvement Components: logging, membership Reporter: Ryan McMahon As part of eliminating membership's dependency on geode-core, we want to move LogService and some other supporting classes to its own module which membership can depend on. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-7177) Move membership's logging dependencies to its own module
[ https://issues.apache.org/jira/browse/GEODE-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-7177: --- Assignee: Ryan McMahon > Move membership's logging dependencies to its own module > > > Key: GEODE-7177 > URL: https://issues.apache.org/jira/browse/GEODE-7177 > Project: Geode > Issue Type: Improvement > Components: logging, membership >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > As part of eliminating membership's dependency on geode-core, we want to move > LogService and some other supporting classes to its own module which > membership can depend on. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GEODE-7172) Add ArchUnit test to break TCPServer dependencies on geode-core
Ryan McMahon created GEODE-7172: --- Summary: Add ArchUnit test to break TCPServer dependencies on geode-core Key: GEODE-7172 URL: https://issues.apache.org/jira/browse/GEODE-7172 Project: Geode Issue Type: Test Components: membership, tests Reporter: Ryan McMahon We would like to shift responsibilities of running the TCPServer which handles PeerRequestMessages from the Locator to the membership module. This is a step towards being able to run membership tests in isolation from the rest of geode-core. A first step is to write an ArchUnit test which will highlight dependencies from the tcpserver package to the rest of geode-core. After the test is written, we can work through breaking all of the undesired dependencies. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-7168) CI failure: Tomcat8ClientServerRollingUpgradeTest > canDoARollingUpgradeOfGeodeServersWithSessionModules[191]
[
https://issues.apache.org/jira/browse/GEODE-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-7168:
---
Assignee: Ryan McMahon
> CI failure: Tomcat8ClientServerRollingUpgradeTest >
> canDoARollingUpgradeOfGeodeServersWithSessionModules[191]
> -
>
> Key: GEODE-7168
> URL: https://issues.apache.org/jira/browse/GEODE-7168
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bruce Schuchardt
>Assignee: Ryan McMahon
>Priority: Major
>
> Recent changes to this test require that there be a Version for any
> geode-old-version we're going to test against. We don't typically create
> Versions for patch releases like 1.9.1 and this is making the test throw NPEs.
> {noformat}
> > Task :geode-assembly:upgradeTest
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest >
> canDoARollingUpgradeOfGeodeServersWithSessionModules[191] FAILED
> java.lang.NullPointerException
> at
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest.getClassPathTomcat8AndOldModules(Tomcat8ClientServerRollingUpgradeTest.java:312)
> at
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest.setup(Tomcat8ClientServerRollingUpgradeTest.java:154)
> java.lang.NullPointerException
> at
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest.stop(Tomcat8ClientServerRollingUpgradeTest.java:181)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (GEODE-7158) Singleton CacheClientNotifier state can pollute tests causing failures
[ https://issues.apache.org/jira/browse/GEODE-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-7158. - Fix Version/s: 1.11.0 Assignee: Ryan McMahon Resolution: Fixed > Singleton CacheClientNotifier state can pollute tests causing failures > -- > > Key: GEODE-7158 > URL: https://issues.apache.org/jira/browse/GEODE-7158 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Two tests in the CacheClientNotifierTest class failed in this PR run: > [https://concourse.apachegeode-ci.info/builds/92365] > They both appear to be failing due to unexpected proxies in their proxy > collections. Our best guess at this point is that these unexpected proxies > are coming from a singleton CacheClientNotifier from a previous test. It is > difficult to pinpoint which test might be causing this pollution, so our best > course of action at this point is to shutdown any existing > CacheClientNotifier singletons in the @Before method, so each test starts > with a clean state. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (GEODE-7158) Singleton CacheClientNotifier state can pollute tests causing failures
[ https://issues.apache.org/jira/browse/GEODE-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-7158. --- > Singleton CacheClientNotifier state can pollute tests causing failures > -- > > Key: GEODE-7158 > URL: https://issues.apache.org/jira/browse/GEODE-7158 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Two tests in the CacheClientNotifierTest class failed in this PR run: > [https://concourse.apachegeode-ci.info/builds/92365] > They both appear to be failing due to unexpected proxies in their proxy > collections. Our best guess at this point is that these unexpected proxies > are coming from a singleton CacheClientNotifier from a previous test. It is > difficult to pinpoint which test might be causing this pollution, so our best > course of action at this point is to shutdown any existing > CacheClientNotifier singletons in the @Before method, so each test starts > with a clean state. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-7089) Possible memory leak due to failure to clean up client's registration queue
[ https://issues.apache.org/jira/browse/GEODE-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-7089: --- Assignee: Ryan McMahon > Possible memory leak due to failure to clean up client's registration queue > --- > > Key: GEODE-7089 > URL: https://issues.apache.org/jira/browse/GEODE-7089 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > It is possible for a client's queue to leak and never be removed from the > ClientRegistrationEventQueueManager's collection, which will result in it > collecting events indefinitely and ultimately cause an OOM exception. This > can happen if the registration fails for any reason (GII failed due to a peer > crashing, unforseen serialization issues while copying the queue, etc). If > the client does not retry on the same server after failure, the queue will > leak. This is because we currently only remove the queue once a successful > registration is performed, but its possible the client will just go to a > different server on its next attempt. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7089) Possible memory leak due to failure to clean up client's registration queue
Ryan McMahon created GEODE-7089: --- Summary: Possible memory leak due to failure to clean up client's registration queue Key: GEODE-7089 URL: https://issues.apache.org/jira/browse/GEODE-7089 Project: Geode Issue Type: Bug Components: client queues Reporter: Ryan McMahon It is possible for a client's queue to leak and never be removed from the ClientRegistrationEventQueueManager's collection, which will result in it collecting events indefinitely and ultimately cause an OOM exception. This can happen if the registration fails for any reason (GII failed due to a peer crashing, unforseen serialization issues while copying the queue, etc). If the client does not retry on the same server after failure, the queue will leak. This is because we currently only remove the queue once a successful registration is performed, but its possible the client will just go to a different server on its next attempt. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7088) Possible ConcurrentModificationException while client queue image is copied
Ryan McMahon created GEODE-7088: --- Summary: Possible ConcurrentModificationException while client queue image is copied Key: GEODE-7088 URL: https://issues.apache.org/jira/browse/GEODE-7088 Project: Geode Issue Type: Bug Components: client queues Reporter: Ryan McMahon The following corner case scenario will result in a ConcurrentModificationException which causes the queue image transfer to fail and subsequently client registration to fail: # Client 1 is currently opening a subscription endpoint with server 1 and events are being staged in the client's temporary registration queue # One or more of those events also match interest for Client 2 who is already fully registered, so the event is put into Client 2's queue (in addition to Client 1's temp queue) # Client 2 asks server 2 to open a secondary subscription endpoint. Server 2 attempts to copy Client 2's queue from server 1. This results in serializing all of the events in Client 2's queue. # While the image is being transferred, Client 1 finishes registration and begins to drain its temporary registration queue. The filter info for each event is recalculated which ends up mutating the shared event in Client 2's queue. # The event has some metadata stored as a non-concurrent set. Recalculating the filter info for Client 1 will mutate that set, but the image transfer for Client 2 is trying to copy that set simultaneously. This can result in a ConcurrentModificationException because the set is not thread safe. Note that there no danger in recalculating the filter from Client 2's perspective, because it is already in Client 2's queue. As such, Client 2's queue transfer should be tolerant of such modifications since they have no consequence to it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7088) Possible ConcurrentModificationException while client queue image is copied
[ https://issues.apache.org/jira/browse/GEODE-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-7088: --- Assignee: Ryan McMahon > Possible ConcurrentModificationException while client queue image is copied > --- > > Key: GEODE-7088 > URL: https://issues.apache.org/jira/browse/GEODE-7088 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > The following corner case scenario will result in a > ConcurrentModificationException which causes the queue image transfer to fail > and subsequently client registration to fail: > # Client 1 is currently opening a subscription endpoint with server 1 and > events are being staged in the client's temporary registration queue > # One or more of those events also match interest for Client 2 who is > already fully registered, so the event is put into Client 2's queue (in > addition to Client 1's temp queue) > # Client 2 asks server 2 to open a secondary subscription endpoint. Server > 2 attempts to copy Client 2's queue from server 1. This results in > serializing all of the events in Client 2's queue. > # While the image is being transferred, Client 1 finishes registration and > begins to drain its temporary registration queue. The filter info for each > event is recalculated which ends up mutating the shared event in Client 2's > queue. > # The event has some metadata stored as a non-concurrent set. Recalculating > the filter info for Client 1 will mutate that set, but the image transfer for > Client 2 is trying to copy that set simultaneously. This can result in a > ConcurrentModificationException because the set is not thread safe. Note > that there no danger in recalculating the filter from Client 2's perspective, > because it is already in Client 2's queue. As such, Client 2's queue > transfer should be tolerant of such modifications since they have no > consequence to it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7064) Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in Concourse
Ryan McMahon created GEODE-7064: --- Summary: Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in Concourse Key: GEODE-7064 URL: https://issues.apache.org/jira/browse/GEODE-7064 Project: Geode Issue Type: Improvement Components: ci Reporter: Ryan McMahon We have seen several timeouts in the execute_test task in UnitTestX jobs in the CI which were found to be resolved by experimenting with increasing the timeout. The community agreed we should increase the timeout from 10 to 20 minutes to handle intermittent degradation of the performance of this task, due to infrastructure issues or otherwise. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7064) Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in Concourse
[ https://issues.apache.org/jira/browse/GEODE-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-7064: --- Assignee: Ryan McMahon > Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in > Concourse > -- > > Key: GEODE-7064 > URL: https://issues.apache.org/jira/browse/GEODE-7064 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > We have seen several timeouts in the execute_test task in UnitTestX jobs in > the CI which were found to be resolved by experimenting with increasing the > timeout. The community agreed we should increase the timeout from 10 to 20 > minutes to handle intermittent degradation of the performance of this task, > due to infrastructure issues or otherwise. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7057) Add Per Test Timeout To JUnit Tests
Ryan McMahon created GEODE-7057: --- Summary: Add Per Test Timeout To JUnit Tests Key: GEODE-7057 URL: https://issues.apache.org/jira/browse/GEODE-7057 Project: Geode Issue Type: Improvement Components: tests Reporter: Ryan McMahon Currently if a test hangs in any of our Concourse test jobs (UnitTest*, DistributedTest*, etc), the Concourse job timeout will be reached but without any indication which test actually hung. It would be useful to explore if we can add a global test timeout which would fail the hanging test before the Concourse timeout is reached. This article has some suggestions on how to do this: [https://github.com/junit-team/junit4/wiki/timeout-for-tests] One suggestion is to use a JUnit rule. We would definitely want to avoid the need to add this annotation to every test class, but we might be able to get away with getting decent coverage by adding it to the test base classes (JUnit4DistributedTestCase, JUnit4CacheTestCase). Another suggestion is use a third party library which provides a global timeout like JUnit Foundation (link in above article). Regardless of implementation, the goal would be to timeout the test that is hanging and show the failure output in CI without hitting the Concourse job timeout. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7056) Update Geode version in native client CI
[ https://issues.apache.org/jira/browse/GEODE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-7056: Issue Type: Improvement (was: Wish) > Update Geode version in native client CI > > > Key: GEODE-7056 > URL: https://issues.apache.org/jira/browse/GEODE-7056 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Geode native client CI is using old Geode version (1.6.0) > It can be seen in logs: > -- Found Geode: /apache-geode-1.6.0/bin/gfsh (found suitable version "1.6.0", > minimum required is "1.0") -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7056) Update Geode version in native client CI
[ https://issues.apache.org/jira/browse/GEODE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-7056: Issue Type: Wish (was: Improvement) > Update Geode version in native client CI > > > Key: GEODE-7056 > URL: https://issues.apache.org/jira/browse/GEODE-7056 > Project: Geode > Issue Type: Wish > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Geode native client CI is using old Geode version (1.6.0) > It can be seen in logs: > -- Found Geode: /apache-geode-1.6.0/bin/gfsh (found suitable version "1.6.0", > minimum required is "1.0") -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6867:
Description:
This story outlines two major issues in the session state docs, but I think the
docs deserve a fairly comprehensive review to determine if there is any other
stale/incorrect information. The two issues are:
# Required jar list is missing some required jars
# Need to indicate that a locator MUST be available for peer-to-peer topology
More details on both issues below:
We should review the session state documentation for completeness/correctness.
When attempting to install and configure the Tomcat and AppServer session
modules by following the docs, I found that there were missing jars in the
[installation
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]
for Tomcat and [setting up
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]
for AppServer. Namely, I had to add these missing jars (as of 9.8, maybe
earlier).
* micrometer-core jar
* geode-commons jar
* geode-management jar
The first is a new jar added since this documentation was written, and I'm
assuming the code was restructured to require the other two jars as
dependencies. I'm not sure how we can ensure that this list is up to date.
Some of our system level tests for session state have to include the same list.
From TomcatInstall.java:
{code:java}
private static final String[] tomcatRequiredJars =
{"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
"geode-common",
"geode-core", "geode-management", "javax.transaction-api", "jgroups",
"log4j-api",
"log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
"jetty-util",
"jetty-http", "jetty-io"};{code}
And you can see that this list was updated to make the tests pass when
dependencies changed.
The other major issue I found while running through the steps is that you MUST
start a locator in the peer-to-peer topology for session state, because
multicast UDP discovery is not available/supported in Geode.
was:
This story outlines two major issues in the session state docs, but I think the
docs deserve a fairly comprehensive review to determine if there is any other
stale/incorrect information. The two issues are:
# Required jar list is missing some required jars
# Need to indicate that a locator MUST be available for peer-to-peer topology
More details on both issues below:
We should review the session state documentation for completeness/correctness.
When attempting to install and configure the Tomcat and AppServer session
modules by following the docs, I found that there were missing jars in the
[installation
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]
for Tomcat and [setting up
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html].
Namely, I had to add these missing jars (as of 9.8, maybe earlier).
* micrometer-core jar
* geode-commons jar
* geode-management jar
The first is a new jar added since this documentation was written, and I'm
assuming the code was restructured to require the other two jars as
dependencies. I'm not sure how we can ensure that this list is up to date.
Some of our system level tests for session state have to include the same list.
From TomcatInstall.java:
{code:java}
private static final String[] tomcatRequiredJars =
{"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
"geode-common",
"geode-core", "geode-management", "javax.transaction-api", "jgroups",
"log4j-api",
"log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
"jetty-util",
"jetty-http", "jetty-io"};{code}
And you can see that this list was updated to make the tests pass when
dependencies changed.
The other major issue I found while running through the steps is that you MUST
start a locator in the peer-to-peer topology for session state, because
multicast UDP discovery is not available/supported in Geode.
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs, http session
>Reporter: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
> other stale/incorrect information. The two issues are:
> # Required jar list is missing some
[jira] [Updated] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6867:
Description:
This story outlines two major issues in the session state docs, but I think the
docs deserve a fairly comprehensive review to determine if there is any other
stale/incorrect information. The two issues are:
# Required jar list is missing some required jars
# Need to indicate that a locator MUST be available for peer-to-peer topology
More details on both issues below:
We should review the session state documentation for completeness/correctness.
When attempting to install and configure the Tomcat and AppServer session
modules by following the docs, I found that there were missing jars in the
[installation
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]
for Tomcat and [setting up
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html].
Namely, I had to add these missing jars (as of 9.8, maybe earlier).
* micrometer-core jar
* geode-commons jar
* geode-management jar
The first is a new jar added since this documentation was written, and I'm
assuming the code was restructured to require the other two jars as
dependencies. I'm not sure how we can ensure that this list is up to date.
Some of our system level tests for session state have to include the same list.
From TomcatInstall.java:
{code:java}
private static final String[] tomcatRequiredJars =
{"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
"geode-common",
"geode-core", "geode-management", "javax.transaction-api", "jgroups",
"log4j-api",
"log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
"jetty-util",
"jetty-http", "jetty-io"};{code}
And you can see that this list was updated to make the tests pass when
dependencies changed.
The other major issue I found while running through the steps is that you MUST
start a locator in the peer-to-peer topology for session state, because
multicast UDP discovery is not available/supported in Geode.
was:
This story outlines two major issues in the session state docs, but I think the
docs deserve a fairly comprehensive review to determine if there is any other
stale/incorrect information. The two issues are:
# Required jar list is missing some required jars
# Need to indicate that a locator MUST be available for peer-to-peer topology
More details on both issues below:
We should review the session state documentation for completeness/correctness.
When attempting to install and configure the Tomcat and AppServer session
modules by following the docs, I found that there were missing jars in the
[installation
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]
for Tomcat and [setting up
section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_setting_up_the_module.html]].
Namely, I had to add these missing jars (as of 9.8, maybe earlier).
* micrometer-core jar
* geode-commons jar
* geode-management jar
The first is a new jar added since this documentation was written, and I'm
assuming the code was restructured to require the other two jars as
dependencies. I'm not sure how we can ensure that this list is up to date.
Some of our system level tests for session state have to include the same list.
From TomcatInstall.java:
{code:java}
private static final String[] tomcatRequiredJars =
{"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
"geode-common",
"geode-core", "geode-management", "javax.transaction-api", "jgroups",
"log4j-api",
"log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
"jetty-util",
"jetty-http", "jetty-io"};{code}
And you can see that this list was updated to make the tests pass when
dependencies changed.
The other major issue I found while running through the steps is that you MUST
start a locator in the peer-to-peer topology for session state, because
multicast UDP discovery is not available/supported in Geode.
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs, http session
>Reporter: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
> other
[jira] [Updated] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6867:
Description:
This story outlines two major issues in the session state docs, but I think the
docs deserve a fairly comprehensive review to determine if there is any other
stale/incorrect information. The two issues are:
# Required jar list is missing some required jars
# Need to indicate that a locator MUST be available for peer-to-peer topology
More details on both issues below:
We should review the session state documentation for completeness/correctness.
When attempting to install and configure the Tomcat and AppServer session
modules by following the docs, I found that there were missing jars in the
[installation
section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]
for Tomcat and [setting up
section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_setting_up_the_module.html]].
Namely, I had to add these missing jars (as of 9.8, maybe earlier).
* micrometer-core jar
* geode-commons jar
* geode-management jar
The first is a new jar added since this documentation was written, and I'm
assuming the code was restructured to require the other two jars as
dependencies. I'm not sure how we can ensure that this list is up to date.
Some of our system level tests for session state have to include the same list.
From TomcatInstall.java:
{code:java}
private static final String[] tomcatRequiredJars =
{"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
"geode-common",
"geode-core", "geode-management", "javax.transaction-api", "jgroups",
"log4j-api",
"log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
"jetty-util",
"jetty-http", "jetty-io"};{code}
And you can see that this list was updated to make the tests pass when
dependencies changed.
The other major issue I found while running through the steps is that you MUST
start a locator in the peer-to-peer topology for session state, because
multicast UDP discovery is not available/supported in Geode.
was:
This story outlines two major issues in the session state docs, but I think the
docs deserve a fairly comprehensive review to determine if there is any other
stale/incorrect information. The two issues are:
# Required jar list is missing some required jars
# Need to indicate that a locator MUST be available for peer-to-peer topology
More details on both issues below:
We should review the session state documentation for completeness/correctness.
When attempting to install and configure the Tomcat and AppServer session
modules by following the docs, I found that there were missing jars in the
[installation
section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]]
for Tomcat and [setting up
section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]].
Namely, I had to add these missing jars (as of 9.8, maybe earlier).
* micrometer-core jar
* geode-commons jar
* geode-management jar
The first is a new jar added since this documentation was written, and I'm
assuming the code was restructured to require the other two jars as
dependencies. I'm not sure how we can ensure that this list is up to date.
Some of our system level tests for session state have to include the same list.
From TomcatInstall.java:
{code:java}
private static final String[] tomcatRequiredJars =
{"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
"geode-common",
"geode-core", "geode-management", "javax.transaction-api", "jgroups",
"log4j-api",
"log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
"jetty-util",
"jetty-http", "jetty-io"};{code}
And you can see that this list was updated to make the tests pass when
dependencies changed.
The other major issue I found while running through the steps is that you MUST
start a locator in the peer-to-peer topology for session state, because
multicast UDP discovery is not available/supported in Geode.
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs, http session
>Reporter: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
>
[jira] [Closed] (GEODE-7015) Servers will hang if move bucket fails during rebalance due to force disconnect with recreated persistent partitioned regions
[ https://issues.apache.org/jira/browse/GEODE-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-7015. --- > Servers will hang if move bucket fails during rebalance due to force > disconnect with recreated persistent partitioned regions > - > > Key: GEODE-7015 > URL: https://issues.apache.org/jira/browse/GEODE-7015 > Project: Geode > Issue Type: Improvement > Components: persistence, regions >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > * Start one server and create a persistent partitioned region on each and > redundancy 0 > * Add data to the region > * Start another server and create the same region with redundancy 0 > * Recycle the servers (close cache/recreate the persistent partitioned > region) > * Perform a rebalance and while server 2 requests bucket images from server > 1, cause that member to force disconnect (we have some hooks to do this in > our test) > * When the forced disconnect member rejoins (auto-reconnect is enabled by > default), both servers will be hung because they think the other has the > latest data -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7015) Servers will hang if move bucket fails during rebalance due to force disconnect with recreated persistent partitioned regions
[ https://issues.apache.org/jira/browse/GEODE-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-7015. - Resolution: Fixed Fix Version/s: 1.10.0 > Servers will hang if move bucket fails during rebalance due to force > disconnect with recreated persistent partitioned regions > - > > Key: GEODE-7015 > URL: https://issues.apache.org/jira/browse/GEODE-7015 > Project: Geode > Issue Type: Improvement > Components: persistence, regions >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > * Start one server and create a persistent partitioned region on each and > redundancy 0 > * Add data to the region > * Start another server and create the same region with redundancy 0 > * Recycle the servers (close cache/recreate the persistent partitioned > region) > * Perform a rebalance and while server 2 requests bucket images from server > 1, cause that member to force disconnect (we have some hooks to do this in > our test) > * When the forced disconnect member rejoins (auto-reconnect is enabled by > default), both servers will be hung because they think the other has the > latest data -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7015) Servers will hang if move bucket fails during rebalance due to force disconnect with recreated persistent partitioned regions
[ https://issues.apache.org/jira/browse/GEODE-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-7015: --- Assignee: Ryan McMahon > Servers will hang if move bucket fails during rebalance due to force > disconnect with recreated persistent partitioned regions > - > > Key: GEODE-7015 > URL: https://issues.apache.org/jira/browse/GEODE-7015 > Project: Geode > Issue Type: Improvement > Components: persistence, regions >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > * Start one server and create a persistent partitioned region on each and > redundancy 0 > * Add data to the region > * Start another server and create the same region with redundancy 0 > * Recycle the servers (close cache/recreate the persistent partitioned > region) > * Perform a rebalance and while server 2 requests bucket images from server > 1, cause that member to force disconnect (we have some hooks to do this in > our test) > * When the forced disconnect member rejoins (auto-reconnect is enabled by > default), both servers will be hung because they think the other has the > latest data -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7030) PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() may fail because flusher thread throws exception
[ https://issues.apache.org/jira/browse/GEODE-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-7030: Labels: GeodeCommons (was: ) > PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() > may fail because flusher thread throws exception > - > > Key: GEODE-7030 > URL: https://issues.apache.org/jira/browse/GEODE-7030 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In this test we expect a CacheClosedException with cause > ConflictingPersistentDataException to be thrown during recovery, but it is > possible for the async flush thread to see the problem first, in which case > the exception will be a CacheClosedException caused by a nested > CacheClosedException caused by ConflictingPersistentDataException. This > causes the test to fail due to our assertions on the exception types. See > the following failure in the PR pipeline: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/3377] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (GEODE-7029) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test can fail if loopback address is returned by INetAddress.getLocalHost()
[ https://issues.apache.org/jira/browse/GEODE-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-7029. --- > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can fail if loopback address is returned by INetAddress.getLocalHost() > - > > Key: GEODE-7029 > URL: https://issues.apache.org/jira/browse/GEODE-7029 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > > It is possible that the INetAddress.getLocalHost() calls in the > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can return the loopback address depending on which network interfaces > are available and the test machines /etc/hosts configuration. This causes > the test to fail because the persistent member revoke pattern won't match and > therefore the expected RevokeFailedException is not thrown. We should make > the logic more robust so that the test isn't as dependent on environment. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7030) PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() may fail because flusher thread throws exception
[ https://issues.apache.org/jira/browse/GEODE-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-7030. - Resolution: Fixed Fix Version/s: 1.10.0 > PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() > may fail because flusher thread throws exception > - > > Key: GEODE-7030 > URL: https://issues.apache.org/jira/browse/GEODE-7030 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In this test we expect a CacheClosedException with cause > ConflictingPersistentDataException to be thrown during recovery, but it is > possible for the async flush thread to see the problem first, in which case > the exception will be a CacheClosedException caused by a nested > CacheClosedException caused by ConflictingPersistentDataException. This > causes the test to fail due to our assertions on the exception types. See > the following failure in the PR pipeline: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/3377] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7029) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test can fail if loopback address is returned by INetAddress.getLocalHost()
[ https://issues.apache.org/jira/browse/GEODE-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-7029. - Resolution: Fixed Fix Version/s: 1.10.0 > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can fail if loopback address is returned by INetAddress.getLocalHost() > - > > Key: GEODE-7029 > URL: https://issues.apache.org/jira/browse/GEODE-7029 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 40m > Remaining Estimate: 0h > > It is possible that the INetAddress.getLocalHost() calls in the > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can return the loopback address depending on which network interfaces > are available and the test machines /etc/hosts configuration. This causes > the test to fail because the persistent member revoke pattern won't match and > therefore the expected RevokeFailedException is not thrown. We should make > the logic more robust so that the test isn't as dependent on environment. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (GEODE-7030) PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() may fail because flusher thread throws exception
[ https://issues.apache.org/jira/browse/GEODE-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-7030. --- > PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() > may fail because flusher thread throws exception > - > > Key: GEODE-7030 > URL: https://issues.apache.org/jira/browse/GEODE-7030 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In this test we expect a CacheClosedException with cause > ConflictingPersistentDataException to be thrown during recovery, but it is > possible for the async flush thread to see the problem first, in which case > the exception will be a CacheClosedException caused by a nested > CacheClosedException caused by ConflictingPersistentDataException. This > causes the test to fail due to our assertions on the exception types. See > the following failure in the PR pipeline: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/3377] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7030) PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() may fail because flusher thread throws exception
[ https://issues.apache.org/jira/browse/GEODE-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-7030: --- Assignee: Ryan McMahon > PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() > may fail because flusher thread throws exception > - > > Key: GEODE-7030 > URL: https://issues.apache.org/jira/browse/GEODE-7030 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > In this test we expect a CacheClosedException with cause > ConflictingPersistentDataException to be thrown during recovery, but it is > possible for the async flush thread to see the problem first, in which case > the exception will be a CacheClosedException caused by a nested > CacheClosedException caused by ConflictingPersistentDataException. This > causes the test to fail due to our assertions on the exception types. See > the following failure in the PR pipeline: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/3377] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7029) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test can fail if loopback address is returned by INetAddress.getLocalHost()
[ https://issues.apache.org/jira/browse/GEODE-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-7029: --- Assignee: Ryan McMahon > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can fail if loopback address is returned by INetAddress.getLocalHost() > - > > Key: GEODE-7029 > URL: https://issues.apache.org/jira/browse/GEODE-7029 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: GeodeCommons > Time Spent: 10m > Remaining Estimate: 0h > > It is possible that the INetAddress.getLocalHost() calls in the > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can return the loopback address depending on which network interfaces > are available and the test machines /etc/hosts configuration. This causes > the test to fail because the persistent member revoke pattern won't match and > therefore the expected RevokeFailedException is not thrown. We should make > the logic more robust so that the test isn't as dependent on environment. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7030) PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() may fail because flusher thread throws exception
Ryan McMahon created GEODE-7030: --- Summary: PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() may fail because flusher thread throws exception Key: GEODE-7030 URL: https://issues.apache.org/jira/browse/GEODE-7030 Project: Geode Issue Type: Bug Components: tests Reporter: Ryan McMahon In this test we expect a CacheClosedException with cause ConflictingPersistentDataException to be thrown during recovery, but it is possible for the async flush thread to see the problem first, in which case the exception will be a CacheClosedException caused by a nested CacheClosedException caused by ConflictingPersistentDataException. This causes the test to fail due to our assertions on the exception types. See the following failure in the PR pipeline: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/3377] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7029) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test can fail if loopback address is returned by INetAddress.getLocalHost()
[ https://issues.apache.org/jira/browse/GEODE-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-7029: Labels: GeodeCommons (was: ) > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can fail if loopback address is returned by INetAddress.getLocalHost() > - > > Key: GEODE-7029 > URL: https://issues.apache.org/jira/browse/GEODE-7029 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Ryan McMahon >Priority: Major > Labels: GeodeCommons > > It is possible that the INetAddress.getLocalHost() calls in the > PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() > test can return the loopback address depending on which network interfaces > are available and the test machines /etc/hosts configuration. This causes > the test to fail because the persistent member revoke pattern won't match and > therefore the expected RevokeFailedException is not thrown. We should make > the logic more robust so that the test isn't as dependent on environment. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7029) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test can fail if loopback address is returned by INetAddress.getLocalHost()
Ryan McMahon created GEODE-7029: --- Summary: PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test can fail if loopback address is returned by INetAddress.getLocalHost() Key: GEODE-7029 URL: https://issues.apache.org/jira/browse/GEODE-7029 Project: Geode Issue Type: Bug Components: tests Reporter: Ryan McMahon It is possible that the INetAddress.getLocalHost() calls in the PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test can return the loopback address depending on which network interfaces are available and the test machines /etc/hosts configuration. This causes the test to fail because the persistent member revoke pattern won't match and therefore the expected RevokeFailedException is not thrown. We should make the logic more robust so that the test isn't as dependent on environment. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7021) Revisit state management in BucketAdvisor
Ryan McMahon created GEODE-7021: --- Summary: Revisit state management in BucketAdvisor Key: GEODE-7021 URL: https://issues.apache.org/jira/browse/GEODE-7021 Project: Geode Issue Type: Improvement Components: regions Reporter: Ryan McMahon The bucket hosting state management in BucketAdvisor amounts to a large and complex switch statement. We should determine if this could be simplified and made more readable by using some form of State pattern/finite state machine. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7020) Refactor GII requesting code to isolate responsibilities
Ryan McMahon created GEODE-7020: --- Summary: Refactor GII requesting code to isolate responsibilities Key: GEODE-7020 URL: https://issues.apache.org/jira/browse/GEODE-7020 Project: Geode Issue Type: Improvement Components: regions Reporter: Ryan McMahon The GII requesting code in InitialImageOperation could benefit from being refactored into single-responsibility methods to make it more readable. For instance, getFromOne is nearly 400 lines long and does many things. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7015) Servers will hang if move bucket fails during rebalance due to force disconnect with recreated persistent partitioned regions
Ryan McMahon created GEODE-7015: --- Summary: Servers will hang if move bucket fails during rebalance due to force disconnect with recreated persistent partitioned regions Key: GEODE-7015 URL: https://issues.apache.org/jira/browse/GEODE-7015 Project: Geode Issue Type: Improvement Components: persistence, regions Reporter: Ryan McMahon * Start one server and create a persistent partitioned region on each and redundancy 0 * Add data to the region * Start another server and create the same region with redundancy 0 * Recycle the servers (close cache/recreate the persistent partitioned region) * Perform a rebalance and while server 2 requests bucket images from server 1, cause that member to force disconnect (we have some hooks to do this in our test) * When the forced disconnect member rejoins (auto-reconnect is enabled by default), both servers will be hung because they think the other has the latest data -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6864) Epic For Session State Caching
[ https://issues.apache.org/jira/browse/GEODE-6864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6864: Labels: GeodeCommons (was: ) > Epic For Session State Caching > -- > > Key: GEODE-6864 > URL: https://issues.apache.org/jira/browse/GEODE-6864 > Project: Geode > Issue Type: Improvement >Reporter: Charlie Black >Priority: Major > Labels: GeodeCommons > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6881) Revisit design for non-sticky sessions in client/server topology for Tomcat session module
[ https://issues.apache.org/jira/browse/GEODE-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6881: Description: In order to use non-sticky sessions, a user must set enableLocalCache false and they should also set the (undocumented) flag gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK to true. The former flag sets the region type to PROXY on the client (no local caching) so that all operations must go to the server. This avoids dealing with asynchronous behavior resulting from local caching (event replication to local caches is performed through asynchronous client queues). It also causes the client to register interest in all keys so it gets notified of expiration/session invalidation events. The latter flag forces the server to add some additional "context" to the event which is forwarded to the client when an expiration/session invalidation occurs. That context is used to retrieve the actual session object and call session.expire(). This logic can easily be found by tracing usages of the flag in the code. It would be better if we could avoid setting this flag on the server, and instead indicate that we need this additional "context" when we register interest with the server. This may already be possible or it may require adding new API around interest registration to request the additional context. That way the customer does not need to remember to set this server flag. We might generally just want to be able to register interest in specific event types, such as EXPIRE_DESTROY in this case. If the above is not possible and we still need the second flag, we should at a minimum add it to the documentation so we ensure session.expire() is always called on the client. If this flag is not set, then session.expire() will not be called which may result in listeners not getting fired or resources not getting cleaned up. was: In order to use non-sticky sessions, a user must set enableLocalCache false and they should also set the (undocumented) flag gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK to true. The former flag sets the region type to PROXY on the client (no local caching) so that all operations must go to the server. This avoids dealing with asynchronous behavior resulting from local caching (event replication to local caches is performed through asynchronous client queues). It also causes the client to register interest in all keys so it gets notified of expiration/session invalidation events. The latter flag forces the server to add some additional "context" to the event which is forwarded to the client when an expiration/session invalidation occurs. That context is used to retrieve the actual session object and call session.expire(). This logic can easily be found by tracing usages of the flag in the code. It would be better if we could avoid setting this flag on the server, and instead indicate that we need this additional "context" when we register interest with the server. This may already be possible or it may require adding new API around interest registration to request the additional context. That way the customer does not need to remember to set this server flag. If the above is not possible and we still need the second flag, we should at a minimum add it to the documentation so we ensure session.expire() is always called on the client. If this flag is not set, then session.expire() will not be called which may result in listeners not getting fired or resources not getting cleaned up. > Revisit design for non-sticky sessions in client/server topology for Tomcat > session module > -- > > Key: GEODE-6881 > URL: https://issues.apache.org/jira/browse/GEODE-6881 > Project: Geode > Issue Type: Improvement > Components: http session >Reporter: Ryan McMahon >Priority: Major > > In order to use non-sticky sessions, a user must set enableLocalCache false > and they should also set the (undocumented) flag > gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK to true. The former flag sets the > region type to PROXY on the client (no local caching) so that all operations > must go to the server. This avoids dealing with asynchronous behavior > resulting from local caching (event replication to local caches is performed > through asynchronous client queues). It also causes the client to register > interest in all keys so it gets notified of expiration/session invalidation > events. > The latter flag forces the server to add some additional "context" to the > event which is forwarded to the client when an expiration/session > invalidation occurs. That context is used to retrieve the actual session > object and call session.expire(). This logic can easily be found by tracing >
[jira] [Created] (GEODE-6881) Revisit design for non-sticky sessions in client/server topology for Tomcat session module
Ryan McMahon created GEODE-6881: --- Summary: Revisit design for non-sticky sessions in client/server topology for Tomcat session module Key: GEODE-6881 URL: https://issues.apache.org/jira/browse/GEODE-6881 Project: Geode Issue Type: Improvement Components: http session Reporter: Ryan McMahon In order to use non-sticky sessions, a user must set enableLocalCache false and they should also set the (undocumented) flag gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK to true. The former flag sets the region type to PROXY on the client (no local caching) so that all operations must go to the server. This avoids dealing with asynchronous behavior resulting from local caching (event replication to local caches is performed through asynchronous client queues). It also causes the client to register interest in all keys so it gets notified of expiration/session invalidation events. The latter flag forces the server to add some additional "context" to the event which is forwarded to the client when an expiration/session invalidation occurs. That context is used to retrieve the actual session object and call session.expire(). This logic can easily be found by tracing usages of the flag in the code. It would be better if we could avoid setting this flag on the server, and instead indicate that we need this additional "context" when we register interest with the server. This may already be possible or it may require adding new API around interest registration to request the additional context. That way the customer does not need to remember to set this server flag. If the above is not possible and we still need the second flag, we should at a minimum add it to the documentation so we ensure session.expire() is always called on the client. If this flag is not set, then session.expire() will not be called which may result in listeners not getting fired or resources not getting cleaned up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6880) Delete ModuleStatistics class and any related classes/documentation
Ryan McMahon created GEODE-6880: --- Summary: Delete ModuleStatistics class and any related classes/documentation Key: GEODE-6880 URL: https://issues.apache.org/jira/browse/GEODE-6880 Project: Geode Issue Type: Improvement Components: http session Reporter: Ryan McMahon The ModuleStatistics class is completely unused and should be deleted. Any documentation around it should also be deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6879) Remove our implementation of Tomcat LifecycleListener if possible
Ryan McMahon created GEODE-6879: --- Summary: Remove our implementation of Tomcat LifecycleListener if possible Key: GEODE-6879 URL: https://issues.apache.org/jira/browse/GEODE-6879 Project: Geode Issue Type: Improvement Components: http session Reporter: Ryan McMahon Our implementations of the Tomcat LifecycleListener are completely unused outside of testing as far as I can tell. Determine if these tests can eliminate this usage so we can delete our LifecycleListener implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6878) Remove documentation around enableLocalCache for Tomcat session peer-to-peer topology
Ryan McMahon created GEODE-6878:
---
Summary: Remove documentation around enableLocalCache for Tomcat
session peer-to-peer topology
Key: GEODE-6878
URL: https://issues.apache.org/jira/browse/GEODE-6878
Project: Geode
Issue Type: Improvement
Components: docs, http session
Reporter: Ryan McMahon
There isn't any use case for enabling local caching in a peer-to-peer topology
when using the Tomcat session state module, because the session region type is
REPLICATE so an additional local ("fronting") region adds no benefit. At one
time the peer-to-peer session region type was not REPLICATE so a local region
could have added performance benefits, but this is no longer the case. As
such, we should remove any documentation around enableLocalCache JUST for
peer-to-peer topology. The documentation for client-server should remain.
{code:java}
Default: false for peer-to-peer, true for client/server
The GemFire API equivalent to setting this parameter:
// For peer-to-peer members: Cache.createRegionFactory(REPLICATE_PROXY); // For
client members: ClientCache.createClientRegionFactory(CACHING_PROXY_HEAP_LRU);
{code}
should become something like:
{code:java}
enableLocalCache is only useful in a client/server topology. Local caching is
enabled by default in this topology.
The GemFire API equivalent to setting this parameter:
ClientCache.createClientRegionFactory(CACHING_PROXY_HEAP_LRU);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6877) Delete code related to Gateway Delta Replication in Tomcat session state module
Ryan McMahon created GEODE-6877:
---
Summary: Delete code related to Gateway Delta Replication in
Tomcat session state module
Key: GEODE-6877
URL: https://issues.apache.org/jira/browse/GEODE-6877
Project: Geode
Issue Type: Improvement
Components: http session
Reporter: Ryan McMahon
There is a partially implemented feature for replicating session state over
WAN, but it is currently hard coded to be disabled. From DeltaSessionManager:
{code:java}
@Override
public boolean getEnableGatewayDeltaReplication() {
// return this.enableGatewayDeltaReplication;
return false; // disabled
}
{code}
There is a lot of code to support this feature which is not used (because of
the above hard coding) and also not well tested. It seems whatever use case
that was driving this feature is no longer high priority, because this feature
was never totally finished and documented. As such, we should remove all the
code related to this unfinished feature to avoid clutter. This will result in
deletion of a lot of code in the Tomcat session state core classes, as well as
the code in the gatewaydelta package. The exact code which can be deleted can
be determined by tracing the usages of the configuration and supporting classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6876) Replace CreateRegionFunction with existing RegionCreateFunction (gfsh) in Tomcat session state module
Ryan McMahon created GEODE-6876: --- Summary: Replace CreateRegionFunction with existing RegionCreateFunction (gfsh) in Tomcat session state module Key: GEODE-6876 URL: https://issues.apache.org/jira/browse/GEODE-6876 Project: Geode Issue Type: Improvement Components: http session Reporter: Ryan McMahon The Tomcat session state module uses a custom function for creating the session region on the server (CreateRegionFunction). After reviewing that code, it appears that this could be replaced with the region creation function/logic used by gfsh (RegionCreateFunction). The RegionCreateFunction is better tested and reusing it means less duplication. The Redis adapter already does something similar; it uses the CreateRegionCommand gfsh object which in turn calls the RegionCreateFunction. That code may serve as a reference. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6875) Remove unused code and deprecated/internal API usages in Tomcat session state module
Ryan McMahon created GEODE-6875: --- Summary: Remove unused code and deprecated/internal API usages in Tomcat session state module Key: GEODE-6875 URL: https://issues.apache.org/jira/browse/GEODE-6875 Project: Geode Issue Type: Improvement Components: http session Reporter: Ryan McMahon The Tomcat session state module has significant amounts of dead code as well as deprecated/internal API usages. We should make a pass through and clean this up. These reports can also be generated via IntelliJ's built-in report tooling if it is more convenient. - Go through the following report and delete all fully unused code [https://drive.google.com/open?id=1W1bbKw2JE7CvcDajE9MyQhpCTSR_IeGw] - Go through the following report and replace deprecated API usage with correct API: [https://drive.google.com/open?id=1b7RvM9Dbf85HsFLqVF7r5xYTEn5PbHOm|https://drive.google.com/drive/folders/1b7RvM9Dbf85HsFLqVF7r5xYTEn5PbHOm?usp=sharing] - Identify areas we use internal Geode APIs and remove the usages if possible, or determine why we cannot use them [https://docs.google.com/document/d/1pvYIj0yvjy6xqRPzLEqE_Mp4t8Lj5yK45DbAoup-QZg/edit?usp=sharing] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6867:
Labels: (was: GeodeCommons)
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Ryan McMahon
>Priority: Major
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
> other stale/incorrect information. The two issues are:
> # Required jar list is missing some required jars
> # Need to indicate that a locator MUST be available for peer-to-peer topology
> More details on both issues below:
> We should review the session state documentation for
> completeness/correctness. When attempting to install and configure the
> Tomcat and AppServer session modules by following the docs, I found that
> there were missing jars in the [installation
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]]
> for Tomcat and [setting up
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]].
> Namely, I had to add these missing jars (as of 9.8, maybe earlier).
> * micrometer-core jar
> * geode-commons jar
> * geode-management jar
> The first is a new jar added since this documentation was written, and I'm
> assuming the code was restructured to require the other two jars as
> dependencies. I'm not sure how we can ensure that this list is up to date.
> Some of our system level tests for session state have to include the same
> list. From TomcatInstall.java:
> {code:java}
> private static final String[] tomcatRequiredJars =
> {"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
> "geode-common",
> "geode-core", "geode-management", "javax.transaction-api", "jgroups",
> "log4j-api",
> "log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
> "jetty-util",
> "jetty-http", "jetty-io"};{code}
> And you can see that this list was updated to make the tests pass when
> dependencies changed.
> The other major issue I found while running through the steps is that you
> MUST start a locator in the peer-to-peer topology for session state, because
> multicast UDP discovery is not available/supported in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6872) Add section with more details about sticky vs non-sticky sessions for Tomcat Session Module
[ https://issues.apache.org/jira/browse/GEODE-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6872: Component/s: http session > Add section with more details about sticky vs non-sticky sessions for Tomcat > Session Module > --- > > Key: GEODE-6872 > URL: https://issues.apache.org/jira/browse/GEODE-6872 > Project: Geode > Issue Type: Bug > Components: docs, http session >Reporter: Ryan McMahon >Priority: Major > > Sticky vs non-sticky sessions and the recommended configurations should be > discussed in better detail the docs (it is not discussed at all for Tomcat > module). If the user configured client-server topology with non-sticky > sessions, we do NOT recommend enableLocalCaching be set because it results in > unpredictable asynchronous behavior/replication. > If they follow our recommendations and disable local caching (proxy-only > client), then they should also set `gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK`. > Otherwise the expire logic will not be called on the client. The side effects > of this may be benign, but if there are any listeners depending on that > expiration logic, it may result in bugs or a resource leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6867:
Component/s: http session
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs, http session
>Reporter: Ryan McMahon
>Priority: Major
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
> other stale/incorrect information. The two issues are:
> # Required jar list is missing some required jars
> # Need to indicate that a locator MUST be available for peer-to-peer topology
> More details on both issues below:
> We should review the session state documentation for
> completeness/correctness. When attempting to install and configure the
> Tomcat and AppServer session modules by following the docs, I found that
> there were missing jars in the [installation
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]]
> for Tomcat and [setting up
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]].
> Namely, I had to add these missing jars (as of 9.8, maybe earlier).
> * micrometer-core jar
> * geode-commons jar
> * geode-management jar
> The first is a new jar added since this documentation was written, and I'm
> assuming the code was restructured to require the other two jars as
> dependencies. I'm not sure how we can ensure that this list is up to date.
> Some of our system level tests for session state have to include the same
> list. From TomcatInstall.java:
> {code:java}
> private static final String[] tomcatRequiredJars =
> {"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
> "geode-common",
> "geode-core", "geode-management", "javax.transaction-api", "jgroups",
> "log4j-api",
> "log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
> "jetty-util",
> "jetty-http", "jetty-io"};{code}
> And you can see that this list was updated to make the tests pass when
> dependencies changed.
> The other major issue I found while running through the steps is that you
> MUST start a locator in the peer-to-peer topology for session state, because
> multicast UDP discovery is not available/supported in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6873) Add Tomcat session state module example to geode-examples
[ https://issues.apache.org/jira/browse/GEODE-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6873: Component/s: http session > Add Tomcat session state module example to geode-examples > - > > Key: GEODE-6873 > URL: https://issues.apache.org/jira/browse/GEODE-6873 > Project: Geode > Issue Type: Improvement > Components: examples, http session >Reporter: Ryan McMahon >Priority: Major > > We don't have any fully working examples of our Tomcat session state module > in the context of a simple sample web application. It would be helpful for > new users to pull down some code to reference when setting up their > applications to use the module. > According to > [this|[https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html]], > you can use Tomcat as an embedded web server for Spring Boot, so maybe a > simple Spring Boot application would suffice. Whether geode-examples is the > right repository is another thing to consider, since our other examples just > exercise plain Geode features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6874) Improve test coverage for Tomcat session state module
Ryan McMahon created GEODE-6874: --- Summary: Improve test coverage for Tomcat session state module Key: GEODE-6874 URL: https://issues.apache.org/jira/browse/GEODE-6874 Project: Geode Issue Type: Improvement Components: http session, tests Reporter: Ryan McMahon Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit, integration and DUnit tests. Write unit and/or integration tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6873) Add Tomcat session state module example to geode-examples
Ryan McMahon created GEODE-6873: --- Summary: Add Tomcat session state module example to geode-examples Key: GEODE-6873 URL: https://issues.apache.org/jira/browse/GEODE-6873 Project: Geode Issue Type: Improvement Components: examples Reporter: Ryan McMahon We don't have any fully working examples of our Tomcat session state module in the context of a simple sample web application. It would be helpful for new users to pull down some code to reference when setting up their applications to use the module. According to [this|[https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html]], you can use Tomcat as an embedded web server for Spring Boot, so maybe a simple Spring Boot application would suffice. Whether geode-examples is the right repository is another thing to consider, since our other examples just exercise plain Geode features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6872) Add section with more details about sticky vs non-sticky sessions for Tomcat Session Module
Ryan McMahon created GEODE-6872: --- Summary: Add section with more details about sticky vs non-sticky sessions for Tomcat Session Module Key: GEODE-6872 URL: https://issues.apache.org/jira/browse/GEODE-6872 Project: Geode Issue Type: Bug Components: docs Reporter: Ryan McMahon Sticky vs non-sticky sessions and the recommended configurations should be discussed in better detail the docs (it is not discussed at all for Tomcat module). If the user configured client-server topology with non-sticky sessions, we do NOT recommend enableLocalCaching be set because it results in unpredictable asynchronous behavior/replication. If they follow our recommendations and disable local caching (proxy-only client), then they should also set `gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK`. Otherwise the expire logic will not be called on the client. The side effects of this may be benign, but if there are any listeners depending on that expiration logic, it may result in bugs or a resource leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6867:
Labels: GeodeCommons (was: )
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
> other stale/incorrect information. The two issues are:
> # Required jar list is missing some required jars
> # Need to indicate that a locator MUST be available for peer-to-peer topology
> More details on both issues below:
> We should review the session state documentation for
> completeness/correctness. When attempting to install and configure the
> Tomcat and AppServer session modules by following the docs, I found that
> there were missing jars in the [installation
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]]
> for Tomcat and [setting up
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]].
> Namely, I had to add these missing jars (as of 9.8, maybe earlier).
> * micrometer-core jar
> * geode-commons jar
> * geode-management jar
> The first is a new jar added since this documentation was written, and I'm
> assuming the code was restructured to require the other two jars as
> dependencies. I'm not sure how we can ensure that this list is up to date.
> Some of our system level tests for session state have to include the same
> list. From TomcatInstall.java:
> {code:java}
> private static final String[] tomcatRequiredJars =
> {"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
> "geode-common",
> "geode-core", "geode-management", "javax.transaction-api", "jgroups",
> "log4j-api",
> "log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
> "jetty-util",
> "jetty-http", "jetty-io"};{code}
> And you can see that this list was updated to make the tests pass when
> dependencies changed.
> The other major issue I found while running through the steps is that you
> MUST start a locator in the peer-to-peer topology for session state, because
> multicast UDP discovery is not available/supported in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-6865) First step in task
[ https://issues.apache.org/jira/browse/GEODE-6865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-6865. --- > First step in task > -- > > Key: GEODE-6865 > URL: https://issues.apache.org/jira/browse/GEODE-6865 > Project: Geode > Issue Type: Sub-task >Reporter: Charlie Black >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6865) First step in task
[ https://issues.apache.org/jira/browse/GEODE-6865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6865. - Resolution: Duplicate > First step in task > -- > > Key: GEODE-6865 > URL: https://issues.apache.org/jira/browse/GEODE-6865 > Project: Geode > Issue Type: Sub-task >Reporter: Charlie Black >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6867) Fix documentation for session state caching
Ryan McMahon created GEODE-6867:
---
Summary: Fix documentation for session state caching
Key: GEODE-6867
URL: https://issues.apache.org/jira/browse/GEODE-6867
Project: Geode
Issue Type: Bug
Components: docs
Reporter: Ryan McMahon
This story outlines two major issues in the session state docs, but I think the
docs deserve a fairly comprehensive review to determine if there is any other
stale/incorrect information. The two issues are:
# Required jar list is missing some required jars
# Need to indicate that a locator MUST be available for peer-to-peer topology
More details on both issues below:
We should review the session state documentation for completeness/correctness.
When attempting to install and configure the Tomcat and AppServer session
modules by following the docs, I found that there were missing jars in the
[installation
section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]]
for Tomcat and [setting up
section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]].
Namely, I had to add these missing jars (as of 9.8, maybe earlier).
* micrometer-core jar
* geode-commons jar
* geode-management jar
The first is a new jar added since this documentation was written, and I'm
assuming the code was restructured to require the other two jars as
dependencies. I'm not sure how we can ensure that this list is up to date.
Some of our system level tests for session state have to include the same list.
From TomcatInstall.java:
{code:java}
private static final String[] tomcatRequiredJars =
{"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
"geode-common",
"geode-core", "geode-management", "javax.transaction-api", "jgroups",
"log4j-api",
"log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
"jetty-util",
"jetty-http", "jetty-io"};{code}
And you can see that this list was updated to make the tests pass when
dependencies changed.
The other major issue I found while running through the steps is that you MUST
start a locator in the peer-to-peer topology for session state, because
multicast UDP discovery is not available/supported in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GEODE-6864) Epic For Session State Caching
[ https://issues.apache.org/jira/browse/GEODE-6864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reopened GEODE-6864: - > Epic For Session State Caching > -- > > Key: GEODE-6864 > URL: https://issues.apache.org/jira/browse/GEODE-6864 > Project: Geode > Issue Type: Improvement >Reporter: Charlie Black >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6845) Make logging consistent across putInProgress() calls in HAEventWrapper
[ https://issues.apache.org/jira/browse/GEODE-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6845. - Resolution: Fixed Fix Version/s: 1.10.0 > Make logging consistent across putInProgress() calls in HAEventWrapper > -- > > Key: GEODE-6845 > URL: https://issues.apache.org/jira/browse/GEODE-6845 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In some cases we logged when we incremented the putInProgress counter on an > HAEventWrapper while in others we do not, so we should probably be consistent > with logging and also indicate where the call is being made from (initial > put, GII queue, client registration). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-6845) Make logging consistent across putInProgress() calls in HAEventWrapper
[ https://issues.apache.org/jira/browse/GEODE-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-6845. --- > Make logging consistent across putInProgress() calls in HAEventWrapper > -- > > Key: GEODE-6845 > URL: https://issues.apache.org/jira/browse/GEODE-6845 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In some cases we logged when we incremented the putInProgress counter on an > HAEventWrapper while in others we do not, so we should probably be consistent > with logging and also indicate where the call is being made from (initial > put, GII queue, client registration). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6842. - Resolution: Fixed Fix Version/s: 1.10.0 > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-6842. --- > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6797) Possibility for missing dependencies in session state modules
[
https://issues.apache.org/jira/browse/GEODE-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon resolved GEODE-6797.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> Possibility for missing dependencies in session state modules
> -
>
> Key: GEODE-6797
> URL: https://issues.apache.org/jira/browse/GEODE-6797
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It was found that the AppServer module in Geode 1.9.0 release package is
> missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
> due to the way we are zipping the module and specifying its dependencies in
> Gradle.
> From Dan Smith:
>
> {noformat}
> The basic issue is that this task includes the module jar in the zip in weird
> way, but doesn't declare the jar task as a dependency (in
> geode-modules-assembly/build.gradle):
> task distAppServer(type: Zip, dependsOn:
> [':extensions:geode-modules-session:jar',
> ':extensions:geode-modules-session-internal:jar',
> ':extensions:geode-modules-tomcat7:jar',
> ':extensions:geode-modules-tomcat8:jar',
> ':extensions:geode-modules-tomcat9:jar']) {
> baseName = moduleBaseName
> classifier = "AppServer"
> into('lib') {
> from getJarArtifact(':extensions:geode-modules-session')
> from getJarArtifact(':extensions:geode-modules-session-internal')
> from getJarArtifact(':extensions:geode-modules')
> from configurations.slf4jDeps
> }
> So I think it's somewhat indeterminant if any given build contains that jar
> in the zip. If we run the distributedTest on that particular build, we would
> catch the issue, but that's not how our build works (at least for geode
> releases).
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-6797) Possibility for missing dependencies in session state modules
[
https://issues.apache.org/jira/browse/GEODE-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon closed GEODE-6797.
---
> Possibility for missing dependencies in session state modules
> -
>
> Key: GEODE-6797
> URL: https://issues.apache.org/jira/browse/GEODE-6797
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> It was found that the AppServer module in Geode 1.9.0 release package is
> missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
> due to the way we are zipping the module and specifying its dependencies in
> Gradle.
> From Dan Smith:
>
> {noformat}
> The basic issue is that this task includes the module jar in the zip in weird
> way, but doesn't declare the jar task as a dependency (in
> geode-modules-assembly/build.gradle):
> task distAppServer(type: Zip, dependsOn:
> [':extensions:geode-modules-session:jar',
> ':extensions:geode-modules-session-internal:jar',
> ':extensions:geode-modules-tomcat7:jar',
> ':extensions:geode-modules-tomcat8:jar',
> ':extensions:geode-modules-tomcat9:jar']) {
> baseName = moduleBaseName
> classifier = "AppServer"
> into('lib') {
> from getJarArtifact(':extensions:geode-modules-session')
> from getJarArtifact(':extensions:geode-modules-session-internal')
> from getJarArtifact(':extensions:geode-modules')
> from configurations.slf4jDeps
> }
> So I think it's somewhat indeterminant if any given build contains that jar
> in the zip. If we run the distributedTest on that particular build, we would
> catch the issue, but that's not how our build works (at least for geode
> releases).
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6845) Make logging consistent across putInProgress() calls in HAEventWrapper
[ https://issues.apache.org/jira/browse/GEODE-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6845: --- Assignee: Ryan McMahon > Make logging consistent across putInProgress() calls in HAEventWrapper > -- > > Key: GEODE-6845 > URL: https://issues.apache.org/jira/browse/GEODE-6845 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > In some cases we logged when we incremented the putInProgress counter on an > HAEventWrapper while in others we do not, so we should probably be consistent > with logging and also indicate where the call is being made from (initial > put, GII queue, client registration). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6845) Make logging consistent across putInProgress() calls in HAEventWrapper
Ryan McMahon created GEODE-6845: --- Summary: Make logging consistent across putInProgress() calls in HAEventWrapper Key: GEODE-6845 URL: https://issues.apache.org/jira/browse/GEODE-6845 Project: Geode Issue Type: Improvement Components: client queues, client/server Reporter: Ryan McMahon In some cases we logged when we incremented the putInProgress counter on an HAEventWrapper while in others we do not, so we should probably be consistent with logging and also indicate where the call is being made from (initial put, GII queue, client registration). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6842: --- Assignee: Ryan McMahon > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
[ https://issues.apache.org/jira/browse/GEODE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6842: Affects Version/s: 1.10.0 > Possible ClassCastException in HAEventWrapper during concurrent client > registration and queue GII > - > > Key: GEODE-6842 > URL: https://issues.apache.org/jira/browse/GEODE-6842 > Project: Geode > Issue Type: Bug > Components: client queues, client/server >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Priority: Major > > It is possible for a ClassCastException to be thrown if a client is > registering interest/CQ concurrently while a queue GII is being performed. > The issue is that the queued event (HAEventWrapper) can be mutated by the > client registration logic while it is in another client's queue, so if a GII > occurs it could be serialized while being mutated. Specifically, the > CqNameToOpHashMap was shown to throw the exception on the deserialization > side, because of a map size/entries mismatch on the serialization side caused > by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6842) Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII
Ryan McMahon created GEODE-6842: --- Summary: Possible ClassCastException in HAEventWrapper during concurrent client registration and queue GII Key: GEODE-6842 URL: https://issues.apache.org/jira/browse/GEODE-6842 Project: Geode Issue Type: Bug Components: client queues, client/server Reporter: Ryan McMahon It is possible for a ClassCastException to be thrown if a client is registering interest/CQ concurrently while a queue GII is being performed. The issue is that the queued event (HAEventWrapper) can be mutated by the client registration logic while it is in another client's queue, so if a GII occurs it could be serialized while being mutated. Specifically, the CqNameToOpHashMap was shown to throw the exception on the deserialization side, because of a map size/entries mismatch on the serialization side caused by the race described above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6797) Possibility for missing dependencies in session state modules
[
https://issues.apache.org/jira/browse/GEODE-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-6797:
---
Assignee: Ryan McMahon
> Possibility for missing dependencies in session state modules
> -
>
> Key: GEODE-6797
> URL: https://issues.apache.org/jira/browse/GEODE-6797
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
>
> It was found that the AppServer module in Geode 1.9.0 release package is
> missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
> due to the way we are zipping the module and specifying its dependencies in
> Gradle.
> From Dan Smith:
>
> {noformat}
> The basic issue is that this task includes the module jar in the zip in weird
> way, but doesn't declare the jar task as a dependency (in
> geode-modules-assembly/build.gradle):
> task distAppServer(type: Zip, dependsOn:
> [':extensions:geode-modules-session:jar',
> ':extensions:geode-modules-session-internal:jar',
> ':extensions:geode-modules-tomcat7:jar',
> ':extensions:geode-modules-tomcat8:jar',
> ':extensions:geode-modules-tomcat9:jar']) {
> baseName = moduleBaseName
> classifier = "AppServer"
> into('lib') {
> from getJarArtifact(':extensions:geode-modules-session')
> from getJarArtifact(':extensions:geode-modules-session-internal')
> from getJarArtifact(':extensions:geode-modules')
> from configurations.slf4jDeps
> }
> So I think it's somewhat indeterminant if any given build contains that jar
> in the zip. If we run the distributedTest on that particular build, we would
> catch the issue, but that's not how our build works (at least for geode
> releases).
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6804) Tab completion does not work when specifying path for --jar argument in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6804: Description: When attempting to use tab completion for the path in the `–jar` argument in gfsh, instead of completing the path it adds the next argument (`–dir` in my case). It would be nice if `–jar` path supported tab completion. !Screen Shot 2019-05-24 at 9.28.29 AM.png! was:When attempting to use tab completion for the path in the `–jar` argument in gfsh, instead of completing the path it adds the next argument (`–dir` in my case). It would be nice if `–jar` path supported tab completion. > Tab completion does not work when specifying path for --jar argument in gfsh > > > Key: GEODE-6804 > URL: https://issues.apache.org/jira/browse/GEODE-6804 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: management, starter > Attachments: Screen Shot 2019-05-24 at 9.28.29 AM.png > > > When attempting to use tab completion for the path in the `–jar` argument in > gfsh, instead of completing the path it adds the next argument (`–dir` in my > case). It would be nice if `–jar` path supported tab completion. > !Screen Shot 2019-05-24 at 9.28.29 AM.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6805) MacOS home shorthand ~ is not support for `--jar` path in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6805: Labels: gfsh management starter (was: management starter) > MacOS home shorthand ~ is not support for `--jar` path in gfsh > -- > > Key: GEODE-6805 > URL: https://issues.apache.org/jira/browse/GEODE-6805 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: gfsh, management, starter > > On MacOS, which is a supported development platform, it would be nice if the > path given for the `–jar` argument supported the MacOS shorthand `~`, rather > than needing to type /Users/user/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6804) Tab completion does not work when specifying path for --jar argument in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6804: Labels: gfsh management starter (was: management starter) > Tab completion does not work when specifying path for --jar argument in gfsh > > > Key: GEODE-6804 > URL: https://issues.apache.org/jira/browse/GEODE-6804 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: gfsh, management, starter > Attachments: Screen Shot 2019-05-24 at 9.28.29 AM.png > > > When attempting to use tab completion for the path in the `–jar` argument in > gfsh, instead of completing the path it adds the next argument (`–dir` in my > case). It would be nice if `–jar` path supported tab completion. > !Screen Shot 2019-05-24 at 9.28.29 AM.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6804) Tab completion does not work when specifying path for --jar argument in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6804: Attachment: Screen Shot 2019-05-24 at 9.28.29 AM.png > Tab completion does not work when specifying path for --jar argument in gfsh > > > Key: GEODE-6804 > URL: https://issues.apache.org/jira/browse/GEODE-6804 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: management, starter > Attachments: Screen Shot 2019-05-24 at 9.28.29 AM.png > > > When attempting to use tab completion for the path in the `–jar` argument in > gfsh, instead of completing the path it adds the next argument (`–dir` in my > case). It would be nice if `–jar` path supported tab completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6804) Tab completion does not work when specifying path for --jar argument in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6804: Labels: management starter (was: management) > Tab completion does not work when specifying path for --jar argument in gfsh > > > Key: GEODE-6804 > URL: https://issues.apache.org/jira/browse/GEODE-6804 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: management, starter > > When attempting to use tab completion for the path in the `–jar` argument in > gfsh, instead of completing the path it adds the next argument (`–dir` in my > case). It would be nice if `–jar` path supported tab completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6805) MacOS home shorthand ~ is not support for `--jar` path in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6805: Labels: management starter (was: management) > MacOS home shorthand ~ is not support for `--jar` path in gfsh > -- > > Key: GEODE-6805 > URL: https://issues.apache.org/jira/browse/GEODE-6805 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: management, starter > > On MacOS, which is a supported development platform, it would be nice if the > path given for the `–jar` argument supported the MacOS shorthand `~`, rather > than needing to type /Users/user/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6805) MacOS home shorthand ~ is not support for `--jar` path in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6805: Description: On MacOS, which is a supported development platform, it would be nice if the path given for the `–jar` argument supported the MacOS shorthand `~`, rather than needing to type /Users/user/. (was: MacOS is not technically a supported platform but many developers will use it to try out the basics of Geode. It would be nice if the path given for the `–jar` argument supported the MacOS shorthand `~`, rather than needing to type /Users/user/.) > MacOS home shorthand ~ is not support for `--jar` path in gfsh > -- > > Key: GEODE-6805 > URL: https://issues.apache.org/jira/browse/GEODE-6805 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: management > > On MacOS, which is a supported development platform, it would be nice if the > path given for the `–jar` argument supported the MacOS shorthand `~`, rather > than needing to type /Users/user/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6805) MacOS home shorthand ~ is not support for `--jar` path in gfsh
Ryan McMahon created GEODE-6805: --- Summary: MacOS home shorthand ~ is not support for `--jar` path in gfsh Key: GEODE-6805 URL: https://issues.apache.org/jira/browse/GEODE-6805 Project: Geode Issue Type: Improvement Components: gfsh Reporter: Ryan McMahon MacOS is not technically a supported platform but many developers will use it to try out the basics of Geode. It would be nice if the path given for the `–jar` argument supported the MacOS shorthand `~`, rather than needing to type /Users/user/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6805) MacOS home shorthand ~ is not support for `--jar` path in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6805: Labels: management (was: ) > MacOS home shorthand ~ is not support for `--jar` path in gfsh > -- > > Key: GEODE-6805 > URL: https://issues.apache.org/jira/browse/GEODE-6805 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Priority: Major > Labels: management > > MacOS is not technically a supported platform but many developers will use it > to try out the basics of Geode. It would be nice if the path given for the > `–jar` argument supported the MacOS shorthand `~`, rather than needing to > type /Users/user/. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6804) Tab completion does not work when specifying path for --jar argument in gfsh
Ryan McMahon created GEODE-6804: --- Summary: Tab completion does not work when specifying path for --jar argument in gfsh Key: GEODE-6804 URL: https://issues.apache.org/jira/browse/GEODE-6804 Project: Geode Issue Type: Improvement Components: gfsh Reporter: Ryan McMahon When attempting to use tab completion for the path in the `–jar` argument in gfsh, instead of completing the path it adds the next argument (`–dir` in my case). It would be nice if `–jar` path supported tab completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6797) Possibility for missing dependencies in session state modules
[
https://issues.apache.org/jira/browse/GEODE-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6797:
Description:
It was found that the AppServer module in Geode 1.9.0 release package is
missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
due to the way we are zipping the module and specifying its dependencies in
Gradle.
>From Dan Smith:
{noformat}
The basic issue is that this task includes the module jar in the zip in weird
way, but doesn't declare the jar task as a dependency (in
geode-modules-assembly/build.gradle):
task distAppServer(type: Zip, dependsOn:
[':extensions:geode-modules-session:jar',
':extensions:geode-modules-session-internal:jar',
':extensions:geode-modules-tomcat7:jar',
':extensions:geode-modules-tomcat8:jar',
':extensions:geode-modules-tomcat9:jar']) {
baseName = moduleBaseName
classifier = "AppServer"
into('lib') {
from getJarArtifact(':extensions:geode-modules-session')
from getJarArtifact(':extensions:geode-modules-session-internal')
from getJarArtifact(':extensions:geode-modules')
from configurations.slf4jDeps
}
So I think it's somewhat indeterminant if any given build contains that jar in
the zip. If we run the distributedTest on that particular build, we would catch
the issue, but that's not how our build works (at least for geode releases).
{noformat}
was:
It was found that the AppServer module in Geode 1.9.0 release package is
missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
due to the way we are zipping the module and specifying its dependencies in
Gradle.
>From Dan Smith:
{noformat}
The basic issue is that this task includes the module jar in the zip in weird
way, but doesn't declare the jar task as a dependency (in
geode-modules-assembly/build.gradle):
task distAppServer(type: Zip, dependsOn:
[':extensions:geode-modules-session:jar',
':extensions:geode-modules-session-internal:jar',
':extensions:geode-modules-tomcat7:jar',
':extensions:geode-modules-tomcat8:jar',
':extensions:geode-modules-tomcat9:jar']) {
baseName = moduleBaseName
classifier = "AppServer"
into('lib') {
from getJarArtifact(':extensions:geode-modules-session')
from getJarArtifact(':extensions:geode-modules-session-internal')
from getJarArtifact(':extensions:geode-modules')
from configurations.slf4jDeps
}
{noformat}
> Possibility for missing dependencies in session state modules
> -
>
> Key: GEODE-6797
> URL: https://issues.apache.org/jira/browse/GEODE-6797
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
>
> It was found that the AppServer module in Geode 1.9.0 release package is
> missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
> due to the way we are zipping the module and specifying its dependencies in
> Gradle.
> From Dan Smith:
>
> {noformat}
> The basic issue is that this task includes the module jar in the zip in weird
> way, but doesn't declare the jar task as a dependency (in
> geode-modules-assembly/build.gradle):
> task distAppServer(type: Zip, dependsOn:
> [':extensions:geode-modules-session:jar',
> ':extensions:geode-modules-session-internal:jar',
> ':extensions:geode-modules-tomcat7:jar',
> ':extensions:geode-modules-tomcat8:jar',
> ':extensions:geode-modules-tomcat9:jar']) {
> baseName = moduleBaseName
> classifier = "AppServer"
> into('lib') {
> from getJarArtifact(':extensions:geode-modules-session')
> from getJarArtifact(':extensions:geode-modules-session-internal')
> from getJarArtifact(':extensions:geode-modules')
> from configurations.slf4jDeps
> }
> So I think it's somewhat indeterminant if any given build contains that jar
> in the zip. If we run the distributedTest on that particular build, we would
> catch the issue, but that's not how our build works (at least for geode
> releases).
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6797) Possibility for missing dependencies in session state modules
Ryan McMahon created GEODE-6797:
---
Summary: Possibility for missing dependencies in session state
modules
Key: GEODE-6797
URL: https://issues.apache.org/jira/browse/GEODE-6797
Project: Geode
Issue Type: Bug
Components: build
Reporter: Ryan McMahon
It was found that the AppServer module in Geode 1.9.0 release package is
missing a dependency, specifically `geode-modules-1.9.0`. This appears to be
due to the way we are zipping the module and specifying its dependencies in
Gradle.
>From Dan Smith:
{noformat}
The basic issue is that this task includes the module jar in the zip in weird
way, but doesn't declare the jar task as a dependency (in
geode-modules-assembly/build.gradle):
task distAppServer(type: Zip, dependsOn:
[':extensions:geode-modules-session:jar',
':extensions:geode-modules-session-internal:jar',
':extensions:geode-modules-tomcat7:jar',
':extensions:geode-modules-tomcat8:jar',
':extensions:geode-modules-tomcat9:jar']) {
baseName = moduleBaseName
classifier = "AppServer"
into('lib') {
from getJarArtifact(':extensions:geode-modules-session')
from getJarArtifact(':extensions:geode-modules-session-internal')
from getJarArtifact(':extensions:geode-modules')
from configurations.slf4jDeps
}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6740) TLS endpoint identification fails using hostnames
[
https://issues.apache.org/jira/browse/GEODE-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840641#comment-16840641
]
Ryan McMahon commented on GEODE-6740:
-
It looks like `-Dgemfire.forceDnsUse=true` only affects hostname resolution in
the InternalDistributedMember. On a closer look, it appears the IP address
which needs reverse lookup is coming from a ServerLocation object which is part
of profile creation, and it is not affected by this flag. I'll post more
details about this as I find them.
> TLS endpoint identification fails using hostnames
> -
>
> Key: GEODE-6740
> URL: https://issues.apache.org/jira/browse/GEODE-6740
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Kenneth Howe
>Assignee: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons, security
>
> Tried to start a cluster with the following Geode security properties.
> {code}
> ssl-enabled-components=cluster,web,jmx,locator,server
> ssl-endpoint-identification-enabled=true
> {code}
> The certificate has the valid hostname wildcard as the SAN list.
> All the Geode config files and parameters use this hostname.
> {code}
> -Dgemfire.locators=3177423e-d7dd-4b27-932d-d33b4bdf5783.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],983d2e55-988e-437d-8b10-8b3dffc8cc82.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],8c222f26-22da-4e42-8d1e-e13a86808600.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221]
> {code}
> {code}
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 21:fc:3f:07:bc:47:5b:46:e3:07:da:c3:39:27:45:c4:83:67:39:4d
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: CN=gemfire-ssl
> Validity
> Not Before: May 2 21:43:51 2019 GMT
> Not After : May 1 21:43:51 2020 GMT
> Subject: CN=gemfire-locator-ssl
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> B8:84:1E:B6:74:C3:B4:BC:61:88:93:52:27:71:E2:92:EA:72:85:C4
> X509v3 Subject Alternative Name:
>
> DNS:*.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh
> X509v3 Authority Key Identifier:
>
> keyid:41:33:74:8E:ED:6D:94:2E:B1:9C:01:68:9B:6F:3C:B7:AF:5A:ED:6C
> X509v3 Basic Constraints: critical
> CA:FALSE
> {code}
> This resulted in the error starting up the locators
> {code}
> [severe 2019/05/02 19:45:54.422 UTC
> locator-707059cc-9aad-47a9-8fa9-b045a14d5b80 tid=0x1] SSL Error in
> connecting to peer /10.0.8.9[55222].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.0.8.9 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1069)
> at
> org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:932)
> at
> org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:894)
> at
> org.apache.geode.internal.net.SocketCreator.connectForServer(SocketCreator.java:873)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1264)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1066)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:305)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:413)
> at
>
[jira] [Resolved] (GEODE-6327) There needs to be a way to specify identity fields for JSON documents converted to PDX
[ https://issues.apache.org/jira/browse/GEODE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6327. - Resolution: Fixed Fix Version/s: 1.10.0 > There needs to be a way to specify identity fields for JSON documents > converted to PDX > -- > > Key: GEODE-6327 > URL: https://issues.apache.org/jira/browse/GEODE-6327 > Project: Geode > Issue Type: New Feature > Components: serialization >Reporter: Barry Oglesby >Assignee: Ryan McMahon >Priority: Major > Labels: SmallFeature > Fix For: 1.10.0 > > Attachments: geode-6327-poc.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > In the current implementation, there is no way to prevent all fields from > being used when executing hashCode and equals. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-6327) There needs to be a way to specify identity fields for JSON documents converted to PDX
[ https://issues.apache.org/jira/browse/GEODE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-6327. --- > There needs to be a way to specify identity fields for JSON documents > converted to PDX > -- > > Key: GEODE-6327 > URL: https://issues.apache.org/jira/browse/GEODE-6327 > Project: Geode > Issue Type: New Feature > Components: serialization >Reporter: Barry Oglesby >Assignee: Ryan McMahon >Priority: Major > Labels: SmallFeature > Fix For: 1.10.0 > > Attachments: geode-6327-poc.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > In the current implementation, there is no way to prevent all fields from > being used when executing hashCode and equals. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6741) Off-heap value may be referenced when draining client registration queue
[ https://issues.apache.org/jira/browse/GEODE-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6741. - Resolution: Fixed Fix Version/s: 1.10.0 > Off-heap value may be referenced when draining client registration queue > > > Key: GEODE-6741 > URL: https://issues.apache.org/jira/browse/GEODE-6741 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > If the value of the event added to a client's temporary registration queue is > off-heap, then it is possible that when draining the queue the event has > already been released which results in an IllegalStateException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-6741) Off-heap value may be referenced when draining client registration queue
[ https://issues.apache.org/jira/browse/GEODE-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-6741. --- > Off-heap value may be referenced when draining client registration queue > > > Key: GEODE-6741 > URL: https://issues.apache.org/jira/browse/GEODE-6741 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > If the value of the event added to a client's temporary registration queue is > off-heap, then it is possible that when draining the queue the event has > already been released which results in an IllegalStateException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6741) Off-heap value may be referenced when draining client registration queue
Ryan McMahon created GEODE-6741: --- Summary: Off-heap value may be referenced when draining client registration queue Key: GEODE-6741 URL: https://issues.apache.org/jira/browse/GEODE-6741 Project: Geode Issue Type: Bug Components: client queues Reporter: Ryan McMahon If the value of the event added to a client's temporary registration queue is off-heap, then it is possible that when draining the queue the event has already been released which results in an IllegalStateException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6741) Off-heap value may be referenced when draining client registration queue
[ https://issues.apache.org/jira/browse/GEODE-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6741: --- Assignee: Ryan McMahon > Off-heap value may be referenced when draining client registration queue > > > Key: GEODE-6741 > URL: https://issues.apache.org/jira/browse/GEODE-6741 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > If the value of the event added to a client's temporary registration queue is > off-heap, then it is possible that when draining the queue the event has > already been released which results in an IllegalStateException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-6708) Possible NPE if two cache client initialization threads are active for the same client ID
[ https://issues.apache.org/jira/browse/GEODE-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-6708. --- > Possible NPE if two cache client initialization threads are active for the > same client ID > - > > Key: GEODE-6708 > URL: https://issues.apache.org/jira/browse/GEODE-6708 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > There are scenarios where a client will have several cache client > initialization threads active (for instance, if the first thread blocked for > a significant amount of time waiting for a lock). In that scenario, it is > possible for two threads to create their own registration queues and only one > "wins", then upon draining the queue the first thread to remove the queue can > cause an NPE in the second thread because it was assumed the queue was still > present. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6708) Possible NPE if two cache client initialization threads are active for the same client ID
[ https://issues.apache.org/jira/browse/GEODE-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6708. - Resolution: Fixed Fix Version/s: 1.10.0 > Possible NPE if two cache client initialization threads are active for the > same client ID > - > > Key: GEODE-6708 > URL: https://issues.apache.org/jira/browse/GEODE-6708 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > There are scenarios where a client will have several cache client > initialization threads active (for instance, if the first thread blocked for > a significant amount of time waiting for a lock). In that scenario, it is > possible for two threads to create their own registration queues and only one > "wins", then upon draining the queue the first thread to remove the queue can > cause an NPE in the second thread because it was assumed the queue was still > present. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6715) Possible NPE if member is becoming elder while shutting down
Ryan McMahon created GEODE-6715: --- Summary: Possible NPE if member is becoming elder while shutting down Key: GEODE-6715 URL: https://issues.apache.org/jira/browse/GEODE-6715 Project: Geode Issue Type: Bug Components: membership Reporter: Ryan McMahon Fix For: 1.10.0 There is a race which can occur if a member is shutting down and becoming elder simultaneously that results in an NPE. The logic for becoming elder assumes we always successfully become the elder, but that might not be the case if the member is shutting down. See the "close in progress" case in ClusterElderManager.waitForElder() method to see when we would return false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6708) Possible NPE if two cache client initialization threads are active for the same client ID
[ https://issues.apache.org/jira/browse/GEODE-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6708: Affects Version/s: 1.10.0 Fix Version/s: (was: 1.10.0) Component/s: client queues > Possible NPE if two cache client initialization threads are active for the > same client ID > - > > Key: GEODE-6708 > URL: https://issues.apache.org/jira/browse/GEODE-6708 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Priority: Major > > There are scenarios where a client will have several cache client > initialization threads active (for instance, if the first thread blocked for > a significant amount of time waiting for a lock). In that scenario, it is > possible for two threads to create their own registration queues and only one > "wins", then upon draining the queue the first thread to remove the queue can > cause an NPE in the second thread because it was assumed the queue was still > present. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6708) Possible NPE if two cache client initialization threads are active for the same client ID
[ https://issues.apache.org/jira/browse/GEODE-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6708: --- Assignee: Ryan McMahon > Possible NPE if two cache client initialization threads are active for the > same client ID > - > > Key: GEODE-6708 > URL: https://issues.apache.org/jira/browse/GEODE-6708 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.10.0 >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > > There are scenarios where a client will have several cache client > initialization threads active (for instance, if the first thread blocked for > a significant amount of time waiting for a lock). In that scenario, it is > possible for two threads to create their own registration queues and only one > "wins", then upon draining the queue the first thread to remove the queue can > cause an NPE in the second thread because it was assumed the queue was still > present. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6708) Possible NPE if two cache client initialization threads are active for the same client ID
Ryan McMahon created GEODE-6708: --- Summary: Possible NPE if two cache client initialization threads are active for the same client ID Key: GEODE-6708 URL: https://issues.apache.org/jira/browse/GEODE-6708 Project: Geode Issue Type: Bug Reporter: Ryan McMahon Fix For: 1.10.0 There are scenarios where a client will have several cache client initialization threads active (for instance, if the first thread blocked for a significant amount of time waiting for a lock). In that scenario, it is possible for two threads to create their own registration queues and only one "wins", then upon draining the queue the first thread to remove the queue can cause an NPE in the second thread because it was assumed the queue was still present. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6607) Possible client subscription data inconsistency due to race between retrieving filter info and distributing event
[ https://issues.apache.org/jira/browse/GEODE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6607. - Resolution: Fixed Fix Version/s: 1.10.0 > Possible client subscription data inconsistency due to race between > retrieving filter info and distributing event > - > > Key: GEODE-6607 > URL: https://issues.apache.org/jira/browse/GEODE-6607 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.10.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > It is possible for a client to miss events from subscription (either CQ or > register interest) due to the following scenario: > Four servers in a cluster, with redundant copies set to 2 for client > subscriptions. The client has its primary subscription endpoint with server > 1 and redundant copies are on servers 2 and 3. Server 2 is killed or lost > due to network partition, so we attempt to restore redundancy by copying the > client queue from server 3 to server 4. > Two things happen when server 4 gets the client queue from server 3. First, > we request the client's filter info which represents the CQ and register > interest info. Second, we actually perform the GII to get the image of the > queue. > A race can occur where an event is being distributed across the cluster > concurrently while server 4 is initializing the client queue. If the > distributed event is processed by server 4 before the filter info is > retrieved, then the event will not match the client subscription filter > because it doesn't exist yet. Then, if the event is processed by server 3 > after GII has started, the event will not be part of the client queue image. > Therefore, the event is never added to the client queue and is lost. > We have a special queue for handling events while a client is initializing, > but it is at too low of a level (MessageDispatcher) to be able to handle this > scenario. One possible solution is moving this special queue to a higher > level (CacheClientNotifier or CacheClientProxy) so the event is queued before > we even attempt to get filter info. Then, when initialization finishes, we > drain the queue, see if it matches the initialized client's filter, and send > it along if so. A similar solution could be done on the GII provider side > but it might be a bit messier. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6327) There needs to be a way to specify identity fields for JSON documents converted to PDX
[ https://issues.apache.org/jira/browse/GEODE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6327: --- Assignee: Ryan McMahon > There needs to be a way to specify identity fields for JSON documents > converted to PDX > -- > > Key: GEODE-6327 > URL: https://issues.apache.org/jira/browse/GEODE-6327 > Project: Geode > Issue Type: New Feature > Components: serialization >Reporter: Barry Oglesby >Assignee: Ryan McMahon >Priority: Major > Labels: SmallFeature > Attachments: geode-6327-poc.patch > > > In the current implementation, there is no way to prevent all fields from > being used when executing hashCode and equals. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6607) Possible client subscription data inconsistency due to race between retrieving filter info and distributing event
[ https://issues.apache.org/jira/browse/GEODE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6607: --- Assignee: Ryan McMahon > Possible client subscription data inconsistency due to race between > retrieving filter info and distributing event > - > > Key: GEODE-6607 > URL: https://issues.apache.org/jira/browse/GEODE-6607 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > It is possible for a client to miss events from subscription (either CQ or > register interest) due to the following scenario: > Four servers in a cluster, with redundant copies set to 2 for client > subscriptions. The client has its primary subscription endpoint with server > 1 and redundant copies are on servers 2 and 3. Server 2 is killed or lost > due to network partition, so we attempt to restore redundancy by copying the > client queue from server 3 to server 4. > Two things happen when server 4 gets the client queue from server 3. First, > we request the client's filter info which represents the CQ and register > interest info. Second, we actually perform the GII to get the image of the > queue. > A race can occur where an event is being distributed across the cluster > concurrently while server 4 is initializing the client queue. If the > distributed event is processed by server 4 before the filter info is > retrieved, then the event will not match the client subscription filter > because it doesn't exist yet. Then, if the event is processed by server 3 > after GII has started, the event will not be part of the client queue image. > Therefore, the event is never added to the client queue and is lost. > We have a special queue for handling events while a client is initializing, > but it is at too low of a level (MessageDispatcher) to be able to handle this > scenario. One possible solution is moving this special queue to a higher > level (CacheClientNotifier or CacheClientProxy) so the event is queued before > we even attempt to get filter info. Then, when initialization finishes, we > drain the queue, see if it matches the initialized client's filter, and send > it along if so. A similar solution could be done on the GII provider side > but it might be a bit messier. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6607) Possible client subscription data inconsistency due to race between retrieving filter info and distributing event
Ryan McMahon created GEODE-6607: --- Summary: Possible client subscription data inconsistency due to race between retrieving filter info and distributing event Key: GEODE-6607 URL: https://issues.apache.org/jira/browse/GEODE-6607 Project: Geode Issue Type: Bug Components: client queues Reporter: Ryan McMahon It is possible for a client to miss events from subscription (either CQ or register interest) due to the following scenario: Four servers in a cluster, with redundant copies set to 2 for client subscriptions. The client has its primary subscription endpoint with server 1 and redundant copies are on servers 2 and 3. Server 2 is killed or lost due to network partition, so we attempt to restore redundancy by copying the client queue from server 3 to server 4. Two things happen when server 4 gets the client queue from server 3. First, we request the client's filter info which represents the CQ and register interest info. Second, we actually perform the GII to get the image of the queue. A race can occur where an event is being distributed across the cluster concurrently while server 4 is initializing the client queue. If the distributed event is processed by server 4 before the filter info is retrieved, then the event will not match the client subscription filter because it doesn't exist yet. Then, if the event is processed by server 3 after GII has started, the event will not be part of the client queue image. Therefore, the event is never added to the client queue and is lost. We have a special queue for handling events while a client is initializing, but it is at too low of a level (MessageDispatcher) to be able to handle this scenario. One possible solution is moving this special queue to a higher level (CacheClientNotifier or CacheClientProxy) so the event is queued before we even attempt to get filter info. Then, when initialization finishes, we drain the queue, see if it matches the initialized client's filter, and send it along if so. A similar solution could be done on the GII provider side but it might be a bit messier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6488) Query monitor may not remove all cancellation tasks if query object reused
[ https://issues.apache.org/jira/browse/GEODE-6488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6488. - Resolution: Fixed Fix Version/s: 1.9.0 > Query monitor may not remove all cancellation tasks if query object reused > -- > > Key: GEODE-6488 > URL: https://issues.apache.org/jira/browse/GEODE-6488 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.9.0 > > Time Spent: 6h > Remaining Estimate: 0h > > If a query instance is reused and monitored by multiple threads, it is > possible that the cancellation tasks for each thread get unscheduled. This > is due to a single cancellation task reference on the DefaultQuery which can > get overwritten if multiple threads are using the same instance. > Scenario: > # Thread 1 monitors and executes a query, and its cancellation task gets > assigned to the query instance. > # Before Thread 1 stops monitoring, thread 2 monitors and executes using the > same query instance, so Thread 1's cancellation task gets overwritten > # Both threads request that the query no longer be monitored, but only > thread 2's cancellation task is unscheduled and removed, because we lost > thread 1's cancellation tasks reference when it was overwritten. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6488) Query monitor may not remove all cancellation tasks if query object reused
[ https://issues.apache.org/jira/browse/GEODE-6488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6488: --- Assignee: Ryan McMahon > Query monitor may not remove all cancellation tasks if query object reused > -- > > Key: GEODE-6488 > URL: https://issues.apache.org/jira/browse/GEODE-6488 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > If a query instance is reused and monitored by multiple threads, it is > possible that the cancellation tasks for each thread get unscheduled. This > is due to a single cancellation task reference on the DefaultQuery which can > get overwritten if multiple threads are using the same instance. > Scenario: > # Thread 1 monitors and executes a query, and its cancellation task gets > assigned to the query instance. > # Before Thread 1 stops monitoring, thread 2 monitors and executes using the > same query instance, so Thread 1's cancellation task gets overwritten > # Both threads request that the query no longer be monitored, but only > thread 2's cancellation task is unscheduled and removed, because we lost > thread 1's cancellation tasks reference when it was overwritten. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5526) CI Failure: ParallelWANStatsDUnitTest.testParallelPropagationHA fails with AssertionError for Queue Size
[
https://issues.apache.org/jira/browse/GEODE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-5526:
---
Assignee: (was: Ryan McMahon)
> CI Failure: ParallelWANStatsDUnitTest.testParallelPropagationHA fails with
> AssertionError for Queue Size
>
>
> Key: GEODE-5526
> URL: https://issues.apache.org/jira/browse/GEODE-5526
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Priority: Major
> Labels: swat
>
> Failed in Geode DistributedTests on August 3rd, 2018 with:
> {{org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest >
> testParallelPropagationHA FAILED}}
> {{java.lang.AssertionError: expected:<0> but was:<-3>}}
> {{at org.junit.Assert.fail(Assert.java:88)}}
> {{at org.junit.Assert.failNotEquals(Assert.java:834)}}
> {{at org.junit.Assert.assertEquals(Assert.java:645)}}
> {{at org.junit.Assert.assertEquals(Assert.java:631)}}
> {{at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.testParallelPropagationHA(ParallelWANStatsDUnitTest.java:429)}}
> On the assertion:
> {{assertEquals(0, v5List.get(0) + v6List.get(0) + v7List.get(0)); // queue
> size}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6488) Query monitor may not remove all cancellation tasks if query object reused
Ryan McMahon created GEODE-6488: --- Summary: Query monitor may not remove all cancellation tasks if query object reused Key: GEODE-6488 URL: https://issues.apache.org/jira/browse/GEODE-6488 Project: Geode Issue Type: Bug Components: querying Reporter: Ryan McMahon If a query instance is reused and monitored by multiple threads, it is possible that the cancellation tasks for each thread get unscheduled. This is due to a single cancellation task reference on the DefaultQuery which can get overwritten if multiple threads are using the same instance. Scenario: # Thread 1 monitors and executes a query, and its cancellation task gets assigned to the query instance. # Before Thread 1 stops monitoring, thread 2 monitors and executes using the same query instance, so Thread 1's cancellation task gets overwritten # Both threads request that the query no longer be monitored, but only thread 2's cancellation task is unscheduled and removed, because we lost thread 1's cancellation tasks reference when it was overwritten. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
