[jira] [Commented] (GEODE-3584) Refactor ServerLauncher and LocatorLauncher to eliminate code duplication
[
https://issues.apache.org/jira/browse/GEODE-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374002#comment-16374002
]
Cyrille Artho commented on GEODE-3584:
--
If we want to preserve API compatibility, probably the best solution is to add
a couple of wrappers that preserve the old method names as deprecated methods.
This leads to some ugly code, such as @deprecated getHostname \{ getHostName();
}, but will provide a consistent API front-end for new code without breaking
old code.
> Refactor ServerLauncher and LocatorLauncher to eliminate code duplication
> -
>
> Key: GEODE-3584
> URL: https://issues.apache.org/jira/browse/GEODE-3584
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Affects Versions: 1.2.0
>Reporter: Kenneth Howe
>Priority: Major
> Attachments: GEODE-3584-1, GEODE-3584-WIP, GEODE-3584-WIP-2,
> GEODE-3584-WIP-3, GEODE-3584-WIP-4
>
>
> There is some duplication of code in the Launcher classes that can be
> eliminated. Both classes have methods such as getBindAddress (called
> getServerBindAddress in ServerLauncher) that could be hoisted into
> AbstractLauncher class that they both extend. The same goes for the inner
> State classes of the Launchers; they have methods that could be moved to
> AbstractLauncher.ServiceState.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4656) gfsh command describe region should list custom expiry setting
[
https://issues.apache.org/jira/browse/GEODE-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373880#comment-16373880
]
ASF subversion and git services commented on GEODE-4656:
Commit bbbc78fd79cc25021c778b9ceb200503e80cbedc in geode's branch
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bbbc78f ]
GEODE-4656: Decribe region shows entry-idle-time-custom-expiry and
entry-time-to-live-custom-expiry
> gfsh command describe region should list custom expiry setting
> --
>
> Key: GEODE-4656
> URL: https://issues.apache.org/jira/browse/GEODE-4656
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The gfsh command
> {code:java}
> describe region --name=region1{code}
> should list the MyCustomExpiry class as the value for the options given on
> the alter/create region command:
> --entry-idle-time-custom-expiry
> --entry-time-to-live-custom-expiry
> {code:java}
> Type | Name | Value
> -- | --- | ---
> Region | data-policy | REPLICATE
> | entry-idle-time-custom-expiry | MyCustomExpiry
> | size | 0
> | statistics-enabled | true
> | scope | distributed-ack{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4407) Separate incremental backup logic from backup task and oplog
[ https://issues.apache.org/jira/browse/GEODE-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4407: -- Labels: pull-request-available (was: ) > Separate incremental backup logic from backup task and oplog > > > Key: GEODE-4407 > URL: https://issues.apache.org/jira/browse/GEODE-4407 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Anilkumar Gingade >Priority: Major > Labels: pull-request-available > > Incremental backup examines the oplog from current destination to the > previously backed up destination to generate oplogs to be backed up. This > logic is present in both backup task and oplog. We need to separate this out > so the logic can be used for different backup destinations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4736) New protocol should consistently record statistics
[ https://issues.apache.org/jira/browse/GEODE-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4736: -- Labels: pull-request-available (was: ) > New protocol should consistently record statistics > -- > > Key: GEODE-4736 > URL: https://issues.apache.org/jira/browse/GEODE-4736 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > > Some of the ProtobufOperationHandler classes update statistics by calling > startOperation and endOperation on the statistics class. We should update the > statistics consistently at a higher level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2667) Need API to destroy gateway receiver
[
https://issues.apache.org/jira/browse/GEODE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373791#comment-16373791
]
ASF subversion and git services commented on GEODE-2667:
Commit 3b596ff38ac4b55e8dcc447dedce4d0e289415af in geode's branch
refs/heads/develop from [~huynhja]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3b596ff ]
GEODE-2667: Improved javaDoc for GatewayReceiver.destroy() (#1490)
> Need API to destroy gateway receiver
> -
>
> Key: GEODE-2667
> URL: https://issues.apache.org/jira/browse/GEODE-2667
> Project: Geode
> Issue Type: Bug
> Components: docs, wan
>Reporter: Swapnil Bawaskar
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> A {{GatewayReceiver}} can be created from {{GatewayReceiverFactory}},
> however, there is no API for destroying the {{GatewayReceiver}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4736) New protocol should consistently record statistics
Dan Smith created GEODE-4736: Summary: New protocol should consistently record statistics Key: GEODE-4736 URL: https://issues.apache.org/jira/browse/GEODE-4736 Project: Geode Issue Type: Task Components: client/server Reporter: Dan Smith Some of the ProtobufOperationHandler classes update statistics by calling startOperation and endOperation on the statistics class. We should update the statistics consistently at a higher level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4736) New protocol should consistently record statistics
[ https://issues.apache.org/jira/browse/GEODE-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-4736: Assignee: Dan Smith > New protocol should consistently record statistics > -- > > Key: GEODE-4736 > URL: https://issues.apache.org/jira/browse/GEODE-4736 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > Some of the ProtobufOperationHandler classes update statistics by calling > startOperation and endOperation on the statistics class. We should update the > statistics consistently at a higher level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3126) Add ad hoc query execution to new protocol
[ https://issues.apache.org/jira/browse/GEODE-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-3126: -- Labels: pull-request-available (was: ) > Add ad hoc query execution to new protocol > -- > > Key: GEODE-3126 > URL: https://issues.apache.org/jira/browse/GEODE-3126 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Brian Baynes >Priority: Major > Labels: pull-request-available > > As a Geode developer using the new client/server protocol, I need to be able > to send queries and receive expected results. > Add ad hoc query execution to new protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4456) Remove singleton calls from all tests in org.apache.geode.internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4456: -- Labels: pull-request-available (was: ) > Remove singleton calls from all tests in org.apache.geode.internal.cache > > > Key: GEODE-4456 > URL: https://issues.apache.org/jira/browse/GEODE-4456 > Project: Geode > Issue Type: Sub-task > Components: regions, tests, transactions >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > These tests in org.apache.geode.internal.cache invoke singleton getters. > CacheFactory.getAnyInstance(): > * Bug37241DUnitTest > * CommitFunction > * GridAdvisorDUnitTest > * NestedTransactionFunction > * RollbackFunction > * SingleHopStatsDUnitTest > * UpdateVersionDUnitTest > CacheFactory.getExisting(DistributedSystem): > * PartitionedRegionTestHelper > GemFireCacheImpl.getInstance(): > * DiskRegRecoveryJUnitTest > * FixedPRSinglehopDUnitTest > * NetSearchMessagingDUnitTest > * RemoteCQTransactionDUnitTest > * RemoteTransactionDUnitTest > * SystemFailureDUnitTest > GemFireCacheImpl.setInstanceForTests(GemFireCacheImpl): > * ColocationHelperTest > InternalDistributedSystem.getAnyInstance(): > * ClientServerTransactionDUnitTest > * GridAdvisorDUnitTest > InternalDistributedSystem.getConnectedInstance(): > * ClientServerTransactionDUnitTest > * TombstoneCreationJUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3876) gfsh command for custom expiry
[
https://issues.apache.org/jira/browse/GEODE-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373738#comment-16373738
]
ASF subversion and git services commented on GEODE-3876:
Commit bf5b8022cbee51ab7cdf67a3027b481dd9f6e0f8 in geode's branch
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf5b802 ]
Merge branch 'feature/GEODE-3876' into develop
* feature/GEODE-3876:
GEODE-3876: Document gfsh command for custom expiry
> gfsh command for custom expiry
> --
>
> Key: GEODE-3876
> URL: https://issues.apache.org/jira/browse/GEODE-3876
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When creating or altering a region the ability to add custom expiration is
> missing.
> It would be great to have something like this:
> {code:java}
> alter/create region --name=regioName
> [--entry-idle-time-custom-expiry=customExpiryImplementationClassName]
> {code}
> If the class implementing custom expiry also implements Declarable, we should
> add support for passing parameters to the init method.
> {code:java}
> alter/create region --name=regionName
> --entry-idle-time-custom-expiry=CustomExpiryImplementation{'k':'v','k2':'v2'}
> {code}
> The two options for custom expiry are:
> {code}
> --entry-idle-time-custom-expiry=value
> --entry-time-to-live-custom-expiry=value
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3876) gfsh command for custom expiry
[
https://issues.apache.org/jira/browse/GEODE-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373736#comment-16373736
]
ASF subversion and git services commented on GEODE-3876:
Commit ccfe15e8dfc421473f1123746c56fd06bfb05ca6 in geode's branch
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccfe15e ]
GEODE-3876: Document gfsh command for custom expiry
> gfsh command for custom expiry
> --
>
> Key: GEODE-3876
> URL: https://issues.apache.org/jira/browse/GEODE-3876
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When creating or altering a region the ability to add custom expiration is
> missing.
> It would be great to have something like this:
> {code:java}
> alter/create region --name=regioName
> [--entry-idle-time-custom-expiry=customExpiryImplementationClassName]
> {code}
> If the class implementing custom expiry also implements Declarable, we should
> add support for passing parameters to the init method.
> {code:java}
> alter/create region --name=regionName
> --entry-idle-time-custom-expiry=CustomExpiryImplementation{'k':'v','k2':'v2'}
> {code}
> The two options for custom expiry are:
> {code}
> --entry-idle-time-custom-expiry=value
> --entry-time-to-live-custom-expiry=value
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3876) gfsh command for custom expiry
[
https://issues.apache.org/jira/browse/GEODE-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373739#comment-16373739
]
ASF subversion and git services commented on GEODE-3876:
Commit bf5b8022cbee51ab7cdf67a3027b481dd9f6e0f8 in geode's branch
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf5b802 ]
Merge branch 'feature/GEODE-3876' into develop
* feature/GEODE-3876:
GEODE-3876: Document gfsh command for custom expiry
> gfsh command for custom expiry
> --
>
> Key: GEODE-3876
> URL: https://issues.apache.org/jira/browse/GEODE-3876
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When creating or altering a region the ability to add custom expiration is
> missing.
> It would be great to have something like this:
> {code:java}
> alter/create region --name=regioName
> [--entry-idle-time-custom-expiry=customExpiryImplementationClassName]
> {code}
> If the class implementing custom expiry also implements Declarable, we should
> add support for passing parameters to the init method.
> {code:java}
> alter/create region --name=regionName
> --entry-idle-time-custom-expiry=CustomExpiryImplementation{'k':'v','k2':'v2'}
> {code}
> The two options for custom expiry are:
> {code}
> --entry-idle-time-custom-expiry=value
> --entry-time-to-live-custom-expiry=value
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3876) gfsh command for custom expiry
[
https://issues.apache.org/jira/browse/GEODE-3876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373737#comment-16373737
]
ASF subversion and git services commented on GEODE-3876:
Commit bf5b8022cbee51ab7cdf67a3027b481dd9f6e0f8 in geode's branch
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf5b802 ]
Merge branch 'feature/GEODE-3876' into develop
* feature/GEODE-3876:
GEODE-3876: Document gfsh command for custom expiry
> gfsh command for custom expiry
> --
>
> Key: GEODE-3876
> URL: https://issues.apache.org/jira/browse/GEODE-3876
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When creating or altering a region the ability to add custom expiration is
> missing.
> It would be great to have something like this:
> {code:java}
> alter/create region --name=regioName
> [--entry-idle-time-custom-expiry=customExpiryImplementationClassName]
> {code}
> If the class implementing custom expiry also implements Declarable, we should
> add support for passing parameters to the init method.
> {code:java}
> alter/create region --name=regionName
> --entry-idle-time-custom-expiry=CustomExpiryImplementation{'k':'v','k2':'v2'}
> {code}
> The two options for custom expiry are:
> {code}
> --entry-idle-time-custom-expiry=value
> --entry-time-to-live-custom-expiry=value
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during s
[
https://issues.apache.org/jira/browse/GEODE-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4675:
--
Labels: pull-request-available (was: )
> CI failure (suspect strings): DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected reported as fatal
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
> > testPartitionedParallelPropagationHA FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 9339
> [fatal 2018/02/13 21:12:48.099 UTC tid=891]
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
> at
> org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
> at
> org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
> at java.lang.Thread.run(Thread.java:748)
> ---
> {noformat}
> According to the logs, this looks like it occurs during shutdown ...
> {noformat}
> [vm1] [info 2018/02/13 21:12:48.075 UTC
> tid=30] Stopping membership services
> [vm0] [info 2018/02/13 21:12:48.077 UTC thread 0> tid=398] GMSHealthMonitor server thread exiting
> [vm0] [info 2018/02/13 21:12:48.078 UTC
> tid=30] GMSHealthMonitor serverSocketExecutor is terminated
> [vm3] [info 2018/02/13 21:12:48.079 UTC
> tid=896] received leave request from 172.17.0.2:32771 for
> 172.17.0.2(180):32771
> [vm0] [info 2018/02/13 21:12:48.084 UTC
> tid=30] DistributionManager stopped in 121ms.
> [vm0] [info 2018/02/13 21:12:48.086 UTC
> tid=30] Marking DistributionManager 172.17.0.2(176):32770 as closed.
> [vm1] [info 2018/02/13 21:12:48.087 UTC
> tid=30] GMSHealthMonitor server socket is closed in stopServices().
> [vm0] [info 2018/02/13 21:12:48.089 UTC
> tid=30] Got result:
[jira] [Resolved] (GEODE-2905) CI failure: org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > searchWithoutIndexShouldReturnError
[
https://issues.apache.org/jira/browse/GEODE-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diane Hardman resolved GEODE-2905.
--
Resolution: Cannot Reproduce
> CI failure:
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest >
> searchWithoutIndexShouldReturnError
> --
>
> Key: GEODE-2905
> URL: https://issues.apache.org/jira/browse/GEODE-2905
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: nabarun
>Priority: Major
>
> This test failed in Apache Jenkins build #830.
> {noformat}
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest >
> searchWithoutIndexShouldReturnError FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest.searchWithoutIndexShouldReturnError(LuceneIndexCommandsDUnitTest.java:462)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4733) Replace and remove trivial methods from ObjectUtils
[
https://issues.apache.org/jira/browse/GEODE-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-4733:
---
Assignee: Patrick Rhomberg
> Replace and remove trivial methods from ObjectUtils
> ---
>
> Key: GEODE-4733
> URL: https://issues.apache.org/jira/browse/GEODE-4733
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> For instance, {{defaultIfNull(T... values)}} is exclusively called with two
> input parameters, while the method name and signature makes it unclear that
> the second value is meant to be the default value if the first parameter is
> null.
> This method can be cleanly replaced by a ternary {{v1 != null ? v1 : v2}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4735) Move CliUtil "find member" methods to GfshCommand
[ https://issues.apache.org/jira/browse/GEODE-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-4735: --- Assignee: Patrick Rhomberg > Move CliUtil "find member" methods to GfshCommand > - > > Key: GEODE-4735 > URL: https://issues.apache.org/jira/browse/GEODE-4735 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > Many of the CliUtil methods, particularly the "find member" methods, are > exclusively used and indeed are on-line calls by GfshCommand methods. > The implementation of these methods should belong to the class that consumes > them. > Moreover, it will make testing / mocking much easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4732) Code Cleanup: Remove unnecessary Util methods / classes
[
https://issues.apache.org/jira/browse/GEODE-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4732:
--
Labels: pull-request-available (was: )
> Code Cleanup: Remove unnecessary Util methods / classes
> ---
>
> Key: GEODE-4732
> URL: https://issues.apache.org/jira/browse/GEODE-4732
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> Geode has many {{*Utils}} classes that duplicate each other and may be
> trivialized by existing libraries, particularly those utilities in the Apache
> Commons library.
> See sub-tasks for additional information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4735) Move CliUtil "find member" methods to GfshCommand
Patrick Rhomberg created GEODE-4735: --- Summary: Move CliUtil "find member" methods to GfshCommand Key: GEODE-4735 URL: https://issues.apache.org/jira/browse/GEODE-4735 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg Many of the CliUtil methods, particularly the "find member" methods, are exclusively used and indeed are on-line calls by GfshCommand methods. The implementation of these methods should belong to the class that consumes them. Moreover, it will make testing / mocking much easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-3584) Refactor ServerLauncher and LocatorLauncher to eliminate code duplication
[ https://issues.apache.org/jira/browse/GEODE-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373286#comment-16373286 ] Kenneth Howe edited comment on GEODE-3584 at 2/23/18 12:04 AM: --- I did some work resolving compilation conflicts between Cyrille's patch and the Geode develop branch as of Jan17, 2018. Pushed to Geode repo on branch feature/GEODE-3584 was (Author: khowe): I done some work resolving compilation coflicts between Cyrille's patch and the Geode develop branch as of Jan17, 2018. Pushed to Geode repo on branch feature/GEODE-3584 > Refactor ServerLauncher and LocatorLauncher to eliminate code duplication > - > > Key: GEODE-3584 > URL: https://issues.apache.org/jira/browse/GEODE-3584 > Project: Geode > Issue Type: Improvement > Components: gfsh >Affects Versions: 1.2.0 >Reporter: Kenneth Howe >Priority: Major > Attachments: GEODE-3584-1, GEODE-3584-WIP, GEODE-3584-WIP-2, > GEODE-3584-WIP-3, GEODE-3584-WIP-4 > > > There is some duplication of code in the Launcher classes that can be > eliminated. Both classes have methods such as getBindAddress (called > getServerBindAddress in ServerLauncher) that could be hoisted into > AbstractLauncher class that they both extend. The same goes for the inner > State classes of the Launchers; they have methods that could be moved to > AbstractLauncher.ServiceState. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4625) Create region with the same name on different groups in gfsh should fail early
[ https://issues.apache.org/jira/browse/GEODE-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373697#comment-16373697 ] ASF subversion and git services commented on GEODE-4625: Commit 804ecfabef7a1e661626027e1e01e5652901c036 in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=804ecfa ] GEODE-4625: name collision check when create region through gfsh (#1483) > Create region with the same name on different groups in gfsh should fail early > -- > > Key: GEODE-4625 > URL: https://issues.apache.org/jira/browse/GEODE-4625 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > 1. creating non-proxy region: check to see if there is a non-proxy region > with the same name on the entire cluster or not. If yes, abort the creation. > 2. creating proxy region: check to see if there is any region with the same > name on the group or not, if yes, abort the creation. > email thread: > http://mail-archives.apache.org/mod_mbox/geode-user/201802.mbox/%3ccaheksukj65m+-lc-hser01djvggeq6up0ondq0pxemi1tbm...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4734) Cleanup some tests to use as examples on Geode wiki
[ https://issues.apache.org/jira/browse/GEODE-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-4734: Assignee: Kirk Lund > Cleanup some tests to use as examples on Geode wiki > --- > > Key: GEODE-4734 > URL: https://issues.apache.org/jira/browse/GEODE-4734 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > I'm looking for some tests to use as recommended examples on the Geode wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4734) Cleanup some tests to use as examples on Geode wiki
Kirk Lund created GEODE-4734: Summary: Cleanup some tests to use as examples on Geode wiki Key: GEODE-4734 URL: https://issues.apache.org/jira/browse/GEODE-4734 Project: Geode Issue Type: Improvement Components: tests Reporter: Kirk Lund I'm looking for some tests to use as recommended examples on the Geode wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4733) Replace and remove trivial methods from ObjectUtils
[
https://issues.apache.org/jira/browse/GEODE-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-4733:
Summary: Replace and remove trivial methods from ObjectUtils (was: Replace
ObjectUtils.defaultIfNull methods with ternary operator.)
> Replace and remove trivial methods from ObjectUtils
> ---
>
> Key: GEODE-4733
> URL: https://issues.apache.org/jira/browse/GEODE-4733
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
>
> {{defaultIfNull(T... values)}} is exclusively called with two input
> parameters, while the method name and signature makes it unclear that the
> second value is meant to be the default value if the first parameter is null.
> This method can be cleanly replaced by a ternary {{v1 != null ? v1 : v2}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4733) Replace and remove trivial methods from ObjectUtils
[
https://issues.apache.org/jira/browse/GEODE-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-4733:
Description:
For instance, {{defaultIfNull(T... values)}} is exclusively called with two
input parameters, while the method name and signature makes it unclear that the
second value is meant to be the default value if the first parameter is null.
This method can be cleanly replaced by a ternary {{v1 != null ? v1 : v2}}.
was:
{{defaultIfNull(T... values)}} is exclusively called with two input parameters,
while the method name and signature makes it unclear that the second value is
meant to be the default value if the first parameter is null.
This method can be cleanly replaced by a ternary {{v1 != null ? v1 : v2}}.
> Replace and remove trivial methods from ObjectUtils
> ---
>
> Key: GEODE-4733
> URL: https://issues.apache.org/jira/browse/GEODE-4733
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
>
> For instance, {{defaultIfNull(T... values)}} is exclusively called with two
> input parameters, while the method name and signature makes it unclear that
> the second value is meant to be the default value if the first parameter is
> null.
> This method can be cleanly replaced by a ternary {{v1 != null ? v1 : v2}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4733) Replace ObjectUtils.defaultIfNull methods with ternary operator.
Patrick Rhomberg created GEODE-4733:
---
Summary: Replace ObjectUtils.defaultIfNull methods with ternary
operator.
Key: GEODE-4733
URL: https://issues.apache.org/jira/browse/GEODE-4733
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
{{defaultIfNull(T... values)}} is exclusively called with two input parameters,
while the method name and signature makes it unclear that the second value is
meant to be the default value if the first parameter is null.
This method can be cleanly replaced by a ternary {{v1 != null ? v1 : v2}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4732) Code Cleanup: Remove unnecessary Util methods / classes
Patrick Rhomberg created GEODE-4732:
---
Summary: Code Cleanup: Remove unnecessary Util methods / classes
Key: GEODE-4732
URL: https://issues.apache.org/jira/browse/GEODE-4732
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Geode has many {{*Utils}} classes that duplicate each other and may be
trivialized by existing libraries, particularly those utilities in the Apache
Commons library.
See sub-tasks for additional information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4731) Reconsile and unify ServerLauncher.Command and LocatorLauncher.Command enums
[ https://issues.apache.org/jira/browse/GEODE-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-4731: --- Assignee: Patrick Rhomberg > Reconsile and unify ServerLauncher.Command and LocatorLauncher.Command enums > > > Key: GEODE-4731 > URL: https://issues.apache.org/jira/browse/GEODE-4731 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4731) Reconsile and unify ServerLauncher.Command and LocatorLauncher.Command enums
Patrick Rhomberg created GEODE-4731: --- Summary: Reconsile and unify ServerLauncher.Command and LocatorLauncher.Command enums Key: GEODE-4731 URL: https://issues.apache.org/jira/browse/GEODE-4731 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3584) Refactor ServerLauncher and LocatorLauncher to eliminate code duplication
[ https://issues.apache.org/jira/browse/GEODE-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373638#comment-16373638 ] Patrick Rhomberg commented on GEODE-3584: - A few thoughts, in no particular order: First, I love the refactoring effort! So thanks for getting that ball rolling. This looks like it's going to touch a lot of non-internal, non-private methods and classes. To adhere to SemVer, we need to not break any public-facing API until the next major release. I definitely think these classes could use some reorganization, but we should start a conversation on d...@geode.apache.org (and maybe user@, too) if we want to, say, deprecate use of the inner-class builders in factor of them becoming their own first-class classes, as it were. It seems like, with how densely connected some of these things are, we should probably split this up into several tickets. I poked through Ken's feature branch and took a run at what I had hoped were low-hanging refactor fruits, and I immediately realized how non-trivial this effort is going to be. Potential tickets that come to my mind are: several tickets for promoting inner classes to their own classes, a ticket for reconciling the differences in the Command enums, and another ticket or two to reduce code duplication. I'll go ahead and open and start the Command reconciliation ticket as a child to this ticket. > Refactor ServerLauncher and LocatorLauncher to eliminate code duplication > - > > Key: GEODE-3584 > URL: https://issues.apache.org/jira/browse/GEODE-3584 > Project: Geode > Issue Type: Improvement > Components: gfsh >Affects Versions: 1.2.0 >Reporter: Kenneth Howe >Priority: Major > Attachments: GEODE-3584-1, GEODE-3584-WIP, GEODE-3584-WIP-2, > GEODE-3584-WIP-3, GEODE-3584-WIP-4 > > > There is some duplication of code in the Launcher classes that can be > eliminated. Both classes have methods such as getBindAddress (called > getServerBindAddress in ServerLauncher) that could be hoisted into > AbstractLauncher class that they both extend. The same goes for the inner > State classes of the Launchers; they have methods that could be moved to > AbstractLauncher.ServiceState. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4570) Remove singleton calls from product code in org.apache.geode.internal.security
[ https://issues.apache.org/jira/browse/GEODE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373605#comment-16373605 ] ASF subversion and git services commented on GEODE-4570: Commit 9a26976e2e30b4277b920a9c7c73432b2dfa6d61 in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9a26976 ] GEODE-4570: Remove getInstance() singleton call from SecurityServiceF… (#1482) * Also now need to pass a SecurityContext into the Spring environment > Remove singleton calls from product code in org.apache.geode.internal.security > -- > > Key: GEODE-4570 > URL: https://issues.apache.org/jira/browse/GEODE-4570 > Project: Geode > Issue Type: Sub-task > Components: security >Reporter: Kirk Lund >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > These product classes in org.apache.geode.internal.security invoke singleton > getters. > GemFireCacheImpl.getInstance(): > * SecurityServiceFactory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4730) Remove DLock acquisition timeouts in ClusterConfigurationService.createConfigurationResponse
Jens Deppe created GEODE-4730: - Summary: Remove DLock acquisition timeouts in ClusterConfigurationService.createConfigurationResponse Key: GEODE-4730 URL: https://issues.apache.org/jira/browse/GEODE-4730 Project: Geode Issue Type: Improvement Components: configuration Reporter: Jens Deppe Reviewing some of this code with [~upthewaterspout] it seems like it would be worse if the lock acquisition fails and an empty response is returned vs. a hang/deadlock happening on server startup. At least if there's a hang we'd know it as opposed to a server starting up without any configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4638) review protobuf server error responses and logging for region-not-found
[ https://issues.apache.org/jira/browse/GEODE-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4638: -- Labels: pull-request-available (was: ) > review protobuf server error responses and logging for region-not-found > --- > > Key: GEODE-4638 > URL: https://issues.apache.org/jira/browse/GEODE-4638 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > > Some operation handlers log region-not-found problems at error level and some > at warning level. Some return a SERVER_ERROR error code and some return an > INVALID_REQUEST error code. These should probably all behave in the same way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4729) Rearrange Geode Native Quickstarts and Examples
Addison created GEODE-4729: -- Summary: Rearrange Geode Native Quickstarts and Examples Key: GEODE-4729 URL: https://issues.apache.org/jira/browse/GEODE-4729 Project: Geode Issue Type: Sub-task Components: native client Reporter: Addison The goal of this ticket is to restructure the Geode Native docs to make the addition of examples easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4728) Geode Native Documentation Improvements
Addison created GEODE-4728: -- Summary: Geode Native Documentation Improvements Key: GEODE-4728 URL: https://issues.apache.org/jira/browse/GEODE-4728 Project: Geode Issue Type: Improvement Components: native client Reporter: Addison This ticket will capture a series of changes to the Geode Native docs to bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4725) LuceneEventListener should set pdxReadSerialized back to original value
[ https://issues.apache.org/jira/browse/GEODE-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4725: -- Labels: pull-request-available (was: ) > LuceneEventListener should set pdxReadSerialized back to original value > --- > > Key: GEODE-4725 > URL: https://issues.apache.org/jira/browse/GEODE-4725 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > > In LuceneEventListener.process, we set the value of pdx read serialized to > true: > DefaultQuery.setPdxReadSerialized(true); > > In the finally block, we end up setting it to false. > This is incorrect, we should store the original value before setting to true > and set the value back to the original value in the finally block. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4638) review protobuf server error responses and logging for region-not-found
[ https://issues.apache.org/jira/browse/GEODE-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge reassigned GEODE-4638: Assignee: Michael Dodge > review protobuf server error responses and logging for region-not-found > --- > > Key: GEODE-4638 > URL: https://issues.apache.org/jira/browse/GEODE-4638 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Michael Dodge >Priority: Major > > Some operation handlers log region-not-found problems at error level and some > at warning level. Some return a SERVER_ERROR error code and some return an > INVALID_REQUEST error code. These should probably all behave in the same way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3523) AutoConnectionSourceDUnitTest: testDynamicallyFindLocators failed with Unable to connect to any locators in the list
[ https://issues.apache.org/jira/browse/GEODE-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373488#comment-16373488 ] ASF subversion and git services commented on GEODE-3523: Commit e9ada484eb671498e76698ef34b0b1d6fd28184b in geode's branch refs/heads/develop from [~geodeintegration] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e9ada48 ] GEODE-3523: Update locatorDiscoveryCallback after updating state Some tests wait for this callback to be notified of new locators before killing old locators. But The callback is called before the internal state on the client is updated. So there was a race condition where the test would know about the new locator, but the client code itself would not use it yet. > AutoConnectionSourceDUnitTest: testDynamicallyFindLocators failed with Unable > to connect to any locators in the list > > > Key: GEODE-3523 > URL: https://issues.apache.org/jira/browse/GEODE-3523 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Hitesh Khamesra >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest > > testDynamicallyFindLocators FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest$3.call > in VM 2 running on Host 97e556d10832 with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:387) > at org.apache.geode.test.dunit.VM.invoke(VM.java:357) > at org.apache.geode.test.dunit.VM.invoke(VM.java:325) > at > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest.putInVM(AutoConnectionSourceDUnitTest.java:470) > at > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest.putAndWaitForSuccess(AutoConnectionSourceDUnitTest.java:448) > at > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest.testDynamicallyFindLocators(AutoConnectionSourceDUnitTest.java:199) > Caused by: > org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to > connect to any locators in the list [LocatorAddress > [socketInetAddress=97e556d10832/172.17.0.4:26078, hostname=97e556d10832, > isIpString=false], LocatorAddress > [socketInetAddress=97e556d10832/172.17.0.4:29796, hostname=172.17.0.4, > isIpString=true]] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3523) AutoConnectionSourceDUnitTest: testDynamicallyFindLocators failed with Unable to connect to any locators in the list
[ https://issues.apache.org/jira/browse/GEODE-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-3523. -- Resolution: Fixed Fix Version/s: 1.5.0 > AutoConnectionSourceDUnitTest: testDynamicallyFindLocators failed with Unable > to connect to any locators in the list > > > Key: GEODE-3523 > URL: https://issues.apache.org/jira/browse/GEODE-3523 > Project: Geode > Issue Type: Bug > Components: locator >Reporter: Hitesh Khamesra >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest > > testDynamicallyFindLocators FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest$3.call > in VM 2 running on Host 97e556d10832 with 4 VMs > at org.apache.geode.test.dunit.VM.invoke(VM.java:387) > at org.apache.geode.test.dunit.VM.invoke(VM.java:357) > at org.apache.geode.test.dunit.VM.invoke(VM.java:325) > at > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest.putInVM(AutoConnectionSourceDUnitTest.java:470) > at > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest.putAndWaitForSuccess(AutoConnectionSourceDUnitTest.java:448) > at > org.apache.geode.cache.client.internal.AutoConnectionSourceDUnitTest.testDynamicallyFindLocators(AutoConnectionSourceDUnitTest.java:199) > Caused by: > org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to > connect to any locators in the list [LocatorAddress > [socketInetAddress=97e556d10832/172.17.0.4:26078, hostname=97e556d10832, > isIpString=false], LocatorAddress > [socketInetAddress=97e556d10832/172.17.0.4:29796, hostname=172.17.0.4, > isIpString=true]] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4641) CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild
[
https://issues.apache.org/jira/browse/GEODE-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fred Krone reassigned GEODE-4641:
-
Assignee: Kirk Lund
> CI Failure:
> PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild
> ---
>
> Key: GEODE-4641
> URL: https://issues.apache.org/jira/browse/GEODE-4641
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Assignee: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:150)
> at
> org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:424)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:1143)
> Caused by:
> org.mockito.exceptions.verification.NoInteractionsWanted:
> No interactions wanted here:
> -> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest$10.call(PersistentColocatedPartitionedRegionDUnitTest.java:521)
> But found this interaction on mock 'appender':
> -> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> ***
> For your reference, here is the list of all invocations ([?] - means
> unverified).
> 1. -> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.addLoggerAppender(AbstractConfiguration.java:704)
> 2. -> at
> org.apache.logging.log4j.core.config.AppenderControl.(AppenderControl.java:51)
> 3. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 4. -> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 5. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 6. -> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 7. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 8. -> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 9. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 10. -> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 11. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 12. -> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 13. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 14. -> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 15. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 16. [?]-> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> 17. -> at
> org.apache.logging.log4j.core.config.AppenderControl.ensureAppenderStarted(AppenderControl.java:134)
> 18. [?]-> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4726) Documentation is misleading with a multi-homed Geode cluster
[
https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyle R Dunn updated GEODE-4726:
---
Description:
The necessary step for binding Geode to an arbitrary network interface (e.g.
{{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
non-loopback NICs) is quite common.
The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on the
interface used by the server process; however passing {{bind-address=w.x.y.z}}
to the server startup produces the correct startup behavior. The documentation
around this is a bit misleading.
The symptom was a startup hang, ultimately timing out, like the following:
{code:bash}
[info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
the distributed system through coordinator
172.16.139.1(locator1:70192:locator):1024 using address
192.168.0.29(server1:70198):1024
{code}
The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8).
{code:bash}
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh <
http://geode.apache.org/schema/cache;
xmlns:gpdb="http://schema.pivotal.io/gemfire/gpdb;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://geode.apache.org/schema/cache
http://geode.apache.org/schema/cache/cache-1.0.xsd
http://schema.pivotal.io/gemfire/gpdb
http://schema.pivotal.io/gemfire/gpdb/gpdb-2.4.xsd;
version="1.0">
{code}
was:
The necessary step for binding Geode to an arbitrary network interface (e.g.
{{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
non-loopback NICs) is quite common.
The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on the
interface used by the server process; however passing {{bind-address=w.x.y.z}}
to the server startup produces the correct startup behavior. The documentation
around this is a bit misleading.
The symptom was a startup hang, ultimately timing out, like the following:
{code:bash}
[info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
the distributed system through coordinator
172.16.139.1(locator1:70192:locator):1024 using address
192.168.0.29(server1:70198):1024
{code}
The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8).
{code:bash}
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh < Documentation is misleading with a multi-homed Geode cluster
>
>
> Key: GEODE-4726
> URL: https://issues.apache.org/jira/browse/GEODE-4726
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Kyle R Dunn
>Priority: Major
>
> The necessary step for binding Geode to an arbitrary network interface (e.g.
> {{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
> non-loopback NICs) is quite common.
> The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on
> the interface used by the server process; however passing
> {{bind-address=w.x.y.z}} to the server startup produces the correct startup
> behavior. The documentation around this is a bit misleading.
> The symptom was a startup hang, ultimately timing out, like the following:
> {code:bash}
> [info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
> the distributed system through coordinator
> 172.16.139.1(locator1:70192:locator):1024 using address
> 192.168.0.29(server1:70198):1024
> {code}
> The following script was used successfully on Mac OS to bind to the "last"
> interface listed by ifconfig (vmnet8).
> {code:bash}
> #!/bin/bash
> rm -rf locator1 server1
> export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
> export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
> gfsh < start locator --name=locator1 --locators=172.16.139.1[10334]
> --bind-address=172.16.139.1 --port=10334 --include-system-classpath
> start server --name=server1 --start-rest-api=true --http-service-port=28080
> --locators=172.16.139.1[10334] --bind-address=172.16.139.1
> --cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH}
> --include-system-classpath
> EOF
> {code}
> The contents of {{ggc_cache.xml}} is below.
> {code:xml}
>
> http://geode.apache.org/schema/cache;
>
[jira] [Updated] (GEODE-4726) Documentation is misleading with a multi-homed Geode cluster
[
https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyle R Dunn updated GEODE-4726:
---
Description:
The necessary step for binding Geode to an arbitrary network interface (e.g.
{{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
non-loopback NICs) is quite common.
The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on the
interface used by the server process; however passing {{bind-address=w.x.y.z}}
to the server startup produces the correct startup behavior. The documentation
around this is a bit misleading.
The symptom was a startup hang, ultimately timing out, like the following:
{code:bash}
[info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
the distributed system through coordinator
172.16.139.1(locator1:70192:locator):1024 using address
192.168.0.29(server1:70198):1024
{code}
The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8).
{code:bash}
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh < tid=0x1] Attempting to join
the distributed system through coordinator
172.16.139.1(locator1:70192:locator):1024 using address
192.168.0.29(server1:70198):1024
{code}
{code:bash}
// The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8)
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh < Documentation is misleading with a multi-homed Geode cluster
>
>
> Key: GEODE-4726
> URL: https://issues.apache.org/jira/browse/GEODE-4726
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Kyle R Dunn
>Priority: Major
>
> The necessary step for binding Geode to an arbitrary network interface (e.g.
> {{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
> non-loopback NICs) is quite common.
> The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on
> the interface used by the server process; however passing
> {{bind-address=w.x.y.z}} to the server startup produces the correct startup
> behavior. The documentation around this is a bit misleading.
> The symptom was a startup hang, ultimately timing out, like the following:
> {code:bash}
> [info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
> the distributed system through coordinator
> 172.16.139.1(locator1:70192:locator):1024 using address
> 192.168.0.29(server1:70198):1024
> {code}
> The following script was used successfully on Mac OS to bind to the "last"
> interface listed by ifconfig (vmnet8).
> {code:bash}
> #!/bin/bash
> rm -rf locator1 server1
> export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
> export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
> gfsh < start locator --name=locator1 --locators=172.16.139.1[10334]
> --bind-address=172.16.139.1 --port=10334 --include-system-classpath
> start server --name=server1 --start-rest-api=true --http-service-port=28080
> --locators=172.16.139.1[10334] --bind-address=172.16.139.1
> --cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH}
> --include-system-classpath
> EOF
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4726) Documentation is misleading with a multi-homed Geode cluster
[
https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyle R Dunn updated GEODE-4726:
---
Description:
The necessary step for binding Geode to an arbitrary network interface (e.g.
{{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
non-loopback NICs) is quite common.
The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on the
interface used by the server process; however passing {{bind-address=w.x.y.z}}
to the server startup produces the correct startup behavior. The documentation
around this is a bit misleading.
The symptom was a startup hang, ultimately timing out, like the following:
{code:bash}
[info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
the distributed system through coordinator
172.16.139.1(locator1:70192:locator):1024 using address
192.168.0.29(server1:70198):1024
{code}
{code:bash}
// The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8)
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh < tid=0x1] Attempting to join
the distributed system through coordinator
172.16.139.1(locator1:70192:locator):1024 using address
192.168.0.29(server1:70198):1024
{code]
{code:bash}
// The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8)
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh < Documentation is misleading with a multi-homed Geode cluster
>
>
> Key: GEODE-4726
> URL: https://issues.apache.org/jira/browse/GEODE-4726
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Kyle R Dunn
>Priority: Major
>
> The necessary step for binding Geode to an arbitrary network interface (e.g.
> {{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
> non-loopback NICs) is quite common.
> The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on
> the interface used by the server process; however passing
> {{bind-address=w.x.y.z}} to the server startup produces the correct startup
> behavior. The documentation around this is a bit misleading.
> The symptom was a startup hang, ultimately timing out, like the following:
> {code:bash}
> [info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
> the distributed system through coordinator
> 172.16.139.1(locator1:70192:locator):1024 using address
> 192.168.0.29(server1:70198):1024
> {code}
> {code:bash}
> // The following script was used successfully on Mac OS to bind to the "last"
> interface listed by ifconfig (vmnet8)
> #!/bin/bash
> rm -rf locator1 server1
> export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
> export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
> gfsh < start locator --name=locator1 --locators=172.16.139.1[10334]
> --bind-address=172.16.139.1 --port=10334 --include-system-classpath
> start server --name=server1 --start-rest-api=true --http-service-port=28080
> --locators=172.16.139.1[10334] --bind-address=172.16.139.1
> --cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH}
> --include-system-classpath
> EOF
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4726) Documentation is misleading with a multi-homed Geode cluster
[
https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyle R Dunn updated GEODE-4726:
---
Description:
The necessary step for binding Geode to an arbitrary network interface (e.g.
{{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
non-loopback NICs) is quite common.
The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on the
interface used by the server process; however passing {{bind-address=w.x.y.z}}
to the server startup produces the correct startup behavior. The documentation
around this is a bit misleading.
The symptom was a startup hang, ultimately timing out, like the following:
{code:bash}
[info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
the distributed system through coordinator
172.16.139.1(locator1:70192:locator):1024 using address
192.168.0.29(server1:70198):1024
{code]
{code:bash}
// The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8)
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh < Documentation is misleading with a multi-homed Geode cluster
>
>
> Key: GEODE-4726
> URL: https://issues.apache.org/jira/browse/GEODE-4726
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Kyle R Dunn
>Priority: Major
>
> The necessary step for binding Geode to an arbitrary network interface (e.g.
> {{eth2}}), is not clearly documented. A multi-homing scenario (i.e. several
> non-loopback NICs) is quite common.
> The {{server-bind-address=w.x.y.z}} parameter appears to have no effect on
> the interface used by the server process; however passing
> {{bind-address=w.x.y.z}} to the server startup produces the correct startup
> behavior. The documentation around this is a bit misleading.
> The symptom was a startup hang, ultimately timing out, like the following:
> {code:bash}
> [info 2018/02/22 13:13:29.134 MST server1 tid=0x1] Attempting to join
> the distributed system through coordinator
> 172.16.139.1(locator1:70192:locator):1024 using address
> 192.168.0.29(server1:70198):1024
> {code]
> {code:bash}
> // The following script was used successfully on Mac OS to bind to the "last"
> interface listed by ifconfig (vmnet8)
> #!/bin/bash
> rm -rf locator1 server1
> export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
> export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
> gfsh < start locator --name=locator1 --locators=172.16.139.1[10334]
> --bind-address=172.16.139.1 --port=10334 --include-system-classpath
> start server --name=server1 --start-rest-api=true --http-service-port=28080
> --locators=172.16.139.1[10334] --bind-address=172.16.139.1
> --cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH}
> --include-system-classpath
> EOF
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4727) Rewrite GfshInitFileJUnitTest
Barbara Pruijn created GEODE-4727: - Summary: Rewrite GfshInitFileJUnitTest Key: GEODE-4727 URL: https://issues.apache.org/jira/browse/GEODE-4727 Project: Geode Issue Type: Improvement Components: gfsh, tests Reporter: Barbara Pruijn Test has a lot of code dedicated to changing static loggers to be no-op to reduce noise. We should be able to simplify the test using PowerMock and/or SystemOutRule/SystemErrRule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4727) Rewrite GfshInitFileJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4727: -- Priority: Minor (was: Major) > Rewrite GfshInitFileJUnitTest > - > > Key: GEODE-4727 > URL: https://issues.apache.org/jira/browse/GEODE-4727 > Project: Geode > Issue Type: Improvement > Components: gfsh, tests >Reporter: Barbara Pruijn >Priority: Minor > > Test has a lot of code dedicated to changing static loggers to be no-op to > reduce noise. We should be able to simplify the test using PowerMock and/or > SystemOutRule/SystemErrRule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4726) Documentation is misleading with a multi-homed Geode cluster
[
https://issues.apache.org/jira/browse/GEODE-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kyle R Dunn updated GEODE-4726:
---
Description:
Trying to bind Geode to an arbitrary network interface (e.g. {{eth2}}),
requires some non-obvious parameters to be set. Some of these parameters
appear to be unrelated to multi-homing entirely, yet are necessary for both a
locator and server to start correctly.
For example, the {{server-bind-address=w.x.y.z}} parameter appears to have no
effect on the interface used by the server process; however passing
{{bind-address=w.x.y.z}} to the server startup produces the correct startup
behavior.
Additionally, the {{hostname-for-clients}} parameter appears to be required for
certain Geode extensions to function once added to the {{CLASSPATH}} - in my
case it was a propriety Pivotal extension (GGC).
{code:shell}
// The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8)
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh < Documentation is misleading with a multi-homed Geode cluster
>
>
> Key: GEODE-4726
> URL: https://issues.apache.org/jira/browse/GEODE-4726
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Kyle R Dunn
>Priority: Major
>
> Trying to bind Geode to an arbitrary network interface (e.g. {{eth2}}),
> requires some non-obvious parameters to be set. Some of these parameters
> appear to be unrelated to multi-homing entirely, yet are necessary for both a
> locator and server to start correctly.
> For example, the {{server-bind-address=w.x.y.z}} parameter appears to have no
> effect on the interface used by the server process; however passing
> {{bind-address=w.x.y.z}} to the server startup produces the correct startup
> behavior.
> Additionally, the {{hostname-for-clients}} parameter appears to be required
> for certain Geode extensions to function once added to the {{CLASSPATH}} - in
> my case it was a propriety Pivotal extension (GGC).
> {code:shell}
> // The following script was used successfully on Mac OS to bind to the "last"
> interface listed by ifconfig (vmnet8)
> #!/bin/bash
> rm -rf locator1 server1
> export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
> export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
> gfsh < start locator --name=locator1 --locators=172.16.139.1[10334]
> --bind-address=172.16.139.1 --port=10334 --include-system-classpath
> --hostname-for-clients=172.16.139.1
> start server --name=server1 --start-rest-api=true --http-service-port=28080
> --locators=172.16.139.1[10334] --bind-address=172.16.139.1
> --cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH}
> --include-system-classpath
> EOF
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4726) Documentation is misleading with a multi-homed Geode cluster
Kyle R Dunn created GEODE-4726:
--
Summary: Documentation is misleading with a multi-homed Geode
cluster
Key: GEODE-4726
URL: https://issues.apache.org/jira/browse/GEODE-4726
Project: Geode
Issue Type: Bug
Components: configuration
Reporter: Kyle R Dunn
Trying to bind Geode to an arbitrary network interface (e.g. {{eth2}}),
requires some non-obvious parameters to be set. Some of these parameters
appear to be unrelated to multi-homing entirely, yet are necessary for both a
locator and server to start correctly.
For example, the {{--server-bind-address=w.x.y.z}} parameter appears to have no
effect on the interface used by the server process; however passing
{{--bind-address=w.x.y.z}} to the server startup produces the correct startup
behavior.
Additionally, the {{--hostname-for-clients}} parameter appears to be required
for certain Geode extensions to function once added to the {{CLASSPATH}} - in
my case it was a propriety Pivotal extension (GGC).
{code:shell}
// The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8)
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh <
[jira] [Resolved] (GEODE-4493) Remove singleton calls from all tests in org.apache.geode.internal.cache.control
[ https://issues.apache.org/jira/browse/GEODE-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-4493. - Resolution: Fixed Fix Version/s: 1.5.0 > Remove singleton calls from all tests in > org.apache.geode.internal.cache.control > > > Key: GEODE-4493 > URL: https://issues.apache.org/jira/browse/GEODE-4493 > Project: Geode > Issue Type: Sub-task > Components: core, regions, tests >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > These tests in org.apache.geode.internal.cache.control invoke singleton > getters. > GemFireCacheImpl.setInstanceForTests(GemFireCacheImpl): > * RebalanceOperationDUnitTest > InternalDistributedSystem.getAnyInstance(): > * TestMemoryThresholdListener -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4493) Remove singleton calls from all tests in org.apache.geode.internal.cache.control
[ https://issues.apache.org/jira/browse/GEODE-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373385#comment-16373385 ] ASF subversion and git services commented on GEODE-4493: Commit 00fa527c85d9d16365f48b881d7951290d47ec5f in geode's branch refs/heads/develop from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=00fa527 ] GEODE-4493: remove InternalDistributedSystem.getAnyInstance call (#1485) Removed by using a static log4j logger > Remove singleton calls from all tests in > org.apache.geode.internal.cache.control > > > Key: GEODE-4493 > URL: https://issues.apache.org/jira/browse/GEODE-4493 > Project: Geode > Issue Type: Sub-task > Components: core, regions, tests >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > These tests in org.apache.geode.internal.cache.control invoke singleton > getters. > GemFireCacheImpl.setInstanceForTests(GemFireCacheImpl): > * RebalanceOperationDUnitTest > InternalDistributedSystem.getAnyInstance(): > * TestMemoryThresholdListener -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4464) Remove singleton calls from all tests in org.apache.geode.cache30
[ https://issues.apache.org/jira/browse/GEODE-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373374#comment-16373374 ] ASF subversion and git services commented on GEODE-4464: Commit 0b15a3bee602c37c617429c919ed19384dd371ca in geode's branch refs/heads/develop from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0b15a3b ] GEODE-4464: remove singleton calls from all tests in org.apache.geode.cache30 (#1484) * removed unneeded fine logging on deprecated method so that getAnyInstance would not be called * changed getAnyInstance calls to getCache * InternalDistributedSystem.getConnectedInstance no longer called * InternalDistributedSystem.getAnyInstance call removed from CachedAllEventsDUnitTest * InternalDistributedSystem.getAnyInstance call removed from CallbackArgDUnitTest * removed InternalDistributedSystem.getAnyInstance call from ClientMembershipDUnitTest * removed getAnyInstance calls from ClientServerTestCase by removing the methods getDistributedMember and getSystemProperties * removed InternalDistributedSystem.getAnyInstance from ProxyDUnitTest * removed InternalDistributedSystem.getAnyInstance call from RegionMembershipListenerDUnitTest * removed unused InternalDistributedSystem.getAnyInstance call from RegionReliabilityTestCase * InternalDistributedSystem.getAnyInstance call removed from TXOrderDUnitTest > Remove singleton calls from all tests in org.apache.geode.cache30 > - > > Key: GEODE-4464 > URL: https://issues.apache.org/jira/browse/GEODE-4464 > Project: Geode > Issue Type: Sub-task > Components: regions, tests >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > These tests in org.apache.geode.cache30 invoke singleton getters. > CacheFactory.getAnyInstance(): > * CacheSerializableRunnable > * ClientServerCCEDUnitTest > * MultiVMRegionTestCase > * ReconnectDUnitTest > CacheFactory.getExisting(DistributedSystem): > * MultiVMRegionTestCase.testDistributedPut > * MultiVMRegionTestCase.testTXAlgebra > * MultiVMRegionTestCase.testTXSimpleOps > * MultiVMRegionTestCase.testTXUpdateLoadNoConflict > * MultiVMRegionTestCase.testTXRmtMirror > * MultiVMRegionTestCase.testTXMultiRegion > InternalDistributedSystem.getAnyInstance(): > * CachedAllEventsDUnitTest > * CallbackArgDUnitTest > * ClientMembershipDUnitTest > * ClientServerTestCase > * ProxyDUnitTest > * ReconnectDUnitTest > * RegionMembershipListenerDUnitTest > * RegionReliabilityTestCase > * RemotePRValuesAreNotDeserializedRegressionTest > * TXOrderDUnitTest > * ValuesAreLazilyDeserializedRegressionTest > InternalDistributedSystem.getConnectedInstance(): > * DistributedNoAckRegionCCEDUnitTest > * MultiVMRegionTestCase > * ReconnectDUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4713) remove getInstance calls from MultiVMRegionTestCase
[ https://issues.apache.org/jira/browse/GEODE-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373369#comment-16373369 ] ASF subversion and git services commented on GEODE-4713: Commit 059acf2320efe129693e0c9ac5fbafac53fdc605 in geode's branch refs/heads/develop from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=059acf2 ] GEODE-4713: remove getInstance calls from from MultiVMRegionTestCase (#1481) * changed getConnectedInstance().getDM() to getCache().getDistributionManager() * assertCacheCallbackEvents is no longer static so it can call getCache() instead of the static singleton. > remove getInstance calls from MultiVMRegionTestCase > --- > > Key: GEODE-4713 > URL: https://issues.apache.org/jira/browse/GEODE-4713 > Project: Geode > Issue Type: Sub-task > Components: regions, tests >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > MultiVMRegionTestCase calls CacheFactory.getAnyInstance() and > InternalDistributedSystem.getConnectedInstance(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4725) LuceneEventListener should set pdxReadSerialized back to original value
Jason Huynh created GEODE-4725: -- Summary: LuceneEventListener should set pdxReadSerialized back to original value Key: GEODE-4725 URL: https://issues.apache.org/jira/browse/GEODE-4725 Project: Geode Issue Type: Bug Components: lucene Reporter: Jason Huynh In LuceneEventListener.process, we set the value of pdx read serialized to true: DefaultQuery.setPdxReadSerialized(true); In the finally block, we end up setting it to false. This is incorrect, we should store the original value before setting to true and set the value back to the original value in the finally block. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4656) gfsh command describe region should list custom expiry setting
[
https://issues.apache.org/jira/browse/GEODE-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373311#comment-16373311
]
ASF subversion and git services commented on GEODE-4656:
Commit dc2b33d726fe4903abeb73d3de6381498896713f in geode's branch
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dc2b33d ]
GEODE-4656: Decribe region shows entry-idle-time-custom-expiry and
entry-time-to-live-custom-expiry (#1455)
> gfsh command describe region should list custom expiry setting
> --
>
> Key: GEODE-4656
> URL: https://issues.apache.org/jira/browse/GEODE-4656
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The gfsh command
> {code:java}
> describe region --name=region1{code}
> should list the MyCustomExpiry class as the value for the options given on
> the alter/create region command:
> --entry-idle-time-custom-expiry
> --entry-time-to-live-custom-expiry
> {code:java}
> Type | Name | Value
> -- | --- | ---
> Region | data-policy | REPLICATE
> | entry-idle-time-custom-expiry | MyCustomExpiry
> | size | 0
> | statistics-enabled | true
> | scope | distributed-ack{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3928) After calling Internal API to create lucene index after region is created, data in the region should be included in the lucene index
[ https://issues.apache.org/jira/browse/GEODE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-3928. -- > After calling Internal API to create lucene index after region is created, > data in the region should be included in the lucene index > > > Key: GEODE-3928 > URL: https://issues.apache.org/jira/browse/GEODE-3928 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Jason Huynh >Priority: Major > > After GEODE-3030 is complete, we will have an internal API to create an index > on an existing region. > After someone calls that API on all members that have the user's region we > should index all of the data in the existing region. > Acceptance: > After calling the API to add the index to an existing region, at some point > in the future calling a query on the region should include all of the entries > that were in the existing region. > Implementation Details: > We think this should be implemented by modifying computeRepository so that it > goes through the following steps: > # If there is no COMPLETE file in the fileAndChunkRegion for this bucket > ## Iterate over the contents of the user region and add them to the lucene > index > ## Write a COMPLETE file to the fileAndChunkRegion > ## Return the IndexRepository > # If there is a COMPLETE file, just return the IndexRepository. > Note: When this task is complete, it's possible queries may block until the > indexing is complete. We will address that issue in GEODE-3926 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3928) After calling Internal API to create lucene index after region is created, data in the region should be included in the lucene index
[ https://issues.apache.org/jira/browse/GEODE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-3928. Resolution: Fixed > After calling Internal API to create lucene index after region is created, > data in the region should be included in the lucene index > > > Key: GEODE-3928 > URL: https://issues.apache.org/jira/browse/GEODE-3928 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Jason Huynh >Priority: Major > > After GEODE-3030 is complete, we will have an internal API to create an index > on an existing region. > After someone calls that API on all members that have the user's region we > should index all of the data in the existing region. > Acceptance: > After calling the API to add the index to an existing region, at some point > in the future calling a query on the region should include all of the entries > that were in the existing region. > Implementation Details: > We think this should be implemented by modifying computeRepository so that it > goes through the following steps: > # If there is no COMPLETE file in the fileAndChunkRegion for this bucket > ## Iterate over the contents of the user region and add them to the lucene > index > ## Write a COMPLETE file to the fileAndChunkRegion > ## Return the IndexRepository > # If there is a COMPLETE file, just return the IndexRepository. > Note: When this task is complete, it's possible queries may block until the > indexing is complete. We will address that issue in GEODE-3926 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4717) IndexRepositoryFactory refactor the computeRepository method
[
https://issues.apache.org/jira/browse/GEODE-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun resolved GEODE-4717.
Resolution: Fixed
> IndexRepositoryFactory refactor the computeRepository method
>
>
> Key: GEODE-4717
> URL: https://issues.apache.org/jira/browse/GEODE-4717
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: nabarun
>Priority: Major
>
> In computeRepository method call refactor the below code into an extracted
> new method
> Set affectedRepos = new HashSet();
> {code:java}
> Iterator keysIterator = dataBucket.keySet().iterator();
> while (keysIterator.hasNext()) {
> Object key = keysIterator.next();
> Object value = getValue(userRegion.getEntry(key));
> if (value != null) {
> repo.update(key, value);
> } else {
> repo.delete(key);
> }
> affectedRepos.add(repo);
> }
> for (IndexRepository affectedRepo : affectedRepos) {
> affectedRepo.commit();
> }
> // fileRegion ops (get/put) need bucketId as a callbackArg for
> PartitionResolver
> fileRegion.put(APACHE_GEODE_INDEX_COMPLETE, APACHE_GEODE_INDEX_COMPLETE,
> bucketId);
> success = true;{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4717) IndexRepositoryFactory refactor the computeRepository method
[
https://issues.apache.org/jira/browse/GEODE-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun closed GEODE-4717.
--
> IndexRepositoryFactory refactor the computeRepository method
>
>
> Key: GEODE-4717
> URL: https://issues.apache.org/jira/browse/GEODE-4717
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: nabarun
>Priority: Major
>
> In computeRepository method call refactor the below code into an extracted
> new method
> Set affectedRepos = new HashSet();
> {code:java}
> Iterator keysIterator = dataBucket.keySet().iterator();
> while (keysIterator.hasNext()) {
> Object key = keysIterator.next();
> Object value = getValue(userRegion.getEntry(key));
> if (value != null) {
> repo.update(key, value);
> } else {
> repo.delete(key);
> }
> affectedRepos.add(repo);
> }
> for (IndexRepository affectedRepo : affectedRepos) {
> affectedRepo.commit();
> }
> // fileRegion ops (get/put) need bucketId as a callbackArg for
> PartitionResolver
> fileRegion.put(APACHE_GEODE_INDEX_COMPLETE, APACHE_GEODE_INDEX_COMPLETE,
> bucketId);
> success = true;{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4718) DefaultQuery.setPdxReadSerialized must rest in computeRepository
[ https://issues.apache.org/jira/browse/GEODE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-4718. -- > DefaultQuery.setPdxReadSerialized must rest in computeRepository > > > Key: GEODE-4718 > URL: https://issues.apache.org/jira/browse/GEODE-4718 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: nabarun >Priority: Major > > In method computeRepository we set setPdxReadSerialized to true but after the > method is done executing we reset it back to false. > This behavior must be to reset to the state it was in before we set it to > true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4719) Add a comment to explain getRepository's function in createLuceneIndexOnDataRegion
[ https://issues.apache.org/jira/browse/GEODE-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-4719. Resolution: Fixed > Add a comment to explain getRepository's function in > createLuceneIndexOnDataRegion > -- > > Key: GEODE-4719 > URL: https://issues.apache.org/jira/browse/GEODE-4719 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: nabarun >Priority: Major > > Add comments above the getRepository call in createLuceneIndexOnDataRegion > method so that it explains that getRepository will call computeRepository > which will in turn index the user region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4719) Add a comment to explain getRepository's function in createLuceneIndexOnDataRegion
[ https://issues.apache.org/jira/browse/GEODE-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-4719. -- > Add a comment to explain getRepository's function in > createLuceneIndexOnDataRegion > -- > > Key: GEODE-4719 > URL: https://issues.apache.org/jira/browse/GEODE-4719 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: nabarun >Priority: Major > > Add comments above the getRepository call in createLuceneIndexOnDataRegion > method so that it explains that getRepository will call computeRepository > which will in turn index the user region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4718) DefaultQuery.setPdxReadSerialized must rest in computeRepository
[ https://issues.apache.org/jira/browse/GEODE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-4718. Resolution: Fixed > DefaultQuery.setPdxReadSerialized must rest in computeRepository > > > Key: GEODE-4718 > URL: https://issues.apache.org/jira/browse/GEODE-4718 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: nabarun >Priority: Major > > In method computeRepository we set setPdxReadSerialized to true but after the > method is done executing we reset it back to false. > This behavior must be to reset to the state it was in before we set it to > true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3584) Refactor ServerLauncher and LocatorLauncher to eliminate code duplication
[ https://issues.apache.org/jira/browse/GEODE-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373286#comment-16373286 ] Kenneth Howe commented on GEODE-3584: - I done some work resolving compilation coflicts between Cyrille's patch and the Geode develop branch as of Jan17, 2018. Pushed to Geode repo on branch feature/GEODE-3584 > Refactor ServerLauncher and LocatorLauncher to eliminate code duplication > - > > Key: GEODE-3584 > URL: https://issues.apache.org/jira/browse/GEODE-3584 > Project: Geode > Issue Type: Improvement > Components: gfsh >Affects Versions: 1.2.0 >Reporter: Kenneth Howe >Priority: Major > Attachments: GEODE-3584-1, GEODE-3584-WIP, GEODE-3584-WIP-2, > GEODE-3584-WIP-3, GEODE-3584-WIP-4 > > > There is some duplication of code in the Launcher classes that can be > eliminated. Both classes have methods such as getBindAddress (called > getServerBindAddress in ServerLauncher) that could be hoisted into > AbstractLauncher class that they both extend. The same goes for the inner > State classes of the Launchers; they have methods that could be moved to > AbstractLauncher.ServiceState. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4724) Undefined class needs to be in a public package
nabarun created GEODE-4724: -- Summary: Undefined class needs to be in a public package Key: GEODE-4724 URL: https://issues.apache.org/jira/browse/GEODE-4724 Project: Geode Issue Type: Bug Components: querying Reporter: nabarun *+Problem+*: * Currently undefined class is placed in the org.apache.geode.cache.query.internal package * But undefined is exposed to the user when queries try to do something like projecting a field that does not exist or extract a value from NULL +*Expectation*+ * Anything that is exposed to the user should not be in the internal package. * This needs to be moved to public package +*Issues*+ * Doing this may result in breaking backwards compatibility * Older clients will be expecting undefined from an internal package but will receive a undefined present in a package that it is not able to identify. This task will need a discussion to find a viable solution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4721) Being invoked within JTA Region.values() does return empty collection
[
https://issues.apache.org/jira/browse/GEODE-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373275#comment-16373275
]
Anthony Baker commented on GEODE-4721:
--
What version of Geode is this? If you have a reproducible test case that would
be great!
> Being invoked within JTA Region.values() does return empty collection
> -
>
> Key: GEODE-4721
> URL: https://issues.apache.org/jira/browse/GEODE-4721
> Project: Geode
> Issue Type: Bug
> Components: regions, transactions
>Reporter: Vadim Lotarev
>Priority: Major
>
> {{Region.values()}} returns empty collection being invoked within JTA. Other
> operations returns data, for example this workaround works (though less
> efficient): {{region.getAll(region.keySet()).values()}}, also
> {{Region.size()}} returns correct value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4414) Support nulls in new client protocol
[ https://issues.apache.org/jira/browse/GEODE-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Rowe resolved GEODE-4414. --- Resolution: Fixed Fix Version/s: 1.5.0 > Support nulls in new client protocol > > > Key: GEODE-4414 > URL: https://issues.apache.org/jira/browse/GEODE-4414 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The new client protocol currently sort of supports nulls, by sending an > EncodedValue that is not set, but there's no mention of this (as far as I can > tell) and it's not explicit. > An example where we might need nulls is when a function returns a list of > null sentinel values that are meaningful. To support this use case, we should > add a null case to EncodedValue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3928) After calling Internal API to create lucene index after region is created, data in the region should be included in the lucene index
[ https://issues.apache.org/jira/browse/GEODE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373263#comment-16373263 ] ASF subversion and git services commented on GEODE-3928: Commit 25978ef5b2117d9aec47703e3abc7677333795fb in geode's branch refs/heads/develop from nabarunnag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=25978ef ] GEODE-3928: Unused imports were removed. > After calling Internal API to create lucene index after region is created, > data in the region should be included in the lucene index > > > Key: GEODE-3928 > URL: https://issues.apache.org/jira/browse/GEODE-3928 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Jason Huynh >Priority: Major > > After GEODE-3030 is complete, we will have an internal API to create an index > on an existing region. > After someone calls that API on all members that have the user's region we > should index all of the data in the existing region. > Acceptance: > After calling the API to add the index to an existing region, at some point > in the future calling a query on the region should include all of the entries > that were in the existing region. > Implementation Details: > We think this should be implemented by modifying computeRepository so that it > goes through the following steps: > # If there is no COMPLETE file in the fileAndChunkRegion for this bucket > ## Iterate over the contents of the user region and add them to the lucene > index > ## Write a COMPLETE file to the fileAndChunkRegion > ## Return the IndexRepository > # If there is a COMPLETE file, just return the IndexRepository. > Note: When this task is complete, it's possible queries may block until the > indexing is complete. We will address that issue in GEODE-3926 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4414) Support nulls in new client protocol
[ https://issues.apache.org/jira/browse/GEODE-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373264#comment-16373264 ] ASF subversion and git services commented on GEODE-4414: Commit 37ff71531d900c160f4d2e05042f509f96da60ef in geode's branch refs/heads/develop from [~WireBaron] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=37ff715 ] GEODE-4414: Support explicit nulls in geode's protobuf protocol (#1437) > Support nulls in new client protocol > > > Key: GEODE-4414 > URL: https://issues.apache.org/jira/browse/GEODE-4414 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > The new client protocol currently sort of supports nulls, by sending an > EncodedValue that is not set, but there's no mention of this (as far as I can > tell) and it's not explicit. > An example where we might need nulls is when a function returns a list of > null sentinel values that are meaningful. To support this use case, we should > add a null case to EncodedValue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3928) After calling Internal API to create lucene index after region is created, data in the region should be included in the lucene index
[ https://issues.apache.org/jira/browse/GEODE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373259#comment-16373259 ] ASF subversion and git services commented on GEODE-3928: Commit fa11e2a84473f603fafe9d2234ba3e196e8c88f8 in geode's branch refs/heads/develop from [~lhughesgodfrey] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fa11e2a ] GEODE-3928: createIndex on existing region creates lucene indexes for existing data > After calling Internal API to create lucene index after region is created, > data in the region should be included in the lucene index > > > Key: GEODE-3928 > URL: https://issues.apache.org/jira/browse/GEODE-3928 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Jason Huynh >Priority: Major > > After GEODE-3030 is complete, we will have an internal API to create an index > on an existing region. > After someone calls that API on all members that have the user's region we > should index all of the data in the existing region. > Acceptance: > After calling the API to add the index to an existing region, at some point > in the future calling a query on the region should include all of the entries > that were in the existing region. > Implementation Details: > We think this should be implemented by modifying computeRepository so that it > goes through the following steps: > # If there is no COMPLETE file in the fileAndChunkRegion for this bucket > ## Iterate over the contents of the user region and add them to the lucene > index > ## Write a COMPLETE file to the fileAndChunkRegion > ## Return the IndexRepository > # If there is a COMPLETE file, just return the IndexRepository. > Note: When this task is complete, it's possible queries may block until the > indexing is complete. We will address that issue in GEODE-3926 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4718) DefaultQuery.setPdxReadSerialized must rest in computeRepository
[ https://issues.apache.org/jira/browse/GEODE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373261#comment-16373261 ] ASF subversion and git services commented on GEODE-4718: Commit 073180cf8a907d944dc20455669ec2fd0f3deb8e in geode's branch refs/heads/develop from nabarunnag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=073180c ] GEODE-4718: PdxReadSerialized is reset * PdxReadSerialized flag is reset back to its initial state before it was changed to true. > DefaultQuery.setPdxReadSerialized must rest in computeRepository > > > Key: GEODE-4718 > URL: https://issues.apache.org/jira/browse/GEODE-4718 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: nabarun >Priority: Major > > In method computeRepository we set setPdxReadSerialized to true but after the > method is done executing we reset it back to false. > This behavior must be to reset to the state it was in before we set it to > true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4717) IndexRepositoryFactory refactor the computeRepository method
[
https://issues.apache.org/jira/browse/GEODE-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373260#comment-16373260
]
ASF subversion and git services commented on GEODE-4717:
Commit 2a72fb22a698bbe1d9ffca026fea096c1e0b12b5 in geode's branch
refs/heads/develop from nabarunnag
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2a72fb2 ]
GEODE-4717: Refactor computeRepository
* Extracted the code to reindex the region entries to an different
method
> IndexRepositoryFactory refactor the computeRepository method
>
>
> Key: GEODE-4717
> URL: https://issues.apache.org/jira/browse/GEODE-4717
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: nabarun
>Priority: Major
>
> In computeRepository method call refactor the below code into an extracted
> new method
> Set affectedRepos = new HashSet();
> {code:java}
> Iterator keysIterator = dataBucket.keySet().iterator();
> while (keysIterator.hasNext()) {
> Object key = keysIterator.next();
> Object value = getValue(userRegion.getEntry(key));
> if (value != null) {
> repo.update(key, value);
> } else {
> repo.delete(key);
> }
> affectedRepos.add(repo);
> }
> for (IndexRepository affectedRepo : affectedRepos) {
> affectedRepo.commit();
> }
> // fileRegion ops (get/put) need bucketId as a callbackArg for
> PartitionResolver
> fileRegion.put(APACHE_GEODE_INDEX_COMPLETE, APACHE_GEODE_INDEX_COMPLETE,
> bucketId);
> success = true;{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-308) Separate hydra from dunit and junit tests in gemfire-core
[ https://issues.apache.org/jira/browse/GEODE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-308. -- Resolution: Fixed > Separate hydra from dunit and junit tests in gemfire-core > - > > Key: GEODE-308 > URL: https://issues.apache.org/jira/browse/GEODE-308 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund >Priority: Major > Labels: hydra > > Usage of Hydra needs to be removed from dunit and junit tests in gemfire-core > and any other project. > The following hydra classes in gemfire-core should be removed (and replaced > if needed by dunit/junit tests): > src/test/java/hydra/GsRandom.java > src/test/java/hydra/HydraRuntimeException.java > src/test/java/hydra/Log.java > src/test/java/hydra/LogVersionHelper.java > src/test/java/hydra/MethExecutor.java > src/test/java/hydra/MethExecutorResult.java > src/test/java/hydra/SchedulingOrder.java > src/test/java/hydra/log/AnyLogWriter.java > src/test/java/hydra/log/CircularOutputStream.java > The following are also not com.gemstone packages and should be removed if > they're specific to Hydra (or Hydra tests) or repackaged if they're actually > used in dunit/junit tests: > src/test/java/batterytest/greplogs/ExpectedStrings.java > src/test/java/batterytest/greplogs/LogConsumer.java > src/test/java/cacheRunner/Portfolio.java > src/test/java/cacheRunner/Position.java > src/test/java/parReg/query/unittest/NewPortfolio.java > src/test/java/parReg/query/unittest/Position.java > src/test/java/perffmwk/Formatter.java > src/test/java/templates/security/DummyAuthenticator.java > src/test/java/templates/security/DummyAuthorization.java > src/test/java/templates/security/FunctionSecurityPrmsHolder.java > src/test/java/templates/security/LdapUserAuthenticator.java > src/test/java/templates/security/PKCSAuthenticator.java > src/test/java/templates/security/PKCSAuthInt.java > src/test/java/templates/security/PKCSPrincipal.java > src/test/java/templates/security/UsernamePrincipal.java > src/test/java/templates.security/UserPasswordAuthInit.java > src/test/java/templates.security/XmlAuthorization.java > src/test/java/templates.security/XmlErrorHandler.java > src/test/java/util/TestException.java > The following are Hydra-related resources in src/test/resources that also > need to be removed: > src/test/resources/jta/cachejta.xml > src/test/resources/ssl/trusted.keystore > src/test/resources/templates/security/authz5_5.dtd > src/test/resources/templates/security/authz6_0.dtd -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2321) Pulse application works incorrectly in some locales
[
https://issues.apache.org/jira/browse/GEODE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373215#comment-16373215
]
Barbara Pruijn commented on GEODE-2321:
---
Docs team, can you please document that the numbers need to be in US format.
> Pulse application works incorrectly in some locales
> ---
>
> Key: GEODE-2321
> URL: https://issues.apache.org/jira/browse/GEODE-2321
> Project: Geode
> Issue Type: Bug
> Components: docs, pulse
>Reporter: Vadim Lotarev
>Priority: Major
>
> I noticed that Pulse application is not able to show cluster view in my
> locale. Doing some investigations I revealed the warning messages like:
> {{serviceException \[for service ClusterDetails\] = For input string: "2,71"}}
> {{serviceException \[for service ClusterMembersRGraph\] = For input string:
> "58,27"}}
> I guess the reason is in parsing numeric values - it looks like coma "," is
> hard coded in Pulse as a decimal separator; so if your region settings have
> separate value (like mine - ".") you'll get such a problem. The workaround
> could be to force usage of US region starting locator:
> {{--J=-Duser.region=US}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-2321) Pulse application works incorrectly in some locales
[
https://issues.apache.org/jira/browse/GEODE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-2321:
--
Component/s: docs
> Pulse application works incorrectly in some locales
> ---
>
> Key: GEODE-2321
> URL: https://issues.apache.org/jira/browse/GEODE-2321
> Project: Geode
> Issue Type: Bug
> Components: docs, pulse
>Reporter: Vadim Lotarev
>Priority: Major
>
> I noticed that Pulse application is not able to show cluster view in my
> locale. Doing some investigations I revealed the warning messages like:
> {{serviceException \[for service ClusterDetails\] = For input string: "2,71"}}
> {{serviceException \[for service ClusterMembersRGraph\] = For input string:
> "58,27"}}
> I guess the reason is in parsing numeric values - it looks like coma "," is
> hard coded in Pulse as a decimal separator; so if your region settings have
> separate value (like mine - ".") you'll get such a problem. The workaround
> could be to force usage of US region starting locator:
> {{--J=-Duser.region=US}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4517) Remove singleton calls from product code in org.apache.geode.management.internal.cli
[ https://issues.apache.org/jira/browse/GEODE-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4517: -- Labels: pull-request-available (was: ) > Remove singleton calls from product code in > org.apache.geode.management.internal.cli > > > Key: GEODE-4517 > URL: https://issues.apache.org/jira/browse/GEODE-4517 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Kirk Lund >Priority: Major > Labels: pull-request-available > > These product classes in org.apache.geode.management.internal.cli invoke > singleton getters. > CacheFactory.getAnyInstance(): > * CliUtil -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4722) Code Improvement: Refactor CliUtil
[ https://issues.apache.org/jira/browse/GEODE-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-4722: Labels: pull-request-available (was: ) > Code Improvement: Refactor CliUtil > -- > > Key: GEODE-4722 > URL: https://issues.apache.org/jira/browse/GEODE-4722 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > > This class could use some cleaning. Many methods are unused, some trivially > replaced by Apache Commons libraries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4722) Code Improvement: Refactor CliUtil
[ https://issues.apache.org/jira/browse/GEODE-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-4722: --- Assignee: Patrick Rhomberg > Code Improvement: Refactor CliUtil > -- > > Key: GEODE-4722 > URL: https://issues.apache.org/jira/browse/GEODE-4722 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > > This class could use some cleaning. Many methods are unused, some trivially > replaced by Apache Commons libraries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4721) Being invoked within JTA Region.values() does return empty collection
Vadim Lotarev created GEODE-4721:
Summary: Being invoked within JTA Region.values() does return
empty collection
Key: GEODE-4721
URL: https://issues.apache.org/jira/browse/GEODE-4721
Project: Geode
Issue Type: Bug
Reporter: Vadim Lotarev
{{Region.values()}} returns empty collection being invoked within JTA. Other
operations returns data, for example this workaround works (though less
efficient): {{region.getAll(region.keySet()).values()}}, also {{Region.size()}}
returns correct value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4720) data is not re-loaded after cluster rebooted while geode acts as a redis server
pengxu created GEODE-4720: - Summary: data is not re-loaded after cluster rebooted while geode acts as a redis server Key: GEODE-4720 URL: https://issues.apache.org/jira/browse/GEODE-4720 Project: Geode Issue Type: Bug Components: redis Reporter: pengxu In Apache 1.4.0, the redis keys cann't be reloaded after the cluster is rebooted. How to reproduce it? 1. start server, ```bash start server --name=server1 --redis-bind-address=localhost --redis-port=11211 --J=-Dgemfireredis.regiontype=PARTITION_PERSISTENT ``` 2. using redis-cli connect to the server sadd hello 1 smembers hello 3. stop the redis server ```bash stop server --name=server1 ``` 4. restart the server after the server is restarted, no data is reloaded automatically. 5. connect to the server by using redis-cli sadd hello 2 the strange thing is that the old entry recovered while adding one new entry -- This message was sent by Atlassian JIRA (v7.6.3#76005)
