[jira] [Commented] (GEODE-5212) Many distributedTest and integrationTest failures on windows
[ https://issues.apache.org/jira/browse/GEODE-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555129#comment-16555129 ] ASF subversion and git services commented on GEODE-5212: Commit ecbe5ce702d713d821b4b9e8abdeeac49a12bbc3 in geode's branch refs/heads/develop from [~sai.boorlaga...@gmail.com] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ecbe5ce ] GEODE-5212: Consider property testCategory for upgradeTest gradle task (#2190) > Many distributedTest and integrationTest failures on windows > > > Key: GEODE-5212 > URL: https://issues.apache.org/jira/browse/GEODE-5212 > Project: Geode > Issue Type: Task > Components: general, gfsh >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available, windows > Time Spent: 2h 10m > Remaining Estimate: 0h > > Windows regressions currently fail spectacularly. The primary culprits > appear to be based around filesystem I/O and passing the current working > directory to members started by our testing framework. > > The scope of this ticket will be defined by "refactors" as children tickets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5429) SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5429:
--
Labels: pull-request-available swat (was: swat)
> SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
> ---
>
> Key: GEODE-5429
> URL: https://issues.apache.org/jira/browse/GEODE-5429
> Project: Geode
> Issue Type: Task
>Reporter: Dan Smith
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available, swat
>
> Several of the test in this class failed multiple times in a pass over 200
> runs of DistributedTest.
> {noformat}
> 16 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSimpleSSLWithMultiKey_KeyStore_WithInvalidClientKey
> (94.02985074626866% success rate)
> 7 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv12ProtocolLegacy
> (97.38805970149254% success rate)
> 5 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithoutKeyStoreTypeLegacy
> (98.13432835820896% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv11Protocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite
> (99.25373134328358% success rate)
> 1 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocolLegacy
> (99.6268656716418% success rate)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5429) SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-5429:
--
Assignee: Mark Hanson
> SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
> ---
>
> Key: GEODE-5429
> URL: https://issues.apache.org/jira/browse/GEODE-5429
> Project: Geode
> Issue Type: Task
>Reporter: Dan Smith
>Assignee: Mark Hanson
>Priority: Major
> Labels: swat
>
> Several of the test in this class failed multiple times in a pass over 200
> runs of DistributedTest.
> {noformat}
> 16 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSimpleSSLWithMultiKey_KeyStore_WithInvalidClientKey
> (94.02985074626866% success rate)
> 7 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv12ProtocolLegacy
> (97.38805970149254% success rate)
> 5 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithoutKeyStoreTypeLegacy
> (98.13432835820896% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv11Protocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite
> (99.25373134328358% success rate)
> 1 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocolLegacy
> (99.6268656716418% success rate)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5429) SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-5429:
--
Assignee: (was: Mark Hanson)
> SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
> ---
>
> Key: GEODE-5429
> URL: https://issues.apache.org/jira/browse/GEODE-5429
> Project: Geode
> Issue Type: Task
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> Several of the test in this class failed multiple times in a pass over 200
> runs of DistributedTest.
> {noformat}
> 16 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSimpleSSLWithMultiKey_KeyStore_WithInvalidClientKey
> (94.02985074626866% success rate)
> 7 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv12ProtocolLegacy
> (97.38805970149254% success rate)
> 5 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithoutKeyStoreTypeLegacy
> (98.13432835820896% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv11Protocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite
> (99.25373134328358% success rate)
> 1 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocolLegacy
> (99.6268656716418% success rate)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5429) SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554967#comment-16554967
]
Mark Hanson commented on GEODE-5429:
This looks to be an issue of the test machine that needs the "Java Cryptography
Extension (JCE) Unlimited Strength Jurisdiction Policy Files" for Java 8
[http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html]
Once installed the tests should pass.
> SUPERFLAKY: Multiple failures from RestAPIsWithSSLDUnitTest
> ---
>
> Key: GEODE-5429
> URL: https://issues.apache.org/jira/browse/GEODE-5429
> Project: Geode
> Issue Type: Task
>Reporter: Dan Smith
>Assignee: Mark Hanson
>Priority: Major
> Labels: swat
>
> Several of the test in this class failed multiple times in a pass over 200
> runs of DistributedTest.
> {noformat}
> 16 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSimpleSSLWithMultiKey_KeyStore_WithInvalidClientKey
> (94.02985074626866% success rate)
> 7 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv12ProtocolLegacy
> (97.38805970149254% success rate)
> 5 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithoutKeyStoreTypeLegacy
> (98.13432835820896% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithTLSv11Protocol
> (99.25373134328358% success rate)
> 2 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite
> (99.25373134328358% success rate)
> 1 failures
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testWithMultipleProtocolLegacy
> (99.6268656716418% success rate)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5469) Pulse per-member region stats do not work for member names with hyphen(s)
[
https://issues.apache.org/jira/browse/GEODE-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5469:
--
Labels: pull-request-available (was: )
> Pulse per-member region stats do not work for member names with hyphen(s)
> -
>
> Key: GEODE-5469
> URL: https://issues.apache.org/jira/browse/GEODE-5469
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Andrey Zolotov
>Priority: Minor
> Labels: pull-request-available
>
> In Region View screen, when you hover over the members for the region on the
> left, the stats and charts do not have any data if the member name contains
> hyphens or other special cha.
> The fix is to replace occurences of *.' + memberName + '.* with *["' +
> memberName + '"].* in PulseCallbacks.js and RegionView.js, forcing the name
> to be treated as single string.
> example diff for one of the lines:
> {code:java}
> - key = 'memberOnRegionJson.' + memberName + '.entryCount';
> + key = 'memberOnRegionJson["' + memberName + '"].entryCount';{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5468) Make line separators platform independent
[ https://issues.apache.org/jira/browse/GEODE-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554916#comment-16554916 ] ASF subversion and git services commented on GEODE-5468: Commit 3192d62a86d344dde6a041145e9b31125f197e9f in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3192d62 ] GEODE-5468: Make line separators platform independent (#2178) > Make line separators platform independent > - > > Key: GEODE-5468 > URL: https://issues.apache.org/jira/browse/GEODE-5468 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5474) Fix test flakiness in DiskRegionAsyncRecoveryJUnitTest and DiskOldAPIsJUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5474:
--
Labels: pull-request-available (was: )
> Fix test flakiness in DiskRegionAsyncRecoveryJUnitTest and
> DiskOldAPIsJUnitTest
> ---
>
> Key: GEODE-5474
> URL: https://issues.apache.org/jira/browse/GEODE-5474
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> These tests will fail intermittently with:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.geode.internal.cache.AbstractDiskRegion.markInitialized(AbstractDiskRegion.java:417)
> at
> org.apache.geode.internal.cache.DiskInitFile.cmnMarkInitialized(DiskInitFile.java:1181)
> at
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2273)
> at
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3059)
> at
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:594)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:376)
> at
> org.apache.geode.internal.cache.DistributedRegion.cleanUpDestroyedTokensAndMarkGIIComplete(DistributedRegion.java:1506)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1288)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1082)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3087)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2982)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2970)
> at
> org.apache.geode.internal.cache.DiskOldAPIsJUnitTest.doSyncBitTest(DiskOldAPIsJUnitTest.java:107)
> at
> org.apache.geode.internal.cache.DiskOldAPIsJUnitTest.testSyncBit(DiskOldAPIsJUnitTest.java:86)
> at sun.reflect.GeneratedMethodAccessor333.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:67)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5212) Many distributedTest and integrationTest failures on windows
[ https://issues.apache.org/jira/browse/GEODE-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554914#comment-16554914 ] ASF subversion and git services commented on GEODE-5212: Commit b702fb451c119cea944ef33d8ea4973da5e1856c in geode's branch refs/heads/develop from [~sai.boorlaga...@gmail.com] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b702fb4 ] GEODE-5212: Added a test task to run Gfsh distributed tests (#2164) * Added a project property 'testCategory' to allow developers to run a specific category of tests. * Removed duplicate definition for an integrationTest task > Many distributedTest and integrationTest failures on windows > > > Key: GEODE-5212 > URL: https://issues.apache.org/jira/browse/GEODE-5212 > Project: Geode > Issue Type: Task > Components: general, gfsh >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available, windows > Time Spent: 1h 50m > Remaining Estimate: 0h > > Windows regressions currently fail spectacularly. The primary culprits > appear to be based around filesystem I/O and passing the current working > directory to members started by our testing framework. > > The scope of this ticket will be defined by "refactors" as children tickets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5474) Fix test flakiness in DiskRegionAsyncRecoveryJUnitTest and DiskOldAPIsJUnitTest
Jens Deppe created GEODE-5474:
-
Summary: Fix test flakiness in DiskRegionAsyncRecoveryJUnitTest
and DiskOldAPIsJUnitTest
Key: GEODE-5474
URL: https://issues.apache.org/jira/browse/GEODE-5474
Project: Geode
Issue Type: Bug
Components: core
Reporter: Jens Deppe
These tests will fail intermittently with:
{noformat}
java.lang.AssertionError
at
org.apache.geode.internal.cache.AbstractDiskRegion.markInitialized(AbstractDiskRegion.java:417)
at
org.apache.geode.internal.cache.DiskInitFile.cmnMarkInitialized(DiskInitFile.java:1181)
at
org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2273)
at
org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3059)
at
org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:594)
at
org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:376)
at
org.apache.geode.internal.cache.DistributedRegion.cleanUpDestroyedTokensAndMarkGIIComplete(DistributedRegion.java:1506)
at
org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1288)
at
org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1082)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3087)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2982)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2970)
at
org.apache.geode.internal.cache.DiskOldAPIsJUnitTest.doSyncBitTest(DiskOldAPIsJUnitTest.java:107)
at
org.apache.geode.internal.cache.DiskOldAPIsJUnitTest.testSyncBit(DiskOldAPIsJUnitTest.java:86)
at sun.reflect.GeneratedMethodAccessor333.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:67)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5473) Docs page describing how to use the query api
Addison created GEODE-5473: -- Summary: Docs page describing how to use the query api Key: GEODE-5473 URL: https://issues.apache.org/jira/browse/GEODE-5473 Project: Geode Issue Type: Sub-task Components: native client Reporter: Addison As a user, I want to be able to see a page describing geode native's query api for both C++ and .NET so that I can issue OQL statements in the most efficient way possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5450) Creating a JNDI binding w/o a username or password leads to NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5450:
--
Labels: pull-request-available (was: )
> Creating a JNDI binding w/o a username or password leads to
> NullPointerException
>
>
> Key: GEODE-5450
> URL: https://issues.apache.org/jira/browse/GEODE-5450
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Bradford D. Boyle
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
>
> If a user creates a JNDI binding through gfsh and they omit either the
> username or password, then they will get a `NullPointerException` when they
> try to get a JDBC connection.
>
> Here is a stack trace:
> {code}
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:94)
> at
> io.pivotal.gemfire.PostgresVersionFunction.execute(PostgresVersionFunction.java:33)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution$2.run(AbstractExecution.java:302)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$9$1.run(ClusterDistributionManager.java:990)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> You can reproduce this with the following function:
> {code:language=java}
> public class PostgresVersionFunction implements Function {
> @Override
> public void execute(FunctionContext context) {
> String[] arguments = (String[]) context.getArguments();
> String dataSourceName = arguments[0];
> LogManager.getLogger().info("[datasource=" +
> context.getArguments()+"]");
> Context ctx = JNDIInvoker.getJNDIContext();
> DataSource dataSource;
> try {
> dataSource = (DataSource) ctx.lookup("java:/" + dataSourceName);
> } catch (Exception e) {
> // TODO exception handling.
> LogManager.getLogger().error(e.getMessage(), e);
> context.getResultSender().lastResult(e);
> return;
> }
> try (Connection connection = dataSource.getConnection();
> Statement statement = connection.createStatement()
> ) {
> ResultSet resultSet = statement.executeQuery("SELECT VERSION();");
> resultSet.next();
> context.getResultSender().lastResult(resultSet.getString(1));
> } catch (SQLException e) {
> context.getResultSender().lastResult(e);
> }
> }
> }
> {code}
> and the following gfsh commands:
> {code}
> start locator --name=locator --include-system-classpath
> start server --name=server1 --include-system-classpath
> deploy --jar=/root/gemfire-greenplum/simple-function.jar
> create jndi-binding --name=datasource --type=SIMPLE
> --jdbc-driver-class="org.postgresql.Driver"
> --connection-url="jdbc:postgresql://localhost:5432/gpadmin"
> execute function --id=io.pivotal.gemfire.PostgresVersionFunction
> --arguments=datasource
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5470) DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED
[ https://issues.apache.org/jira/browse/GEODE-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-5470: --- Description: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139 org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:255] java.lang.RuntimeException: test failed [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:256] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict(DlockAndTxlockRegressionTest.java:161) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:257] [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:258] Caused by: [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:259] java.lang.RuntimeException: dlock failed to prevent a transaction conflict [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:260] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:234) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:261] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.lambda$testDLockProtectsAgainstTransactionConflict$bb17a952$5(DlockAndTxlockRegressionTest.java:123) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:262] [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:263] Caused by: [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:264] org.apache.geode.cache.CommitConflictException: Concurrent transaction commit detected The key TestKey in region /TestRegion was being modified by another transaction locally. [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:265] at org.apache.geode.internal.cache.locks.TXLockServiceImpl.txLock(TXLockServiceImpl.java:137) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:266] at org.apache.geode.internal.cache.TXLockRequest.obtain(TXLockRequest.java:88) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:267] at org.apache.geode.internal.cache.TXState.reserveAndCheck(TXState.java:340) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:268] at org.apache.geode.internal.cache.TXState.commit(TXState.java:411) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:269] at org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:210) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:270] at org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:413) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:271] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:232) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:272] ... 1 more was: org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:255] java.lang.RuntimeException: test failed [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:256] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict(DlockAndTxlockRegressionTest.java:161) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:257] [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:258] Caused by: [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:259] java.lang.RuntimeException: dlock failed to prevent a transaction conflict [
[jira] [Commented] (GEODE-4728) Geode Native Documentation Improvements
[ https://issues.apache.org/jira/browse/GEODE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554852#comment-16554852 ] ASF subversion and git services commented on GEODE-4728: Commit 07e3865e4cb606a47448c7dfc9da80eb5d6ade60 in geode-native's branch refs/heads/develop from [~dbarnes97] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=07e3865 ] GEODE-4728: User Guide -Modify data serialization navigation > Geode Native Documentation Improvements > --- > > Key: GEODE-4728 > URL: https://issues.apache.org/jira/browse/GEODE-4728 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 3h 40m > Remaining Estimate: 0h > > This ticket will capture a series of changes to the Geode Native docs to > bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5256) GFSH Start Server Command Parameters Overridden by Default Values
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554833#comment-16554833
]
ASF subversion and git services commented on GEODE-5256:
Commit 667fbb4176c2f9bf8e399809b1c46f744486c3cd in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=667fbb4 ]
GEODE-5256: Parameters Precedence in Start Server (#2013)
* GEODE-5256: Parameters Precedence in Start Server
Configuration options set as part of the `start server` command now
take precedence over those configured in the `cache.xml` file, the
`cluster-configuration-service` and defaults.
- Rebased against latest develop branch.
- Removed unused `throws` clauses from tests.
- Renamed `ServerLauncherIntegrationTest` to
`ServerLauncherBuilderIntegrationTest`.
- Added tests for `ServerLauncher` and `CacheCreation`.
- Added acceptance tests for `gfsh start server` command.
- Fixed `ServerLauncher.parseArguments` method, it was wrongly calling
`setMaxConnections` for other unrelated parameters (maxMessageCount,
messageTimeToLive and sockerBufferSize).
- The `ServerLauncher` class now sets all the relevent startup
parameters during initialization within the static `parameters` field
on `CacheServerLauncher` class. The `CacheCreation` class, in turn,
reconfigures the `Server` attributes using
`CacheServerLauncher.parameters` before starting the `AcceptorImpl`.
* GEODE-5256: Changes requested by reviewers
- Rebased against latest develop branch.
- Replaced `Wait` references for `Awaitility` in related tests.
- Class `CacheServerLauncher.Parameters` is now a top level class.
- Added `@Deprecated` annotation and docs for `CacheServerLauncher`.
- `StartServerCommandAcceptanceTest` now uses `FileUtils` instead of
manually opening and reading the log file.
> GFSH Start Server Command Parameters Overridden by Default Values
> -
>
> Key: GEODE-5256
> URL: https://issues.apache.org/jira/browse/GEODE-5256
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Attachments: workspace.zip
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello team,
> The order on which we apply the cache configuration vs the startup parameters
> when starting servers through {{gfs}} seems to be wrong.
> No matter whether the cache is configured through a local {{cache.xml}} or
> the cluster configuration service, internally we end up parsing the
> configuration using {{CacheXmlParser}} and {{CacheCreation}} classes. The
> class {{CacheCreation}} creates a server through {{CacheServerCreation}} and
> this one extends {{AbstractCacheServer}}, which has some default values
> configured, overriding the values set by the startup parameters.
> I've been able to reproduce this for the {{max-connections}} configuration
> property specifically but right now a bunch of parameters are completely
> ignored if a {{cache.xml}} file is specified or if the
> {{cluster-configuration-service}} is enabled, no matter if the actual
> parameter is specifically configured or not, the default values are always
> used. In fact, the only parameters that seem to override the {{cache.xml}} /
> {{cluster-configuration}} are {{serverPort}}, {{serverBindAddress}} and
> {{disableDefaultServer}}, they are communicated between the
> {{ServerLauncher}} and {{CacheCreation}} classes through public static fields
> in the {{CacheServerLauncher}} class.
> As an example, after adding some extra logging on the
> {{setMaxConnections()}} method, below is the output shown when starting the
> server:
> {noformat}
> gfsh start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> [info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 1033.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
> [info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
> Configuration: port=40401 max-connections=1033 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
>
[jira] [Commented] (GEODE-5256) GFSH Start Server Command Parameters Overridden by Default Values
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554834#comment-16554834
]
ASF subversion and git services commented on GEODE-5256:
Commit 667fbb4176c2f9bf8e399809b1c46f744486c3cd in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=667fbb4 ]
GEODE-5256: Parameters Precedence in Start Server (#2013)
* GEODE-5256: Parameters Precedence in Start Server
Configuration options set as part of the `start server` command now
take precedence over those configured in the `cache.xml` file, the
`cluster-configuration-service` and defaults.
- Rebased against latest develop branch.
- Removed unused `throws` clauses from tests.
- Renamed `ServerLauncherIntegrationTest` to
`ServerLauncherBuilderIntegrationTest`.
- Added tests for `ServerLauncher` and `CacheCreation`.
- Added acceptance tests for `gfsh start server` command.
- Fixed `ServerLauncher.parseArguments` method, it was wrongly calling
`setMaxConnections` for other unrelated parameters (maxMessageCount,
messageTimeToLive and sockerBufferSize).
- The `ServerLauncher` class now sets all the relevent startup
parameters during initialization within the static `parameters` field
on `CacheServerLauncher` class. The `CacheCreation` class, in turn,
reconfigures the `Server` attributes using
`CacheServerLauncher.parameters` before starting the `AcceptorImpl`.
* GEODE-5256: Changes requested by reviewers
- Rebased against latest develop branch.
- Replaced `Wait` references for `Awaitility` in related tests.
- Class `CacheServerLauncher.Parameters` is now a top level class.
- Added `@Deprecated` annotation and docs for `CacheServerLauncher`.
- `StartServerCommandAcceptanceTest` now uses `FileUtils` instead of
manually opening and reading the log file.
> GFSH Start Server Command Parameters Overridden by Default Values
> -
>
> Key: GEODE-5256
> URL: https://issues.apache.org/jira/browse/GEODE-5256
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Attachments: workspace.zip
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello team,
> The order on which we apply the cache configuration vs the startup parameters
> when starting servers through {{gfs}} seems to be wrong.
> No matter whether the cache is configured through a local {{cache.xml}} or
> the cluster configuration service, internally we end up parsing the
> configuration using {{CacheXmlParser}} and {{CacheCreation}} classes. The
> class {{CacheCreation}} creates a server through {{CacheServerCreation}} and
> this one extends {{AbstractCacheServer}}, which has some default values
> configured, overriding the values set by the startup parameters.
> I've been able to reproduce this for the {{max-connections}} configuration
> property specifically but right now a bunch of parameters are completely
> ignored if a {{cache.xml}} file is specified or if the
> {{cluster-configuration-service}} is enabled, no matter if the actual
> parameter is specifically configured or not, the default values are always
> used. In fact, the only parameters that seem to override the {{cache.xml}} /
> {{cluster-configuration}} are {{serverPort}}, {{serverBindAddress}} and
> {{disableDefaultServer}}, they are communicated between the
> {{ServerLauncher}} and {{CacheCreation}} classes through public static fields
> in the {{CacheServerLauncher}} class.
> As an example, after adding some extra logging on the
> {{setMaxConnections()}} method, below is the output shown when starting the
> server:
> {noformat}
> gfsh start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> [info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 1033.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
> [info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
> Configuration: port=40401 max-connections=1033 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
>
[jira] [Commented] (GEODE-5256) GFSH Start Server Command Parameters Overridden by Default Values
[
https://issues.apache.org/jira/browse/GEODE-5256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554835#comment-16554835
]
ASF subversion and git services commented on GEODE-5256:
Commit 667fbb4176c2f9bf8e399809b1c46f744486c3cd in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=667fbb4 ]
GEODE-5256: Parameters Precedence in Start Server (#2013)
* GEODE-5256: Parameters Precedence in Start Server
Configuration options set as part of the `start server` command now
take precedence over those configured in the `cache.xml` file, the
`cluster-configuration-service` and defaults.
- Rebased against latest develop branch.
- Removed unused `throws` clauses from tests.
- Renamed `ServerLauncherIntegrationTest` to
`ServerLauncherBuilderIntegrationTest`.
- Added tests for `ServerLauncher` and `CacheCreation`.
- Added acceptance tests for `gfsh start server` command.
- Fixed `ServerLauncher.parseArguments` method, it was wrongly calling
`setMaxConnections` for other unrelated parameters (maxMessageCount,
messageTimeToLive and sockerBufferSize).
- The `ServerLauncher` class now sets all the relevent startup
parameters during initialization within the static `parameters` field
on `CacheServerLauncher` class. The `CacheCreation` class, in turn,
reconfigures the `Server` attributes using
`CacheServerLauncher.parameters` before starting the `AcceptorImpl`.
* GEODE-5256: Changes requested by reviewers
- Rebased against latest develop branch.
- Replaced `Wait` references for `Awaitility` in related tests.
- Class `CacheServerLauncher.Parameters` is now a top level class.
- Added `@Deprecated` annotation and docs for `CacheServerLauncher`.
- `StartServerCommandAcceptanceTest` now uses `FileUtils` instead of
manually opening and reading the log file.
> GFSH Start Server Command Parameters Overridden by Default Values
> -
>
> Key: GEODE-5256
> URL: https://issues.apache.org/jira/browse/GEODE-5256
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Attachments: workspace.zip
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello team,
> The order on which we apply the cache configuration vs the startup parameters
> when starting servers through {{gfs}} seems to be wrong.
> No matter whether the cache is configured through a local {{cache.xml}} or
> the cluster configuration service, internally we end up parsing the
> configuration using {{CacheXmlParser}} and {{CacheCreation}} classes. The
> class {{CacheCreation}} creates a server through {{CacheServerCreation}} and
> this one extends {{AbstractCacheServer}}, which has some default values
> configured, overriding the values set by the startup parameters.
> I've been able to reproduce this for the {{max-connections}} configuration
> property specifically but right now a bunch of parameters are completely
> ignored if a {{cache.xml}} file is specified or if the
> {{cluster-configuration-service}} is enabled, no matter if the actual
> parameter is specifically configured or not, the default values are always
> used. In fact, the only parameters that seem to override the {{cache.xml}} /
> {{cluster-configuration}} are {{serverPort}}, {{serverBindAddress}} and
> {{disableDefaultServer}}, they are communicated between the
> {{ServerLauncher}} and {{CacheCreation}} classes through public static fields
> in the {{CacheServerLauncher}} class.
> As an example, after adding some extra logging on the
> {{setMaxConnections()}} method, below is the output shown when starting the
> server:
> {noformat}
> gfsh start server --name=server1 --server-port=40401
> --locators=localhost[10101] --max-connections=1033
> [info 2018/05/25 13:55:20.752 IST server1 tid=0x1] Initialization of
> region PdxTypes completed
> [X]: CacheServerImpl.setMaxConnections() is changing maxConnections from
> 800 to 1033.
> java.lang.Throwable
> at
> org.apache.geode.internal.cache.CacheServerImpl.setMaxConnections(CacheServerImpl.java:209)
> at
> org.apache.geode.distributed.ServerLauncher.startCacheServer(ServerLauncher.java:956)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:781)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
> [info 2018/05/25 13:55:20.825 IST server1 tid=0x1] CacheServer
> Configuration: port=40401 max-connections=1033 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
>
[jira] [Assigned] (GEODE-5450) Creating a JNDI binding w/o a username or password leads to NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross reassigned GEODE-5450:
--
Assignee: Benjamin P Ross
> Creating a JNDI binding w/o a username or password leads to
> NullPointerException
>
>
> Key: GEODE-5450
> URL: https://issues.apache.org/jira/browse/GEODE-5450
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Bradford D. Boyle
>Assignee: Benjamin P Ross
>Priority: Major
>
> If a user creates a JNDI binding through gfsh and they omit either the
> username or password, then they will get a `NullPointerException` when they
> try to get a JDBC connection.
>
> Here is a stack trace:
> {code}
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:460)
> at
> org.apache.geode.internal.datasource.GemFireBasicDataSource.getConnection(GemFireBasicDataSource.java:94)
> at
> io.pivotal.gemfire.PostgresVersionFunction.execute(PostgresVersionFunction.java:33)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution$2.run(AbstractExecution.java:302)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$9$1.run(ClusterDistributionManager.java:990)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> You can reproduce this with the following function:
> {code:language=java}
> public class PostgresVersionFunction implements Function {
> @Override
> public void execute(FunctionContext context) {
> String[] arguments = (String[]) context.getArguments();
> String dataSourceName = arguments[0];
> LogManager.getLogger().info("[datasource=" +
> context.getArguments()+"]");
> Context ctx = JNDIInvoker.getJNDIContext();
> DataSource dataSource;
> try {
> dataSource = (DataSource) ctx.lookup("java:/" + dataSourceName);
> } catch (Exception e) {
> // TODO exception handling.
> LogManager.getLogger().error(e.getMessage(), e);
> context.getResultSender().lastResult(e);
> return;
> }
> try (Connection connection = dataSource.getConnection();
> Statement statement = connection.createStatement()
> ) {
> ResultSet resultSet = statement.executeQuery("SELECT VERSION();");
> resultSet.next();
> context.getResultSender().lastResult(resultSet.getString(1));
> } catch (SQLException e) {
> context.getResultSender().lastResult(e);
> }
> }
> }
> {code}
> and the following gfsh commands:
> {code}
> start locator --name=locator --include-system-classpath
> start server --name=server1 --include-system-classpath
> deploy --jar=/root/gemfire-greenplum/simple-function.jar
> create jndi-binding --name=datasource --type=SIMPLE
> --jdbc-driver-class="org.postgresql.Driver"
> --connection-url="jdbc:postgresql://localhost:5432/gpadmin"
> execute function --id=io.pivotal.gemfire.PostgresVersionFunction
> --arguments=datasource
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3506) LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails intermittently with IllegalStateException: Failed to read status file
[
https://issues.apache.org/jira/browse/GEODE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-3506:
Labels: CI swat (was: CI)
> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails
> intermittently with IllegalStateException: Failed to read status file
> --
>
> Key: GEODE-3506
> URL: https://issues.apache.org/jira/browse/GEODE-3506
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Kirk Lund
>Priority: Major
> Labels: CI, swat
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> startDeletesStaleControlFiles FAILED
> java.lang.IllegalStateException: Failed to read status file
> {noformat}
> Full stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to read status file
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:152)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:940)
> at
> org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:868)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.awaitility.core.AssertionCondition$1.eval(AssertionCondition.java:55)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5472) PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs
[
https://issues.apache.org/jira/browse/GEODE-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5472:
--
Labels: pull-request-available swat (was: swat)
> PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes
> hangs
> --
>
> Key: GEODE-5472
> URL: https://issues.apache.org/jira/browse/GEODE-5472
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available, swat
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/138]
>
> *{color:#cc3300}Pooled Waiting Message Processor 1{color}* is in deadlock
> with *{color:#cc3300}RMI TCP Connection(1)-172.17.0.5{color}*
> *{color:#003300}Pooled Waiting Message Processor 1{color}* - priority:10 -
> threadId:0x7ff740004800 - nativeId:0x498 -
> state:*{color:#cc3300}BLOCKED{color}*
> stackTrace:
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.removeRoot({color:#80}GemFireCacheImpl.java:3604{color})
> - waiting to lock *<0xe0822280>* (a java.util.HashMap)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6288{color})
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion({color:#80}DistributedRegion.java:1730{color})
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6211{color})
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroyRegion({color:#80}LocalRegion.java:2229{color})
> at
> org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion({color:#80}AbstractRegion.java:424{color})
> at
> org.apache.geode.management.internal.ManagementResourceRepo.destroyLocalMonitoringRegion({color:#80}ManagementResourceRepo.java:73{color})
> at
> org.apache.geode.management.internal.LocalManager.cleanUpResources({color:#80}LocalManager.java:279{color})
> at
> org.apache.geode.management.internal.LocalManager.stopManager({color:#80}LocalManager.java:413{color})
> at
> org.apache.geode.management.internal.SystemManagementService.close({color:#80}SystemManagementService.java:240{color})
> - locked *<0xe03dcfe0>* (a java.util.HashMap)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval({color:#80}ManagementAdapter.java:737{color})
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent({color:#80}ManagementListener.java:122{color})
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners({color:#80}InternalDistributedSystem.java:2201{color})
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent({color:#80}InternalDistributedSystem.java:590{color})
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close({color:#80}GemFireCacheImpl.java:2147{color})
> - locked *<0xe03dd028>* (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1371{color})
> - locked *<0xe03dd028>* (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1021{color})
> at
> org.apache.geode.test.dunit.Disconnect.disconnectFromDS({color:#80}Disconnect.java:43{color})
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionRegressionTest$1.beforeSendMessage({color:#80}PersistentPartitionedRegionRegressionTest.java:288{color})
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing({color:#80}ClusterDistributionManager.java:1720{color})
> at
> org.apache.geode.internal.cache.partitioned.ManageBucketMessage$ManageBucketReplyMessage.sendAcceptance({color:#80}ManageBucketMessage.java:278{color})
> at
> org.apache.geode.internal.cache.partitioned.ManageBucketMessage.operateOnPartitionedRegion({color:#80}ManageBucketMessage.java:152{color})
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process({color:#80}PartitionMessage.java:331{color})
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction({color:#80}DistributionMessage.java:378{color})
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run({color:#80}DistributionMessage.java:444{color})
> at
>
[jira] [Updated] (GEODE-5472) PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs
[
https://issues.apache.org/jira/browse/GEODE-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-5472:
---
Description:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/138]
*{color:#cc3300}Pooled Waiting Message Processor 1{color}* is in deadlock with
*{color:#cc3300}RMI TCP Connection(1)-172.17.0.5{color}*
*{color:#003300}Pooled Waiting Message Processor 1{color}* - priority:10 -
threadId:0x7ff740004800 - nativeId:0x498 -
state:*{color:#cc3300}BLOCKED{color}*
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.geode.internal.cache.GemFireCacheImpl.removeRoot({color:#80}GemFireCacheImpl.java:3604{color})
- waiting to lock *<0xe0822280>* (a java.util.HashMap)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6288{color})
at
org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion({color:#80}DistributedRegion.java:1730{color})
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion({color:#80}LocalRegion.java:6211{color})
at
org.apache.geode.internal.cache.LocalRegion.localDestroyRegion({color:#80}LocalRegion.java:2229{color})
at
org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion({color:#80}AbstractRegion.java:424{color})
at
org.apache.geode.management.internal.ManagementResourceRepo.destroyLocalMonitoringRegion({color:#80}ManagementResourceRepo.java:73{color})
at
org.apache.geode.management.internal.LocalManager.cleanUpResources({color:#80}LocalManager.java:279{color})
at
org.apache.geode.management.internal.LocalManager.stopManager({color:#80}LocalManager.java:413{color})
at
org.apache.geode.management.internal.SystemManagementService.close({color:#80}SystemManagementService.java:240{color})
- locked *<0xe03dcfe0>* (a java.util.HashMap)
at
org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval({color:#80}ManagementAdapter.java:737{color})
at
org.apache.geode.management.internal.beans.ManagementListener.handleEvent({color:#80}ManagementListener.java:122{color})
at
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners({color:#80}InternalDistributedSystem.java:2201{color})
at
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent({color:#80}InternalDistributedSystem.java:590{color})
at
org.apache.geode.internal.cache.GemFireCacheImpl.close({color:#80}GemFireCacheImpl.java:2147{color})
- locked *<0xe03dd028>* (a java.lang.Class for
org.apache.geode.internal.cache.GemFireCacheImpl)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1371{color})
- locked *<0xe03dd028>* (a java.lang.Class for
org.apache.geode.internal.cache.GemFireCacheImpl)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect({color:#80}InternalDistributedSystem.java:1021{color})
at
org.apache.geode.test.dunit.Disconnect.disconnectFromDS({color:#80}Disconnect.java:43{color})
at
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionRegressionTest$1.beforeSendMessage({color:#80}PersistentPartitionedRegionRegressionTest.java:288{color})
at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing({color:#80}ClusterDistributionManager.java:1720{color})
at
org.apache.geode.internal.cache.partitioned.ManageBucketMessage$ManageBucketReplyMessage.sendAcceptance({color:#80}ManageBucketMessage.java:278{color})
at
org.apache.geode.internal.cache.partitioned.ManageBucketMessage.operateOnPartitionedRegion({color:#80}ManageBucketMessage.java:152{color})
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.process({color:#80}PartitionMessage.java:331{color})
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction({color:#80}DistributionMessage.java:378{color})
at
org.apache.geode.distributed.internal.DistributionMessage$1.run({color:#80}DistributionMessage.java:444{color})
at
java.util.concurrent.ThreadPoolExecutor.runWorker({color:#80}ThreadPoolExecutor.java:1149{color})
at
java.util.concurrent.ThreadPoolExecutor$Worker.run({color:#80}ThreadPoolExecutor.java:624{color})
at
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown({color:#80}ClusterDistributionManager.java:1121{color})
at
org.apache.geode.distributed.internal.ClusterDistributionManager.access$000({color:#80}ClusterDistributionManager.java:109{color})
at
org.apache.geode.distributed.internal.ClusterDistributionManager$6$1.run({color:#80}ClusterDistributionManager.java:865{color})
at java.lang.Thread.run({color:#80}Thread.java:748{color})
Locked ownable synchronizers:
-
[jira] [Commented] (GEODE-3506) LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails intermittently with IllegalStateException: Failed to read status file
[
https://issues.apache.org/jira/browse/GEODE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554668#comment-16554668
]
Galen O'Sullivan commented on GEODE-3506:
-
I saw this in a PR run recently:
http://files.apachegeode-ci.info/builds/geode-pr-2174/test-results/integrationTest/1532380769/
> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails
> intermittently with IllegalStateException: Failed to read status file
> --
>
> Key: GEODE-3506
> URL: https://issues.apache.org/jira/browse/GEODE-3506
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Kirk Lund
>Priority: Major
> Labels: CI
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> startDeletesStaleControlFiles FAILED
> java.lang.IllegalStateException: Failed to read status file
> {noformat}
> Full stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to read status file
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:152)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:940)
> at
> org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:868)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.awaitility.core.AssertionCondition$1.eval(AssertionCondition.java:55)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5453) Isolate and split up rolling upgrade tests.
[ https://issues.apache.org/jira/browse/GEODE-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554652#comment-16554652 ] ASF subversion and git services commented on GEODE-5453: Commit 0271f12583a3213ac2d2a1297d2f82599dd1052c in geode's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0271f12 ] GEODE-5453: Isolates upgrade tests in upgradeTest source set. (#2160) * DistributedTest task depends on UpgradeTest, until set in its own CI job Co-authored-by: Robert Houghton Co-authored-by: Patrick Rhomberg > Isolate and split up rolling upgrade tests. > --- > > Key: GEODE-5453 > URL: https://issues.apache.org/jira/browse/GEODE-5453 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Isolate rolling upgrades into their own category of test. > Split up rolling upgrade tests into individual test classes to improve > parallelization. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5469) Pulse per-member region stats do not work for member names with hyphen(s)
[
https://issues.apache.org/jira/browse/GEODE-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554594#comment-16554594
]
Anthony Baker commented on GEODE-5469:
--
[~azolotov] Thanks for the excellent bug report!
> Pulse per-member region stats do not work for member names with hyphen(s)
> -
>
> Key: GEODE-5469
> URL: https://issues.apache.org/jira/browse/GEODE-5469
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Andrey Zolotov
>Priority: Minor
>
> In Region View screen, when you hover over the members for the region on the
> left, the stats and charts do not have any data if the member name contains
> hyphens or other special cha.
> The fix is to replace occurences of *.' + memberName + '.* with *["' +
> memberName + '"].* in PulseCallbacks.js and RegionView.js, forcing the name
> to be treated as single string.
> example diff for one of the lines:
> {code:java}
> - key = 'memberOnRegionJson.' + memberName + '.entryCount';
> + key = 'memberOnRegionJson["' + memberName + '"].entryCount';{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5470) DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED
[ https://issues.apache.org/jira/browse/GEODE-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-5470: --- Assignee: Galen O'Sullivan > DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict > FAILED > - > > Key: GEODE-5470 > URL: https://issues.apache.org/jira/browse/GEODE-5470 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Galen O'Sullivan >Priority: Major > Labels: swat > > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest > > testDLockProtectsAgainstTransactionConflict FAILED > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:255] > java.lang.RuntimeException: test failed > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:256] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict(DlockAndTxlockRegressionTest.java:161) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:257] > > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:258] > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:259] > java.lang.RuntimeException: dlock failed to prevent a transaction conflict > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:260] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:234) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:261] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.lambda$testDLockProtectsAgainstTransactionConflict$bb17a952$5(DlockAndTxlockRegressionTest.java:123) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:262] > > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:263] > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:264] > org.apache.geode.cache.CommitConflictException: Concurrent transaction > commit detected The key TestKey in region /TestRegion was being modified by > another transaction locally. > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:265] > at > org.apache.geode.internal.cache.locks.TXLockServiceImpl.txLock(TXLockServiceImpl.java:137) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:266] > at > org.apache.geode.internal.cache.TXLockRequest.obtain(TXLockRequest.java:88) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:267] > at org.apache.geode.internal.cache.TXState.reserveAndCheck(TXState.java:340) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:268] > at org.apache.geode.internal.cache.TXState.commit(TXState.java:411) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:269] > at > org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:210) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:270] > at > org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:413) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:271] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:232) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:272] > ... 1 more > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5472) PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs
[ https://issues.apache.org/jira/browse/GEODE-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-5472: -- Assignee: Jinmei Liao > PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes > hangs > -- > > Key: GEODE-5472 > URL: https://issues.apache.org/jira/browse/GEODE-5472 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: swat > > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/138 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5472) PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs
[ https://issues.apache.org/jira/browse/GEODE-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-5472: --- Labels: swat (was: ) > PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes > hangs > -- > > Key: GEODE-5472 > URL: https://issues.apache.org/jira/browse/GEODE-5472 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: swat > > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/138 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5472) PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs
Jinmei Liao created GEODE-5472: -- Summary: PersistentPartitionedRegionRegressionTest recoversAfterBucketCreationCrashes hangs Key: GEODE-5472 URL: https://issues.apache.org/jira/browse/GEODE-5472 Project: Geode Issue Type: Bug Reporter: Jinmei Liao https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/138 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5467) MemberStaterRule.withJMXManager selects port before binding
[
https://issues.apache.org/jira/browse/GEODE-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Rowe reassigned GEODE-5467:
-
Assignee: Brian Rowe
> MemberStaterRule.withJMXManager selects port before binding
> ---
>
> Key: GEODE-5467
> URL: https://issues.apache.org/jira/browse/GEODE-5467
> Project: Geode
> Issue Type: Bug
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>Priority: Major
> Labels: swat
>
> Integration test #143 on develop fails with:
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSecurityTest
> > classMethod FAILED
> org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 21592; nested exception
> is:
> java.net.BindException: Failed to create server socket on null[21,592]
> Caused by:
> java.rmi.server.ExportException: Port already in use: 21592; nested
> exception is:
> java.net.BindException: Failed to create server socket on null[21,592]
> Caused by:
> java.net.BindException: Failed to create server socket on null[21,592]
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
>
> Digging into this a bit, I found that the test is trying to start up the jmx
> manager using a port which was randomly chosen via
> AvailablePortHelper.getRandomAvailableTCPPort() during setup. Unfortunately
> there was at least one other call to getRandomAvailableTCPPort after this
> (prior to where we're trying to bind the socket for the jmx manager), which
> creates the possibility that we'll have multiple services trying to bind the
> same port.
> The port is selected in the MemberStaterRule.withJMXManager call, which
> happens prior to the crash seen above, which has the following stack:
> {{org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 21592; nested exception
> is:
> java.net.BindException: Failed to create server socket on null[21,592]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:161)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:590)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1217)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:792)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:778)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:80)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:59)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource.access$000(SerializableExternalResource.java:24)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:35)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
>
[jira] [Updated] (GEODE-5471) Split Rolling Upgrade tests into one-test-per-class
[ https://issues.apache.org/jira/browse/GEODE-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5471: -- Labels: pull-request-available (was: ) > Split Rolling Upgrade tests into one-test-per-class > --- > > Key: GEODE-5471 > URL: https://issues.apache.org/jira/browse/GEODE-5471 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > > RollingUpgrade tests take over 45 minutes to complete. This will allow us to > fork on each test-method and get runtime closer to 10 minutes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5097) SUPERFLAKY: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
[
https://issues.apache.org/jira/browse/GEODE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Rowe resolved GEODE-5097.
---
Resolution: Fixed
Fix Version/s: 1.7.0
> SUPERFLAKY: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
>
>
> Key: GEODE-5097
> URL: https://issues.apache.org/jira/browse/GEODE-5097
> Project: Geode
> Issue Type: Bug
>Reporter: Barry Oglesby
>Assignee: Brian Rowe
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Occurred in FlakyTest 434:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/434
> {noformat}
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest
> > testAsyncStatsTwoListeners FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest$$Lambda$79/2036409943.run
> in VM 2 running on Host 5f4c74fb-2dca-48a0-4b2c-156d54846ff4 with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
> at
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners(AsyncEventQueueStatsDUnitTest.java:139)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda
> expression in org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase
> that uses int,
> intorg.apache.geode.cache.asyncqueue.internal.AsyncEventQueueStats Expected
> queue entries: 1000 but actual entries: 999 expected:<1000> but was:<999>
> within 120 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase.checkAsyncEventQueueStats(AsyncEventQueueTestBase.java:735)
> at org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUni
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5097) SUPERFLAKY: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
[
https://issues.apache.org/jira/browse/GEODE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554533#comment-16554533
]
ASF subversion and git services commented on GEODE-5097:
Commit 5f8f3fcdb7742617c31c1ae8fc7c199495eb3481 in geode's branch
refs/heads/develop from [~browe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5f8f3fc ]
GEODE-5097: Wait for dispatcher to pause in AsyncEventQueue test (#2175)
* GEODE-5097: Wait for dispatcher to pause in AsyncEventQueue test
> SUPERFLAKY: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
>
>
> Key: GEODE-5097
> URL: https://issues.apache.org/jira/browse/GEODE-5097
> Project: Geode
> Issue Type: Bug
>Reporter: Barry Oglesby
>Assignee: Brian Rowe
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Occurred in FlakyTest 434:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/434
> {noformat}
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest
> > testAsyncStatsTwoListeners FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest$$Lambda$79/2036409943.run
> in VM 2 running on Host 5f4c74fb-2dca-48a0-4b2c-156d54846ff4 with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
> at
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners(AsyncEventQueueStatsDUnitTest.java:139)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda
> expression in org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase
> that uses int,
> intorg.apache.geode.cache.asyncqueue.internal.AsyncEventQueueStats Expected
> queue entries: 1000 but actual entries: 999 expected:<1000> but was:<999>
> within 120 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase.checkAsyncEventQueueStats(AsyncEventQueueTestBase.java:735)
> at org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUni
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5097) SUPERFLAKY: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
[
https://issues.apache.org/jira/browse/GEODE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554532#comment-16554532
]
ASF subversion and git services commented on GEODE-5097:
Commit 5f8f3fcdb7742617c31c1ae8fc7c199495eb3481 in geode's branch
refs/heads/develop from [~browe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5f8f3fc ]
GEODE-5097: Wait for dispatcher to pause in AsyncEventQueue test (#2175)
* GEODE-5097: Wait for dispatcher to pause in AsyncEventQueue test
> SUPERFLAKY: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
>
>
> Key: GEODE-5097
> URL: https://issues.apache.org/jira/browse/GEODE-5097
> Project: Geode
> Issue Type: Bug
>Reporter: Barry Oglesby
>Assignee: Brian Rowe
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Occurred in FlakyTest 434:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/434
> {noformat}
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest
> > testAsyncStatsTwoListeners FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest$$Lambda$79/2036409943.run
> in VM 2 running on Host 5f4c74fb-2dca-48a0-4b2c-156d54846ff4 with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
> at
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners(AsyncEventQueueStatsDUnitTest.java:139)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda
> expression in org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase
> that uses int,
> intorg.apache.geode.cache.asyncqueue.internal.AsyncEventQueueStats Expected
> queue entries: 1000 but actual entries: 999 expected:<1000> but was:<999>
> within 120 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase.checkAsyncEventQueueStats(AsyncEventQueueTestBase.java:735)
> at org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUni
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5471) Split Rolling Upgrade tests into one-test-per-class
Robert Houghton created GEODE-5471: -- Summary: Split Rolling Upgrade tests into one-test-per-class Key: GEODE-5471 URL: https://issues.apache.org/jira/browse/GEODE-5471 Project: Geode Issue Type: Improvement Components: build Reporter: Robert Houghton Fix For: 1.7.0 RollingUpgrade tests take over 45 minutes to complete. This will allow us to fork on each test-method and get runtime closer to 10 minutes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4728) Geode Native Documentation Improvements
[ https://issues.apache.org/jira/browse/GEODE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554505#comment-16554505 ] ASF subversion and git services commented on GEODE-4728: Commit 1f0bd2dd75762f2fa91f2857f59e9623a2557d56 in geode-native's branch refs/heads/develop from [~dbarnes97] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=1f0bd2d ] GEODE-4728: User Guide -Modify data serialization navigation > Geode Native Documentation Improvements > --- > > Key: GEODE-4728 > URL: https://issues.apache.org/jira/browse/GEODE-4728 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 3h 40m > Remaining Estimate: 0h > > This ticket will capture a series of changes to the Geode Native docs to > bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5469) Pulse per-member region stats do not work for member names with hyphen(s)
[
https://issues.apache.org/jira/browse/GEODE-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Zolotov updated GEODE-5469:
--
Description:
In Region View screen, when you hover over the members for the region on the
left, the stats and charts do not have any data if the member name contains
hyphens or other special cha.
The fix is to replace occurences of *.' + memberName + '.* with *["' +
memberName + '"].* in PulseCallbacks.js and RegionView.js, forcing the name to
be treated as single string.
example diff for one of the lines:
{code:java}
- key = 'memberOnRegionJson.' + memberName + '.entryCount';
+ key = 'memberOnRegionJson["' + memberName + '"].entryCount';{code}
was:
In Region View screen, when you hover over the members for the region on the
left, the stats and charts do not have any data if the member name contains
hyphens or other special cha.
The fix is to replace occurences of *.' + memberName + '.* with *["' +
memberName + '"].* in PulseCallbacks.js and RegionView.js, essentially forcing
the name to be treated as single string.
example diff for one of the lines:
{code:java}
- key = 'memberOnRegionJson.' + memberName + '.entryCount';
+ key = 'memberOnRegionJson["' + memberName + '"].entryCount';{code}
> Pulse per-member region stats do not work for member names with hyphen(s)
> -
>
> Key: GEODE-5469
> URL: https://issues.apache.org/jira/browse/GEODE-5469
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Andrey Zolotov
>Priority: Minor
>
> In Region View screen, when you hover over the members for the region on the
> left, the stats and charts do not have any data if the member name contains
> hyphens or other special cha.
> The fix is to replace occurences of *.' + memberName + '.* with *["' +
> memberName + '"].* in PulseCallbacks.js and RegionView.js, forcing the name
> to be treated as single string.
> example diff for one of the lines:
> {code:java}
> - key = 'memberOnRegionJson.' + memberName + '.entryCount';
> + key = 'memberOnRegionJson["' + memberName + '"].entryCount';{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5470) DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED
[ https://issues.apache.org/jira/browse/GEODE-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554497#comment-16554497 ] Jinmei Liao commented on GEODE-5470: The test has a comment that says: "sometimes fail if the background cleanup takes too long." > DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict > FAILED > - > > Key: GEODE-5470 > URL: https://issues.apache.org/jira/browse/GEODE-5470 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: swat > > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest > > testDLockProtectsAgainstTransactionConflict FAILED > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:255] > java.lang.RuntimeException: test failed > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:256] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict(DlockAndTxlockRegressionTest.java:161) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:257] > > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:258] > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:259] > java.lang.RuntimeException: dlock failed to prevent a transaction conflict > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:260] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:234) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:261] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.lambda$testDLockProtectsAgainstTransactionConflict$bb17a952$5(DlockAndTxlockRegressionTest.java:123) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:262] > > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:263] > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:264] > org.apache.geode.cache.CommitConflictException: Concurrent transaction > commit detected The key TestKey in region /TestRegion was being modified by > another transaction locally. > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:265] > at > org.apache.geode.internal.cache.locks.TXLockServiceImpl.txLock(TXLockServiceImpl.java:137) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:266] > at > org.apache.geode.internal.cache.TXLockRequest.obtain(TXLockRequest.java:88) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:267] > at org.apache.geode.internal.cache.TXState.reserveAndCheck(TXState.java:340) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:268] > at org.apache.geode.internal.cache.TXState.commit(TXState.java:411) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:269] > at > org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:210) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:270] > at > org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:413) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:271] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:232) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:272] > ... 1 more > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5470) DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED
Jinmei Liao created GEODE-5470: -- Summary: DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED Key: GEODE-5470 URL: https://issues.apache.org/jira/browse/GEODE-5470 Project: Geode Issue Type: Bug Reporter: Jinmei Liao org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:255] java.lang.RuntimeException: test failed [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:256] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict(DlockAndTxlockRegressionTest.java:161) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:257] [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:258] Caused by: [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:259] java.lang.RuntimeException: dlock failed to prevent a transaction conflict [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:260] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:234) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:261] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.lambda$testDLockProtectsAgainstTransactionConflict$bb17a952$5(DlockAndTxlockRegressionTest.java:123) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:262] [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:263] Caused by: [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:264] org.apache.geode.cache.CommitConflictException: Concurrent transaction commit detected The key TestKey in region /TestRegion was being modified by another transaction locally. [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:265] at org.apache.geode.internal.cache.locks.TXLockServiceImpl.txLock(TXLockServiceImpl.java:137) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:266] at org.apache.geode.internal.cache.TXLockRequest.obtain(TXLockRequest.java:88) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:267] at org.apache.geode.internal.cache.TXState.reserveAndCheck(TXState.java:340) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:268] at org.apache.geode.internal.cache.TXState.commit(TXState.java:411) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:269] at org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:210) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:270] at org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:413) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:271] at org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:232) [ |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:272] ... 1 more -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5470) DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict FAILED
[ https://issues.apache.org/jira/browse/GEODE-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-5470: --- Labels: swat (was: ) > DlockAndTxlockRegressionTest > testDLockProtectsAgainstTransactionConflict > FAILED > - > > Key: GEODE-5470 > URL: https://issues.apache.org/jira/browse/GEODE-5470 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: swat > > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest > > testDLockProtectsAgainstTransactionConflict FAILED > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:255] > java.lang.RuntimeException: test failed > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:256] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict(DlockAndTxlockRegressionTest.java:161) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:257] > > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:258] > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:259] > java.lang.RuntimeException: dlock failed to prevent a transaction conflict > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:260] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:234) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:261] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.lambda$testDLockProtectsAgainstTransactionConflict$bb17a952$5(DlockAndTxlockRegressionTest.java:123) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:262] > > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:263] > Caused by: > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:264] > org.apache.geode.cache.CommitConflictException: Concurrent transaction > commit detected The key TestKey in region /TestRegion was being modified by > another transaction locally. > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:265] > at > org.apache.geode.internal.cache.locks.TXLockServiceImpl.txLock(TXLockServiceImpl.java:137) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:266] > at > org.apache.geode.internal.cache.TXLockRequest.obtain(TXLockRequest.java:88) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:267] > at org.apache.geode.internal.cache.TXState.reserveAndCheck(TXState.java:340) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:268] > at org.apache.geode.internal.cache.TXState.commit(TXState.java:411) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:269] > at > org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:210) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:270] > at > org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:413) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:271] > at > org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest.performOps(DlockAndTxlockRegressionTest.java:232) > [ > |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/139#L5b4cf155:272] > ... 1 more > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5455) ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not reconstructible from CompositeData
[
https://issues.apache.org/jira/browse/GEODE-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554492#comment-16554492
]
ASF subversion and git services commented on GEODE-5455:
Commit e4ede167e489f521f906239c90a8714e080125f1 in geode's branch
refs/heads/develop from [~khowe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e4ede16 ]
GEODE-5455: add new tests to verify MemberMXBean method return types (#2169)
Verify that JMX MXBean proxy reconstructs correct return type from
CompositeDataSupport. Correct type recontruction of types such as OSMetrics
requires that the mxbean proxy is intantiated from JMX.newMXBeanProxy() not
javax.management.MBeanServerInvocationHandler.newProxyInstance(), which
returns an mbean proxy
> ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not
> reconstructible from CompositeData
>
>
> Key: GEODE-5455
> URL: https://issues.apache.org/jira/browse/GEODE-5455
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.4.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following code snippet throws
> {code}
> Exception in thread "main" java.lang.ClassCastException:
> javax.management.openmbean.CompositeDataSupport cannot be cast to
> org.apache.geode.management.OSMetrics at
> com.sun.proxy.$Proxy0.showOSMetrics(Unknown Source)
> {code}
> {code:java}
> public static MBeanServerConnection getLocalMBeanServerConnectionStatic(int
> pid) {
> try {
> String address = ConnectorAddressLink.importFrom(pid);
> JMXServiceURL jmxUrl = new JMXServiceURL(address);
> return JMXConnectorFactory.connect(jmxUrl).getMBeanServerConnection();
> } catch (IOException e) {
> throw new RuntimeException(
> "Of course you still have to implement a good connection handling");
> }
> }
> public static void main(String[] args) throws IOException,
> MalformedObjectNameException, InstanceNotFoundException,
> ReflectionException {
> MBeanServerConnection mbeanServerConnection =
> getLocalMBeanServerConnectionStatic(127510);
> ObjectName mbeanName = new
> ObjectName("GemFire:type=Member,member=server1");
> MemberMXBean
> memberbeanInstance =
> (MemberMXBean) MBeanServerInvocationHandler
> .newProxyInstance(mbeanServerConnection, mbeanName,
> MemberMXBean.class, Boolean.TRUE);
> System.out.println(Arrays.toString(memberbeanInstance.listRegions()));
> OSMetrics cdOSMetrics = memberbeanInstance.showOSMetrics();
> //.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4934) CI Failure: GfshScript timing out intermittently waiting for execution to complete
[
https://issues.apache.org/jira/browse/GEODE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554490#comment-16554490
]
Jinmei Liao commented on GEODE-4934:
this failed in a recent CI build:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/198
> CI Failure: GfshScript timing out intermittently waiting for execution to
> complete
> --
>
> Key: GEODE-4934
> URL: https://issues.apache.org/jira/browse/GEODE-4934
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: CI, pull-request-available, swat
> Time Spent: 40m
> Remaining Estimate: 0h
>
> GfshScript.awaitIfNecessary native method call to determine if the process
> executing the script is alive hangs. This is not a hard failure, but it can
> be reproduced with frequently running selected tests from command line. This
> following set of tests produces failures when run on a Linux host (tested on
> CentOS 7).
> {code}
> ./gradlew clean geode-lucene:precheckin --parallel -x rat -x javadoc -x
> spotlessCheck{code}
> {code}
> {code:title=Typical failure stack}
> org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest >
> cannotStopServerByNameWhenNotConnected FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:98)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:87)
> at
> org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:35)
> {code}
> All failures show the same stack from {{at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:98)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4934) CI Failure: GfshScript timing out intermittently waiting for execution to complete
[
https://issues.apache.org/jira/browse/GEODE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-4934:
---
Labels: CI pull-request-available swat (was: CI pull-request-available)
> CI Failure: GfshScript timing out intermittently waiting for execution to
> complete
> --
>
> Key: GEODE-4934
> URL: https://issues.apache.org/jira/browse/GEODE-4934
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: CI, pull-request-available, swat
> Time Spent: 40m
> Remaining Estimate: 0h
>
> GfshScript.awaitIfNecessary native method call to determine if the process
> executing the script is alive hangs. This is not a hard failure, but it can
> be reproduced with frequently running selected tests from command line. This
> following set of tests produces failures when run on a Linux host (tested on
> CentOS 7).
> {code}
> ./gradlew clean geode-lucene:precheckin --parallel -x rat -x javadoc -x
> spotlessCheck{code}
> {code}
> {code:title=Typical failure stack}
> org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest >
> cannotStopServerByNameWhenNotConnected FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:98)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:87)
> at
> org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:35)
> {code}
> All failures show the same stack from {{at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:98)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3530) All DistributedTests that extend CliCommandTestBase are Flaky
[ https://issues.apache.org/jira/browse/GEODE-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16554374#comment-16554374 ] ASF subversion and git services commented on GEODE-3530: Commit 5cdf4c7c2f890e508f7a0b3c9315a75c8a64ffa0 in geode's branch refs/heads/develop from FSOUTHERLAND [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5cdf4c7 ] GEODE-3530 Added command tests using http connection (#2177) > All DistributedTests that extend CliCommandTestBase are Flaky > - > > Key: GEODE-3530 > URL: https://issues.apache.org/jira/browse/GEODE-3530 > Project: Geode > Issue Type: Bug > Components: management, tests >Reporter: Kirk Lund >Assignee: Jinmei Liao >Priority: Major > Labels: CliCommandTestBase, DistributedTest, Flaky, > pull-request-available, swat > Time Spent: 4h 50m > Remaining Estimate: 0h > > All DistributedTests that extend CliCommandTestBase are Flaky. The tests need > to be rewritten with GfshShellConnectionRule so we can delete > CliCommandTestBase. > List of test classes extending CliCommandTestBase and existing Flaky tickets: > * -AlterRegionCommandDUnitTest- (GEODE-3018) > * -ClusterConfigurationDUnitTest- (GEODE-1333, GEODE-1334) > * -ConfigCommandsDUnitTest- (GEODE-1449) > * -ConnectCommandWithHttpAndSSLDUnitTest- > * -CreateAlterDestroyRegionCommandsDUnitTest- (GEODE-973, GEODE-2009, > GEODE-3018) > * -CreateRegionCommandDUnitTest- (GEODE-973) > * -DescribeClientCommandDUnitTest- (GEODE-910) > * -DestroyRegionCommandDUnitTest- > * -DiskStoreCommandsDUnitTest- (GEODE-1206, GEODE-1406, GEODE-2102) > * -DurableClientCommandsDUnitTest- (GEODE-1705, GEODE-3404, GEODE-3359) > * -FunctionCommandsDUnitTest- (GEODE-1563) > * -GemfireDataCommandsDUnitTest- (GEODE-1182, GEODE-1249, GEODE-1404, > GEODE-1430, GEODE-1487, GEODE-1496, GEODE-1561, GEODE-1822, GEODE-2006) > * -GetCommandOnRegionWithCacheLoaderDuringCacheMissDUnitTest- (Does not > exist) > * LauncherLifecycleCommandsDUnitTest > * -ListAndDescribeDiskStoreCommandsDUnitTest (does not exist)- > * -ListClientCommandDUnitTest- (GEODE-908) (Jinmei/Finn) > * -ListIndexCommandDUnitTest- > * -LuceneIndexCommandsDUnitTest- (does not exist) > * -MiscellaneousCommandsDUnitTest (GEODE-1034, GEODE-1385, GEODE-1518, > GEODE-1605, GEODE-1706, GEODE-2126)- > * -QueueCommandsDUnitTest- (does not exist) (GEODE-1429, GEODE-1976) > * -RebalanceCommandDistributedTest- (Finn) > * -RebalanceCommandOverHttpDistributedTest- (Finn) > * -ShellCommandsDUnitTest- (GEODE-989) > * -ShowMetricsDUnitTest- (GEODE-1764) > * -ShowStackTraceDUnitTest- (does not exist) > * -WANCommandTestBase- (and subclasses) > * -ClientCommandsTestUtils- > * -ShellCommandsDUnitTest- (Jinmei) > Test classes that *use* but do not extend CliCommandTestBase: > * CommandOverrHttpDUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5469) Pulse per-member region stats do not work for member names with hyphen(s)
[
https://issues.apache.org/jira/browse/GEODE-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Zolotov updated GEODE-5469:
--
Priority: Minor (was: Major)
> Pulse per-member region stats do not work for member names with hyphen(s)
> -
>
> Key: GEODE-5469
> URL: https://issues.apache.org/jira/browse/GEODE-5469
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Andrey Zolotov
>Priority: Minor
>
> In Region View screen, when you hover over the members for the region on the
> left, the stats and charts do not have any data if the member name contains
> hyphens or other special cha.
> The fix is to replace occurences of *.' + memberName + '.* with *["' +
> memberName + '"].* in PulseCallbacks.js and RegionView.js, essentially
> forcing the name to be treated as single string.
> example diff for one of the lines:
> {code:java}
> - key = 'memberOnRegionJson.' + memberName + '.entryCount';
> + key = 'memberOnRegionJson["' + memberName + '"].entryCount';{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5469) Pulse per-member region stats do not work for member names with hyphen(s)
Andrey Zolotov created GEODE-5469:
-
Summary: Pulse per-member region stats do not work for member
names with hyphen(s)
Key: GEODE-5469
URL: https://issues.apache.org/jira/browse/GEODE-5469
Project: Geode
Issue Type: Bug
Components: pulse
Reporter: Andrey Zolotov
In Region View screen, when you hover over the members for the region on the
left, the stats and charts do not have any data if the member name contains
hyphens or other special cha.
The fix is to replace occurences of *.' + memberName + '.* with *["' +
memberName + '"].* in PulseCallbacks.js and RegionView.js, essentially forcing
the name to be treated as single string.
example diff for one of the lines:
{code:java}
- key = 'memberOnRegionJson.' + memberName + '.entryCount';
+ key = 'memberOnRegionJson["' + memberName + '"].entryCount';{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5224) statistics of Type DiskRegionStatistics is not correct after recovery from eviction
[ https://issues.apache.org/jira/browse/GEODE-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553896#comment-16553896 ] yossi reginiano edited comment on GEODE-5224 at 7/24/18 7:03 AM: - as per my tests i have found that during recovery from Eviction - primary JVM's acts different from Redundant ones in primary ones seems like during eviction all records are being stored on disk (also the ones that were stored in memory) in redundant ones i dont see this behavior and records that are stored in memory are not persisted into dist during eviction for example - LRU was set to be 2 I created 3 records – 2 should be on the memory and 1 should be on Disk , but I see that for some reason during eviction recovery all the 3 records are stored in the Disk Now this is only in the primary JVM – in the redundant I see that only 1 is stored in the Disk and 2 are stored in memory – as should be the corruption on statistics comes from the redundant buckets - where it should be handled different ( as per my comments above ) then the primary ones was (Author: yossireg): as per my tests i have found that during recovery from Eviction - primary JVM's acts different from Redundant ones in primary ones seems like during eviction all records are being stored on disk (also the ones that were stored in memory) in redundant ones i dont see this behavior and records that are stored in memory are not persisted into dist during eviction for example - LRU was set to be 2 I created 3 records – 2 should be on the memory and 1 should be on Disk , but I see that for some reason during eviction recovery all the 3 records are stored in the Disk Now this is only in the primary JVM – in the redundant I see that only 1 is stored in the Disk and 2 are stored in memory – as should be the corruption on statistics comes from the redundant buckets - where it should be handled different ( as per my upate above ) then the primary ones > statistics of Type DiskRegionStatistics is not correct after recovery from > eviction > --- > > Key: GEODE-5224 > URL: https://issues.apache.org/jira/browse/GEODE-5224 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: yossi reginiano >Priority: Major > Labels: pull-request-available > Attachments: EntriesInVM.png, EntriesOnlyOnDisk.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > we are using geode 1.4 and facing the following issue > after getting into eviction we can see that entriesOnlyOnDisk is shown > correctly, the problem is when getting out of eviction - we can see that the > summarize is getting messed up and that entriesOnlyOnDisk is not reduced to 0 > but rather stay high and on the other end - entriesInVM is reduced under 0. > the numbers sum up ok - the issue is only that we reduce too much from > entriesInVM while part of it should have been removed from entriesOnlyOnDisk. > the issue can be reproduced very simply by getting into and out of eviction > and monitoring the statistics. > please see following screen shots that describes the issue- > !image-2018-05-16-15-02-35-522.png! > > > !image-2018-05-16-15-03-18-815.png! > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5224) statistics of Type DiskRegionStatistics is not correct after recovery from eviction
[ https://issues.apache.org/jira/browse/GEODE-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553896#comment-16553896 ] yossi reginiano commented on GEODE-5224: as per my tests i have found that during recovery from Eviction - primary JVM's acts different from Redundant ones in primary ones seems like during eviction all records are being stored on disk (also the ones that were stored in memory) in redundant ones i dont see this behavior and records that are stored in memory are not persisted into dist during eviction for example - LRU was set to be 2 I created 3 records – 2 should be on the memory and 1 should be on Disk , but I see that for some reason during eviction recovery all the 3 records are stored in the Disk Now this is only in the primary JVM – in the redundant I see that only 1 is stored in the Disk and 2 are stored in memory – as should be the corruption on statistics comes from the redundant buckets - where it should be handled different ( as per my upate above ) then the primary ones > statistics of Type DiskRegionStatistics is not correct after recovery from > eviction > --- > > Key: GEODE-5224 > URL: https://issues.apache.org/jira/browse/GEODE-5224 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: yossi reginiano >Priority: Major > Labels: pull-request-available > Attachments: EntriesInVM.png, EntriesOnlyOnDisk.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > we are using geode 1.4 and facing the following issue > after getting into eviction we can see that entriesOnlyOnDisk is shown > correctly, the problem is when getting out of eviction - we can see that the > summarize is getting messed up and that entriesOnlyOnDisk is not reduced to 0 > but rather stay high and on the other end - entriesInVM is reduced under 0. > the numbers sum up ok - the issue is only that we reduce too much from > entriesInVM while part of it should have been removed from entriesOnlyOnDisk. > the issue can be reproduced very simply by getting into and out of eviction > and monitoring the statistics. > please see following screen shots that describes the issue- > !image-2018-05-16-15-02-35-522.png! > > > !image-2018-05-16-15-03-18-815.png! > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5224) statistics of Type DiskRegionStatistics is not correct after recovery from eviction
[ https://issues.apache.org/jira/browse/GEODE-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5224: -- Labels: pull-request-available (was: ) > statistics of Type DiskRegionStatistics is not correct after recovery from > eviction > --- > > Key: GEODE-5224 > URL: https://issues.apache.org/jira/browse/GEODE-5224 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: yossi reginiano >Priority: Major > Labels: pull-request-available > Attachments: EntriesInVM.png, EntriesOnlyOnDisk.png > > > we are using geode 1.4 and facing the following issue > after getting into eviction we can see that entriesOnlyOnDisk is shown > correctly, the problem is when getting out of eviction - we can see that the > summarize is getting messed up and that entriesOnlyOnDisk is not reduced to 0 > but rather stay high and on the other end - entriesInVM is reduced under 0. > the numbers sum up ok - the issue is only that we reduce too much from > entriesInVM while part of it should have been removed from entriesOnlyOnDisk. > the issue can be reproduced very simply by getting into and out of eviction > and monitoring the statistics. > please see following screen shots that describes the issue- > !image-2018-05-16-15-02-35-522.png! > > > !image-2018-05-16-15-03-18-815.png! > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
