[jira] [Updated] (GEODE-3027) A developer can co-locate two keys on a put
[ https://issues.apache.org/jira/browse/GEODE-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-3027: --- Component/s: docs > A developer can co-locate two keys on a put > --- > > Key: GEODE-3027 > URL: https://issues.apache.org/jira/browse/GEODE-3027 > Project: Geode > Issue Type: Improvement > Components: docs, regions >Reporter: Fred Krone > Fix For: 1.3.0 > > > Provide a way to put co-locate two keys represented in a delimited string > "AccountId:OrderId" > Here ":" is the delimiter. The String before the delimiter is the routing > key. The String after the delimiter is the simple key. > Acceptance > A user configuring a Region with this PartitionResolver implementation gets > correctly delimited String keys colocated > Keys can only be Strings or error > Delimiter is present ":" or error > Update JavaDocs -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes
[
https://issues.apache.org/jira/browse/GEODE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-2947.
Resolution: Fixed
Documentation update cherry picked to the release/1.2.0 branch with
https://github.com/apache/geode/commit/96f77fc8c9b4e76e7f88d7561bd4f31c98198ac2
> Improve error message (seen in gfsh) when attempting to destroy a region
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> If a user attempta to destroy region before destroying the lucene index (via
> gfsh), the error message returned is not clear. It should state that the
> lucene index should be destroyed prior to destroying the region.
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent
> region [/testRegion] in colocation chain cannot be destroyed, unless all its
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2931) Document existing REST API functionality for primitives as PUT values
[ https://issues.apache.org/jira/browse/GEODE-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2931: -- Assignee: (was: Karen Smoler Miller) > Document existing REST API functionality for primitives as PUT values > - > > Key: GEODE-2931 > URL: https://issues.apache.org/jira/browse/GEODE-2931 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Joey McAllister > > Plain text is valid JSON, but is not supported by the REST API. Same issue > for all primitive types: bool, number, arrays. Only objects are accepted. > This is a pain point with a story (GEODE-2794) to address it, but the current > functionality/limitations should be noted in the documentation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes
[
https://issues.apache.org/jira/browse/GEODE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16033858#comment-16033858
]
Karen Smoler Miller commented on GEODE-2947:
Ticket reopened so that we can do the associated correction in the
documentation.
> Improve error message (seen in gfsh) when attempting to destroy a region
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> If a user attempta to destroy region before destroying the lucene index (via
> gfsh), the error message returned is not clear. It should state that the
> lucene index should be destroyed prior to destroying the region.
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent
> region [/testRegion] in colocation chain cannot be destroyed, unless all its
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes
[
https://issues.apache.org/jira/browse/GEODE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-2947:
---
Component/s: docs
> Improve error message (seen in gfsh) when attempting to destroy a region
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> If a user attempta to destroy region before destroying the lucene index (via
> gfsh), the error message returned is not clear. It should state that the
> lucene index should be destroyed prior to destroying the region.
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent
> region [/testRegion] in colocation chain cannot be destroyed, unless all its
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes
[
https://issues.apache.org/jira/browse/GEODE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reopened GEODE-2947:
Assignee: Karen Smoler Miller
> Improve error message (seen in gfsh) when attempting to destroy a region
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> If a user attempta to destroy region before destroying the lucene index (via
> gfsh), the error message returned is not clear. It should state that the
> lucene index should be destroyed prior to destroying the region.
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent
> region [/testRegion] in colocation chain cannot be destroyed, unless all its
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2931) Document existing REST API functionality for primitives as PUT values
[ https://issues.apache.org/jira/browse/GEODE-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2931: -- Assignee: Karen Smoler Miller > Document existing REST API functionality for primitives as PUT values > - > > Key: GEODE-2931 > URL: https://issues.apache.org/jira/browse/GEODE-2931 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Joey McAllister >Assignee: Karen Smoler Miller > > Plain text is valid JSON, but is not supported by the REST API. Same issue > for all primitive types: bool, number, arrays. Only objects are accepted. > This is a pain point with a story (GEODE-2794) to address it, but the current > functionality/limitations should be noted in the documentation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-3014) Document gfsh create lucene index and region failure sequence
[ https://issues.apache.org/jira/browse/GEODE-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-3014: -- Assignee: Karen Smoler Miller > Document gfsh create lucene index and region failure sequence > - > > Key: GEODE-3014 > URL: https://issues.apache.org/jira/browse/GEODE-3014 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Barry Oglesby >Assignee: Karen Smoler Miller > > When creating a lucene index and region using gfsh, there is a specific > command sequence that causes the region to not be created successfully. > The sequence that fails is: > - start server(s) > - create lucene index > - start additional server(s) > - create region > What fails about this sequence is the lucene index is not saved in cluster > configuration until after the region is created. Before the region is > created, its only saved locally in existing servers. Since new servers don't > have the index when the region is created, the index definitions aren't > consistent across servers. This causes the region to be created only in some > servers (either all the original ones with the index or all the new ones > without the index). > An alternate sequence that succeeds is: > - start server(s) > - create lucene index > - create region > - start additional server(s) > Once the region has been created, then both the lucene index and region are > saved in cluster configuration, so new servers will create both the region > and index. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-3011) gfsh example to do a Lucene query is incorrect
[ https://issues.apache.org/jira/browse/GEODE-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-3011. Resolution: Fixed Fix Version/s: 1.2.0 > gfsh example to do a Lucene query is incorrect > -- > > Key: GEODE-3011 > URL: https://issues.apache.org/jira/browse/GEODE-3011 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Diane Hardman >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > In the Lucene integration section of the docs is the following incorrect gfsh > command example: > gfsh> lucene search --regionName=/orders -queryStrings="John*" > --defaultField=field1 > Instead it should be: > gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" > --defaultField=customer --limit=100 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2994) Doc task: interactions of backups with persistence
[ https://issues.apache.org/jira/browse/GEODE-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2994. Resolution: Fixed Fix Version/s: 1.2.0 > Doc task: interactions of backups with persistence > -- > > Key: GEODE-2994 > URL: https://issues.apache.org/jira/browse/GEODE-2994 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > Document that an inconsistent state can occur by using a backup to restore > system state, if the backup is made at the wrong time. > There are 2 examples where persistence and taking a backup might cause an > inconsistency with region data, if that backup is used to restore a system. > # *A Lucene index.* The Lucene index is persistent. If a backup is unlucky > enough to be taken between a persisted write to a region (disk op) and a > persisted write to the Lucene index (disk op), then the backup represents > inconsistent data in the region and Lucene index. > # *An AEQ.* The AEQ is persistent. If a backup is unlucky enough to be taken > between a persisted write to a region (disk op) and a persisted write to the > AEQ (disk op), then the backup represents inconsistent data in the region and > the AEQ. > The solution is to make sure that backups are taken when the system is > quiescent WRT region operations. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-3011) gfsh example to do a Lucene query is incorrect
[ https://issues.apache.org/jira/browse/GEODE-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-3011: -- Assignee: Karen Smoler Miller > gfsh example to do a Lucene query is incorrect > -- > > Key: GEODE-3011 > URL: https://issues.apache.org/jira/browse/GEODE-3011 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Diane Hardman >Assignee: Karen Smoler Miller > > In the Lucene integration section of the docs is the following incorrect gfsh > command example: > gfsh> lucene search --regionName=/orders -queryStrings="John*" > --defaultField=field1 > Instead it should be: > gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" > --defaultField=customer --limit=100 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-3002) Improve doc of (Lucene) __REGION_VALUE_FIELD
[
https://issues.apache.org/jira/browse/GEODE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-3002.
Resolution: Fixed
Fix Version/s: 1.2.0
> Improve doc of (Lucene) __REGION_VALUE_FIELD
>
>
> Key: GEODE-3002
> URL: https://issues.apache.org/jira/browse/GEODE-3002
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
> Fix For: 1.2.0
>
>
> The original description of {{__REGION_VALUE_FIELD}} is not quite right. In
> addition, there is an example gfsh command using this value that is wrong.
> It is in the {{gfsh create lucene index}} command reference page.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2957) null used as a default parameter when specifying analyzers
[ https://issues.apache.org/jira/browse/GEODE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2957. Resolution: Fixed > null used as a default parameter when specifying analyzers > -- > > Key: GEODE-2957 > URL: https://issues.apache.org/jira/browse/GEODE-2957 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Assignee: David Anuta > Fix For: 1.2.0 > > > null seems to be the way to specify using the default > StandardKeywordAnalyzer. This can be used when specifying a long list of > field/analyzers. > So the line may look like > --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer} > We should probably change that to default or some other keyword. null seems > a bit confusing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2952) gfsh doesn't support exact match lucene queries
[
https://issues.apache.org/jira/browse/GEODE-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-2952.
Resolution: Fixed
> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString.
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (GEODE-2951) A gfsh lucene query specifying --pageSize fails with a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-2951.
Resolution: Fixed
> A gfsh lucene query specifying --pageSize fails with a NullPointerException
> ---
>
> Key: GEODE-2951
> URL: https://issues.apache.org/jira/browse/GEODE-2951
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> A gfsh lucene query specifying {{--pageSize}} fails with a
> NullPointerException:
> {noformat}
> gfsh>search lucene --name=index --region=data --queryStrings=NYPD
> --defaultField=Agency --pageSize=10
> Could not process command due to GemFire error. An error occurred while
> searching lucene index across the Geode cluster: null
> {noformat}
> This exception is logged in the locator.log:
> {noformat}
> [info 2017/05/18 12:42:22.317 PDT locator
> tid=0x7f] null
> java.lang.NullPointerException
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.displayResults(LuceneIndexCommands.java:476)
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.searchIndex(LuceneIndexCommands.java:299)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> The same query without the {{--pageSize=10}} setting works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-3002) Improve doc of (Lucene) __REGION_VALUE_FIELD
[
https://issues.apache.org/jira/browse/GEODE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-3002:
---
Priority: Minor (was: Major)
> Improve doc of (Lucene) __REGION_VALUE_FIELD
>
>
> Key: GEODE-3002
> URL: https://issues.apache.org/jira/browse/GEODE-3002
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Priority: Minor
>
> The original description of {{__REGION_VALUE_FIELD}} is not quite right. In
> addition, there is an example gfsh command using this value that is wrong.
> It is in the {{gfsh create lucene index}} command reference page.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-3002) Improve doc of (Lucene) __REGION_VALUE_FIELD
[
https://issues.apache.org/jira/browse/GEODE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reassigned GEODE-3002:
--
Assignee: Karen Smoler Miller
> Improve doc of (Lucene) __REGION_VALUE_FIELD
>
>
> Key: GEODE-3002
> URL: https://issues.apache.org/jira/browse/GEODE-3002
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> The original description of {{__REGION_VALUE_FIELD}} is not quite right. In
> addition, there is an example gfsh command using this value that is wrong.
> It is in the {{gfsh create lucene index}} command reference page.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-3002) Improve doc of (Lucene) __REGION_VALUE_FIELD
Karen Smoler Miller created GEODE-3002:
--
Summary: Improve doc of (Lucene) __REGION_VALUE_FIELD
Key: GEODE-3002
URL: https://issues.apache.org/jira/browse/GEODE-3002
Project: Geode
Issue Type: Bug
Components: docs
Reporter: Karen Smoler Miller
The original description of {{__REGION_VALUE_FIELD}} is not quite right. In
addition, there is an example gfsh command using this value that is wrong. It
is in the {{gfsh create lucene index}} command reference page.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GEODE-2952) gfsh doesn't support exact match lucene queries
[
https://issues.apache.org/jira/browse/GEODE-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reopened GEODE-2952:
Reopening this ticket, as we should document the use of the double quote marks
in exact match query strings.
> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString.
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (GEODE-2957) null used as a default parameter when specifying analyzers
[ https://issues.apache.org/jira/browse/GEODE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reopened GEODE-2957: Changing "null" to "DEFAULT" requires that the documentation of this feature also needs to change. Reopening the ticket for this documentation task. > null used as a default parameter when specifying analyzers > -- > > Key: GEODE-2957 > URL: https://issues.apache.org/jira/browse/GEODE-2957 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Assignee: David Anuta > Fix For: 1.2.0 > > > null seems to be the way to specify using the default > StandardKeywordAnalyzer. This can be used when specifying a long list of > field/analyzers. > So the line may look like > --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer} > We should probably change that to default or some other keyword. null seems > a bit confusing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2985) Doc task: making/using backups when there are indexes
[ https://issues.apache.org/jira/browse/GEODE-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2985. Resolution: Invalid Ticket has incorrect info. Will open a new ticket with correct info. > Doc task: making/using backups when there are indexes > - > > Key: GEODE-2985 > URL: https://issues.apache.org/jira/browse/GEODE-2985 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > We should document that making a backup or using a backup to restore a system > when that system also has/had indexes can be problematic. > When taking a backup on a system that has an index, if there are region > operations in progress, the asynchronous nature of propagating the results of > the operations to an index means that the index content may be inconsistent > with the region content. If the backup were later used to restore a system, > the inconsistency will be introduced back into the system. > The fix for this is to make sure that the system is quiescent with respect to > region operations when a backup is taken. > In addition, the restoration procedure should rebuild indexes. > This issue exists for both regular (OQL) indexes and for Lucene indexes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2913) Update Lucene documentation
[
https://issues.apache.org/jira/browse/GEODE-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-2913.
Resolution: Fixed
> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> * Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create
> the Lucene index before creating the region, even though this member does not
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT tid=0x1]
> java.lang.IllegalStateException: Must create Lucene index full_index on
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create
> Lucene index full_index on region /data because it is defined in another
> member.
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The
> Lucene search will always be done on the server. Besides, _you can't create
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't,
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results.
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> * Destroying a region will *NOT* automatically destroy any Lucene index
> associated with that region. Instead, attempting to destroy a region with a
> Lucene index will throw a colocated region exception.
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation
> chain cannot be destroyed, unless all its children
> [[/cusip_index#_data.files]] are destroyed
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh:
> 1. export region data
> 2. destroy Lucene index, destroy region
> 3. create new index, create new region without user-defined business
> logic callbacks
> 4. import data with option to turn on callbacks (to invoke Lucene Async
> Event Listener to index the data)
> 5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not
> supported.
> * Document security implementation and defaults. If a user has security
> configured for their cluster, creating a Lucene index requires DATA:MANAGE
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE
> privilege because a function is called (different from OQL which requires
> only DATA:READ privilege). Here are all the required privileges for the gfsh
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction
> configured with local destroy. If using Lucene indexing, eviction can only be
> configured with overflow to disk. In this case, only the region data is
> overflowed to disk, *NOT* the Lucene index. An UnsupportedOperationException
> is thrown:
> {quote}
> [error 2017/05/02 16:12:32.461 PDT tid=0x1]
>
[jira] [Assigned] (GEODE-2985) Doc task: making/using backups when there are indexes
[ https://issues.apache.org/jira/browse/GEODE-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2985: -- Assignee: Karen Smoler Miller > Doc task: making/using backups when there are indexes > - > > Key: GEODE-2985 > URL: https://issues.apache.org/jira/browse/GEODE-2985 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > We should document that making a backup or using a backup to restore a system > when that system also has/had indexes can be problematic. > When taking a backup on a system that has an index, if there are region > operations in progress, the asynchronous nature of propagating the results of > the operations to an index means that the index content may be inconsistent > with the region content. If the backup were later used to restore a system, > the inconsistency will be introduced back into the system. > The fix for this is to make sure that the system is quiescent with respect to > region operations when a backup is taken. > In addition, the restoration procedure should rebuild indexes. > This issue exists for both regular (OQL) indexes and for Lucene indexes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2985) Doc task: making/using backups when there are indexes
Karen Smoler Miller created GEODE-2985: -- Summary: Doc task: making/using backups when there are indexes Key: GEODE-2985 URL: https://issues.apache.org/jira/browse/GEODE-2985 Project: Geode Issue Type: Bug Components: docs Reporter: Karen Smoler Miller We should document that making a backup or using a backup to restore a system when that system also has/had indexes can be problematic. When taking a backup on a system that has an index, if there are region operations in progress, the asynchronous nature of propagating the results of the operations to an index means that the index content may be inconsistent with the region content. If the backup were later used to restore a system, the inconsistency will be introduced back into the system. The fix for this is to make sure that the system is quiescent with respect to region operations when a backup is taken. In addition, the restoration procedure should rebuild indexes. This issue exists for both regular (OQL) indexes and for Lucene indexes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (GEODE-2951) A gfsh lucene query specifying --pageSize fails with a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reopened GEODE-2951:
Not yet completed. Docs need to be updated, but the docs update is blocked,
waiting for completion of GEODE-2913.
> A gfsh lucene query specifying --pageSize fails with a NullPointerException
> ---
>
> Key: GEODE-2951
> URL: https://issues.apache.org/jira/browse/GEODE-2951
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> A gfsh lucene query specifying {{--pageSize}} fails with a
> NullPointerException:
> {noformat}
> gfsh>search lucene --name=index --region=data --queryStrings=NYPD
> --defaultField=Agency --pageSize=10
> Could not process command due to GemFire error. An error occurred while
> searching lucene index across the Geode cluster: null
> {noformat}
> This exception is logged in the locator.log:
> {noformat}
> [info 2017/05/18 12:42:22.317 PDT locator
> tid=0x7f] null
> java.lang.NullPointerException
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.displayResults(LuceneIndexCommands.java:476)
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.searchIndex(LuceneIndexCommands.java:299)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> The same query without the {{--pageSize=10}} setting works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (GEODE-2951) A gfsh lucene query specifying --pageSize fails with a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reassigned GEODE-2951:
--
Assignee: Karen Smoler Miller
> A gfsh lucene query specifying --pageSize fails with a NullPointerException
> ---
>
> Key: GEODE-2951
> URL: https://issues.apache.org/jira/browse/GEODE-2951
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> A gfsh lucene query specifying {{--pageSize}} fails with a
> NullPointerException:
> {noformat}
> gfsh>search lucene --name=index --region=data --queryStrings=NYPD
> --defaultField=Agency --pageSize=10
> Could not process command due to GemFire error. An error occurred while
> searching lucene index across the Geode cluster: null
> {noformat}
> This exception is logged in the locator.log:
> {noformat}
> [info 2017/05/18 12:42:22.317 PDT locator
> tid=0x7f] null
> java.lang.NullPointerException
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.displayResults(LuceneIndexCommands.java:476)
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.searchIndex(LuceneIndexCommands.java:299)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> The same query without the {{--pageSize=10}} setting works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2951) A gfsh lucene query specifying --pageSize fails with a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-2951:
---
Component/s: docs
> A gfsh lucene query specifying --pageSize fails with a NullPointerException
> ---
>
> Key: GEODE-2951
> URL: https://issues.apache.org/jira/browse/GEODE-2951
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Reporter: Barry Oglesby
>
> A gfsh lucene query specifying {{--pageSize}} fails with a
> NullPointerException:
> {noformat}
> gfsh>search lucene --name=index --region=data --queryStrings=NYPD
> --defaultField=Agency --pageSize=10
> Could not process command due to GemFire error. An error occurred while
> searching lucene index across the Geode cluster: null
> {noformat}
> This exception is logged in the locator.log:
> {noformat}
> [info 2017/05/18 12:42:22.317 PDT locator
> tid=0x7f] null
> java.lang.NullPointerException
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.displayResults(LuceneIndexCommands.java:476)
> at
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.searchIndex(LuceneIndexCommands.java:299)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> The same query without the {{--pageSize=10}} setting works fine.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (GEODE-2913) Update Lucene documentation
[
https://issues.apache.org/jira/browse/GEODE-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021440#comment-16021440
]
Karen Smoler Miller commented on GEODE-2913:
Work that also must be completed with this ticket: add Lucene XSD/XML
definitions to the Reference section of the docs.
> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> * Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create
> the Lucene index before creating the region, even though this member does not
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT tid=0x1]
> java.lang.IllegalStateException: Must create Lucene index full_index on
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create
> Lucene index full_index on region /data because it is defined in another
> member.
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The
> Lucene search will always be done on the server. Besides, _you can't create
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't,
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results.
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> * Destroying a region will *NOT* automatically destroy any Lucene index
> associated with that region. Instead, attempting to destroy a region with a
> Lucene index will throw a colocated region exception.
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation
> chain cannot be destroyed, unless all its children
> [[/cusip_index#_data.files]] are destroyed
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh:
> 1. export region data
> 2. destroy Lucene index, destroy region
> 3. create new index, create new region without user-defined business
> logic callbacks
> 4. import data with option to turn on callbacks (to invoke Lucene Async
> Event Listener to index the data)
> 5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not
> supported.
> * Document security implementation and defaults. If a user has security
> configured for their cluster, creating a Lucene index requires DATA:MANAGE
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE
> privilege because a function is called (different from OQL which requires
> only DATA:READ privilege). Here are all the required privileges for the gfsh
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction
> configured with local destroy. If using Lucene indexing, eviction can only be
> configured with overflow to disk. In this case, only the region data is
> overflowed to disk, *NOT* the Lucene index. An
[jira] [Resolved] (GEODE-2855) Document Rename Execution.withArgs to Execution.setArguments
[ https://issues.apache.org/jira/browse/GEODE-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2855. Resolution: Implemented Task was completed with the parent ticket, GEODE-728. > Document Rename Execution.withArgs to Execution.setArguments > > > Key: GEODE-2855 > URL: https://issues.apache.org/jira/browse/GEODE-2855 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Joey McAllister > Fix For: 1.2.0 > > > FunctionContext has a getArguments method. withArgs should be renamed to > match. > See https://issues.apache.org/jira/browse/GEODE-728 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2913) Update Lucene documentation
[
https://issues.apache.org/jira/browse/GEODE-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014981#comment-16014981
]
Karen Smoler Miller commented on GEODE-2913:
LuceneIndexStats need to be added to the docs. Here's a list of stats:
- queryExecutions - Number of lucene queries executed on this member
- queryExecutionTime - Amount of time spent executing lucene queries
- queryExecutionsInProgress, Number of query executions currently in progress
- queryExecutionTotalHits - Total number of documents returned by query
executions
- repositoryQueryExecutions - Number of lucene repository queries executed on
this member
- repositoryQueryExecutionTime - Amount of time spent executing lucene
repository queries
- repositoryQueryExecutionsInProgress - Number of repository query executions
currently in progress
- repositoryQueryExecutionTotalHits - Total number of documents returned by
repository query executions
- updates - Number of lucene index documents added/removed on this member
- updateTime - Amount of time spent adding or removing documents from the index
- updatesInProgress - Number of index updates in progress
- commits - Number of lucene index commits on this member
- commitTime - Amount of time spent in lucene index commits
- commitsInProgress - Number of lucene index commits in progress
- documents - Number of documents in the index
> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> * Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create
> the Lucene index before creating the region, even though this member does not
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT tid=0x1]
> java.lang.IllegalStateException: Must create Lucene index full_index on
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create
> Lucene index full_index on region /data because it is defined in another
> member.
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The
> Lucene search will always be done on the server. Besides, _you can't create
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't,
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results.
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> * Destroying a region will *NOT* automatically destroy any Lucene index
> associated with that region. Instead, attempting to destroy a region with a
> Lucene index will throw a colocated region exception.
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation
> chain cannot be destroyed, unless all its children
> [[/cusip_index#_data.files]] are destroyed
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh:
> 1. export region data
> 2. destroy Lucene index, destroy region
> 3. create new index, create new region without user-defined business
> logic callbacks
> 4. import data with option to turn on callbacks (to invoke Lucene Async
> Event Listener to index the
[jira] [Commented] (GEODE-2913) Update Lucene documentation
[
https://issues.apache.org/jira/browse/GEODE-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014738#comment-16014738
]
Karen Smoler Miller commented on GEODE-2913:
The {{destroy lucene index}} gfsh command reference page needs to be corrected.
It shows the {{--region}} specification as optional. It is required.
> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> * Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create
> the Lucene index before creating the region, even though this member does not
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT tid=0x1]
> java.lang.IllegalStateException: Must create Lucene index full_index on
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create
> Lucene index full_index on region /data because it is defined in another
> member.
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The
> Lucene search will always be done on the server. Besides, _you can't create
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't,
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results.
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> * Destroying a region will *NOT* automatically destroy any Lucene index
> associated with that region. Instead, attempting to destroy a region with a
> Lucene index will throw a colocated region exception.
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation
> chain cannot be destroyed, unless all its children
> [[/cusip_index#_data.files]] are destroyed
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh:
> 1. export region data
> 2. destroy Lucene index, destroy region
> 3. create new index, create new region without user-defined business
> logic callbacks
> 4. import data with option to turn on callbacks (to invoke Lucene Async
> Event Listener to index the data)
> 5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not
> supported.
> * Document security implementation and defaults. If a user has security
> configured for their cluster, creating a Lucene index requires DATA:MANAGE
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE
> privilege because a function is called (different from OQL which requires
> only DATA:READ privilege). Here are all the required privileges for the gfsh
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction
> configured with local destroy. If using Lucene indexing, eviction can only be
> configured with overflow to disk. In this case, only the region data is
> overflowed to disk, *NOT* the Lucene index.
[jira] [Updated] (GEODE-2906) Users need easy co-location of entries on partitioned regions
[ https://issues.apache.org/jira/browse/GEODE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2906: --- Component/s: docs > Users need easy co-location of entries on partitioned regions > - > > Key: GEODE-2906 > URL: https://issues.apache.org/jira/browse/GEODE-2906 > Project: Geode > Issue Type: Improvement > Components: docs, regions >Reporter: Fred Krone > > Implement a dynamic PartitionResolver that takes a String key and uses a '.' > as the separator between the actual key and the partitioning key, returning > the partitioning key when called. > The actual key would be the entire string, the partitioning key would be > everything after the last '.' unless there are no dots in which case it is > the whole String (which is the default without a PartitionResolver). > Requirements: > Make configurable via GFSH, cache.xml, or programmatically > -- Allow them to define their own resolver token > Make it work from the client -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2913) Update Lucene documentation
[
https://issues.apache.org/jira/browse/GEODE-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reassigned GEODE-2913:
--
Assignee: Karen Smoler Miller
> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .setXXX()
> .setYYY()
> .create()
> {code}
> * Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create
> the Lucene index before creating the region, even though this member does not
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT tid=0x1]
> java.lang.IllegalStateException: Must create Lucene index full_index on
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create
> Lucene index full_index on region /data because it is defined in another
> member.
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The
> Lucene search will always be done on the server. Besides, _you can't create
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't,
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results.
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> * Destroying a region will *NOT* automatically destroy any Lucene index
> associated with that region. Instead, attempting to destroy a region with a
> Lucene index will throw a colocated region exception.
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation
> chain cannot be destroyed, unless all its children
> [[/cusip_index#_data.files]] are destroyed
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh:
> 1. export region data
> 2. destroy Lucene index, destroy region
> 3. create new index, create new region without user-defined business
> logic callbacks
> 4. import data with option to turn on callbacks (to invoke Lucene Async
> Event Listener to index the data)
> 5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not
> supported.
> * Document security implementation and defaults. If a user has security
> configured for their cluster, creating a Lucene index requires DATA:MANAGE
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE
> privilege because a function is called (different from OQL which requires
> only DATA:READ privilege). Here are all the required privileges for the gfsh
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction
> configured with local destroy. If using Lucene indexing, eviction can only be
> configured with overflow to disk. In this case, only the region data is
> overflowed to disk, *NOT* the Lucene index. An UnsupportedOperationException
> is thrown:
> {quote}
> [error 2017/05/02 16:12:32.461 PDT tid=0x1]
> java.lang.UnsupportedOperationException: Lucene indexes on regions with
[jira] [Created] (GEODE-2913) Update Lucene documentation
Karen Smoler Miller created GEODE-2913:
--
Summary: Update Lucene documentation
Key: GEODE-2913
URL: https://issues.apache.org/jira/browse/GEODE-2913
Project: Geode
Issue Type: Bug
Components: docs
Reporter: Karen Smoler Miller
Improvements to the code base that need to be reflected in the docs:
* Change LuceneService.createIndex to use a factory pattern
{code:java}
luceneService.createIndex(region, index, ...)
{code}
changes to
{code:java}
luceneService.createIndexFactory()
.setXXX()
.setYYY()
.create()
{code}
* Lucene indexes will *NOT* be stored in off-heap memory.
* Document how to configure an index on accessors - you still need to create
the Lucene index before creating the region, even though this member does not
hold any region data.
If the index is not defined on the accessor, an exception like this will be
thrown while attempting to create the region:
{quote}
[error 2017/05/02 15:19:26.018 PDT tid=0x1]
java.lang.IllegalStateException: Must create Lucene index full_index on region
/data because it is defined in another member.
Exception in thread "main" java.lang.IllegalStateException: Must create Lucene
index full_index on region /data because it is defined in another member.
at
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
at
org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
{quote}
* Do not need to create a Lucene index on a client with a Proxy cache. The
Lucene search will always be done on the server. Besides, _you can't create an
index on a client._
* If you configure Invalidates for region entries (alone or as part of
expiration), these will *NOT* invalidate the Lucene indexes.
The problem with this is the index contains the keys, but the region doesn't,
so the query produces results that don't exist.
In this test, the first time the query is run, it produces N valid results. The
second time it is run it produces N empty results:
** load entries
** run query
** invalidate entries
** run query again
* Destroying a region will *NOT* automatically destroy any Lucene index
associated with that region. Instead, attempting to destroy a region with a
Lucene index will throw a colocated region exception.
An IllegalStateException is thrown:
{quote}
java.lang.IllegalStateException: The parent region [/data] in colocation chain
cannot be destroyed, unless all its children [[/cusip_index#_data.files]] are
destroyed
at
org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
at
org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
at
org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
at
DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
{quote}
* The process to change a Lucene index using gfsh:
1. export region data
2. destroy Lucene index, destroy region
3. create new index, create new region without user-defined business
logic callbacks
4. import data with option to turn on callbacks (to invoke Lucene Async
Event Listener to index the data)
5. alter region to add user-defined business logic callbacks
* Make sure there are no references to replicated regions as they are not
supported.
* Document security implementation and defaults. If a user has security
configured for their cluster, creating a Lucene index requires DATA:MANAGE
privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE
privilege because a function is called (different from OQL which requires only
DATA:READ privilege). Here are all the required privileges for the gfsh
commands:
** create index requires DATA:MANAGE:region
** describe index requires CLUSTER:READ
** list indexes requires CLUSTER:READ
** search index requires DATA:WRITE
** destroy index requires DATA:MANAGE:region
* A user cannot create a Lucene index on a region that has eviction configured
with local destroy. If using Lucene indexing, eviction can only be configured
with overflow to disk. In this case, only the region data is overflowed to
disk, *NOT* the Lucene index. An UnsupportedOperationException is thrown:
{quote}
[error 2017/05/02 16:12:32.461 PDT tid=0x1]
java.lang.UnsupportedOperationException: Lucene indexes on regions with
eviction and action local destroy are not supported
Exception in thread "main" java.lang.UnsupportedOperationException: Lucene
indexes on regions with eviction and action local destroy are not supported
at
org.apache.geode.cache.lucene.internal.LuceneRegionListener.beforeCreate(LuceneRegionListener.java:85)
at
[jira] [Resolved] (GEODE-2103) start locator command should include --http-service-port and --http-service-bind-address
[ https://issues.apache.org/jira/browse/GEODE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2103. Resolution: Fixed > start locator command should include --http-service-port and > --http-service-bind-address > > > Key: GEODE-2103 > URL: https://issues.apache.org/jira/browse/GEODE-2103 > Project: Geode > Issue Type: Improvement > Components: docs, management >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > To facilitate starting the Admin REST API on a Locator, start locator command > should include --http-service-port and --http-service-bind-address. > Workaround is to specify these configuration properties with --J: > --J=-Dgemfire.http-service-port= > --J=-Dgemfire.http-service-bind-address= -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2103) start locator command should include --http-service-port and --http-service-bind-address
[ https://issues.apache.org/jira/browse/GEODE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2103: -- Assignee: Karen Smoler Miller (was: Joey McAllister) > start locator command should include --http-service-port and > --http-service-bind-address > > > Key: GEODE-2103 > URL: https://issues.apache.org/jira/browse/GEODE-2103 > Project: Geode > Issue Type: Improvement > Components: docs, management >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > To facilitate starting the Admin REST API on a Locator, start locator command > should include --http-service-port and --http-service-bind-address. > Workaround is to specify these configuration properties with --J: > --J=-Dgemfire.http-service-port= > --J=-Dgemfire.http-service-bind-address= -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2788) Add official Socket timeout parameter when connecting to servers/locators
[ https://issues.apache.org/jira/browse/GEODE-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2788: --- Component/s: docs > Add official Socket timeout parameter when connecting to servers/locators > - > > Key: GEODE-2788 > URL: https://issues.apache.org/jira/browse/GEODE-2788 > Project: Geode > Issue Type: Improvement > Components: client/server, docs >Reporter: Masaki Yamakawa >Priority: Minor > Labels: patch > > When connecting from the client to the servers/locators, if the > servers/locators is not started, the connection can not be established and a > Socket timeout occurs. > This timeout value is 59 seconds by default. This timeout value is too long. > This timeout value can be changed by specifying the unofficial parameter > "gemfire.PoolImpl.HANDSHAKE_TIMEOUT" in java system property, but I > corresponded so that it can be specified by official parameters. > Like the NativeClient, the official parameters should be specified by > "connect-timeout" in gemfire.properties. > Timeout values ​​are determined in the following order of priority. > 1. java system property:gemfire.PoolImpl.HANDSHAKE_TIMEOUT > 2. java system property:gemfire.connect-timeout > 3. gemfire.properties:connect-timeout > 4. default:59000 milli seconds > As another idea, there is also an idea to make it possible to specify it as > an attribute of Pool. In that case NativeClient needs the same modification. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2777) Change version number from 1.1 to 1.2 in docs
[ https://issues.apache.org/jira/browse/GEODE-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2777. Resolution: Fixed > Change version number from 1.1 to 1.2 in docs > - > > Key: GEODE-2777 > URL: https://issues.apache.org/jira/browse/GEODE-2777 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Joey McAllister >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > On the `develop` branch, change any reference to v1.1 to be v1.2 in the > `geode-docs` and `geode-book` directories. > In the `geode-book` directory, make sure to change the hrefs in the subnav > from `/11/` to `/12/` and make relevant version changes to the `config.yml` > file. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2777) Change version number from 1.1 to 1.2 in docs
[ https://issues.apache.org/jira/browse/GEODE-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15967863#comment-15967863 ] Karen Smoler Miller commented on GEODE-2777: This task is to be completed before a 1.2 release candidate is made. > Change version number from 1.1 to 1.2 in docs > - > > Key: GEODE-2777 > URL: https://issues.apache.org/jira/browse/GEODE-2777 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Joey McAllister >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > On the `develop` branch, change any reference to v1.1 to be v1.2 in the > `geode-docs` and `geode-book` directories. > In the `geode-book` directory, make sure to change the hrefs in the subnav > from `/11/` to `/12/` and make relevant version changes to the `config.yml` > file. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2777) Change version number from 1.1 to 1.2 in docs
[ https://issues.apache.org/jira/browse/GEODE-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2777: -- Assignee: Karen Smoler Miller > Change version number from 1.1 to 1.2 in docs > - > > Key: GEODE-2777 > URL: https://issues.apache.org/jira/browse/GEODE-2777 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Joey McAllister >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > On the `develop` branch, change any reference to v1.1 to be v1.2 in the > `geode-docs` and `geode-book` directories. > In the `geode-book` directory, make sure to change the hrefs in the subnav > from `/11/` to `/12/` and make relevant version changes to the `config.yml` > file. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2763) Remove of nonSingleHopsCount stat in client
[ https://issues.apache.org/jira/browse/GEODE-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2763: --- Component/s: docs > Remove of nonSingleHopsCount stat in client > --- > > Key: GEODE-2763 > URL: https://issues.apache.org/jira/browse/GEODE-2763 > Project: Geode > Issue Type: Bug > Components: docs, native client >Reporter: Michael Dodge > > A pre-existing issue (GEODE-2017) required the removal of the > nonSingleHopsCount statistic in the clients. Whilst marked for the native > client as well, it was not addressed in the native client. It should be. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2231) Create new partitioning example
[ https://issues.apache.org/jira/browse/GEODE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2231: --- Fix Version/s: 1.2.0 > Create new partitioning example > --- > > Key: GEODE-2231 > URL: https://issues.apache.org/jira/browse/GEODE-2231 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Minor > Fix For: 1.2.0 > > > Add a new example to the geode-examples that demonstrates partitioning. > The example will use the same structure as the replicated example, starting 2 > servers that host a partitioned region (with no redundant copies). Run the > producer to populate the region. Run the consumer to see the contents of the > region. Then, stop one of the servers and run the consumer again to notice > that only roughly half (with 2 servers and hopefully a reasonable hash) of > the entries are present. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2743) Adjust gradle build of geode-examples JAR files
[
https://issues.apache.org/jira/browse/GEODE-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15951564#comment-15951564
]
Karen Smoler Miller commented on GEODE-2743:
I'm talking about an application's JAR, where the application is built as part
of a particular geode-examples repo example. The partitioned example builds a
JAR for the Producer, Consumer, EmployeeKey, and EmployeeData classes. Today
(before Geode 1.2 is released), the gradle build names this JAR file
{{partitioned-1.2.0-SNAPSHOT.jar}}. I want this JAR file to be named
partitioned.jar, or similar, but without the '1.2.0-SNAPSHOT' portion. This
JAR represents code used in the example that ought to work with pretty much any
version of Geode, unless there is some remarkably drastic change to the API.
> Adjust gradle build of geode-examples JAR files
> ---
>
> Key: GEODE-2743
> URL: https://issues.apache.org/jira/browse/GEODE-2743
> Project: Geode
> Issue Type: Improvement
>Reporter: Karen Smoler Miller
>
> With a versioned build of geode-examples, the JAR file created for any
> specific example (right now there are 2, replicated and partitioned) has a
> version number in its file name. This makes it difficult or impossible to
> write a robust shell script that must place that JAR file on the classpath.
> One idea floated was to just grab whatever JAR file was in the build/libs
> directory and use it on the classpath. That doesn't work if the developer
> running the examples has used 2 (or more) distinct version of Geode over
> time, such that there are 2 (or more) JAR files in the build/libs directory.
> Another idea was to not use shell scripts to run the example. Just inform
> the developer how to form the correct gfsh commands. This works, but it
> makes the examples more effort for the developer, who can no longer
> copy/paste any of the commands from the README instructions that explain how
> to run the example. I think it also hobbles a developer of further examples.
> Since the examples should be fairly independent of which version of Geode is
> actually running, my proposed solution is for the build to not inject a Geode
> version number into the name of the JAR file. That is what this ticket is
> meant to implement.
> Once this is done, both the replicated and partitioned examples will need to
> be revised, since both have scripts that reference versioned files.
> This will also decrease the effort of a release manager, since right now, to
> have a working example, the release manager would need to update the
> geode-examples gradle.properties file (this will always need to be done) and
> the versioned file names that are embedded into an example's scripts.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2743) Adjust gradle build of geode-examples JAR files
Karen Smoler Miller created GEODE-2743: -- Summary: Adjust gradle build of geode-examples JAR files Key: GEODE-2743 URL: https://issues.apache.org/jira/browse/GEODE-2743 Project: Geode Issue Type: Improvement Reporter: Karen Smoler Miller With a versioned build of geode-examples, the JAR file created for any specific example (right now there are 2, replicated and partitioned) has a version number in its file name. This makes it difficult or impossible to write a robust shell script that must place that JAR file on the classpath. One idea floated was to just grab whatever JAR file was in the build/libs directory and use it on the classpath. That doesn't work if the developer running the examples has used 2 (or more) distinct version of Geode over time, such that there are 2 (or more) JAR files in the build/libs directory. Another idea was to not use shell scripts to run the example. Just inform the developer how to form the correct gfsh commands. This works, but it makes the examples more effort for the developer, who can no longer copy/paste any of the commands from the README instructions that explain how to run the example. I think it also hobbles a developer of further examples. Since the examples should be fairly independent of which version of Geode is actually running, my proposed solution is for the build to not inject a Geode version number into the name of the JAR file. That is what this ticket is meant to implement. Once this is done, both the replicated and partitioned examples will need to be revised, since both have scripts that reference versioned files. This will also decrease the effort of a release manager, since right now, to have a working example, the release manager would need to update the geode-examples gradle.properties file (this will always need to be done) and the versioned file names that are embedded into an example's scripts. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2399) Update docs to reflect branding changes on native clients.
[ https://issues.apache.org/jira/browse/GEODE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15944195#comment-15944195 ] Karen Smoler Miller commented on GEODE-2399: For this ticket, only looking to make 2 changes within the docs: - GemStone.GemFire.Cache.dll -> Apache.Geode.dll - gfcppcache.dll -> apache-geode.dll > Update docs to reflect branding changes on native clients. > -- > > Key: GEODE-2399 > URL: https://issues.apache.org/jira/browse/GEODE-2399 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Jacob S. Barrett >Assignee: Karen Smoler Miller > > Native client library names change. See parent ticket for changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2720) Docs should have 2-digit release number, not 3-digit
[ https://issues.apache.org/jira/browse/GEODE-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2720: --- Fix Version/s: 1.2.0 > Docs should have 2-digit release number, not 3-digit > > > Key: GEODE-2720 > URL: https://issues.apache.org/jira/browse/GEODE-2720 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > The top of the Geode docs about.html page has a header which contains a > 3-digit release number (for example, Geode 1.1.0). It should instead only > have the first 2 digits (for example, Geode 1.1). > With this change, a release that revs the 3rd digit (for example, Geode 1.1.0 > to Geode 1.1.1) will not need a new version of the docs, if there are no > documentation ramifications to the release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2720) Docs should have 2-digit release number, not 3-digit
[ https://issues.apache.org/jira/browse/GEODE-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2720: -- Assignee: Karen Smoler Miller > Docs should have 2-digit release number, not 3-digit > > > Key: GEODE-2720 > URL: https://issues.apache.org/jira/browse/GEODE-2720 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > The top of the Geode docs about.html page has a header which contains a > 3-digit release number (for example, Geode 1.1.0). It should instead only > have the first 2 digits (for example, Geode 1.1). > With this change, a release that revs the 3rd digit (for example, Geode 1.1.0 > to Geode 1.1.1) will not need a new version of the docs, if there are no > documentation ramifications to the release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2720) Docs should have 2-digit release number, not 3-digit
Karen Smoler Miller created GEODE-2720: -- Summary: Docs should have 2-digit release number, not 3-digit Key: GEODE-2720 URL: https://issues.apache.org/jira/browse/GEODE-2720 Project: Geode Issue Type: Bug Components: docs Reporter: Karen Smoler Miller The top of the Geode docs about.html page has a header which contains a 3-digit release number (for example, Geode 1.1.0). It should instead only have the first 2 digits (for example, Geode 1.1). With this change, a release that revs the 3rd digit (for example, Geode 1.1.0 to Geode 1.1.1) will not need a new version of the docs, if there are no documentation ramifications to the release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2719) The total-max-memory region attribute does not appear to do anything
[
https://issues.apache.org/jira/browse/GEODE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-2719:
---
Component/s: docs
> The total-max-memory region attribute does not appear to do anything
>
>
> Key: GEODE-2719
> URL: https://issues.apache.org/jira/browse/GEODE-2719
> Project: Geode
> Issue Type: Improvement
> Components: docs, regions
>Reporter: Darrel Schneider
>
> I could not find that the "total-max-memory" region partitioned attribute
> does anything. If this is correct then it should be deprecated and removed in
> a future release. A user read the geode docs and expected it cause LRU
> eviction since this docs say this about it:
> {quote}
> Maximum combined megabytes of memory to be used by all processes hosting this
> region for all copies, primary and redundant.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2656) gfsh should be at parity with cache.xml
[ https://issues.apache.org/jira/browse/GEODE-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2656: --- Component/s: docs > gfsh should be at parity with cache.xml > --- > > Key: GEODE-2656 > URL: https://issues.apache.org/jira/browse/GEODE-2656 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Reporter: Swapnil Bawaskar > > A user should be able to able to configure their cluster using gfsh; without > having to resort to a mix of gfsh and cache.xml -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software
[ https://issues.apache.org/jira/browse/GEODE-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903514#comment-15903514 ] Karen Smoler Miller commented on GEODE-2513: Instead of changing just this one instance of the wrong properties file name with PR 49, let's add another task to this JIRA that searches for all instances of the properties file name, and updates all. > Geode Native docs: rebrand to match open-source software > > > Key: GEODE-2513 > URL: https://issues.apache.org/jira/browse/GEODE-2513 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes > > The newly-contributed Geode Native doc sources contain some GemFire artifacts > that have been purged from the open-source code. Docs should be updated to > match. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege
[ https://issues.apache.org/jira/browse/GEODE-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2605: --- Component/s: docs > Unable to do a Lucene query without CLUSTER:READ privilege > -- > > Key: GEODE-2605 > URL: https://issues.apache.org/jira/browse/GEODE-2605 > Project: Geode > Issue Type: Bug > Components: docs, lucene, security >Reporter: Diane Hardman > Attachments: security.json > > > I have configured a small cluster with security and am testing the privileges > I need for creating a Lucene index and then executing a query/search using > Lucene. > I have confirmed that DATA:MANAGE privilege allows me to create a lucene > index (similar to creating OQL indexes). > I assumed I needed DATA:WRITE privilege to execute 'search lucene' because > the implementation uses a function. Instead, I am getting an error that I > need CLUSTER:READ privilege. I don't know why. > As an aside, we may want to document that all DATA privileges automatically > include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but > could not list the indexes I created without CLUSTER:READ... go figure. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2562) Docs: simplify language in Main Features section
[ https://issues.apache.org/jira/browse/GEODE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2562: --- Fix Version/s: 1.2.0 > Docs: simplify language in Main Features section > > > Key: GEODE-2562 > URL: https://issues.apache.org/jira/browse/GEODE-2562 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > Fix For: 1.2.0 > > > Simplify some language within the page that describes main features of Geode. > Will do this task as commit-then-review. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2562) Docs: simplify language in Main Features section
[ https://issues.apache.org/jira/browse/GEODE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2562: -- Assignee: Karen Smoler Miller > Docs: simplify language in Main Features section > > > Key: GEODE-2562 > URL: https://issues.apache.org/jira/browse/GEODE-2562 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > Simplify some language within the page that describes main features of Geode. > Will do this task as commit-then-review. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2562) Docs: simplify language in Main Features section
[ https://issues.apache.org/jira/browse/GEODE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2562. Resolution: Fixed > Docs: simplify language in Main Features section > > > Key: GEODE-2562 > URL: https://issues.apache.org/jira/browse/GEODE-2562 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > Fix For: 1.2.0 > > > Simplify some language within the page that describes main features of Geode. > Will do this task as commit-then-review. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-2562) Docs: simplify language in Main Features section
[ https://issues.apache.org/jira/browse/GEODE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15890790#comment-15890790 ] Karen Smoler Miller commented on GEODE-2562: Adding a paragraph about Geode Native and the clients that can be written. > Docs: simplify language in Main Features section > > > Key: GEODE-2562 > URL: https://issues.apache.org/jira/browse/GEODE-2562 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > > Simplify some language within the page that describes main features of Geode. > Will do this task as commit-then-review. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2562) Docs: simplify language in Main Features section
Karen Smoler Miller created GEODE-2562: -- Summary: Docs: simplify language in Main Features section Key: GEODE-2562 URL: https://issues.apache.org/jira/browse/GEODE-2562 Project: Geode Issue Type: Bug Components: docs Reporter: Karen Smoler Miller Simplify some language within the page that describes main features of Geode. Will do this task as commit-then-review. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2404) Add API to destroy a region containing lucene indexes
[
https://issues.apache.org/jira/browse/GEODE-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-2404:
---
Component/s: docs
> Add API to destroy a region containing lucene indexes
> -
>
> Key: GEODE-2404
> URL: https://issues.apache.org/jira/browse/GEODE-2404
> Project: Geode
> Issue Type: New Feature
> Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
> Attachments: DestroyRegionMultipleMembersFunction.java
>
>
> h2. Description
> An application {{Region}} containing {{LuceneIndexes}} should be able to be
> destroyed.
> There are several options, including:
> - Invoke one API to destroy both the application {{Region}} and its
> {{LuceneIndexes}}
> - Invoke two API:
> ## destroy the {{LuceneIndexes}}
> ## destroy application {{Region}} as it is done currently
> h3. One API
> In this case, we would need a callback on {{LuceneService}} to destroy the
> {{LuceneIndexes}} before destroying the application {{Region}} like:
> {noformat}
> public void beforeDestroyRegion(Region region);
> {noformat}
> This API would get all the {{LuceneIndexes}} for the application {{Region}},
> then destroy each one. See the *Two API* section below for details on
> destroying a {{LuceneIndex}}.
> Without changes to the way {{PartitionedRegions}} are destroyed, this causes
> an issue though.
> The current behavior of {{PartitionedRegion destroyRegion}} is to first check
> for colocated children. If there are any, the call fails.
> There are two options for adding the call to destroy the {{LuceneIndexes}}:
> # check for colocated children
> # invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
> # do the rest of the destroy
>
> # invoke {{LuceneService beforeDestroyRegion}} to remove the {{LuceneIndexes}}
> # check for colocated children
> # do the rest of the destroy
> Both of these options are problematic in different ways.
> In the case of a {{PartitionedRegion}} with {{LuceneIndexes}}, there are
> colocated children, so the first option would cause the {{destroyRegion}}
> call to fail; the second option would succeed. I don't think the first option
> should fail since the colocated children are internal {{Regions}} that the
> application knows nothing about.
> In the case of a {{PartitionedRegion}} defining {{LuceneIndexes}} and having
> an {{AsyncEventQueue}}, there are colocated children, so the first option
> would cause the {{destroyRegion}} call to fail. This is ok since one of the
> children is an application-known {{AsyncEventQueue}}. The second option would
> fail in a bad way. It would first remove the {{LuceneIndexes}}, then fail the
> colocated children check, so the {{destroyRegion}} call would fail. In this
> case, the application {{Region}} doesn't get destroyed but its
> {{LuceneIndexes}} do. This would be bad.
> One option would be to look into changing the check for colocated children to
> check for application-defined (or not hidden) colocated children. Then the
> code would be something like:
> # check for application-defined colocated children
> # invoke LuceneService beforeDestroyRegion to remove the LuceneIndexes
> # do the rest of the destroy
> I think this would be ok in both cases.
> h3. Two API
> The destroy API on {{LuceneIndex}} would be something like:
> {noformat}
> public void destroy();
> {noformat}
> Destroying each {{LuceneIndex}} would require:
> # destroying the chunk {{Region}}
> # destroying the file {{Region}}
> # destroying the {{AsyncEventQueue}} which would require:
> ## retrieving and stopping the {{AsyncEventQueue's}} underlying
> {{GatewaySender}} (there probably should be stop API on {{AsyncEventQueue}}
> which does this)
> ## removing the id from the application {{Region's AsyncEventQueue}} ids
> ## destroying the {{AsyncEventQueue}} (this destroys the underlying
> {{GatewaySender}} and removes it from the {{GemFireCacheImpl's}} collection
> of {{GatewaySenders}})
> ## removing the {{AsyncEventQueue}} from the {{GemFireCacheImpl's}}
> collection of {{AsyncEventQueues}} (this should be included in the destroy
> method above)
> # removing {{LuceneIndex}} from {{LuceneService's}} map of indexes
> I also think the API on {{LuceneService}} should be something like:
> {noformat}
> public void destroyIndexes(String regionPath);
> public void destroyIndex(String indexName, String regionPath);
> {noformat}
> These methods would get the appropriate {{LuceneIndex(es)}} and invoke
> destroy on them. Then they would remove the index(es) from the
> {{LuceneService's}} collection of {{LuceneIndexes}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (GEODE-2537) Docs: redraw image to remove GemFire label
Karen Smoler Miller created GEODE-2537: -- Summary: Docs: redraw image to remove GemFire label Key: GEODE-2537 URL: https://issues.apache.org/jira/browse/GEODE-2537 Project: Geode Issue Type: Bug Components: docs Reporter: Karen Smoler Miller The image referenced within the How Delta Propagation Works subsection of *both* the Geode and the Geode Native manuals has labels that say 'GemFire.' There do not appear to be any source files available, so this gif diagram will need to be redrawn, and made available to both repos: geode and geode-native. The gif for the image is - geode-native/docs/geode-native-docs/common/images/delta-propagation.gif - geode/geode-docs/images/DeltaPropagation-1.gif -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (GEODE-2507) Acquire and populate new geode-site repo for the web site
[ https://issues.apache.org/jira/browse/GEODE-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2507: -- Assignee: Karen Smoler Miller > Acquire and populate new geode-site repo for the web site > - > > Key: GEODE-2507 > URL: https://issues.apache.org/jira/browse/GEODE-2507 > Project: Geode > Issue Type: New Feature > Components: web-content >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > Move the web site content to its own repo. > 1. Acquire the repo. Name it geode-site. > 2. Populate the repo with the current web site's contents on the master branch > 3. Request that the asf-site branch be switched from the geode repo to this > new geode-site repo, and test that everything works > 4. Update the contents of LICENSE files for geode and geode-site > 5. Setup auto-publish by creating an INFRA JIRA ticket > 6. Revise README for publishing instructions -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2498) Revise 1.1.0 manual to remove references to 1.0.0-incubating
Karen Smoler Miller created GEODE-2498:
--
Summary: Revise 1.1.0 manual to remove references to
1.0.0-incubating
Key: GEODE-2498
URL: https://issues.apache.org/jira/browse/GEODE-2498
Project: Geode
Issue Type: Bug
Components: docs, web-content
Reporter: Karen Smoler Miller
There are two errant instances within the Geode 1.1.0 manual that say
1.0.0-incubating. This task is to remove these references, and further, to
revise the prose such that it does not contain a version number that would need
to be changed in future releases. That would avoid the mistake that occurred
with the 1.1.0 manual.
The 2 instances are within files
* {{geode-docs/about_geode.html.md.erb}}
* {{geode-docs/prereq_and_install.html.md.erb}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-2479) correct doc reference to a com.gemstone package
[ https://issues.apache.org/jira/browse/GEODE-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2479: --- Fix Version/s: 1.2.0 > correct doc reference to a com.gemstone package > --- > > Key: GEODE-2479 > URL: https://issues.apache.org/jira/browse/GEODE-2479 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > Fix For: 1.2.0 > > > File geode-docs/developing/data_serialization/auto_serialization.html still > has a spurious reference to a com.gemstone package. It should be corrected > to identify org.apache.geode instead. > At the same time, remove links to the 2 subsections with headers > - Customizing Serialization with Class Pattern Strings > - Extending the ReflectionBasedAutoSerializer > These are in the navigation bar, so the links server no purpose. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (GEODE-2479) correct doc reference to a com.gemstone package
[ https://issues.apache.org/jira/browse/GEODE-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2479. Resolution: Fixed Assignee: Karen Smoler Miller > correct doc reference to a com.gemstone package > --- > > Key: GEODE-2479 > URL: https://issues.apache.org/jira/browse/GEODE-2479 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.2.0 > > > File geode-docs/developing/data_serialization/auto_serialization.html still > has a spurious reference to a com.gemstone package. It should be corrected > to identify org.apache.geode instead. > At the same time, remove links to the 2 subsections with headers > - Customizing Serialization with Class Pattern Strings > - Extending the ReflectionBasedAutoSerializer > These are in the navigation bar, so the links server no purpose. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2479) correct doc reference to a com.gemstone package
[ https://issues.apache.org/jira/browse/GEODE-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2479: --- Summary: correct doc reference to a com.gemstone package (was: correct doc reference to a com.gemstone packatge) > correct doc reference to a com.gemstone package > --- > > Key: GEODE-2479 > URL: https://issues.apache.org/jira/browse/GEODE-2479 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > > File geode-docs/developing/data_serialization/auto_serialization.html still > has a spurious reference to a com.gemstone package. It should be corrected > to identify org.apache.geode instead. > At the same time, remove links to the 2 subsections with headers > - Customizing Serialization with Class Pattern Strings > - Extending the ReflectionBasedAutoSerializer > These are in the navigation bar, so the links server no purpose. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (GEODE-2479) correct doc reference to a com.gemstone packatge
Karen Smoler Miller created GEODE-2479: -- Summary: correct doc reference to a com.gemstone packatge Key: GEODE-2479 URL: https://issues.apache.org/jira/browse/GEODE-2479 Project: Geode Issue Type: Bug Components: docs Reporter: Karen Smoler Miller File geode-docs/developing/data_serialization/auto_serialization.html still has a spurious reference to a com.gemstone package. It should be corrected to identify org.apache.geode instead. At the same time, remove links to the 2 subsections with headers - Customizing Serialization with Class Pattern Strings - Extending the ReflectionBasedAutoSerializer These are in the navigation bar, so the links server no purpose. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2420) Warn a user if they try to export too much data
[ https://issues.apache.org/jira/browse/GEODE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2420: --- Component/s: docs > Warn a user if they try to export too much data > --- > > Key: GEODE-2420 > URL: https://issues.apache.org/jira/browse/GEODE-2420 > Project: Geode > Issue Type: Sub-task > Components: configuration, docs, gfsh >Reporter: Jared Stewart > > We should warn a user and prompt for confirmation before trying to perform an > `export logs` operation that would result in a file over some threshold. > (Logs and stats have the potential to be very large.) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (GEODE-283) Remove Gateway class if possible
[ https://issues.apache.org/jira/browse/GEODE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848907#comment-15848907 ] Karen Smoler Miller commented on GEODE-283: --- There are no instances of the Gateway class in the documentation. > Remove Gateway class if possible > > > Key: GEODE-283 > URL: https://issues.apache.org/jira/browse/GEODE-283 > Project: Geode > Issue Type: Sub-task > Components: wan >Reporter: Darrel Schneider > Original Estimate: 3h > Remaining Estimate: 3h > > com.gemstone.gemfire.cache.util.Gateway used to be marked deprecated and was > removed along with the other deprecated Gateway classes. But rolling upgrade > tests had problems because the old and new members try to exchange a > Gateway$OrderPolicy instance. > So a stripped down version of Gateway was brought back for geode. > But later a decision was made to not support rolling upgrade for the initial > geode release which means that Gateway and Gateway$OrderPolicy can be removed. > If we end up needing to keep them then the javadocs in the new Gateway need > to be improved. They should probably just say it is for internal use only and > it should be marked as deprecated in 8.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-1672) When amount of overflowed persisted data exceeds heap size startup may run out of memory
[ https://issues.apache.org/jira/browse/GEODE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-1672: --- Component/s: docs > When amount of overflowed persisted data exceeds heap size startup may run > out of memory > > > Key: GEODE-1672 > URL: https://issues.apache.org/jira/browse/GEODE-1672 > Project: Geode > Issue Type: Bug > Components: docs, persistence >Reporter: Darrel Schneider > > Basically, when the amount of data overflowed approaches the heap size, ,such > that the total amount of data is very close to or actually surpasses your > total tenured heap, it is possible that you will not be able to restart. > The algorithm during recovery of oplogs/buckets is such that we don't "evict" > in the normal sense as data fills the heap during early stages of recovery > prior to creating the regions. When the data is first created in the heap, > it's not yet official in the region. > At any rate, if during this early phase of recovery, or during subsequent > phase where eviction is working as usual, it is possible that the total data > or an early imbalance of buckets prior to the opportunity to rebalance causes > us to surpass the critical threshold which will kill us before successful > startup. > To reproduce, you could have 1 region with tons of data that evicts and > overflows with persistence. Call it R1. Then another region with persistence > that does not evict. Call it R2. > List R1 fist in the cache.xml file. Start running the system and add data > over time until you have overflowed tons of data approaching the heap size in > the evicted region, and also have enough data in the R2 region. > Once you fill these regions with enough data and have overflowed enough to > disk and persisted the other region, then shutdown, and then attempt to > restart. If you put enough data in, you will hit the critical threshold > before being able to complete startup. > You can work around this issue by configuring geode to not recovery values by > setting this system property: -Dgemfire.disk.recoverValues=false > Values will not be faulted into memory until a read operation is done on that > value's key. > If you have regions that do not use overflow and some that do then another > work around is the create the regions that do not use overflow first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (GEODE-2299) Integrate Geode with Grafana for historical and real-time metrics analysis
[ https://issues.apache.org/jira/browse/GEODE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2299: --- Component/s: docs > Integrate Geode with Grafana for historical and real-time metrics analysis > -- > > Key: GEODE-2299 > URL: https://issues.apache.org/jira/browse/GEODE-2299 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, management, pulse, statistics >Reporter: Christian Tzolov > > Use Grafana dashboards for querying, visualizing and analysing Apache Geode > statistics archives and JMX real-time metrics. > Solution should provide unified technical stack for visualizing and analysing > both real-time (e.g JMX metrics) and historical (archive files) cluster > statistics. > Initial work: https://github.com/tzolov/geode-dashboard -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2260) Move geode examples to new repo home
[ https://issues.apache.org/jira/browse/GEODE-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15815534#comment-15815534 ] Karen Smoler Miller commented on GEODE-2260: The geode-examples repository is set up and ready to be used. I am extending the original description of this ticket to also include removing the geode-examples module from the Apache Geode repository, revising the build to work without the module. > Move geode examples to new repo home > > > Key: GEODE-2260 > URL: https://issues.apache.org/jira/browse/GEODE-2260 > Project: Geode > Issue Type: New Feature >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > Initialize new repository (https://github.com/apache/geode-examples) for > geode-examples module. > Move current geode-examples module to the new repo. > Revise instructions to work outside the geode repo. Verify the replicated > example works once moved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2270) Need API to call gfsh and get results dynamically from code
[
https://issues.apache.org/jira/browse/GEODE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-2270:
---
Component/s: docs
> Need API to call gfsh and get results dynamically from code
> ---
>
> Key: GEODE-2270
> URL: https://issues.apache.org/jira/browse/GEODE-2270
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh
>Reporter: Wes Williams
>
> GIVEN:
> 1) The GfshParser and CommandResult are internal classes.
> 2) CommandResult returns headings, line.separator's and UI concerns along
> with the answer
> WHEN:
> I pass a gfsh command into a public gfsh API from code
> THEN:
> I get back an XML or JSON representation of the core results without the
> headings, line.separator's and UI concerns
> EXAMPLE (idea node and not actual implementation):
> WHEN:
> String gfshResults = gfshPublicAPI("list regions");
> return gfshResults;
> String gfshPublicAPI(String gfshCommand) {
> ParseResult parseResult = gfshParser.parse(gfshCommand);
> String results = (String) parseResult.getMethod()+"Json"
> .invoke(parseResult.getInstance(), parseResult.getArguments())
>return results;
> }
> CommandResult gfshInternalAPI(String gfshCommand) {
> ParseResult parseResult = gfshParser.parse(gfshCommand);
> CommandResult results = (CommandResult) parseResult.getMethod()
> .invoke(parseResult.getInstance(), parseResult.getArguments())
>return results;
> }
> Another option is to include a new property --output=json into gfsh commands
> that return the core results without the UI concerns, per Anthony Baker's
> comment on Fri, 04 Nov, 20:31 at:
> https://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201611.mbox/browser
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2269) It seems the gfsh "remove" command cannot remove r...
[ https://issues.apache.org/jira/browse/GEODE-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2269: --- Component/s: docs > It seems the gfsh "remove" command cannot remove r... > - > > Key: GEODE-2269 > URL: https://issues.apache.org/jira/browse/GEODE-2269 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Gregory Green > > It seems the gfsh "remove" command cannot remove region entries with a 0 > length string key. > gfsh>query --query="select toString().length() from /Recipient.keySet()" > Result : true > startCount : 0 > endCount : 20 > Rows : 3 > Result > -- > 0 > 2 > 5 > gfsh>remove --region=/Recipient --key="" > Message : Key is either empty or Null > Result : false > gfsh>remove --region=/Recipient --key="''" > Message : Key is either empty or Null > Result : false -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2267) Add gfsh command to export all cluster artifacts
[ https://issues.apache.org/jira/browse/GEODE-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2267: --- Component/s: docs > Add gfsh command to export all cluster artifacts > > > Key: GEODE-2267 > URL: https://issues.apache.org/jira/browse/GEODE-2267 > Project: Geode > Issue Type: Bug > Components: configuration, docs, gfsh >Reporter: Diane Hardman > > Both GSS and the PCF Tile team have requested a single gfsh command to > collect and export all logfiles and stat files into a single package. This > package (zipfile) can then be saved and attached to emails and Jira tickets > to help evaluate the GemFire cluster status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2260) Move geode examples to new repo home
Karen Smoler Miller created GEODE-2260: -- Summary: Move geode examples to new repo home Key: GEODE-2260 URL: https://issues.apache.org/jira/browse/GEODE-2260 Project: Geode Issue Type: New Feature Reporter: Karen Smoler Miller Initialize new repository (https://github.com/apache/geode-examples) for geode-examples module. Move current geode-examples module to the new repo. Revise instructions to work outside the geode repo. Verify the replicated example works once moved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2258) fix doc typos for setting properties
[
https://issues.apache.org/jira/browse/GEODE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-2258.
Resolution: Fixed
> fix doc typos for setting properties
>
>
> Key: GEODE-2258
> URL: https://issues.apache.org/jira/browse/GEODE-2258
> Project: Geode
> Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> In file
> {{basic_config/gemfire_properties/setting_distributed_properties.html}}, this
> text is wrong:
> {{System.setProperty("DgemfirePropertyFile", "gfTest");}}
> {{System.setProperty("Dgemfire.mcast-port", "10999");}}
> The capital D at the beginning of each property name should be deleted.
> In the same file, the reference to DistributedSystem javadocs should be
> changed to refer to this class:
> {{org.apache.geode.distributed.ConfigurationProperties}}
> {{ConfigurationProperties}} also defines constants for each property name so
> that applications can use them instead of embedding string constants in their
> code. This has the benefit of avoiding typing mistakes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2258) fix doc typos for setting properties
[
https://issues.apache.org/jira/browse/GEODE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-2258:
---
Fix Version/s: 1.1.0
> fix doc typos for setting properties
>
>
> Key: GEODE-2258
> URL: https://issues.apache.org/jira/browse/GEODE-2258
> Project: Geode
> Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0
>
>
> In file
> {{basic_config/gemfire_properties/setting_distributed_properties.html}}, this
> text is wrong:
> {{System.setProperty("DgemfirePropertyFile", "gfTest");}}
> {{System.setProperty("Dgemfire.mcast-port", "10999");}}
> The capital D at the beginning of each property name should be deleted.
> In the same file, the reference to DistributedSystem javadocs should be
> changed to refer to this class:
> {{org.apache.geode.distributed.ConfigurationProperties}}
> {{ConfigurationProperties}} also defines constants for each property name so
> that applications can use them instead of embedding string constants in their
> code. This has the benefit of avoiding typing mistakes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2258) fix doc typos for setting properties
Karen Smoler Miller created GEODE-2258:
--
Summary: fix doc typos for setting properties
Key: GEODE-2258
URL: https://issues.apache.org/jira/browse/GEODE-2258
Project: Geode
Issue Type: Bug
Reporter: Karen Smoler Miller
In file
{{http://gemfire.docs.pivotal.io/geode/basic_config/gemfire_properties/setting_distributed_properties.html}},
this text is wrong:
{{System.setProperty("DgemfirePropertyFile", "gfTest");}}
{{System.setProperty("Dgemfire.mcast-port", "10999");}}
The capital D at the beginning of each property name should be deleted.
In the same file, the reference to DistributedSystem javadocs should be changed
to refer to this class:
{{org.apache.geode.distributed.ConfigurationProperties}}
{{ConfigurationProperties}} also defines constants for each property name so
that applications can use them instead of embedding string constants in their
code. This has the benefit of avoiding typing mistakes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2252) Remove doc reference to too-old vmware guide
[ https://issues.apache.org/jira/browse/GEODE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2252: --- Fix Version/s: 1.1.0 > Remove doc reference to too-old vmware guide > > > Key: GEODE-2252 > URL: https://issues.apache.org/jira/browse/GEODE-2252 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller > Fix For: 1.1.0 > > > The docs section on Performance Tuning discusses running on vSphere. That > documentation may still be relevant, but the end of the section has a link to > very old and no-longer-relevant documentation. So, remove the link. > At the same time, update the Geode book subnav to not reference subsections > (within this performance tuning subsection) distinguished by anchors, as this > causes the subnav to misbehave. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2252) Remove doc reference to too-old vmware guide
[ https://issues.apache.org/jira/browse/GEODE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2252. Resolution: Fixed Assignee: Karen Smoler Miller > Remove doc reference to too-old vmware guide > > > Key: GEODE-2252 > URL: https://issues.apache.org/jira/browse/GEODE-2252 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.1.0 > > > The docs section on Performance Tuning discusses running on vSphere. That > documentation may still be relevant, but the end of the section has a link to > very old and no-longer-relevant documentation. So, remove the link. > At the same time, update the Geode book subnav to not reference subsections > (within this performance tuning subsection) distinguished by anchors, as this > causes the subnav to misbehave. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2032) gfsh show metrics --member should list "offheap" category
[ https://issues.apache.org/jira/browse/GEODE-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-2032. Resolution: Duplicate > gfsh show metrics --member should list "offheap" category > - > > Key: GEODE-2032 > URL: https://issues.apache.org/jira/browse/GEODE-2032 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Darrel Schneider > > http://geode.docs.pivotal.io/docs/tools_modules/gfsh/command-pages/show.html#topic_6EB786C63AEB46179EEE8FA18624295A > lists all the member metric categories like so: > member specified: member, jvm, region, serialization, communication, > function, transaction, diskstore, lock, eviction, distribution > I should also list "offheap". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2153) PostProcessor security
[
https://issues.apache.org/jira/browse/GEODE-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15781594#comment-15781594
]
Karen Smoler Miller commented on GEODE-2153:
Should we open an new ticket to rename the associated
{{security-post-processor}} property? It defines the implementation for the
PostProcessor interface, and its name implies that it implements something
having to do with security.
> PostProcessor security
> --
>
> Key: GEODE-2153
> URL: https://issues.apache.org/jira/browse/GEODE-2153
> Project: Geode
> Issue Type: Improvement
> Components: security
>Reporter: Jared Stewart
>
> I have started a server and locator using the sample RedactingPostProcessor
> implementation. I created a /customers region and inserted a Customer:
> {code}
> Region region = connectToRegion("customers");
> Customer customer = new Customer(1L, "FirstName", "LastName", "123-456-7890");
> region.put("galen", customer);
> {code}
> The following query and get operation show our customer's SSN getting
> redacted as expected:
> {code}
> Customer customerFromGet = region.get("galen");
> //{ type = com.jaredjstewart.Customer, customerId = 1, firstName = FirstName,
> lastName = LastName, ssn = ** }
> Object customerFromQuery = queryService.newQuery("select * from
> /customers").execute();
> //{ type = com.jaredjstewart.Customer, customerId = 1, firstName = FirstName,
> lastName = LastName, ssn = ** }
> {code}
> However, it is possible to leak information by accessing the field which is
> supposed to be redacted in a where clause:
> {code}
> Object customer = queryService.newQuery("select c from /customers c
> where c.socialSecurityNumber='123-456-7890'").execute();
> //this redacts but still leaks the vital information
> {code}
> It is also possible to query the field directly:
> {code}
> Object customerSSN = queryService.newQuery("select c.socialSecurityNumber
> from /customers c").execute();
> //[123-456-7890]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-2231) Create new partitioning example
[ https://issues.apache.org/jira/browse/GEODE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2231: -- Assignee: Karen Smoler Miller > Create new partitioning example > --- > > Key: GEODE-2231 > URL: https://issues.apache.org/jira/browse/GEODE-2231 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > Add a new example to the geode-examples that demonstrates partitioning. > The example will use the same structure as the replicated example, starting 2 > servers that host a partitioned region (with no redundant copies). Run the > producer to populate the region. Run the consumer to see the contents of the > region. Then, stop one of the servers and run the consumer again to notice > that only roughly half (with 2 servers and hopefully a reasonable hash) of > the entries are present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2231) Create new partitioning example
Karen Smoler Miller created GEODE-2231: -- Summary: Create new partitioning example Key: GEODE-2231 URL: https://issues.apache.org/jira/browse/GEODE-2231 Project: Geode Issue Type: Improvement Components: docs Reporter: Karen Smoler Miller Add a new example to the geode-examples that demonstrates partitioning. The example will use the same structure as the replicated example, starting 2 servers that host a partitioned region (with no redundant copies). Run the producer to populate the region. Run the consumer to see the contents of the region. Then, stop one of the servers and run the consumer again to notice that only roughly half (with 2 servers and hopefully a reasonable hash) of the entries are present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (GEODE-2208) Document limitation of transactions on mixed region types
[ https://issues.apache.org/jira/browse/GEODE-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15745837#comment-15745837 ] Karen Smoler Miller edited comment on GEODE-2208 at 12/13/16 9:42 PM: -- Since I'm already touching the section on transactions, I'm also going to fix a minor issue with the navigation links. The two subsections "About Transactions" and "Types of Transactions" are in the same file, and the subnav does not handle this case well. So, I will collapse the 2 subsections into 1. Subsections under headings Developing -> Transactions ->How Geode Cache Transactions Work -> Transactions by Region Type -> Transactions and Partitioned Regions also have a subnav/markdown problem, so fixing this as well. was (Author: karensmolermiller): Since I'm already touching the section on transactions, I'm also going to fix a minor issue with the navigation links. The two subsections "About Transactions" and "Types of Transactions" are in the same file, and the subnav does not handle this case well. So, I will collapse the 2 subsections into 1. > Document limitation of transactions on mixed region types > - > > Key: GEODE-2208 > URL: https://issues.apache.org/jira/browse/GEODE-2208 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > For transactions that run on a mix of replicated and partitioned regions, the > first operation needs to be to a partitioned region. This sets/fixes the > host where subsequent operations will run, and it will be where data is > colocated if there are multiple partitioned regions involved. If the first > operation is to the replicated region, then the host set may be one that is > not where the colocated data is, leading to data not colocated exceptions. > This limitation needs to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2208) Document limitation of transactions on mixed region types
[ https://issues.apache.org/jira/browse/GEODE-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2208: -- Assignee: Karen Smoler Miller (was: Mark Bretl) > Document limitation of transactions on mixed region types > - > > Key: GEODE-2208 > URL: https://issues.apache.org/jira/browse/GEODE-2208 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > For transactions that run on a mix of replicated and partitioned regions, the > first operation needs to be to a partitioned region. This sets/fixes the > host where subsequent operations will run, and it will be where data is > colocated if there are multiple partitioned regions involved. If the first > operation is to the replicated region, then the host set may be one that is > not where the colocated data is, leading to data not colocated exceptions. > This limitation needs to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2208) Document limitation of transactions on mixed region types
Karen Smoler Miller created GEODE-2208: -- Summary: Document limitation of transactions on mixed region types Key: GEODE-2208 URL: https://issues.apache.org/jira/browse/GEODE-2208 Project: Geode Issue Type: Improvement Components: docs Reporter: Karen Smoler Miller Assignee: Mark Bretl For transactions that run on a mix of replicated and partitioned regions, the first operation needs to be to a partitioned region. This sets/fixes the host where subsequent operations will run, and it will be where data is colocated if there are multiple partitioned regions involved. If the first operation is to the replicated region, then the host set may be one that is not where the colocated data is, leading to data not colocated exceptions. This limitation needs to be documented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
