[jira] [Commented] (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:comment-tabpanel=16901671#comment-16901671 ] ASF subversion and git services commented on GEODE-7015: Commit 08bd776f8ceaa127b40523a49a294f3c115d0aa6 in geode's branch refs/heads/develop from Ryan McMahon [ https://gitbox.apache.org/repos/asf?p=geode.git;h=08bd776 ] GEODE-7015: Fixing redundant copies in test > 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: 1h 50m > 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-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-7053:
Assignee: Anthony Baker
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the thread loses CPU for any reason.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-7055) Deadlock with StartupMessages if P2P error requiring a sendFailureReply
Ernest Burghardt created GEODE-7055:
---
Summary: Deadlock with StartupMessages if P2P error requiring a
sendFailureReply
Key: GEODE-7055
URL: https://issues.apache.org/jira/browse/GEODE-7055
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Ernest Burghardt
An error/exception occurs on the P2P message thread, which requires a
FailureReply be sent, but the StartupResponse message has not been recieved (on
the P2P message thread) the failure reply will DEADLOCK on the call to
org.apache.geode.distributed.internal.ClusterDistributionManager.waitUntilReadyToSendMsgs
as the StartupOperation is already in a waitForReplies() for the StartupResponse
{code:java}
// below is an example of an Exception triggering the DEADLOCK
{code}
{code:java}
[fatal 2019/08/05 22:47:06.462 UTC :56152(version:GEODE
1.9.0) shared unordered uid=63 port=49194> tid=0x25] Error deserializing
message java.lang.ClassNotFoundException:
org.apache.geode.modules.util.BootstrappingFunction at
org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:180)
at
org.apache.geode.internal.InternalDataSerializer.getCachedClass(InternalDataSerializer.java:3274)
at org.apache.geode.DataSerializer.readClass(DataSerializer.java:264)
at
org.apache.geode.internal.InternalDataSerializer.readDataSerializable(InternalDataSerializer.java:2398)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2673)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2968)
at
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.fromData(MemberFunctionStreamingMessage.java:277)
at
org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2372)
at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:997)
at
org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2516)
at
org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2528)
at
org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3111)
at
org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2920)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748) "P2P message reader for
10.0.8.10(cacheserver-28663bad-c0b0-41f7-b723-5a2425fa54ff:1):56152(version:GEODE
1.9.0) shared unordered uid=63 port=49194" #37 daemon prio=10 os_prio=0
tid=0x7f4a108bb800 nid=0x2a in Object.wait() [0x7f4a0dca7000]
java.lang.Thread.State: WAITING (on object monitor) at
java.lang.Object.wait(Native Method) - waiting on <0x0006d39c4538>
(a java.lang.Object) at java.lang.Object.wait(Object.java:502) at
org.apache.geode.distributed.internal.ClusterDistributionManager.waitUntilReadyToSendMsgs(ClusterDistributionManager.java:1212)
- locked <0x0006d39c4538> (a java.lang.Object) at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2816)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1528)
at
org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:113)
at
org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:86)
at
org.apache.geode.internal.tcp.Connection.sendFailureReply(Connection.java:1954)
at
org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3162)
at
org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2920)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){code}
--
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] [Reopened] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region
[ https://issues.apache.org/jira/browse/GEODE-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun reopened GEODE-6973: > getExistingIdForType should not compare all entries in idToType region > -- > > Key: GEODE-6973 > URL: https://issues.apache.org/jira/browse/GEODE-6973 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > We found the PeerTypeRegistration's getExistingIdForType() will iterate > through the idToType region's entries to find if the incoming newType is > there. > If idToType region contains 20K or 100K entries, this will impact the put > throughput (customers did notice the performance downgrade when there're many > pdxTypes). > To make the things worse, the comparison is to compare the whole object, > field to field. If the json object (which will be converted to pdxType) > contains 30 fields, the comparison will have to compare up to 30 fields. If > the idToType region contains 20K entries, A new pdxType will do 20K x 30 > string comparisons before register it. > We found each server maintained a typeToId map, this map is used to check if > the pdxType exists. If exists, it will return the type id without check the > IdToType region. The total number of pdxType did not impact the put > performance if the pdxTypd exists. > The typeToId map is maintained with a d-lock, each time we added a new > pdxType, it will update into the map while still holding the d-lok. So we > believe that the map should be the same as the region in content. If we > cannot find the pdxType in the map, it should not be in the region. We can > skip the iteration of region (which is the root cause of the performance > issue). > Another issue in current code is: when each time a new type come, it will > recreate the map. This is unnecessary and contributes to the slowness too. > We should only create the map during initialize(). > Here are the tests we want to introduce: > 1) a junit test to prove that reorder fields in a big JSON file will not > cause significant hashcode conflicts (<1%) > 2) a junit test to prove that add a index to a field in a big JSON file will > hardly cause hashcode conflicts. > This 2 tests are to prove that hashcode conflict is not the root cause of > linear probing for PDXTypeId. > 3) a junit test to prove that for the cases that hashcode conflict caused by > reordered fields, there will be no hashcode conflicts if using > SORT_JSON_FIELD_NAMES_PROPERTY=true. > 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false > did not impact the performance to add a new pdxType. > 5) a dunit test to create a new pdxType from 2 peer server at the same time. > The test is to prove that the d-lock take effect, one server create the > pdxType, and another server should find the pdxType exists. > Do this test both from server directly and from clients. > 6) Create 2 different objects which ends up with the same hashcode (we can > get the 2 objects from test-1), try to put the 2 objects to create new > pdxType. The 2nd one should also create a new type. It should not be treated > as "found an existing pdxType". -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region
[ https://issues.apache.org/jira/browse/GEODE-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901470#comment-16901470 ] ASF subversion and git services commented on GEODE-6973: Commit 10677330666d6bbc45ac535268db026d1351872e in geode's branch refs/heads/release/1.10.0 from Naburun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1067733 ] Revert "GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r… (#3853)" This reverts commit 181e3a4a465aa9f5e06f39cd1285c94f9bc78600. > getExistingIdForType should not compare all entries in idToType region > -- > > Key: GEODE-6973 > URL: https://issues.apache.org/jira/browse/GEODE-6973 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > We found the PeerTypeRegistration's getExistingIdForType() will iterate > through the idToType region's entries to find if the incoming newType is > there. > If idToType region contains 20K or 100K entries, this will impact the put > throughput (customers did notice the performance downgrade when there're many > pdxTypes). > To make the things worse, the comparison is to compare the whole object, > field to field. If the json object (which will be converted to pdxType) > contains 30 fields, the comparison will have to compare up to 30 fields. If > the idToType region contains 20K entries, A new pdxType will do 20K x 30 > string comparisons before register it. > We found each server maintained a typeToId map, this map is used to check if > the pdxType exists. If exists, it will return the type id without check the > IdToType region. The total number of pdxType did not impact the put > performance if the pdxTypd exists. > The typeToId map is maintained with a d-lock, each time we added a new > pdxType, it will update into the map while still holding the d-lok. So we > believe that the map should be the same as the region in content. If we > cannot find the pdxType in the map, it should not be in the region. We can > skip the iteration of region (which is the root cause of the performance > issue). > Another issue in current code is: when each time a new type come, it will > recreate the map. This is unnecessary and contributes to the slowness too. > We should only create the map during initialize(). > Here are the tests we want to introduce: > 1) a junit test to prove that reorder fields in a big JSON file will not > cause significant hashcode conflicts (<1%) > 2) a junit test to prove that add a index to a field in a big JSON file will > hardly cause hashcode conflicts. > This 2 tests are to prove that hashcode conflict is not the root cause of > linear probing for PDXTypeId. > 3) a junit test to prove that for the cases that hashcode conflict caused by > reordered fields, there will be no hashcode conflicts if using > SORT_JSON_FIELD_NAMES_PROPERTY=true. > 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false > did not impact the performance to add a new pdxType. > 5) a dunit test to create a new pdxType from 2 peer server at the same time. > The test is to prove that the d-lock take effect, one server create the > pdxType, and another server should find the pdxType exists. > Do this test both from server directly and from clients. > 6) Create 2 different objects which ends up with the same hashcode (we can > get the 2 objects from test-1), try to put the 2 objects to create new > pdxType. The 2nd one should also create a new type. It should not be treated > as "found an existing pdxType". -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region
[ https://issues.apache.org/jira/browse/GEODE-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901469#comment-16901469 ] ASF subversion and git services commented on GEODE-6973: Commit 2047c40d59ea31967bcbc36ae7c62e6489cdb74e in geode's branch refs/heads/develop from Naburun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2047c40 ] Revert "GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r… (#3853)" This reverts commit 181e3a4a > getExistingIdForType should not compare all entries in idToType region > -- > > Key: GEODE-6973 > URL: https://issues.apache.org/jira/browse/GEODE-6973 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > We found the PeerTypeRegistration's getExistingIdForType() will iterate > through the idToType region's entries to find if the incoming newType is > there. > If idToType region contains 20K or 100K entries, this will impact the put > throughput (customers did notice the performance downgrade when there're many > pdxTypes). > To make the things worse, the comparison is to compare the whole object, > field to field. If the json object (which will be converted to pdxType) > contains 30 fields, the comparison will have to compare up to 30 fields. If > the idToType region contains 20K entries, A new pdxType will do 20K x 30 > string comparisons before register it. > We found each server maintained a typeToId map, this map is used to check if > the pdxType exists. If exists, it will return the type id without check the > IdToType region. The total number of pdxType did not impact the put > performance if the pdxTypd exists. > The typeToId map is maintained with a d-lock, each time we added a new > pdxType, it will update into the map while still holding the d-lok. So we > believe that the map should be the same as the region in content. If we > cannot find the pdxType in the map, it should not be in the region. We can > skip the iteration of region (which is the root cause of the performance > issue). > Another issue in current code is: when each time a new type come, it will > recreate the map. This is unnecessary and contributes to the slowness too. > We should only create the map during initialize(). > Here are the tests we want to introduce: > 1) a junit test to prove that reorder fields in a big JSON file will not > cause significant hashcode conflicts (<1%) > 2) a junit test to prove that add a index to a field in a big JSON file will > hardly cause hashcode conflicts. > This 2 tests are to prove that hashcode conflict is not the root cause of > linear probing for PDXTypeId. > 3) a junit test to prove that for the cases that hashcode conflict caused by > reordered fields, there will be no hashcode conflicts if using > SORT_JSON_FIELD_NAMES_PROPERTY=true. > 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false > did not impact the performance to add a new pdxType. > 5) a dunit test to create a new pdxType from 2 peer server at the same time. > The test is to prove that the d-lock take effect, one server create the > pdxType, and another server should find the pdxType exists. > Do this test both from server directly and from clients. > 6) Create 2 different objects which ends up with the same hashcode (we can > get the 2 objects from test-1), try to put the 2 objects to create new > pdxType. The 2nd one should also create a new type. It should not be treated > as "found an existing pdxType". -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6747) CI failure: GMSJoinLeaveJUnitTest fails intermittently, possibly due to incorrect use of Mockito spy from multiple threads
[
https://issues.apache.org/jira/browse/GEODE-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-6747.
-
Resolution: Fixed
Fix Version/s: 1.11.0
> CI failure: GMSJoinLeaveJUnitTest fails intermittently, possibly due to
> incorrect use of Mockito spy from multiple threads
> --
>
> Key: GEODE-6747
> URL: https://issues.apache.org/jira/browse/GEODE-6747
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Priority: Major
> Fix For: 1.11.0
>
>
> {noformat}
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest
> > testRemoveMessageForRogueCausesImmediateRemovalMessageToRogue FAILED
> org.mockito.exceptions.misusing.WrongTypeOfReturnValue:
> Messenger$MockitoMock$1405677960 cannot be returned by
> getCancelCriterion()
> getCancelCriterion() should return Stopper
> ***
> If you're unsure why you're getting above error read on.
> Due to the nature of the syntax above problem might occur because:
> 1. This exception *might* occur in wrongly written multi-threaded tests.
> Please refer to Mockito FAQ on limitations of concurrency testing.
> 2. A spy is stubbed using when(spy.foo()).then() syntax. It is safer to
> stub spies -
> - with doReturn|Throw() family of methods. More in javadocs for
> Mockito.spy() method.
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.prepareAndInstallView(GMSJoinLeaveJUnitTest.java:347)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testRemoveMessageForRogueCausesImmediateRemovalMessageToRogue(GMSJoinLeaveJUnitTest.java:599)
> {noformat}
> ^ lookie right there. I wonder if our test is accessing Mockito spy
> functionality (incorrectly) from multiple threads?!?
> Concourse build:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/691]
> …on this commit: ddef7b7418fb21526b144f91cd4896a016a05e3c
> Previous build, on this commit, passed:
> d315756f958e91875bbe79179de1ed37141502b6
> Next build, on this commit, passed: a716be9262a928871c0cd61480ed3ac5051ad429
> So it's obvious that this is a brand new bug.
> I ran the test about 25 times in IntelliJ with no failures. So it appears to
> be intermittent.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-6747) CI failure: GMSJoinLeaveJUnitTest fails intermittently, possibly due to incorrect use of Mockito spy from multiple threads
[
https://issues.apache.org/jira/browse/GEODE-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901445#comment-16901445
]
ASF subversion and git services commented on GEODE-6747:
Commit 2419ffb7fae07971ffaef159a0f3945a12e28342 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2419ffb ]
GEODE-6747 CI failure: GMSJoinLeaveJUnitTest fails intermittently, possibly due
to incorrect use of Mockito spy from multiple threads
Removed redundant mocking - especially in places where we've launched a
ViewCreator thread before doing more mocking.
> CI failure: GMSJoinLeaveJUnitTest fails intermittently, possibly due to
> incorrect use of Mockito spy from multiple threads
> --
>
> Key: GEODE-6747
> URL: https://issues.apache.org/jira/browse/GEODE-6747
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest
> > testRemoveMessageForRogueCausesImmediateRemovalMessageToRogue FAILED
> org.mockito.exceptions.misusing.WrongTypeOfReturnValue:
> Messenger$MockitoMock$1405677960 cannot be returned by
> getCancelCriterion()
> getCancelCriterion() should return Stopper
> ***
> If you're unsure why you're getting above error read on.
> Due to the nature of the syntax above problem might occur because:
> 1. This exception *might* occur in wrongly written multi-threaded tests.
> Please refer to Mockito FAQ on limitations of concurrency testing.
> 2. A spy is stubbed using when(spy.foo()).then() syntax. It is safer to
> stub spies -
> - with doReturn|Throw() family of methods. More in javadocs for
> Mockito.spy() method.
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.prepareAndInstallView(GMSJoinLeaveJUnitTest.java:347)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testRemoveMessageForRogueCausesImmediateRemovalMessageToRogue(GMSJoinLeaveJUnitTest.java:599)
> {noformat}
> ^ lookie right there. I wonder if our test is accessing Mockito spy
> functionality (incorrectly) from multiple threads?!?
> Concourse build:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/691]
> …on this commit: ddef7b7418fb21526b144f91cd4896a016a05e3c
> Previous build, on this commit, passed:
> d315756f958e91875bbe79179de1ed37141502b6
> Next build, on this commit, passed: a716be9262a928871c0cd61480ed3ac5051ad429
> So it's obvious that this is a brand new bug.
> I ran the test about 25 times in IntelliJ with no failures. So it appears to
> be intermittent.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7051) Log4j dependency should be upgraded to 2.12.0
[ https://issues.apache.org/jira/browse/GEODE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7051: - Affects Version/s: 1.11.0 1.10.0 > Log4j dependency should be upgraded to 2.12.0 > - > > Key: GEODE-7051 > URL: https://issues.apache.org/jira/browse/GEODE-7051 > Project: Geode > Issue Type: Wish > Components: build, logging >Affects Versions: 1.10.0, 1.11.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Log4j dependency should be upgraded to 2.12.0 in Geode. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6883) Move the membership code into a separate gradle sub-project
[ https://issues.apache.org/jira/browse/GEODE-6883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901370#comment-16901370 ] ASF subversion and git services commented on GEODE-6883: Commit 159dd7b694a5c3cde160dd4d5b14fe3b77aa7fb4 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=159dd7b ] GEODE-6883 Move the membership code into a separate gradle sub-project This commit is focused on removing references to InternalDistributedMember and DistributionMessage from "gms" packages. GMS classes only refer to GMSMember GMS classes use GMSMembershipView. NetView is now an interface GMS classes do not refer to DistributionMessage. JGroupsMessenger expects GMSMessage instances. Geode messages to be sent over UDP are wrapped in a GMSMessageAdapter. "gms" messages extend AbstractGMSMessage which implements GMSMessage GMSMembershipManager has an inner class that implements the GMS Manager interface and is now in the "adapter" package GMSMembershipManager translates GMSMembershipView into a MembershipView for the rest of Geode to use (this is the old NetView class) GMS instantiation allows us to inject the Manager into the new Services instance. Other adapter classes have been added to translate between Geode and GMS. GMSUtil has new methods for marshalling/unmarshalling InternalDistributedMember instances for backward-compatibility. GMSMember now has the same on-wire form as InternalDistributedMember. This allows the GMS classes to deserialize a message from a pre-1.10 member whose code writes InternalDistributedMembers when serializing something like a JoinRequest. > Move the membership code into a separate gradle sub-project > --- > > Key: GEODE-6883 > URL: https://issues.apache.org/jira/browse/GEODE-6883 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Priority: Major > Time Spent: 6h 40m > Remaining Estimate: 0h > > In order to make membership more testable, we want to move the membership > code out of geode-core and into a new geode-membership gradle sub-project. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6998) NPE during update of index due to GII
[ https://issues.apache.org/jira/browse/GEODE-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901367#comment-16901367 ] ASF subversion and git services commented on GEODE-6998: Commit 861812093f088c27f264d6be7ecc9c4837d2e9e4 in geode's branch refs/heads/develop from Jason Huynh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8618120 ] GEODE-6998: Add index test for gii tombstone/values update to tombstone (#3873) * parameterized entire test to take in different cache xml > NPE during update of index due to GII > - > > Key: GEODE-6998 > URL: https://issues.apache.org/jira/browse/GEODE-6998 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.9.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available, recovery > Fix For: 1.10.0 > > Attachments: logs.tgz > > Time Spent: 4h 50m > Remaining Estimate: 0h > > On REPLICATE_PERSISTENT region with defined indexes, in configuration with 2 > servers, continues traffic (put, delete) is run. After one server is > restarted, NullPointerException occurres. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901364#comment-16901364
]
Kirk Lund edited comment on GEODE-7053 at 8/6/19 6:41 PM:
--
I don't think this is related to GEODE-7015.
It's probably just some basic multi-threaded flakiness in the test itself. It
has a looping background thread with a 10 ms sleep. Fixing this ticket probably
requires tightening that up in some way.
was (Author: klund):
I don't think this is related to GEODE-7015.
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the thread loses CPU for any reason.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901364#comment-16901364
]
Kirk Lund commented on GEODE-7053:
--
I don't think this is related to GEODE-7015.
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the thread loses CPU for any reason.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-7053:
-
Description:
This test appears to be flaky and fails intermittently with:
{noformat}
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
readsInOtherMemberShouldPreventExpiration FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
in VM 0 running on Host 40e899358944 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
{noformat}
This test depends on a background thread waking up every 10 ms to perform a GET
which prevents another thread from expiring an entry. I think that would be
very prone to failing if the thread loses CPU for any reason.
was:
This test appears to be flaky and fails intermittently with:
{noformat}
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
readsInOtherMemberShouldPreventExpiration FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
in VM 0 running on Host 40e899358944 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
{noformat}
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the
[jira] [Updated] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-7053:
-
Description:
This test appears to be flaky and fails intermittently with:
{noformat}
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
readsInOtherMemberShouldPreventExpiration FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
in VM 0 running on Host 40e899358944 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
{noformat}
was:
This test appears to be flaky and fails intermittently with:
{noformat}
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
readsInOtherMemberShouldPreventExpiration FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
in VM 0 running on Host 40e899358944 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
{noformat}
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (GEODE-7052) create a rolling-upgrade test for session caching
[ https://issues.apache.org/jira/browse/GEODE-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt closed GEODE-7052. --- > create a rolling-upgrade test for session caching > - > > Key: GEODE-7052 > URL: https://issues.apache.org/jira/browse/GEODE-7052 > Project: Geode > Issue Type: Bug > Components: extensions, http session >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.0 > > > There is no rolling-upgrade test for our session caching module. Let's > create one! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7052) create a rolling-upgrade test for session caching
[ https://issues.apache.org/jira/browse/GEODE-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-7052. - Resolution: Not A Problem Fix Version/s: 1.9.0 Dan pointed me to an existing session caching test for rolling upgrade: Tomcat8ClientServerRollingUpgradeTest > create a rolling-upgrade test for session caching > - > > Key: GEODE-7052 > URL: https://issues.apache.org/jira/browse/GEODE-7052 > Project: Geode > Issue Type: Bug > Components: extensions, http session >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.9.0 > > > There is no rolling-upgrade test for our session caching module. Let's > create one! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7054) Add some SSL benchmarks to CI
[ https://issues.apache.org/jira/browse/GEODE-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murtuza Boxwala reassigned GEODE-7054: -- Assignee: Murtuza Boxwala > Add some SSL benchmarks to CI > - > > Key: GEODE-7054 > URL: https://issues.apache.org/jira/browse/GEODE-7054 > Project: Geode > Issue Type: Improvement >Reporter: Murtuza Boxwala >Assignee: Murtuza Boxwala >Priority: Major > > Add task for running some benchmarks with SSL enabled. This task should run > in parallel with the current benchmark task. Should run targeted benchmarks. > Benchmarks: > * *GetBenchmark > * *PutBenchmark > Args: > -PwithSsl > Accpetance: > Benchmarks are stable between runs and don't cause numerous false failures. > May require adding story for adding parameter analyzer to specify alternative > threshold (default is 5%). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7054) Add some SSL benchmarks to CI
Murtuza Boxwala created GEODE-7054: -- Summary: Add some SSL benchmarks to CI Key: GEODE-7054 URL: https://issues.apache.org/jira/browse/GEODE-7054 Project: Geode Issue Type: Improvement Reporter: Murtuza Boxwala Add task for running some benchmarks with SSL enabled. This task should run in parallel with the current benchmark task. Should run targeted benchmarks. Benchmarks: * *GetBenchmark * *PutBenchmark Args: -PwithSsl Accpetance: Benchmarks are stable between runs and don't cause numerous false failures. May require adding story for adding parameter analyzer to specify alternative threshold (default is 5%). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
Kirk Lund created GEODE-7053:
Summary:
PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
fails intermittently in CI
Key: GEODE-7053
URL: https://issues.apache.org/jira/browse/GEODE-7053
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Kirk Lund
This test appears to be flaky and fails intermittently with:
{noformat}
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
readsInOtherMemberShouldPreventExpiration FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
in VM 0 running on Host 40e899358944 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-7051) Log4j dependency should be upgraded to 2.12.0
[
https://issues.apache.org/jira/browse/GEODE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901338#comment-16901338
]
Kirk Lund commented on GEODE-7051:
--
Investigate removal of {{log4j-api}} dependency from all modules except for
{{geode-core}}. This should still pull in {{log4j-api}} as a transitive
dependency.
Example dependencies in pom of {{geode-cq}}:
{noformat}
org.apache.geode
geode-core
compile
org.apache.logging.log4j
log4j-api
compile
{noformat}
> Log4j dependency should be upgraded to 2.12.0
> -
>
> Key: GEODE-7051
> URL: https://issues.apache.org/jira/browse/GEODE-7051
> Project: Geode
> Issue Type: Wish
> Components: build, logging
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Log4j dependency should be upgraded to 2.12.0 in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (GEODE-6964) Log4j configuration can be altered by adding geode-core to the classpath
[
https://issues.apache.org/jira/browse/GEODE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901296#comment-16901296
]
Kirk Lund edited comment on GEODE-6964 at 8/6/19 5:46 PM:
--
Notes for fixing this ticket:
* All code that uses {{log4j-core}} should move to new submodule
{{geode-log4j}} which will create its own jar file
* The {{log4j2.xml}} should move to {{geode-log4j}}
* Backport the above changes to {{1.9.x}} (and above) maintenance branches
See also https://issues.apache.org/jira/browse/GEODE-7051.
was (Author: klund):
Notes for fixing this ticket:
* All code that uses {{log4j-core}} should move to new submodule
{{geode-log4j}} which will create its own jar file
* The {{log4j2.xml}} should move to {{geode-log4j}}
* Backport the above changes to {{1.9.x}} (and above) maintenance branches
> Log4j configuration can be altered by adding geode-core to the classpath
>
>
> Key: GEODE-6964
> URL: https://issues.apache.org/jira/browse/GEODE-6964
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Stephane Nicoll
>Assignee: Kirk Lund
>Priority: Major
>
> {{geode-core}} ships with a {{log4j2.xml}} at the standard location which
> means that it is a candidate for bootstraping the logging infrastructure of
> any app using that library. See also #GEODE-189
> This is a problem when embedding this library in application that relies on
> the absence of such a file to derive a sensible default configuration
> (typically a Spring Boot app).
> In general, the hard dependency on log4j is a bit annoying for the embedded
> use case. There is more context available here:
> https://github.com/spring-projects/spring-boot-data-geode/issues/42
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (GEODE-6964) Log4j configuration can be altered by adding geode-core to the classpath
[
https://issues.apache.org/jira/browse/GEODE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901296#comment-16901296
]
Kirk Lund edited comment on GEODE-6964 at 8/6/19 5:45 PM:
--
Notes for fixing this ticket:
* All code that uses {{log4j-core}} should move to new submodule
{{geode-log4j}} which will create its own jar file
* The {{log4j2.xml}} should move to {{geode-log4j}}
* Backport the above changes to {{1.9.x}} (and above) maintenance branches
was (Author: klund):
Notes for fixing this ticket:
* All code that uses {{log4j-core}} should move to new submodule
{{geode-log4j}} which will create its own jar file
* The {{log4j2.xml}} should move to either {{geode-log4j}} or
{{geode-log4j-config}} -- users might want to use {{log4j2.xml}} without the
log4j-core code in {{geode-log4j}} especially for geode clients
* Backport the above changes to {{1.9.x}} (and above) maintenance branches
> Log4j configuration can be altered by adding geode-core to the classpath
>
>
> Key: GEODE-6964
> URL: https://issues.apache.org/jira/browse/GEODE-6964
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Stephane Nicoll
>Assignee: Kirk Lund
>Priority: Major
>
> {{geode-core}} ships with a {{log4j2.xml}} at the standard location which
> means that it is a candidate for bootstraping the logging infrastructure of
> any app using that library. See also #GEODE-189
> This is a problem when embedding this library in application that relies on
> the absence of such a file to derive a sensible default configuration
> (typically a Spring Boot app).
> In general, the hard dependency on log4j is a bit annoying for the embedded
> use case. There is more context available here:
> https://github.com/spring-projects/spring-boot-data-geode/issues/42
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-6964) Log4j configuration can be altered by adding geode-core to the classpath
[
https://issues.apache.org/jira/browse/GEODE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-6964:
Assignee: Kirk Lund
> Log4j configuration can be altered by adding geode-core to the classpath
>
>
> Key: GEODE-6964
> URL: https://issues.apache.org/jira/browse/GEODE-6964
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Stephane Nicoll
>Assignee: Kirk Lund
>Priority: Major
>
> {{geode-core}} ships with a {{log4j2.xml}} at the standard location which
> means that it is a candidate for bootstraping the logging infrastructure of
> any app using that library. See also #GEODE-189
> This is a problem when embedding this library in application that relies on
> the absence of such a file to derive a sensible default configuration
> (typically a Spring Boot app).
> In general, the hard dependency on log4j is a bit annoying for the embedded
> use case. There is more context available here:
> https://github.com/spring-projects/spring-boot-data-geode/issues/42
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (GEODE-7051) Log4j dependency should be upgraded to 2.12.0
[
https://issues.apache.org/jira/browse/GEODE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901331#comment-16901331
]
Kirk Lund edited comment on GEODE-7051 at 8/6/19 5:42 PM:
--
Notes on fixing this ticket:
* The {{geode-core}} dependency on {{log4j-core}} should also be changed to
{{optional}}
was (Author: klund):
Notes on fixing this ticket:
* The dependency on {{log4j-core}} should also be marked {{optional}}
> Log4j dependency should be upgraded to 2.12.0
> -
>
> Key: GEODE-7051
> URL: https://issues.apache.org/jira/browse/GEODE-7051
> Project: Geode
> Issue Type: Wish
> Components: build, logging
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Log4j dependency should be upgraded to 2.12.0 in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-7051) Log4j dependency should be upgraded to 2.12.0
[
https://issues.apache.org/jira/browse/GEODE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901331#comment-16901331
]
Kirk Lund commented on GEODE-7051:
--
Notes on fixing this ticket:
* The dependency on {{log4j-core}} should also be marked {{optional}}
> Log4j dependency should be upgraded to 2.12.0
> -
>
> Key: GEODE-7051
> URL: https://issues.apache.org/jira/browse/GEODE-7051
> Project: Geode
> Issue Type: Wish
> Components: build, logging
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Log4j dependency should be upgraded to 2.12.0 in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
[
https://issues.apache.org/jira/browse/GEODE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901304#comment-16901304
]
Kirk Lund commented on GEODE-7050:
--
Notes on fixing this ticket:
* Log4jAgent probably needs to check logger class before casting it
> Log4jAgent should avoid casting non-log4j loggers
> -
>
> Key: GEODE-7050
> URL: https://issues.apache.org/jira/browse/GEODE-7050
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Users should be able to use SLF4J API with Geode even when log4j-core is in
> the class path and the Geode log4j appenders are being used.
> Log4jAgent assumes that all Loggers are Log4J loggers. This can result in a
> ClassCastException when encountering an instance of SLF4JLogger.
> {noformat}
> Caused by: java.lang.ClassCastException: org.apache.logging.slf4j.SLF4JLogger
> cannot be cast to org.apache.logging.log4j.core.Logger
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:91)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:95)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:80)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:129)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:107)
> at
> org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:152)
> at
> org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:141)
> at
> org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:65)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:762)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:446)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:432)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:257)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:164)
> at
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:243)
> at
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:214)
> at
> org.springframework.data.gemfire.client.ClientCacheFactoryBean.createCache(ClientCacheFactoryBean.java:391)
> at
> org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:325)
> at
> org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:269)
> ... 107 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-6959) NPE if AlertAppender is not defined
[
https://issues.apache.org/jira/browse/GEODE-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901303#comment-16901303
]
Kirk Lund commented on GEODE-6959:
--
Notes for fixing this ticket:
* Write a regression test based on LogServiceWithCustomLogConfigIntegrationTest
and AlertAppenderIntegrationTest
* Ensure that use of AlertAppender is optional as intended
> NPE if AlertAppender is not defined
> ---
>
> Key: GEODE-6959
> URL: https://issues.apache.org/jira/browse/GEODE-6959
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
>
> NullPointer exception is produced if custom Log4j2.xml is used and
> AlertAppender is not defined.
>
> {code:java}
> 01:43:12.760 WARN [] JGRP39: 192.168.100.109:10100: failed to
> deliver OOB message [dst: 192.168.100.109:10100, src:
> 192.168.100.109:41000 (2 headers), size=208 bytes,
> flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2558)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1093)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:674)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1897)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1328)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> ~[geode-core-1.9.0.jar:?]
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.JChannel.up(JChannel.java:741)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> {code}
> I would propose to make AlertAppender optional.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-6964) Log4j configuration can be altered by adding geode-core to the classpath
[
https://issues.apache.org/jira/browse/GEODE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901296#comment-16901296
]
Kirk Lund commented on GEODE-6964:
--
Notes for fixing this ticket:
* All code that uses {{log4j-core}} should move to new submodule
{{geode-log4j}} which will create its own jar file
* The {{log4j2.xml}} should move to either {{geode-log4j}} or
{{geode-log4j-config}} -- users might want to use {{log4j2.xml}} without the
log4j-core code in {{geode-log4j}} especially for geode clients
* Backport the above changes to {{1.9.x}} (and above) maintenance branches
> Log4j configuration can be altered by adding geode-core to the classpath
>
>
> Key: GEODE-6964
> URL: https://issues.apache.org/jira/browse/GEODE-6964
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Stephane Nicoll
>Priority: Major
>
> {{geode-core}} ships with a {{log4j2.xml}} at the standard location which
> means that it is a candidate for bootstraping the logging infrastructure of
> any app using that library. See also #GEODE-189
> This is a problem when embedding this library in application that relies on
> the absence of such a file to derive a sensible default configuration
> (typically a Spring Boot app).
> In general, the hard dependency on log4j is a bit annoying for the embedded
> use case. There is more context available here:
> https://github.com/spring-projects/spring-boot-data-geode/issues/42
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-6959) NPE if AlertAppender is not defined
[
https://issues.apache.org/jira/browse/GEODE-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6959:
-
Affects Version/s: 1.9.0
> NPE if AlertAppender is not defined
> ---
>
> Key: GEODE-6959
> URL: https://issues.apache.org/jira/browse/GEODE-6959
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
>
> NullPointer exception is produced if custom Log4j2.xml is used and
> AlertAppender is not defined.
>
> {code:java}
> 01:43:12.760 WARN [] JGRP39: 192.168.100.109:10100: failed to
> deliver OOB message [dst: 192.168.100.109:10100, src:
> 192.168.100.109:41000 (2 headers), size=208 bytes,
> flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2558)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1093)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:674)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1897)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1328)
> ~[geode-core-1.9.0.jar:?]
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> ~[geode-core-1.9.0.jar:?]
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.JChannel.up(JChannel.java:741)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> ~[jgroups-3.6.14.Final.jar:3.6.14.Final]
> {code}
> I would propose to make AlertAppender optional.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-7052) create a rolling-upgrade test for session caching
Bruce Schuchardt created GEODE-7052: --- Summary: create a rolling-upgrade test for session caching Key: GEODE-7052 URL: https://issues.apache.org/jira/browse/GEODE-7052 Project: Geode Issue Type: Bug Components: extensions, http session Reporter: Bruce Schuchardt There is no rolling-upgrade test for our session caching module. Let's create one! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7051) Log4j dependency should be upgraded to 2.12.0
[ https://issues.apache.org/jira/browse/GEODE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7051: - Issue Type: Wish (was: Bug) > Log4j dependency should be upgraded to 2.12.0 > - > > Key: GEODE-7051 > URL: https://issues.apache.org/jira/browse/GEODE-7051 > Project: Geode > Issue Type: Wish > Components: build, logging >Reporter: Kirk Lund >Priority: Major > > Log4j dependency should be upgraded to 2.12.0 in Geode. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7051) Log4j dependency should be upgraded to 2.12.0
[ https://issues.apache.org/jira/browse/GEODE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-7051: Assignee: Kirk Lund > Log4j dependency should be upgraded to 2.12.0 > - > > Key: GEODE-7051 > URL: https://issues.apache.org/jira/browse/GEODE-7051 > Project: Geode > Issue Type: Wish > Components: build, logging >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Log4j dependency should be upgraded to 2.12.0 in Geode. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7051) Log4j dependency should be upgraded to 2.12.0
Kirk Lund created GEODE-7051: Summary: Log4j dependency should be upgraded to 2.12.0 Key: GEODE-7051 URL: https://issues.apache.org/jira/browse/GEODE-7051 Project: Geode Issue Type: Bug Components: build, logging Reporter: Kirk Lund Log4j dependency should be upgraded to 2.12.0 in Geode. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
Kirk Lund created GEODE-7050:
Summary: Log4jAgent should avoid casting non-log4j loggers
Key: GEODE-7050
URL: https://issues.apache.org/jira/browse/GEODE-7050
Project: Geode
Issue Type: Bug
Components: logging
Reporter: Kirk Lund
Users should be able to use SLF4J API with Geode even when log4j-core is in the
class path and the Geode log4j appenders are being used.
Log4jAgent assumes that all Loggers are Log4J loggers. This can result in a
ClassCastException when encountering an instance of SLF4JLogger.
{noformat}
Caused by: java.lang.ClassCastException: org.apache.logging.slf4j.SLF4JLogger
cannot be cast to org.apache.logging.log4j.core.Logger
at
org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:91)
at
org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:95)
at
org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:80)
at
org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:129)
at
org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:107)
at
org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:152)
at
org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:141)
at
org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:65)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:762)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:446)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:432)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:257)
at
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:164)
at
org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:243)
at
org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:214)
at
org.springframework.data.gemfire.client.ClientCacheFactoryBean.createCache(ClientCacheFactoryBean.java:391)
at
org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:325)
at
org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:269)
... 107 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
[
https://issues.apache.org/jira/browse/GEODE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-7050:
-
Affects Version/s: 1.9.0
> Log4jAgent should avoid casting non-log4j loggers
> -
>
> Key: GEODE-7050
> URL: https://issues.apache.org/jira/browse/GEODE-7050
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.9.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Users should be able to use SLF4J API with Geode even when log4j-core is in
> the class path and the Geode log4j appenders are being used.
> Log4jAgent assumes that all Loggers are Log4J loggers. This can result in a
> ClassCastException when encountering an instance of SLF4JLogger.
> {noformat}
> Caused by: java.lang.ClassCastException: org.apache.logging.slf4j.SLF4JLogger
> cannot be cast to org.apache.logging.log4j.core.Logger
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:91)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:95)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:80)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:129)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:107)
> at
> org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:152)
> at
> org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:141)
> at
> org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:65)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:762)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:446)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:432)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:257)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:164)
> at
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:243)
> at
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:214)
> at
> org.springframework.data.gemfire.client.ClientCacheFactoryBean.createCache(ClientCacheFactoryBean.java:391)
> at
> org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:325)
> at
> org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:269)
> ... 107 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-7050) Log4jAgent should avoid casting non-log4j loggers
[
https://issues.apache.org/jira/browse/GEODE-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-7050:
Assignee: Kirk Lund
> Log4jAgent should avoid casting non-log4j loggers
> -
>
> Key: GEODE-7050
> URL: https://issues.apache.org/jira/browse/GEODE-7050
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Users should be able to use SLF4J API with Geode even when log4j-core is in
> the class path and the Geode log4j appenders are being used.
> Log4jAgent assumes that all Loggers are Log4J loggers. This can result in a
> ClassCastException when encountering an instance of SLF4JLogger.
> {noformat}
> Caused by: java.lang.ClassCastException: org.apache.logging.slf4j.SLF4JLogger
> cannot be cast to org.apache.logging.log4j.core.Logger
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getRootLoggerContext(Log4jAgent.java:91)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.getConfiguration(Log4jAgent.java:95)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.isUsingGemFireDefaultConfig(Log4jAgent.java:80)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.shouldUpdateLogLevels(Log4jAgent.java:129)
> at
> org.apache.geode.internal.logging.log4j.Log4jAgent.configure(Log4jAgent.java:107)
> at
> org.apache.geode.internal.logging.Configuration.configChanged(Configuration.java:152)
> at
> org.apache.geode.internal.logging.Configuration.initialize(Configuration.java:141)
> at
> org.apache.geode.internal.logging.LoggingSession.createSession(LoggingSession.java:65)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:762)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:446)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:432)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:257)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:164)
> at
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:243)
> at
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:214)
> at
> org.springframework.data.gemfire.client.ClientCacheFactoryBean.createCache(ClientCacheFactoryBean.java:391)
> at
> org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:325)
> at
> org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:269)
> ... 107 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-1359) Cleanup CliCommandTestBase tests
[ https://issues.apache.org/jira/browse/GEODE-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901205#comment-16901205 ] Alberto Bustamante Reyes commented on GEODE-1359: - hi [~klund], I think the sub-tasks of this ticket are already done. I have not found CliCommandTestBase in the code, and I found that GEODE-3530 was doing the same as this ticket (removing CliCommandTestBase). Is it ok if I close all of them? > Cleanup CliCommandTestBase tests > > > Key: GEODE-1359 > URL: https://issues.apache.org/jira/browse/GEODE-1359 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Priority: Major > > Cleanup CliCommandTestBase tests > * Fix up potential time sensitivity issues. > * Ensure output goes to TemporaryFolder. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-3353) Refactor QueueCommandsDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901194#comment-16901194
]
Alberto Bustamante Reyes commented on GEODE-3353:
-
QueueCommandsDUnitTest was removed by https://github.com/apache/geode/pull/1093
> Refactor QueueCommandsDUnitTest to use test rules
> -
>
> Key: GEODE-3353
> URL: https://issues.apache.org/jira/browse/GEODE-3353
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Priority: Major
>
> {{QueueCommandsDUnitTest}} is using {{CliCommandTestBase}}, which is a
> deprecated class. It should be refactored to use more current test rules.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-3347) Refacor ListAndDescribeDiskStoreCommandsDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901190#comment-16901190
]
Alberto Bustamante Reyes commented on GEODE-3347:
-
The tests in
{code}geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListAndDescribeDiskStoreCommandsDUnitTest.java{code}
were splitted into
{code}geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeDiskStoreCommandIntegrationTest.java
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListDiskStoreCommandIntegrationTest.java{code}
by a commit of GEODE-3539 (
https://gitbox.apache.org/repos/asf?p=geode.git;h=f3a0219 )
> Refacor ListAndDescribeDiskStoreCommandsDUnitTest to use test rules
> ---
>
> Key: GEODE-3347
> URL: https://issues.apache.org/jira/browse/GEODE-3347
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Priority: Major
>
> {{ListAndDescribeDiskStoreCommandsDUnitTest}} is using
> {{CliCommandTestBase}}, which is a deprecated class. It should be refactored
> to use more current test rules.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-3343) Reactor GemfireDataCommandsDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901183#comment-16901183
]
Alberto Bustamante Reyes commented on GEODE-3343:
-
The file
{code}geode-core/src/distributedTest/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java{code}
was moved to
{code}geode-dunit/src/main/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTestBase.java{code}
by https://github.com/apache/geode/pull/2325/
> Reactor GemfireDataCommandsDUnitTest to use test rules
> --
>
> Key: GEODE-3343
> URL: https://issues.apache.org/jira/browse/GEODE-3343
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Priority: Major
>
> {{GemfireDataCommandsDUnitTest}} is using {{CliCommandTestBase}}, which is a
> deprecated class. It should be refactored to use more current test rules.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-7012) Distributed deadlock with StartupMessages if executor pools get full
[ https://issues.apache.org/jira/browse/GEODE-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901177#comment-16901177 ] ASF subversion and git services commented on GEODE-7012: Commit 43e02edaff74e2827d7ab0b8a765d8b7ee630521 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=43e02ed ] Merge pull request #3877 from Bill/feature/GEODE-7012 GEODE-7012: Failure in upgrade testing - upgrading 1.9 to 1.10 > Distributed deadlock with StartupMessages if executor pools get full > > > Key: GEODE-7012 > URL: https://issues.apache.org/jira/browse/GEODE-7012 > Project: Geode > Issue Type: Bug >Affects Versions: 1.10.0 >Reporter: Dan Smith >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We hit a distributed deadlock in one of our tests where two members are hung > sending startup messages to each other. > It turns out that until a member gets a response to a StartupMessage, it is > in a state where it blocks all outgoing messages. At the same time, the > member is receiving an attempting to respond to other messages, but those > responses get blocked. If too many messages come in before the > StartupResponseMessage, this ends up filling up the > ClusterDistributionManager.highPriorityPool. > If two members are trying to start up at the same time, and they both fill up > the highPriorityPool, they both will fail to process each other's > StartupMessage, because that message is executed in the same pool. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7012) Distributed deadlock with StartupMessages if executor pools get full
[ https://issues.apache.org/jira/browse/GEODE-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901178#comment-16901178 ] ASF subversion and git services commented on GEODE-7012: Commit 43e02edaff74e2827d7ab0b8a765d8b7ee630521 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=43e02ed ] Merge pull request #3877 from Bill/feature/GEODE-7012 GEODE-7012: Failure in upgrade testing - upgrading 1.9 to 1.10 > Distributed deadlock with StartupMessages if executor pools get full > > > Key: GEODE-7012 > URL: https://issues.apache.org/jira/browse/GEODE-7012 > Project: Geode > Issue Type: Bug >Affects Versions: 1.10.0 >Reporter: Dan Smith >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We hit a distributed deadlock in one of our tests where two members are hung > sending startup messages to each other. > It turns out that until a member gets a response to a StartupMessage, it is > in a state where it blocks all outgoing messages. At the same time, the > member is receiving an attempting to respond to other messages, but those > responses get blocked. If too many messages come in before the > StartupResponseMessage, this ends up filling up the > ClusterDistributionManager.highPriorityPool. > If two members are trying to start up at the same time, and they both fill up > the highPriorityPool, they both will fail to process each other's > StartupMessage, because that message is executed in the same pool. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Description:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
clients allow to pass a timeout parameter on a function execution basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
was:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
clients allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
> Add timeout parameter to Java native client Execution::execute() methods
> -
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> The Java native client only allows to set a timeout to functions by means of
> a system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C#
> native clients allow to pass a timeout parameter on a function execution
> basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez updated GEODE-7049:
-
Description:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
clients allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
was:
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
client allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
> Add timeout parameter to Java native client Execution::execute() methods
> -
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> The Java native client only allows to set a timeout to functions by means of
> a system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C#
> native clients allow to pass a timeout parameter on a function invocation
> basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-3376) Refactor RebalanceCommandOverHttpDistributedTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901167#comment-16901167
]
Alberto Bustamante Reyes commented on GEODE-3376:
-
The file
{code}geode-core/src/distributedTest/java/org/apache/geode/management/internal/cli/commands/RebalanceCommandDistributedTest.java{code}
was moved to
{code}geode-dunit/src/main/java/org/apache/geode/management/internal/cli/commands/RebalanceCommandDistributedTestBase.java{code}
by https://github.com/apache/geode/pull/2325/
> Refactor RebalanceCommandOverHttpDistributedTest to use test rules
> --
>
> Key: GEODE-3376
> URL: https://issues.apache.org/jira/browse/GEODE-3376
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Priority: Major
>
> {{RebalanceCommandOverHttpDistributedTest}} is using {{CliCommandTestBase}},
> which is a deprecated class. It should be refactored to use more current test
> rules.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
[
https://issues.apache.org/jira/browse/GEODE-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Gomez reassigned GEODE-7049:
Assignee: Alberto Gomez
> Add timeout parameter to Java native client Execution::execute() methods
> -
>
> Key: GEODE-7049
> URL: https://issues.apache.org/jira/browse/GEODE-7049
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> The Java native client only allows to set a timeout to functions by means of
> a system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C#
> native client allow to pass a timeout parameter on a function invocation
> basis.
> It will be good to have the same functionality on the Java native client by
> means of having the following methods on the Execution interface:
>
> {code:java}
> ResultCollector execute(Function function, int timeoutMs) throws
> FunctionException;
> ResultCollector execute(String functionId, int timeoutMs) throws
> FunctionException;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-7049) Add timeout parameter to Java native client Execution::execute() methods
Alberto Gomez created GEODE-7049:
Summary: Add timeout parameter to Java native client
Execution::execute() methods
Key: GEODE-7049
URL: https://issues.apache.org/jira/browse/GEODE-7049
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Alberto Gomez
The Java native client only allows to set a timeout to functions by means of a
system property (gemfire.CLIENT_FUNCTION_TIMEOUT) while the C++ and C# native
client allow to pass a timeout parameter on a function invocation basis.
It will be good to have the same functionality on the Java native client by
means of having the following methods on the Execution interface:
{code:java}
ResultCollector execute(Function function, int timeoutMs) throws
FunctionException;
ResultCollector execute(String functionId, int timeoutMs) throws
FunctionException;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-3346) Refactor GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901151#comment-16901151
]
Alberto Bustamante Reyes commented on GEODE-3346:
-
GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest was removed by
following PR:
[https://github.com/apache/geode/pull/966]
> Refactor GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest to use
> test rules
>
>
> Key: GEODE-3346
> URL: https://issues.apache.org/jira/browse/GEODE-3346
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Priority: Major
>
> {{GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest}} is using
> {{CliCommandTestBase}}, which is a deprecated class. It should be refactored
> to use more current test rules.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-3343) Reactor GemfireDataCommandsDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes updated GEODE-3343:
Description: {{GemfireDataCommandsDUnitTest}} is using
{{CliCommandTestBase}}, which is a deprecated class. It should be refactored to
use more current test rules. (was: {{GemfireDataCommandsDUnitTest}} is using
{{CliCommandTestBase}}, which is a deprecated class. It should be refactored to
use more current test rules.Style)
> Reactor GemfireDataCommandsDUnitTest to use test rules
> --
>
> Key: GEODE-3343
> URL: https://issues.apache.org/jira/browse/GEODE-3343
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Priority: Major
>
> {{GemfireDataCommandsDUnitTest}} is using {{CliCommandTestBase}}, which is a
> deprecated class. It should be refactored to use more current test rules.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-3343) Reactor GemfireDataCommandsDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes updated GEODE-3343:
Description: {{GemfireDataCommandsDUnitTest}} is using
{{CliCommandTestBase}}, which is a deprecated class. It should be refactored to
use more current test rules.Style (was: {{GemfireDataCommandsDUnitTest}} is
using {{CliCommandTestBase}}, which is a deprecated class. It should be
refactored to use more current test rules.)
> Reactor GemfireDataCommandsDUnitTest to use test rules
> --
>
> Key: GEODE-3343
> URL: https://issues.apache.org/jira/browse/GEODE-3343
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Priority: Major
>
> {{GemfireDataCommandsDUnitTest}} is using {{CliCommandTestBase}}, which is a
> deprecated class. It should be refactored to use more current test rules.Style
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7048) Remove dead code in GatewaySenderBatchOp
[ https://issues.apache.org/jira/browse/GEODE-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-7048: Priority: Trivial (was: Major) > Remove dead code in GatewaySenderBatchOp > > > Key: GEODE-7048 > URL: https://issues.apache.org/jira/browse/GEODE-7048 > Project: Geode > Issue Type: Bug >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > I found out that executeOn function has an if-else with duplicated code. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7048) Remove dead code in GatewaySenderBatchOp
[ https://issues.apache.org/jira/browse/GEODE-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-7048: Labels: pull-request-available (was: ) > Remove dead code in GatewaySenderBatchOp > > > Key: GEODE-7048 > URL: https://issues.apache.org/jira/browse/GEODE-7048 > Project: Geode > Issue Type: Bug >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Trivial > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > I found out that executeOn function has an if-else with duplicated code. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7048) Remove dead code in GatewaySenderBatchOp
Alberto Bustamante Reyes created GEODE-7048: --- Summary: Remove dead code in GatewaySenderBatchOp Key: GEODE-7048 URL: https://issues.apache.org/jira/browse/GEODE-7048 Project: Geode Issue Type: Bug Reporter: Alberto Bustamante Reyes I found out that executeOn function has an if-else with duplicated code. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7048) Remove dead code in GatewaySenderBatchOp
[ https://issues.apache.org/jira/browse/GEODE-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-7048: --- Assignee: Alberto Bustamante Reyes > Remove dead code in GatewaySenderBatchOp > > > Key: GEODE-7048 > URL: https://issues.apache.org/jira/browse/GEODE-7048 > Project: Geode > Issue Type: Bug >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > I found out that executeOn function has an if-else with duplicated code. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
