[jira] [Commented] (GEODE-5535) Upgrade fast-classpath-scanner to 4.x
[ https://issues.apache.org/jira/browse/GEODE-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576976#comment-16576976 ] ASF subversion and git services commented on GEODE-5535: Commit 162897646cc56af9309527c3d764fe1fab4bc764 in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1628976 ] Revert "GEODE-5535: Upgrade FastClasspathScanner to 4.0.6 (#2290)" This reverts commit c2d3c1e16c49aac021a26dca65b57996be7d94a2. > Upgrade fast-classpath-scanner to 4.x > - > > Key: GEODE-5535 > URL: https://issues.apache.org/jira/browse/GEODE-5535 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The package has been renamed to 'ClassGraph'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5142) new Thread Monitoring Mechanism
[ https://issues.apache.org/jira/browse/GEODE-5142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-5142: --- Component/s: docs > new Thread Monitoring Mechanism > --- > > Key: GEODE-5142 > URL: https://issues.apache.org/jira/browse/GEODE-5142 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: yossi reginiano >Priority: Major > Labels: pull-request-available > Time Spent: 6h 20m > Remaining Estimate: 0h > > One of the most severe issues hitting our real time application is thread > stuck for multiple reasons, such as long lasting locks, deadlocks, threads > which wait for reply forever in case of packet drop issue etc... > Such kind of stuck are under Radar of the existing system health check > methods. In mission critical applications, this will be resulted as an > immediate outage. > Here we introduce thread monitoring mechanism, to detect threads which are > stuck for any reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-3780: -- Labels: pull-request-available (was: ) > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.4.0 > > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5473) Docs page describing how to use the query api
[ https://issues.apache.org/jira/browse/GEODE-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5473: -- Labels: pull-request-available (was: ) > 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 >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > 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-5567) Replace usage of std::atomic
[ https://issues.apache.org/jira/browse/GEODE-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5567: -- Labels: pull-request-available (was: ) > Replace usage of std::atomic > > > Key: GEODE-5567 > URL: https://issues.apache.org/jira/browse/GEODE-5567 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > std::atomic template is only compatible with types which are "trivially > copyable". std::chrono::*::time_span is _not guaranteed_ trivially copyable, > and will probably change in future versions of the library, so this code > needs to be refactored to use std::atomic with a template parameter that's an > integral type like a long long. The "rep" field of std:: duration should > work fine for this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5567) Replace usage of std::atomic
[ https://issues.apache.org/jira/browse/GEODE-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576942#comment-16576942 ] ASF subversion and git services commented on GEODE-5567: Commit e5c49fb00f0cbf207a5a707274293c8439235596 in geode-native's branch refs/heads/develop from [~bbender] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=e5c49fb ] GEODE-5567: Replace template parameter of std::atomic with a known trivially-copyable type Co-authored-by: Ivan Godwin > Replace usage of std::atomic > > > Key: GEODE-5567 > URL: https://issues.apache.org/jira/browse/GEODE-5567 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > std::atomic template is only compatible with types which are "trivially > copyable". std::chrono::*::time_span is _not guaranteed_ trivially copyable, > and will probably change in future versions of the library, so this code > needs to be refactored to use std::atomic with a template parameter that's an > integral type like a long long. The "rep" field of std:: duration should > work fine for this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-3780) suspected member is never watched again after passing final check
[ https://issues.apache.org/jira/browse/GEODE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reopened GEODE-3780: - Assignee: Bruce Schuchardt The fix for this ticket caused the health monitor to never advance beyond the first member to the right in the membership view once a tcp/ip liveness check is done on that member. It ought to be advancing to the next member in the view if the current member it's watching is declared dead. I also noticed that we aren't updating the suspect-requests list if a member is declared non-suspect. > suspected member is never watched again after passing final check > - > > Key: GEODE-3780 > URL: https://issues.apache.org/jira/browse/GEODE-3780 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Fix For: 1.4.0 > > > In a network-down test we saw a node on the losing side of the network > partition perform final checks on members on the winning side. One of the > final checks mysteriously succeeded > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check failed but detected recent message > traffic for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > [info 2017/09/17 12:24:45.552 PDT > gemfire1_rs-FullRegression-2017-09-15-21-00-35-client-10_8941 Detection thread 4> tid=0x128] Final check passed for suspect member > 10.32.109.252(gemfire3_rs-FullRegression-2017-09-15-21-00-35-client-16_6135:6135):1026 > After this the suspected member was never checked again and the losing side > failed to shut down. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5565) Release off heap entry during gii if Region has been destroyed
[ https://issues.apache.org/jira/browse/GEODE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5565: -- Labels: pull-request-available (was: ) > Release off heap entry during gii if Region has been destroyed > --- > > Key: GEODE-5565 > URL: https://issues.apache.org/jira/browse/GEODE-5565 > Project: Geode > Issue Type: Bug > Components: offheap >Affects Versions: 1.0.0-incubating >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > > A RegionDestroyedException can occur at the following stack trace > at > org.apache.geode.internal.cache.DiskStoreImpl.acquireReadLock(DiskStoreImpl.java:1170) > at > org.apache.geode.internal.cache.DiskRegion.acquireReadLock(DiskRegion.java:649) > at > org.apache.geode.internal.cache.entries.DiskEntry$Helper.update(DiskEntry.java:856) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:38) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:32) > at > org.apache.geode.internal.cache.entries.AbstractRegionEntry.initialImageInit(AbstractRegionEntry.java:747) > at > org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:949) > at > org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:978) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1308) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2796) > at > org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435) > 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:1136) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:112) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:849) > at java.lang.Thread.run(Thread.java:748) > This ends up with an off heap reference, although the region is no longer > there. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5480) SUPERFLAKY test UniversalMembershipListenerAdapterDUnitTest > testSystemClientEventsInServer
[
https://issues.apache.org/jira/browse/GEODE-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576861#comment-16576861
]
ASF subversion and git services commented on GEODE-5480:
Commit 0a9da64bc2cca0cc4e7cd6b889df85ace99dc8a7 in geode's branch
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0a9da64 ]
GEODE-5480: Changing wait blocks to use a while loop
This test has many wait blocks that just used an if. So if the thread
was notified by some other event, it would leave the wait without the
expected event being delivered.
> SUPERFLAKY test UniversalMembershipListenerAdapterDUnitTest >
> testSystemClientEventsInServer
>
>
> Key: GEODE-5480
> URL: https://issues.apache.org/jira/browse/GEODE-5480
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Dan Smith
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Attachments: Test results - Class
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.html
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest >
> testSystemClientEventsInServer FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:699)
> {noformat}
> See failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/151#L5b4cf768:7281
> See pass:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/152#L5b59cf6d:7039
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5509) Replace the docs Transactions section
[ https://issues.apache.org/jira/browse/GEODE-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5509: -- Labels: pull-request-available (was: ) > Replace the docs Transactions section > - > > Key: GEODE-5509 > URL: https://issues.apache.org/jira/browse/GEODE-5509 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > Our documentation section on Transactions is lengthy. It contains a lot of > material that is irrelevant for users of Geode. In its attempt at being > complete, users cannot find what they need. > I propose moving the entire section into another place within the docs to > keep as reference material for anyone who needs to search for and find > details. At the same time, I will replace the current Transactions section > with something much more concise and opinionated. This new section is to > target the best/right way to implement transactions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5535) Upgrade fast-classpath-scanner to 4.x
[ https://issues.apache.org/jira/browse/GEODE-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576824#comment-16576824 ] ASF subversion and git services commented on GEODE-5535: Commit c2d3c1e16c49aac021a26dca65b57996be7d94a2 in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c2d3c1e ] GEODE-5535: Upgrade FastClasspathScanner to 4.0.6 (#2290) > Upgrade fast-classpath-scanner to 4.x > - > > Key: GEODE-5535 > URL: https://issues.apache.org/jira/browse/GEODE-5535 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The package has been renamed to 'ClassGraph'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5480) SUPERFLAKY test UniversalMembershipListenerAdapterDUnitTest > testSystemClientEventsInServer
[
https://issues.apache.org/jira/browse/GEODE-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5480:
--
Labels: flaky pull-request-available swat (was: flaky swat)
> SUPERFLAKY test UniversalMembershipListenerAdapterDUnitTest >
> testSystemClientEventsInServer
>
>
> Key: GEODE-5480
> URL: https://issues.apache.org/jira/browse/GEODE-5480
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Dan Smith
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Attachments: Test results - Class
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.html
>
>
> {noformat}
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest >
> testSystemClientEventsInServer FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:699)
> {noformat}
> See failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/151#L5b4cf768:7281
> See pass:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/152#L5b59cf6d:7039
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-5546) auto-reconnecting member reuses old address including vmViewId
[ https://issues.apache.org/jira/browse/GEODE-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt closed GEODE-5546. --- > auto-reconnecting member reuses old address including vmViewId > -- > > Key: GEODE-5546 > URL: https://issues.apache.org/jira/browse/GEODE-5546 > Project: Geode > Issue Type: Bug > Components: membership >Affects Versions: 1.6.0 >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > During network-down testing I found that if I restore the network immediately > after all "losing side" servers go into auto-reconnect that sometimes they > receive a view-preparation message from the surviving cluster that holds > their old membership ID. They use this ID instead of waiting for a valid new > ID and end up being shut down as rogue processes. > For instance, this process used to have an identifier with before it > went into auto-reconnect. When it tried to rejoin it ended up using that > same identifier due to receiving a view-preparation message holding it: > [info 2018/07/28 22:17:14.588 PDT > gemfire1_rs-FullRegression29040205a1i3xlarge-hydra-client-18_15643 > tid=0x2d2] Attempting to join the distributed system > through coordinator > 10.32.110.93(gemfire6_rs-FullRegression29040205a1i3xlarge-hydra-client-50_13624:13624:locator):1024 > using address > 10.32.108.125(gemfire1_rs-FullRegression29040205a1i3xlarge-hydra-client-18_15643:15643):1026 > In this run it then proceeded to hang trying to send startup messages to the > cluster. Cluster members rejected all of its attempts to contact them but > were also unsuccessful in getting the rogue process to shut down. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5546) auto-reconnecting member reuses old address including vmViewId
[ https://issues.apache.org/jira/browse/GEODE-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-5546. - Resolution: Fixed Fix Version/s: 1.7.0 > auto-reconnecting member reuses old address including vmViewId > -- > > Key: GEODE-5546 > URL: https://issues.apache.org/jira/browse/GEODE-5546 > Project: Geode > Issue Type: Bug > Components: membership >Affects Versions: 1.6.0 >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > During network-down testing I found that if I restore the network immediately > after all "losing side" servers go into auto-reconnect that sometimes they > receive a view-preparation message from the surviving cluster that holds > their old membership ID. They use this ID instead of waiting for a valid new > ID and end up being shut down as rogue processes. > For instance, this process used to have an identifier with before it > went into auto-reconnect. When it tried to rejoin it ended up using that > same identifier due to receiving a view-preparation message holding it: > [info 2018/07/28 22:17:14.588 PDT > gemfire1_rs-FullRegression29040205a1i3xlarge-hydra-client-18_15643 > tid=0x2d2] Attempting to join the distributed system > through coordinator > 10.32.110.93(gemfire6_rs-FullRegression29040205a1i3xlarge-hydra-client-50_13624:13624:locator):1024 > using address > 10.32.108.125(gemfire1_rs-FullRegression29040205a1i3xlarge-hydra-client-18_15643:15643):1026 > In this run it then proceeded to hang trying to send startup messages to the > cluster. Cluster members rejected all of its attempts to contact them but > were also unsuccessful in getting the rogue process to shut down. -- 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=16576785#comment-16576785 ] ASF subversion and git services commented on GEODE-5212: Commit 3d261a00d237e2e17b8cdd074a531fa7d54b936f in geode's branch refs/heads/develop from [~sai.boorlaga...@gmail.com] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3d261a0 ] GEODE-5212: run windows jobs in serial (#2301) > 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: 6h > 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] [Commented] (GEODE-5565) Release off heap entry during gii if Region has been destroyed
[ https://issues.apache.org/jira/browse/GEODE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576772#comment-16576772 ] Jason Huynh commented on GEODE-5565: If a region is destroyed during gii, there is a chance that we have allocated memory for off heap for the entry, but end up not being able to set the value. This bubbles up but never releases the memory. > Release off heap entry during gii if Region has been destroyed > --- > > Key: GEODE-5565 > URL: https://issues.apache.org/jira/browse/GEODE-5565 > Project: Geode > Issue Type: Bug > Components: offheap >Affects Versions: 1.0.0-incubating >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > > A RegionDestroyedException can occur at the following stack trace > at > org.apache.geode.internal.cache.DiskStoreImpl.acquireReadLock(DiskStoreImpl.java:1170) > at > org.apache.geode.internal.cache.DiskRegion.acquireReadLock(DiskRegion.java:649) > at > org.apache.geode.internal.cache.entries.DiskEntry$Helper.update(DiskEntry.java:856) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:38) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:32) > at > org.apache.geode.internal.cache.entries.AbstractRegionEntry.initialImageInit(AbstractRegionEntry.java:747) > at > org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:949) > at > org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:978) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1308) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2796) > at > org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435) > 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:1136) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:112) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:849) > at java.lang.Thread.run(Thread.java:748) > This ends up with an off heap reference, although the region is no longer > there. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5566) Unable to query PDX objects with "select *" from gfsh
Jens Deppe created GEODE-5566:
-
Summary: Unable to query PDX objects with "select *" from gfsh
Key: GEODE-5566
URL: https://issues.apache.org/jira/browse/GEODE-5566
Project: Geode
Issue Type: Bug
Components: gfsh, serialization
Reporter: Jens Deppe
I am populating a region with PDX objects from a Java client. When querying the
region with gfsh, I am able to query specific object attributes but not the
whole object. For example '{{select c.name from /REGION as c}}' works but
'{{select *}}' produces this error:
{noformat}
[vm1] [info 2018/08/10 12:29:27.088 PDT tid=87]
Exception occurred:
[vm1] org.apache.geode.pdx.PdxSerializationException: Could not create an
instance of a class org.apache.geode.test.Customer
[vm1] at
org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:693)
[vm1] at
org.apache.geode.pdx.internal.PdxInstanceImpl.basicGetObject(PdxInstanceImpl.java:623)
[vm1] at
org.apache.geode.pdx.internal.PdxInstanceImpl.getObject(PdxInstanceImpl.java:244)
[vm1] at
org.apache.geode.cache.query.internal.ResultsCollectionPdxDeserializerWrapper$SelectResultsPdxInstanceIterator.next(ResultsCollectionPdxDeserializerWrapper.java:92)
[vm1] at
org.apache.geode.management.internal.cli.functions.DataCommandFunction.select_SelectResults(DataCommandFunction.java:248)
[vm1] at
org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:220)
[vm1] at
org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:173)
[vm1] at
org.apache.geode.management.internal.cli.functions.DataCommandFunction.execute(DataCommandFunction.java:122)
[vm1] at
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193)
[vm1] at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369)
[vm1] at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435)
[vm1] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[vm1] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[vm1] at
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1136)
[vm1] at
org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:112)
[vm1] at
org.apache.geode.distributed.internal.ClusterDistributionManager$9$1.run(ClusterDistributionManager.java:1006)
[vm1] at java.lang.Thread.run(Thread.java:748)
[vm1] Caused by: java.lang.ClassNotFoundException:
org.apache.geode.test.Customer
[vm1] at
org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:170)
[vm1] at
org.apache.geode.internal.InternalDataSerializer.getCachedClass(InternalDataSerializer.java:3921)
[vm1] at
org.apache.geode.pdx.internal.PdxReaderImpl.basicGetObject(PdxReaderImpl.java:689)
[vm1] ... 16 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5565) Release off heap entry during gii if Region has been destroyed
Jason Huynh created GEODE-5565: -- Summary: Release off heap entry during gii if Region has been destroyed Key: GEODE-5565 URL: https://issues.apache.org/jira/browse/GEODE-5565 Project: Geode Issue Type: Bug Components: offheap Reporter: Jason Huynh A RegionDestroyedException can occur at the following stack trace at org.apache.geode.internal.cache.DiskStoreImpl.acquireReadLock(DiskStoreImpl.java:1170) at org.apache.geode.internal.cache.DiskRegion.acquireReadLock(DiskRegion.java:649) at org.apache.geode.internal.cache.entries.DiskEntry$Helper.update(DiskEntry.java:856) at org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:38) at org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:32) at org.apache.geode.internal.cache.entries.AbstractRegionEntry.initialImageInit(AbstractRegionEntry.java:747) at org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:949) at org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:978) at org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1308) at org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209) at org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2796) at org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193) at org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186) at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369) at org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435) 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:1136) at org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:112) at org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:849) at java.lang.Thread.run(Thread.java:748) This ends up with an off heap reference, although the region is no longer there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5565) Release off heap entry during gii if Region has been destroyed
[ https://issues.apache.org/jira/browse/GEODE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh updated GEODE-5565: --- Affects Version/s: 1.0.0-incubating > Release off heap entry during gii if Region has been destroyed > --- > > Key: GEODE-5565 > URL: https://issues.apache.org/jira/browse/GEODE-5565 > Project: Geode > Issue Type: Bug > Components: offheap >Affects Versions: 1.0.0-incubating >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > > A RegionDestroyedException can occur at the following stack trace > at > org.apache.geode.internal.cache.DiskStoreImpl.acquireReadLock(DiskStoreImpl.java:1170) > at > org.apache.geode.internal.cache.DiskRegion.acquireReadLock(DiskRegion.java:649) > at > org.apache.geode.internal.cache.entries.DiskEntry$Helper.update(DiskEntry.java:856) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:38) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:32) > at > org.apache.geode.internal.cache.entries.AbstractRegionEntry.initialImageInit(AbstractRegionEntry.java:747) > at > org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:949) > at > org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:978) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1308) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2796) > at > org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435) > 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:1136) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:112) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:849) > at java.lang.Thread.run(Thread.java:748) > This ends up with an off heap reference, although the region is no longer > there. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5565) Release off heap entry during gii if Region has been destroyed
[ https://issues.apache.org/jira/browse/GEODE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh reassigned GEODE-5565: -- Assignee: Jason Huynh > Release off heap entry during gii if Region has been destroyed > --- > > Key: GEODE-5565 > URL: https://issues.apache.org/jira/browse/GEODE-5565 > Project: Geode > Issue Type: Bug > Components: offheap >Affects Versions: 1.0.0-incubating >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > > A RegionDestroyedException can occur at the following stack trace > at > org.apache.geode.internal.cache.DiskStoreImpl.acquireReadLock(DiskStoreImpl.java:1170) > at > org.apache.geode.internal.cache.DiskRegion.acquireReadLock(DiskRegion.java:649) > at > org.apache.geode.internal.cache.entries.DiskEntry$Helper.update(DiskEntry.java:856) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:38) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:32) > at > org.apache.geode.internal.cache.entries.AbstractRegionEntry.initialImageInit(AbstractRegionEntry.java:747) > at > org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:949) > at > org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:978) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1308) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2796) > at > org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435) > 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:1136) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:112) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:849) > at java.lang.Thread.run(Thread.java:748) > This ends up with an off heap reference, although the region is no longer > there. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5546) auto-reconnecting member reuses old address including vmViewId
[ https://issues.apache.org/jira/browse/GEODE-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576764#comment-16576764 ] ASF subversion and git services commented on GEODE-5546: Commit b08e37fba1261c118acf9d264f46c048dd519276 in geode's branch refs/heads/develop from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b08e37f ] GEODE-5546 auto-reconnecting member reuses old address including vmViewId Old membership IDs are now retained in JGroupsMessenger and GMSJoinLeave uses a new method, Messenger.isOldMembershipIdentifier(), to avoid accepting a prepared view that contains an old identity. GMSJoinLeave is also modified to send an immediate removal message to servers that are no longer members of the cluster but are attempting to interact with the cluster. This closes #2286 > auto-reconnecting member reuses old address including vmViewId > -- > > Key: GEODE-5546 > URL: https://issues.apache.org/jira/browse/GEODE-5546 > Project: Geode > Issue Type: Bug > Components: membership >Affects Versions: 1.6.0 >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > During network-down testing I found that if I restore the network immediately > after all "losing side" servers go into auto-reconnect that sometimes they > receive a view-preparation message from the surviving cluster that holds > their old membership ID. They use this ID instead of waiting for a valid new > ID and end up being shut down as rogue processes. > For instance, this process used to have an identifier with before it > went into auto-reconnect. When it tried to rejoin it ended up using that > same identifier due to receiving a view-preparation message holding it: > [info 2018/07/28 22:17:14.588 PDT > gemfire1_rs-FullRegression29040205a1i3xlarge-hydra-client-18_15643 > tid=0x2d2] Attempting to join the distributed system > through coordinator > 10.32.110.93(gemfire6_rs-FullRegression29040205a1i3xlarge-hydra-client-50_13624:13624:locator):1024 > using address > 10.32.108.125(gemfire1_rs-FullRegression29040205a1i3xlarge-hydra-client-18_15643:15643):1026 > In this run it then proceeded to hang trying to send startup messages to the > cluster. Cluster members rejected all of its attempts to contact them but > were also unsuccessful in getting the rogue process to shut down. -- 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=16576754#comment-16576754 ] ASF subversion and git services commented on GEODE-5212: Commit 914adc4aa8515e0c1506cd1c8f3d319eae9a7151 in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=914adc4 ] GEODE-5212: Account for dynamic values returned from metrics MBean (#2300) > 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: 5h 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] [Reopened] (GEODE-5428) SUPERFLAKY: DurableClientTestCase.testDurableHAFailover
[
https://issues.apache.org/jira/browse/GEODE-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reopened GEODE-5428:
--
Assignee: (was: Mark Hanson)
This test failed again in CI
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/240
{noformat}
org.apache.geode.internal.cache.tier.sockets.DurableClientNetDownDUnitTest >
testDurableHAFailover FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase$30.run in VM
2 running on Host c7195c46f09c with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.verifyListenerUpdatesEntries(DurableClientTestCase.java:847)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientNetDownDUnitTest.verifyListenerUpdates(DurableClientNetDownDUnitTest.java:76)
Caused by:
java.lang.AssertionError: expected:<3> but was:<2>
{noformat}
> SUPERFLAKY: DurableClientTestCase.testDurableHAFailover
> ---
>
> Key: GEODE-5428
> URL: https://issues.apache.org/jira/browse/GEODE-5428
> Project: Geode
> Issue Type: Task
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Attachments: Test results - Class
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.html
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This test failed frequently over many 200+ runs of DistributedTest. It looks
> like this test was reenabled recently, See GEODE-3721.
> {noformat}
> 23 failures
> org.apache.geode.internal.cache.tier.sockets.DurableClientCrashDUnitTest.testDurableHAFailover
> (91.4179104477612% success rate)
> 19 failures
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover
> (92.91044776119402% success rate)
> 2 failures
> org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.testDurableHAFailover
> (99.25373134328358% success rate)
> {noformat}
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase >
> testDurableHAFailover FAILED
>
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase$57.run in
> VM 2 running on Host 70293b28b05f with 4 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.tier.sockets.DurableClientTestCase.checkPrimaryRecovery(DurableClientTestCase.java:1732)
>
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:1247)
>
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:1102)
>
>
> Caused by:
>
> java.lang.AssertionError: Event never occurred after 3 ms: Did
> not detect primary recovery event during wait period
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at
> org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:190)
>
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase$57.run2(DurableClientTestCase.java:1746)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5480) SUPERFLAKY test UniversalMembershipListenerAdapterDUnitTest > testSystemClientEventsInServer
[
https://issues.apache.org/jira/browse/GEODE-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-5480:
Assignee: Dan Smith
> SUPERFLAKY test UniversalMembershipListenerAdapterDUnitTest >
> testSystemClientEventsInServer
>
>
> Key: GEODE-5480
> URL: https://issues.apache.org/jira/browse/GEODE-5480
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Dan Smith
>Priority: Major
> Labels: flaky, swat
> Attachments: Test results - Class
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.html
>
>
> {noformat}
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest >
> testSystemClientEventsInServer FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest.testSystemClientEventsInServer(UniversalMembershipListenerAdapterDUnitTest.java:699)
> {noformat}
> See failure:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/151#L5b4cf768:7281
> See pass:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/152#L5b59cf6d:7039
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5549) Flaky test NonBlockingProcessStreamReaderIntegrationTest > processTerminatesWhenDestroyed
[
https://issues.apache.org/jira/browse/GEODE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5549.
--
Resolution: Fixed
Fix Version/s: 1.8.0
> Flaky test NonBlockingProcessStreamReaderIntegrationTest >
> processTerminatesWhenDestroyed
> -
>
> Key: GEODE-5549
> URL: https://issues.apache.org/jira/browse/GEODE-5549
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Dan Smith
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.process.NonBlockingProcessStreamReaderIntegrationTest
> > processTerminatesWhenDestroyed FAILED
> java.lang.AssertionError:
> Expecting:
> <0>
> to be greater than:
> <0>
> {noformat}
> Failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/237
> Passed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/236
> Passed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/235
> Failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/234
> Failing intermittently on pr pipeline as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5549) Flaky test NonBlockingProcessStreamReaderIntegrationTest > processTerminatesWhenDestroyed
[
https://issues.apache.org/jira/browse/GEODE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576682#comment-16576682
]
ASF subversion and git services commented on GEODE-5549:
Commit 9a4a6c6b04d5ec6cdd151547fcbec9f2e0d67aa1 in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9a4a6c6 ]
GEODE-5549: Removing assertion about process exit status from kill test
the processTerminatesWhenDestroyedTest was asserting the exit value was
greater than zero. It looks like in some cases it can be 0. Since the
point of the test is to assert what happens to the stream reader
threads, removing this extra assertion.
Co-authored-by: Kirk Lund
> Flaky test NonBlockingProcessStreamReaderIntegrationTest >
> processTerminatesWhenDestroyed
> -
>
> Key: GEODE-5549
> URL: https://issues.apache.org/jira/browse/GEODE-5549
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Dan Smith
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.process.NonBlockingProcessStreamReaderIntegrationTest
> > processTerminatesWhenDestroyed FAILED
> java.lang.AssertionError:
> Expecting:
> <0>
> to be greater than:
> <0>
> {noformat}
> Failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/237
> Passed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/236
> Passed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/235
> Failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/234
> Failing intermittently on pr pipeline as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5564) Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClea
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob S. Barrett updated GEODE-5564:
Description:
{noformat}
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> testIndexUpdateWithRegionClear FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
in VM 0 running on Host 92f89c21d1b0 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
at
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
Caused by:
java.lang.AssertionError: After clear region size is supposed to be
zero as all index updates are blocked. Current region size is: 13
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
{noformat}
Failing:
https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/556
Passing:
https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/547
was:
{noformat}
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> testIndexUpdateWithRegionClear FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
in VM 0 running on Host 92f89c21d1b0 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
at
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
Caused by:
java.lang.AssertionError: After clear region size is supposed to be
zero as all index updates are blocked. Current region size is: 13
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
{noformat}
> Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest >
> testIndexUpdateWithRegionClea
> --
>
> Key: GEODE-5564
> URL: https://issues.apache.org/jira/browse/GEODE-5564
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> > testIndexUpdateWithRegionClear FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
> in VM 0 running on Host 92f89c21d1b0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
> Caused by:
> java.lang.AssertionError: After clear region size is supposed to be
> zero as all index updates are blocked. Current region size is: 13
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/556
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/547
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5564) Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClea
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob S. Barrett updated GEODE-5564:
Affects Version/s: 1.8.0
> Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest >
> testIndexUpdateWithRegionClea
> --
>
> Key: GEODE-5564
> URL: https://issues.apache.org/jira/browse/GEODE-5564
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> > testIndexUpdateWithRegionClear FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
> in VM 0 running on Host 92f89c21d1b0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
> Caused by:
> java.lang.AssertionError: After clear region size is supposed to be
> zero as all index updates are blocked. Current region size is: 13
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5564) Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClea
Jacob S. Barrett created GEODE-5564:
---
Summary: Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest >
testIndexUpdateWithRegionClea
Key: GEODE-5564
URL: https://issues.apache.org/jira/browse/GEODE-5564
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Jacob S. Barrett
{noformat}
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> testIndexUpdateWithRegionClear FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
in VM 0 running on Host 92f89c21d1b0 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
at
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
Caused by:
java.lang.AssertionError: After clear region size is supposed to be
zero as all index updates are blocked. Current region size is: 13
at org.junit.Assert.fail(Assert.java:88)
at
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5564) Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClea
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob S. Barrett updated GEODE-5564:
Labels: flaky swat (was: )
> Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest >
> testIndexUpdateWithRegionClea
> --
>
> Key: GEODE-5564
> URL: https://issues.apache.org/jira/browse/GEODE-5564
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> > testIndexUpdateWithRegionClear FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
> in VM 0 running on Host 92f89c21d1b0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
> Caused by:
> java.lang.AssertionError: After clear region size is supposed to be
> zero as all index updates are blocked. Current region size is: 13
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5563) Replace use of System.currentTimeMillis() in single-thread timing in GMS
Bruce Schuchardt created GEODE-5563: --- Summary: Replace use of System.currentTimeMillis() in single-thread timing in GMS Key: GEODE-5563 URL: https://issues.apache.org/jira/browse/GEODE-5563 Project: Geode Issue Type: Improvement Components: membership Reporter: Bruce Schuchardt There are places in membership code, like GMSJoinLeave and GMSHealthMonitor, that use System.currentTimeMillis() to time operations in a single thread. These should be modified to use the nanotime clock, which is cheaper and less error-prone. -- 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=16576667#comment-16576667 ] ASF subversion and git services commented on GEODE-5212: Commit 1785f7369f73128412f705824f73f244fabdb68a in geode's branch refs/heads/develop from [~sai.boorlaga...@gmail.com] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1785f73 ] GEODE-5212: use Paths.get to retrieve resourcePath (#2295) > 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: 5h 20m > 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-5562) LowMemoryException message sometimes does not provide the member that is low on memory
Lynn Gallinat created GEODE-5562: Summary: LowMemoryException message sometimes does not provide the member that is low on memory Key: GEODE-5562 URL: https://issues.apache.org/jira/browse/GEODE-5562 Project: Geode Issue Type: Bug Reporter: Lynn Gallinat org.apache.geode.cache.LowMemoryException: Region: /replicatedRegion cannot process operation on key: Object_7998 because member [] is running low on memory at org.apache.geode.internal.cache.LocalRegion.checkIfAboveThreshold(LocalRegion.java:5729) at org.apache.geode.internal.cache.LocalRegion.checkIfAboveThreshold(LocalRegion.java:5705) at org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5654) at org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:371) at org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152) at org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5086) at org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1618) at org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1605) at org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:413) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5562) LowMemoryException message sometimes does not provide the member that is low on memory
[ https://issues.apache.org/jira/browse/GEODE-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lynn Gallinat reassigned GEODE-5562: Assignee: Lynn Gallinat > LowMemoryException message sometimes does not provide the member that is low > on memory > -- > > Key: GEODE-5562 > URL: https://issues.apache.org/jira/browse/GEODE-5562 > Project: Geode > Issue Type: Bug >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat >Priority: Major > > org.apache.geode.cache.LowMemoryException: Region: /replicatedRegion cannot > process operation on key: Object_7998 because member [] is running low on > memory > at > org.apache.geode.internal.cache.LocalRegion.checkIfAboveThreshold(LocalRegion.java:5729) > at > org.apache.geode.internal.cache.LocalRegion.checkIfAboveThreshold(LocalRegion.java:5705) > at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5654) > at > org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:371) > at > org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152) > at > org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5086) > at > org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1618) > at > org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1605) > at > org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:413) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5550) Flaky test ShorteningExpirationTimeRegressionTest > customEntryTimeToLiveCanBeShortened
[
https://issues.apache.org/jira/browse/GEODE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5550.
--
Resolution: Duplicate
> Flaky test ShorteningExpirationTimeRegressionTest >
> customEntryTimeToLiveCanBeShortened
> ---
>
> Key: GEODE-5550
> URL: https://issues.apache.org/jira/browse/GEODE-5550
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.cache30.ShorteningExpirationTimeRegressionTest >
> customEntryTimeToLiveCanBeShortened FAILED
> org.junit.ComparisonFailure: expected:<"quickExpire"> but was:
> 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.cache30.ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened(ShorteningExpirationTimeRegressionTest.java:100)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/IntegrationTest/builds/531
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/IntegrationTest/builds/530
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5552) Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
[
https://issues.apache.org/jira/browse/GEODE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5552.
--
Resolution: Duplicate
> Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
>
>
> Key: GEODE-5552
> URL: https://issues.apache.org/jira/browse/GEODE-5552
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithJmxSSL FAILED
> java.lang.AssertionError:
> Expecting:
> <"_ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.8.0-SNAPSHOT
>
> Monitor and Manage Apache Geode
> Connecting to Locator at [host=localhost, port=42647] ..
> Connection reset
> ">
> to contain:
> <"trying to connect a non-SSL-enabled client to an SSL-enabled locator">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithJmxSSL(ConnectCommandWithSSLTest.java:219)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/521
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/522
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5554) Standardize naming of Geode Native example *.md files
[ https://issues.apache.org/jira/browse/GEODE-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-5554: --- Description: The *.md files describing how to build and run examples do not follow a consistent naming pattern. Current state: * examples/dotnet/README.md describes building examples, refers user to README.md in each example directory for running. * examples/cpp/BUILDING.md describes building examples and running them. Only one individual example has its own README.md file. Problems: * Top-level file in dotnet should have 'BUILD' in its name. * The geode-native distribution has a 'BUILDING.md' in its root directory. Top-level files in both dotnet and cpp should not be named 'BUILDING.md', because it's confusing to the user when both are open on the desktop at the same time. * The cpp examples should follow the dotnet pattern of an individual README.md for each example with instructions for running. * The cpp examples should follow the practice recommended for the dotnet examples of copying the installed example to a personal workspace before building and running. This practice preserves a clean copy from which the user can start over, if necessary. Recommendations: * Rename example build instructions to BUILD-EXAMPLES.md for both dotnet and cpp * Add README.md to individual cpp examples * Update all CMake scripts to deploy these *.md files when examples are installed. was: The *.md files describing how to build and run examples do not follow a consistent naming pattern. Current state: * examples/dotnet/README.md describes building examples, refers user to README.md in each example directory for running. * examples/cpp/BUILDING.md describes building examples and running them. Only one individual example has its own README.md file. Problems: * Top-level file in dotnet should have 'BUILD' in its name. * The geode-native distribution has a 'BUILDING.md' in its root directory. Top-level files in both dotnet and cpp should not be named 'BUILDING.md', because it's confusing to the user when both are open on the desktop at the same time. * The cpp examples should follow the dotnet pattern of an individual README.md for each example with instructions for running. Recommendations: * Rename example build instructions to BUILD-EXAMPLES.md for both dotnet and cpp * Add README.md to individual cpp examples * Update all CMake scripts to deploy these *.md files when examples are installed. > Standardize naming of Geode Native example *.md files > - > > Key: GEODE-5554 > URL: https://issues.apache.org/jira/browse/GEODE-5554 > Project: Geode > Issue Type: Sub-task > Components: docs, native client >Reporter: Dave Barnes >Priority: Major > > The *.md files describing how to build and run examples do not follow a > consistent naming pattern. Current state: > * examples/dotnet/README.md describes building examples, refers user to > README.md in each example directory for running. > * examples/cpp/BUILDING.md describes building examples and running them. > Only one individual example has its own README.md file. > Problems: > * Top-level file in dotnet should have 'BUILD' in its name. > * The geode-native distribution has a 'BUILDING.md' in its root directory. > Top-level files in both dotnet and cpp should not be named 'BUILDING.md', > because it's confusing to the user when both are open on the desktop at the > same time. > * The cpp examples should follow the dotnet pattern of an individual > README.md for each example with instructions for running. > * The cpp examples should follow the practice recommended for the dotnet > examples of copying the installed example to a personal workspace before > building and running. This practice preserves a clean copy from which the > user can start over, if necessary. > Recommendations: > * Rename example build instructions to BUILD-EXAMPLES.md for both dotnet and > cpp > * Add README.md to individual cpp examples > * Update all CMake scripts to deploy these *.md files when examples are > installed. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5555) Create `devBuild` build target for typical developer workflow
[
https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576561#comment-16576561
]
ASF subversion and git services commented on GEODE-:
Commit e73ef5a2a0112255ccaa3acf949a1c4fc9548bc6 in geode's branch
refs/heads/develop from [~rhoughton]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e73ef5a ]
GEODE-: Add 'devBuild' task (#2293)
* devBuild depends on :assembly and :spotlessApply
* Ensure that spotlessApply and spotlessCheck run before compilation
*** This ordering dependency is project wide, not only with respect to
devBuild
* Correct apparent error in precheckin task only running
acceptanceTest task in geode-assembly module
*** Historically, this was the only module that contained
acceptanceTests. This was changed with the introduction of nebula
facets.
* Minor readability improvements in touched files.
Co-authored-by: Robert Houghton
Co-authored-by: Patrick Rhomberg
> Create `devBuild` build target for typical developer workflow
> -
>
> Key: GEODE-
> URL: https://issues.apache.org/jira/browse/GEODE-
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> A typical developer does not want to run, for instance, {{rat}} or
> {{javadoc}} as part of their standard build workflow. A {{devBuild}} target
> should only build classes and, likely, also include {{spotlessApply}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5560) member becomes coordinator but then stops when it receives a view
[
https://issues.apache.org/jira/browse/GEODE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576548#comment-16576548
]
ASF subversion and git services commented on GEODE-5560:
Commit 378e69377e2ae3d052ab419dfeb3bb13f9b38573 in geode's branch
refs/heads/feature/GEODE-5560 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=378e693 ]
GEODE-5560 member becomes coordinator but then stops when it receives a view
Upgraded the check to see if the receiver of a new membership view should
become the coordinator. If we've received a Leave message from the coordinator
or the coordinator is scheduled to be kicked out of the system we take over
the role of coordinator if necessary.
> member becomes coordinator but then stops when it receives a view
> -
>
> Key: GEODE-5560
> URL: https://issues.apache.org/jira/browse/GEODE-5560
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.3.0, 1.2.1, 1.4.0,
> 1.5.0, 1.6.0
>Reporter: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> In a test run that aggressively shuts down and restarts locators I saw a
> member become the membership coordinator but then receive a new view from the
> old coordinator. This caused it to shut down its view-creator thread and
> give up the role of coordinator. It stayed in this state for over 5 minutes
> until the test was nuked.
> {noformat}
> [info 2018/08/07 23:21:06.655 PDT peerZoneDgemfire2_host1_28017 Priority Message Processor 21> tid=0x102] This member is becoming the
> membership coordinator with address
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28017:28017):1038
> [info 2018/08/07 23:21:06.660 PDT peerZoneDgemfire2_host1_28017 Priority Message Processor 21> tid=0x102] ViewCreator starting
> on:rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28017:28017):1038
> [info 2018/08/07 23:21:06.696 PDT peerZoneDgemfire2_host1_28017 Priority Message Processor 21> tid=0x102] Member at
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27853:27853):1030
> gracefully left the distributed cache: shutdown message received
> [info 2018/08/07 23:21:06.726 PDT peerZoneDgemfire2_host1_28017 Membership View Creator> tid=0x323] View Creator thread is starting
> [info 2018/08/07 23:21:06.726 PDT peerZoneDgemfire2_host1_28017 receiver,rs-FullRegression08042427a0i3large-hydra-client-104-51513> tid=0x28]
> received new view:
> View[rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27853:27853):1030|36]
> members:
> [rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27853:27853):1030{lead},
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27876:27876):1029,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire1_host1_27947:27947):1033,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire1_host1_27932:27932):1034,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire2_host1_27970:27970):1036,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire2_host1_27959:27959):1035,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire1_host1_27985:27985):1037,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28017:28017):1038,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28033:28033):1040]
> shutdown:
> [rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire1_host1_28001:28001):1039,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire1_host1_27819:27819):1025,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire2_host1_27844:27844):1026,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire2_host1_27834:27834):1027,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire1_host1_27826:27826):1028,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire2_host1_27898:27898):1031,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire2_host1_27917:27917):1032]
> [info 2018/08/07 23:21:07.400 PDT peerZoneDgemfire2_host1_28017
> tid=0x311] Connection: shared=false
> ordered=true failed to connect to peer
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27876:27876):1029
> because: java.net.ConnectException: Connection refused
> [warning 2018/08/07 23:21:09.400 PDT peerZoneDgemfire2_host1_28017
> tid=0x311] Connection: Attempting
> reconnect to peer
>
[jira] [Updated] (GEODE-5560) member becomes coordinator but then stops when it receives a view
[
https://issues.apache.org/jira/browse/GEODE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5560:
--
Labels: pull-request-available (was: )
> member becomes coordinator but then stops when it receives a view
> -
>
> Key: GEODE-5560
> URL: https://issues.apache.org/jira/browse/GEODE-5560
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.3.0, 1.2.1, 1.4.0,
> 1.5.0, 1.6.0
>Reporter: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> In a test run that aggressively shuts down and restarts locators I saw a
> member become the membership coordinator but then receive a new view from the
> old coordinator. This caused it to shut down its view-creator thread and
> give up the role of coordinator. It stayed in this state for over 5 minutes
> until the test was nuked.
> {noformat}
> [info 2018/08/07 23:21:06.655 PDT peerZoneDgemfire2_host1_28017 Priority Message Processor 21> tid=0x102] This member is becoming the
> membership coordinator with address
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28017:28017):1038
> [info 2018/08/07 23:21:06.660 PDT peerZoneDgemfire2_host1_28017 Priority Message Processor 21> tid=0x102] ViewCreator starting
> on:rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28017:28017):1038
> [info 2018/08/07 23:21:06.696 PDT peerZoneDgemfire2_host1_28017 Priority Message Processor 21> tid=0x102] Member at
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27853:27853):1030
> gracefully left the distributed cache: shutdown message received
> [info 2018/08/07 23:21:06.726 PDT peerZoneDgemfire2_host1_28017 Membership View Creator> tid=0x323] View Creator thread is starting
> [info 2018/08/07 23:21:06.726 PDT peerZoneDgemfire2_host1_28017 receiver,rs-FullRegression08042427a0i3large-hydra-client-104-51513> tid=0x28]
> received new view:
> View[rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27853:27853):1030|36]
> members:
> [rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27853:27853):1030{lead},
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27876:27876):1029,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire1_host1_27947:27947):1033,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire1_host1_27932:27932):1034,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire2_host1_27970:27970):1036,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneCgemfire2_host1_27959:27959):1035,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire1_host1_27985:27985):1037,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28017:28017):1038,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire2_host1_28033:28033):1040]
> shutdown:
> [rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneDgemfire1_host1_28001:28001):1039,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire1_host1_27819:27819):1025,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire2_host1_27844:27844):1026,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire2_host1_27834:27834):1027,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneAgemfire1_host1_27826:27826):1028,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire2_host1_27898:27898):1031,
>
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire2_host1_27917:27917):1032]
> [info 2018/08/07 23:21:07.400 PDT peerZoneDgemfire2_host1_28017
> tid=0x311] Connection: shared=false
> ordered=true failed to connect to peer
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27876:27876):1029
> because: java.net.ConnectException: Connection refused
> [warning 2018/08/07 23:21:09.400 PDT peerZoneDgemfire2_host1_28017
> tid=0x311] Connection: Attempting
> reconnect to peer
> rs-FullRegression08042427a0i3large-hydra-client-104(peerZoneBgemfire1_host1_27876:27876):1029
> {noformat}
> The method GMSJoinLeave.installView() needs to perform a check similar to
> GMSJoinLeave.processLeaveRequest() and not abdicate its role as coordinator
> if the creator of the view is queued up to be removed from membership.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5534) With oql indexes and compression enabled, memory usage is greater after compression than before
[
https://issues.apache.org/jira/browse/GEODE-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby resolved GEODE-5534.
--
Resolution: Fixed
Fix Version/s: 1.7.0
> With oql indexes and compression enabled, memory usage is greater after
> compression than before
> ---
>
> Key: GEODE-5534
> URL: https://issues.apache.org/jira/browse/GEODE-5534
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> A test that shows the behavior is:
> - xml configuration like:
> {noformat}
>
> data-policy="persistent-replicate" disk-store-name="orderDiskStore"
> disk-synchronous="false" cloning-enabled="true">
>
> org.apache.geode.compression.SnappyCompressor
>
>
> expression="index_from.clOrdID" type="range"/>
> expression="index_from.externalOrderID" type="range"/>
> expression="index_from.externalOrderIDSource" type="range"/>
> expression="index_from.orderID" type="range"/>
> expression="index_from.parentOrderID" type="range"/>
>
> {noformat}
> - an Order object defining string fields for clOrdID, externalOrderID,
> orderID and parentOrderID and an enum field for externalOrderIDSource
> Here are some histograms showing the behavior:
> With indexes and no compression:
> {noformat}
> num #instances #bytes class name
> --
> 1: 502136 562132008 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 50 800
> org.apache.geode.internal.cache.PreferBytesCachedDeserializable
> 9: 250680 6016320 java.util.concurrent.ConcurrentSkipListMap$Index
> 10: 80 4196104
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> Total 5474612 739440976
> {noformat}
> With indexes and compression
> {noformat}
> num #instances #bytes class name
> --
> 1: 1003644 643754184 [B
> 2: 200 4800
> org.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node
> 3: 40 35999280
> org.apache.geode.internal.cache.entries.VersionedThinDiskRegionEntryHeapStringKey2
> 4: 54 24000192
> org.apache.geode.internal.cache.DiskId$PersistenceWithIntOffset
> 5: 1503 15457776
> [Lorg.apache.geode.internal.concurrent.CompactConcurrentHashSet2$Node;
> 6: 501508 12036192 java.util.concurrent.ConcurrentSkipListMap$Node
> 7: 501500 12036000 org.apache.geode.pdx.internal.PdxString
> 8: 250889 6021336 java.util.concurrent.ConcurrentSkipListMap$Index
> 9: 80 4196096
> [Lorg.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap$HashEntry;
> 10: 34380 3261936 [C
> Total 5476808 813096488
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5518) some records in the region are not fetched when executing fetch query
[ https://issues.apache.org/jira/browse/GEODE-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575224#comment-16575224 ] Jason Huynh edited comment on GEODE-5518 at 8/10/18 4:05 PM: - What type of map are you using? I don't think put all can maintain the order of the map unless the map itself provides an iterator that is in order. Even if it does provide the values in put order, there are scenarios like single-hop where that order won't be maintained... The query would then get a 'snapshot' of whatever is currently in the region. If the putAll was mid process (and random order), you could see some entries and not others. Is the putAll totally complete before the special process begins? was (Author: huynhja): What type of map are you using? I don't think put all can maintain the order of the map unless the map itself provides an iterator that is in order. The query would then get a 'snapshot' of whatever is currently in the region. If the putAll was mid process (and random order), you could see some entries and not others. Is the putAll totally complete before the special process begins? > some records in the region are not fetched when executing fetch query > - > > Key: GEODE-5518 > URL: https://issues.apache.org/jira/browse/GEODE-5518 > Project: Geode > Issue Type: Bug > Components: core, querying >Reporter: yossi reginiano >Priority: Major > > hi all, > we are using geode 1.4 and facing the following: > we are starting to adopt the putAll functions which accepts a bulk of records > and persists them into the region > we have noticed that the process that fetches the records from the region > (executing fetch command with bulks of 1000) , from time to time missing a > record or two , which is causing this records to be left in the region as a > "Zombie" - because now current index is greater then this record's index > now this started to happen only when we started to use the putAll function - > prior to this we did not face any such issue > also - when we are using putAll with only 1 record at a time it is also > working fine > has anybody faced this? > is there some constraint on the number of records that can be sent to the > putAll function? > thanks in advance > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5558) DistributedLockServiceDUnitTest.testGrantTokenCleanup should not return early
[ https://issues.apache.org/jira/browse/GEODE-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576483#comment-16576483 ] ASF subversion and git services commented on GEODE-5558: Commit 25d1bfdc741b10384b0b281fcca6103b1df8 in geode's branch refs/heads/develop from [~khowe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=25d ] Feature/geode 5558 (#2297) * GEODE-5558: Cleanup to DistributedLockServiceDUnitTest, some to DLockService * Use only new style invoke() calls * Unboxing * Lambdas * commented code * And more... * cleanup DLockService typecasts. Signed-off-by: Galen O'Sullivan * Remove early return from testGrantTokenCleanup Signed-off-by: Galen O'Sullivan > DistributedLockServiceDUnitTest.testGrantTokenCleanup should not return early > - > > Key: GEODE-5558 > URL: https://issues.apache.org/jira/browse/GEODE-5558 > Project: Geode > Issue Type: Task > Components: distributed lock service, tests >Reporter: Galen O'Sullivan >Assignee: Kenneth Howe >Priority: Major > > This test is marked with a TODO to finish the test after an ancient > (pre-Geode) bug is fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5549) Flaky test NonBlockingProcessStreamReaderIntegrationTest > processTerminatesWhenDestroyed
[
https://issues.apache.org/jira/browse/GEODE-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576475#comment-16576475
]
Sai Boorlagadda commented on GEODE-5549:
Also a failure on pr-develop: https://concourse.apachegeode-ci.info/builds/17008
> Flaky test NonBlockingProcessStreamReaderIntegrationTest >
> processTerminatesWhenDestroyed
> -
>
> Key: GEODE-5549
> URL: https://issues.apache.org/jira/browse/GEODE-5549
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Dan Smith
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.process.NonBlockingProcessStreamReaderIntegrationTest
> > processTerminatesWhenDestroyed FAILED
> java.lang.AssertionError:
> Expecting:
> <0>
> to be greater than:
> <0>
> {noformat}
> Failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/237
> Passed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/236
> Passed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/235
> Failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/234
> Failing intermittently on pr pipeline as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5558) DistributedLockServiceDUnitTest.testGrantTokenCleanup should not return early
[ https://issues.apache.org/jira/browse/GEODE-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe reassigned GEODE-5558: --- Assignee: Kenneth Howe > DistributedLockServiceDUnitTest.testGrantTokenCleanup should not return early > - > > Key: GEODE-5558 > URL: https://issues.apache.org/jira/browse/GEODE-5558 > Project: Geode > Issue Type: Task > Components: distributed lock service, tests >Reporter: Galen O'Sullivan >Assignee: Kenneth Howe >Priority: Major > > This test is marked with a TODO to finish the test after an ancient > (pre-Geode) bug is fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5561) Remove incorrect description in putAll documentation
[ https://issues.apache.org/jira/browse/GEODE-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576448#comment-16576448 ] Jason Huynh edited comment on GEODE-5561 at 8/10/18 3:30 PM: - looks like that page doesn't exist anymore, only in incubating docs was (Author: huynhja): looks like that page doesn't exist anymore. > Remove incorrect description in putAll documentation > > > Key: GEODE-5561 > URL: https://issues.apache.org/jira/browse/GEODE-5561 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Jason Huynh >Priority: Major > > On the page > http://geode.apache.org/docs/guide/10/basic_config/data_entries_custom_classes/managing_data_entries.html > that we claim : "The updates to the cache are done individually in the order > in which they were placed in the Map" > I don't think this is correct, it depends on the map type/iterator type as > well as whether we have single hop enabled or not. In most cases I don't > think it is possible. I think we should probably remove this line from the > description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5561) Remove incorrect description in putAll documentation
[ https://issues.apache.org/jira/browse/GEODE-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-5561. Resolution: Invalid > Remove incorrect description in putAll documentation > > > Key: GEODE-5561 > URL: https://issues.apache.org/jira/browse/GEODE-5561 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Jason Huynh >Priority: Major > > On the page > http://geode.apache.org/docs/guide/10/basic_config/data_entries_custom_classes/managing_data_entries.html > that we claim : "The updates to the cache are done individually in the order > in which they were placed in the Map" > I don't think this is correct, it depends on the map type/iterator type as > well as whether we have single hop enabled or not. In most cases I don't > think it is possible. I think we should probably remove this line from the > description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-5561) Remove incorrect description in putAll documentation
[ https://issues.apache.org/jira/browse/GEODE-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh closed GEODE-5561. -- > Remove incorrect description in putAll documentation > > > Key: GEODE-5561 > URL: https://issues.apache.org/jira/browse/GEODE-5561 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Jason Huynh >Priority: Major > > On the page > http://geode.apache.org/docs/guide/10/basic_config/data_entries_custom_classes/managing_data_entries.html > that we claim : "The updates to the cache are done individually in the order > in which they were placed in the Map" > I don't think this is correct, it depends on the map type/iterator type as > well as whether we have single hop enabled or not. In most cases I don't > think it is possible. I think we should probably remove this line from the > description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5561) Remove incorrect description in putAll documentation
Jason Huynh created GEODE-5561: -- Summary: Remove incorrect description in putAll documentation Key: GEODE-5561 URL: https://issues.apache.org/jira/browse/GEODE-5561 Project: Geode Issue Type: Improvement Components: docs Reporter: Jason Huynh On the page http://geode.apache.org/docs/guide/10/basic_config/data_entries_custom_classes/managing_data_entries.html that we claim : "The updates to the cache are done individually in the order in which they were placed in the Map" I don't think this is correct, it depends on the map type/iterator type as well as whether we have single hop enabled or not. In most cases I don't think it is possible. I think we should probably remove this line from the description -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5487) Choice of detect read conflict on transaction commit on a per-region basis.
[ https://issues.apache.org/jira/browse/GEODE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576390#comment-16576390 ] Eugene Nedzvetsky commented on GEODE-5487: -- We use most of regions in read-only mode. Typical our function modifies 1-10 records in one or two regions and reads a few thousand records from another 10-20 regions. So we have a few TXEntrtyState#dirty=true records per transaction if detectReadConflict = false. In case of detectReadConflict=true it produces additional a few thousand TXEntrtyState#dirty=true records which produces additional information in TXLockRequest and additional network traffic between nodes. It's a good point. First of all I'll create performance test. GEODE-5557 duplicates GEODE-5486. GEODE-5486 has unit test with this issue. > Choice of detect read conflict on transaction commit on a per-region basis. > --- > > Key: GEODE-5487 > URL: https://issues.apache.org/jira/browse/GEODE-5487 > Project: Geode > Issue Type: Improvement > Components: docs, transactions >Reporter: Eugene Nedzvetsky >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Geode supports detect read conflict(-Dgemfire.detectReadConflicts=true) on > transaction commit(see > https://geode.apache.org/docs/guide/11/developing/transactions/transaction_semantics.html) > This functionality can be enabled only on application level. It can > dramatically decrease application performance. > I propose to add ability to setup this property per region basis. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
