Re: Index on Region

[John Blum]

Well, the way I handle this in *Spring Data for Apache Geode* is, and to
*Kirk's* point, the schema (XSD) version matches the SDG version.  I.e. in
SDG 2.0.0 [1] there is a spring-geode-2.0.0.xsd, and in SDG 2.1.0 [2] there
now exists a spring-geode-2.1.0.xsd.

So, you could have a cache-1.1.xsd, or a cache-1.6.xsd to match the next
Apache Geode version.  I suggest the later.

If you parser is smart enough (which *Spring's* is), then you can also have
something like this [3], which "defaults the version", when the user does
not explicitly call out the version in an XML document instance based on
the XSD.

Food for thought,
John


[1]
https://github.com/spring-projects/spring-data-geode/tree/2.0.6.RELEASE/src/main/resources/org/springframework/data/gemfire/config
[2]
https://github.com/spring-projects/spring-data-geode/tree/2.1.0.M2/src/main/resources/org/springframework/data/gemfire/config
[3]
https://github.com/spring-projects/spring-data-geode/blob/2.1.0.M2/src/main/resources/META-INF/spring.schemas


On Tue, Apr 17, 2018 at 8:32 AM, Jinmei Liao  wrote:

> but our xsd is versioned. If user wants to use a more "correct" xsd when
> they are creating a cache.xml file, should we allow them to reference a
> cache-2.0.xsd instead of cache-1.0.xsd? (provided that 2.0 is only a washed
> down version of 1.0, nothing new added).
>
> On Tue, Apr 17, 2018 at 8:28 AM, Michael Stolz  wrote:
>
> > Correct. We can "deprecate" any time we like as long as we have provided
> an
> > alternative, but we should only "remove" on a major release.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Lead
> > Mobile: +1-631-835-4771
> > Download the new GemFire book here.
> >  > with-pivotal-gemfire>
> >
> > On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker 
> wrote:
> >
> > > Deprecation is a signal that a user should begin migrating to an
> > > alternative because that thing may be removed in a future release.
> > > Following the SemVer practice gives our users confidence that we won’t
> > > break stuff in a minor release.
> > >
> > > Anthony
> > >
> > >
> > > > On Apr 16, 2018, at 3:11 PM, Kirk Lund  wrote:
> > > >
> > > > We should probably target removal of the "deprecated" cache xsd
> > > > types/elements in Geode 2.0. I'm not sure if we can introduce
> > > cache-2.0.xsd
> > > > before Geode 2.0 or not (anyone know?).
> > > >
> > > > On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao 
> > wrote:
> > > >
> > > >> Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits.
> Would
> > > it
> > > >> make sense to start creating a cache-2.0.xsd? or better yet, a
> > > >> server-cache-2.0.xsd and a client-cache-2.0.xsd?
> > > >>
> > > >>
> > > >> On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg <
> > prhomb...@pivotal.io
> > > >
> > > >> wrote:
> > > >>
> > > >>> Some types / fields have their deprecation noted in their
> > > documentation,
> > > >>> within the  block.  Alternatively / in addition,
> > > some
> > > >>> xsd:element have the block
> > > >>>
> > > >>> 
> > > >>>  deprecated
> > > >>> 
> > > >>>
> > > >>>
> > > >>> Although I don't know if these annotations count as "visible," but
> > they
> > > >> are
> > > >>> there.
> > > >>>
> > > >>> On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao 
> > > wrote:
> > > >>>
> > >  I don't think we have a process for deprecating elements in
> > cache.xml
> > >  yet All the changes we've had so far are additions, not
> removal.
> > > 
> > >  The reason I am asking is that we are creating POJO's (started by
> > JAXB
> > > >>> tool
> > >  from xsd file) that would generate the cluster configuration xml
> > >  automatically. As long as we know there are "new" ways to do
> things,
> > > we
> > >  should have these POJO's only generate XML that's in the new
> style.
> > > 
> > >  Thanks!
> > > 
> > >  On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh 
> > > >> wrote:
> > > 
> > > > Hi Jinmei,
> > > >
> > > > I am not sure whether these elements were deprecated or not.  I
> > know
> > > >>> that
> > > > they were at one time valid and a user could specify the
> following
> > in
> > >  their
> > > > app at one point:
> > > >
> > > > 
> > > >   
> > > > 
> > > >
> > > > I believe the "new" way to do this would be:
> > > >
> > > >  > > >> expression="ID"/>
> > > >
> > > > How would deprecation for this work? Would your roll a new
> version
> > of
> > > > the new definition/scheme?
> > > >
> > > >
> > > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao 
> > > >>> wrote:
> > > >
> > > >> From the cache-1.0.xsd, we noticed that an index can have
> element
> > > >>> like
> > > >> "functional" and "primary-key", but the docs did not mention
> > > 

Re: Index on Region

[Jinmei Liao]

but our xsd is versioned. If user wants to use a more "correct" xsd when
they are creating a cache.xml file, should we allow them to reference a
cache-2.0.xsd instead of cache-1.0.xsd? (provided that 2.0 is only a washed
down version of 1.0, nothing new added).

On Tue, Apr 17, 2018 at 8:28 AM, Michael Stolz  wrote:

> Correct. We can "deprecate" any time we like as long as we have provided an
> alternative, but we should only "remove" on a major release.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771
> Download the new GemFire book here.
>  with-pivotal-gemfire>
>
> On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker  wrote:
>
> > Deprecation is a signal that a user should begin migrating to an
> > alternative because that thing may be removed in a future release.
> > Following the SemVer practice gives our users confidence that we won’t
> > break stuff in a minor release.
> >
> > Anthony
> >
> >
> > > On Apr 16, 2018, at 3:11 PM, Kirk Lund  wrote:
> > >
> > > We should probably target removal of the "deprecated" cache xsd
> > > types/elements in Geode 2.0. I'm not sure if we can introduce
> > cache-2.0.xsd
> > > before Geode 2.0 or not (anyone know?).
> > >
> > > On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao 
> wrote:
> > >
> > >> Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would
> > it
> > >> make sense to start creating a cache-2.0.xsd? or better yet, a
> > >> server-cache-2.0.xsd and a client-cache-2.0.xsd?
> > >>
> > >>
> > >> On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg <
> prhomb...@pivotal.io
> > >
> > >> wrote:
> > >>
> > >>> Some types / fields have their deprecation noted in their
> > documentation,
> > >>> within the  block.  Alternatively / in addition,
> > some
> > >>> xsd:element have the block
> > >>>
> > >>> 
> > >>>  deprecated
> > >>> 
> > >>>
> > >>>
> > >>> Although I don't know if these annotations count as "visible," but
> they
> > >> are
> > >>> there.
> > >>>
> > >>> On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao 
> > wrote:
> > >>>
> >  I don't think we have a process for deprecating elements in
> cache.xml
> >  yet All the changes we've had so far are additions, not removal.
> > 
> >  The reason I am asking is that we are creating POJO's (started by
> JAXB
> > >>> tool
> >  from xsd file) that would generate the cluster configuration xml
> >  automatically. As long as we know there are "new" ways to do things,
> > we
> >  should have these POJO's only generate XML that's in the new style.
> > 
> >  Thanks!
> > 
> >  On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh 
> > >> wrote:
> > 
> > > Hi Jinmei,
> > >
> > > I am not sure whether these elements were deprecated or not.  I
> know
> > >>> that
> > > they were at one time valid and a user could specify the following
> in
> >  their
> > > app at one point:
> > >
> > > 
> > >   
> > > 
> > >
> > > I believe the "new" way to do this would be:
> > >
> > >  > >> expression="ID"/>
> > >
> > > How would deprecation for this work? Would your roll a new version
> of
> > > the new definition/scheme?
> > >
> > >
> > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao 
> > >>> wrote:
> > >
> > >> From the cache-1.0.xsd, we noticed that an index can have element
> > >>> like
> > >> "functional" and "primary-key", but the docs did not mention
> > >> anything
> > > about
> > >> it (
> > >>
> > >> https://geode.apache.org/docs/guide/13/reference/topics/
> > > cache_xml.html#region
> > >> ).
> > >> I am wondering if these are deprecated? Would it be better for the
> > >>> the
> > > xml
> > >> created by the cluster configuration not consist any of these?
> > >>
> > >> 
> > >>  
> > >>
> > >>  
> > >>A functional type of index needs a from-clause, expression
> > >> which are mandatory.
> > >>The import string is used for specifying the type of Object
> > >>> in
> > >> the region or
> > >>the type of Object which the indexed expression evaluates
> > >> to.
> > >>  
> > >>
> > >>
> > >>   > >>> use="required"
> > > />
> > >>   >  use="required"
> > > />
> > >>   > >> use="optional"
> > >>> />
> > >>
> > >>  
> > >>
> > >>  
> > >>
> > >>  
> > >>A primary-key type of index needs a field attribute which
> > >> is
> > >> mandatory.
> > >>There should be only one or zero primary-index defined for
> > >> a
> > > region
> > >>  
> > >>
> > >>
> > >>   > >> />
> > >>
> > >>  
> > >> 
> > >>

Re: Index on Region

[Michael Stolz]

Correct. We can "deprecate" any time we like as long as we have provided an
alternative, but we should only "remove" on a major release.

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771
Download the new GemFire book here.


On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker  wrote:

> Deprecation is a signal that a user should begin migrating to an
> alternative because that thing may be removed in a future release.
> Following the SemVer practice gives our users confidence that we won’t
> break stuff in a minor release.
>
> Anthony
>
>
> > On Apr 16, 2018, at 3:11 PM, Kirk Lund  wrote:
> >
> > We should probably target removal of the "deprecated" cache xsd
> > types/elements in Geode 2.0. I'm not sure if we can introduce
> cache-2.0.xsd
> > before Geode 2.0 or not (anyone know?).
> >
> > On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao  wrote:
> >
> >> Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would
> it
> >> make sense to start creating a cache-2.0.xsd? or better yet, a
> >> server-cache-2.0.xsd and a client-cache-2.0.xsd?
> >>
> >>
> >> On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg  >
> >> wrote:
> >>
> >>> Some types / fields have their deprecation noted in their
> documentation,
> >>> within the  block.  Alternatively / in addition,
> some
> >>> xsd:element have the block
> >>>
> >>> 
> >>>  deprecated
> >>> 
> >>>
> >>>
> >>> Although I don't know if these annotations count as "visible," but they
> >> are
> >>> there.
> >>>
> >>> On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao 
> wrote:
> >>>
>  I don't think we have a process for deprecating elements in cache.xml
>  yet All the changes we've had so far are additions, not removal.
> 
>  The reason I am asking is that we are creating POJO's (started by JAXB
> >>> tool
>  from xsd file) that would generate the cluster configuration xml
>  automatically. As long as we know there are "new" ways to do things,
> we
>  should have these POJO's only generate XML that's in the new style.
> 
>  Thanks!
> 
>  On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh 
> >> wrote:
> 
> > Hi Jinmei,
> >
> > I am not sure whether these elements were deprecated or not.  I know
> >>> that
> > they were at one time valid and a user could specify the following in
>  their
> > app at one point:
> >
> > 
> >   
> > 
> >
> > I believe the "new" way to do this would be:
> >
> >  >> expression="ID"/>
> >
> > How would deprecation for this work? Would your roll a new version of
> > the new definition/scheme?
> >
> >
> > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao 
> >>> wrote:
> >
> >> From the cache-1.0.xsd, we noticed that an index can have element
> >>> like
> >> "functional" and "primary-key", but the docs did not mention
> >> anything
> > about
> >> it (
> >>
> >> https://geode.apache.org/docs/guide/13/reference/topics/
> > cache_xml.html#region
> >> ).
> >> I am wondering if these are deprecated? Would it be better for the
> >>> the
> > xml
> >> created by the cluster configuration not consist any of these?
> >>
> >> 
> >>  
> >>
> >>  
> >>A functional type of index needs a from-clause, expression
> >> which are mandatory.
> >>The import string is used for specifying the type of Object
> >>> in
> >> the region or
> >>the type of Object which the indexed expression evaluates
> >> to.
> >>  
> >>
> >>
> >>   >>> use="required"
> > />
> >>    use="required"
> > />
> >>   >> use="optional"
> >>> />
> >>
> >>  
> >>
> >>  
> >>
> >>  
> >>A primary-key type of index needs a field attribute which
> >> is
> >> mandatory.
> >>There should be only one or zero primary-index defined for
> >> a
> > region
> >>  
> >>
> >>
> >>   >> />
> >>
> >>  
> >> 
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
> 
> 
> 
>  --
>  Cheers
> 
>  Jinmei
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>

Re: Index on Region

[Jinmei Liao]

They way it works now is that our xsd, xml parser and xml generator are
disconnected. The xsd file is only used by the xml editor when editing the
xml. The parser is parsing everything allowed by xsd, but it's not
generated by xsd. The XML generated by our generator is not validated using
the xsd either. So technically, if we are only to remove
element/attributes, i.e. create a more restrictive xsd, and have our
cluster configuration generated by a "washed down version" of the xsd,
then our parser would not break at all.


On Tue, Apr 17, 2018 at 7:51 AM, Anthony Baker  wrote:

> Deprecation is a signal that a user should begin migrating to an
> alternative because that thing may be removed in a future release.
> Following the SemVer practice gives our users confidence that we won’t
> break stuff in a minor release.
>
> Anthony
>
>
> > On Apr 16, 2018, at 3:11 PM, Kirk Lund  wrote:
> >
> > We should probably target removal of the "deprecated" cache xsd
> > types/elements in Geode 2.0. I'm not sure if we can introduce
> cache-2.0.xsd
> > before Geode 2.0 or not (anyone know?).
> >
> > On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao  wrote:
> >
> >> Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would
> it
> >> make sense to start creating a cache-2.0.xsd? or better yet, a
> >> server-cache-2.0.xsd and a client-cache-2.0.xsd?
> >>
> >>
> >> On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg  >
> >> wrote:
> >>
> >>> Some types / fields have their deprecation noted in their
> documentation,
> >>> within the  block.  Alternatively / in addition,
> some
> >>> xsd:element have the block
> >>>
> >>> 
> >>>  deprecated
> >>> 
> >>>
> >>>
> >>> Although I don't know if these annotations count as "visible," but they
> >> are
> >>> there.
> >>>
> >>> On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao 
> wrote:
> >>>
>  I don't think we have a process for deprecating elements in cache.xml
>  yet All the changes we've had so far are additions, not removal.
> 
>  The reason I am asking is that we are creating POJO's (started by JAXB
> >>> tool
>  from xsd file) that would generate the cluster configuration xml
>  automatically. As long as we know there are "new" ways to do things,
> we
>  should have these POJO's only generate XML that's in the new style.
> 
>  Thanks!
> 
>  On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh 
> >> wrote:
> 
> > Hi Jinmei,
> >
> > I am not sure whether these elements were deprecated or not.  I know
> >>> that
> > they were at one time valid and a user could specify the following in
>  their
> > app at one point:
> >
> > 
> >   
> > 
> >
> > I believe the "new" way to do this would be:
> >
> >  >> expression="ID"/>
> >
> > How would deprecation for this work? Would your roll a new version of
> > the new definition/scheme?
> >
> >
> > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao 
> >>> wrote:
> >
> >> From the cache-1.0.xsd, we noticed that an index can have element
> >>> like
> >> "functional" and "primary-key", but the docs did not mention
> >> anything
> > about
> >> it (
> >>
> >> https://geode.apache.org/docs/guide/13/reference/topics/
> > cache_xml.html#region
> >> ).
> >> I am wondering if these are deprecated? Would it be better for the
> >>> the
> > xml
> >> created by the cluster configuration not consist any of these?
> >>
> >> 
> >>  
> >>
> >>  
> >>A functional type of index needs a from-clause, expression
> >> which are mandatory.
> >>The import string is used for specifying the type of Object
> >>> in
> >> the region or
> >>the type of Object which the indexed expression evaluates
> >> to.
> >>  
> >>
> >>
> >>   >>> use="required"
> > />
> >>    use="required"
> > />
> >>   >> use="optional"
> >>> />
> >>
> >>  
> >>
> >>  
> >>
> >>  
> >>A primary-key type of index needs a field attribute which
> >> is
> >> mandatory.
> >>There should be only one or zero primary-index defined for
> >> a
> > region
> >>  
> >>
> >>
> >>   >> />
> >>
> >>  
> >> 
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
> 
> 
> 
>  --
>  Cheers
> 
>  Jinmei
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>


-- 
Cheers

Jinmei

Re: Index on Region

[Kirk Lund]

We should probably target removal of the "deprecated" cache xsd
types/elements in Geode 2.0. I'm not sure if we can introduce cache-2.0.xsd
before Geode 2.0 or not (anyone know?).

On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao  wrote:

> Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would it
> make sense to start creating a cache-2.0.xsd? or better yet, a
> server-cache-2.0.xsd and a client-cache-2.0.xsd?
>
>
> On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg 
> wrote:
>
> > Some types / fields have their deprecation noted in their documentation,
> > within the  block.  Alternatively / in addition, some
> > xsd:element have the block
> >
> > 
> >   deprecated
> > 
> >
> >
> > Although I don't know if these annotations count as "visible," but they
> are
> > there.
> >
> > On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao  wrote:
> >
> > > I don't think we have a process for deprecating elements in cache.xml
> > > yet All the changes we've had so far are additions, not removal.
> > >
> > > The reason I am asking is that we are creating POJO's (started by JAXB
> > tool
> > > from xsd file) that would generate the cluster configuration xml
> > > automatically. As long as we know there are "new" ways to do things, we
> > > should have these POJO's only generate XML that's in the new style.
> > >
> > > Thanks!
> > >
> > > On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh 
> wrote:
> > >
> > > > Hi Jinmei,
> > > >
> > > > I am not sure whether these elements were deprecated or not.  I know
> > that
> > > > they were at one time valid and a user could specify the following in
> > > their
> > > > app at one point:
> > > >
> > > > 
> > > >
> > > > 
> > > >
> > > > I believe the "new" way to do this would be:
> > > >
> > > >  expression="ID"/>
> > > >
> > > > How would deprecation for this work? Would your roll a new version of
> > > > the new definition/scheme?
> > > >
> > > >
> > > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao 
> > wrote:
> > > >
> > > > > From the cache-1.0.xsd, we noticed that an index can have element
> > like
> > > > > "functional" and "primary-key", but the docs did not mention
> anything
> > > > about
> > > > > it (
> > > > >
> > > > > https://geode.apache.org/docs/guide/13/reference/topics/
> > > > cache_xml.html#region
> > > > > ).
> > > > > I am wondering if these are deprecated? Would it be better for the
> > the
> > > > xml
> > > > > created by the cluster configuration not consist any of these?
> > > > >
> > > > > 
> > > > >   
> > > > > 
> > > > >   
> > > > > A functional type of index needs a from-clause, expression
> > > > > which are mandatory.
> > > > > The import string is used for specifying the type of Object
> > in
> > > > > the region or
> > > > > the type of Object which the indexed expression evaluates
> to.
> > > > >   
> > > > > 
> > > > > 
> > > > >> use="required"
> > > > />
> > > > >> > use="required"
> > > > />
> > > > >use="optional"
> > />
> > > > > 
> > > > >   
> > > > >
> > > > >   
> > > > > 
> > > > >   
> > > > > A primary-key type of index needs a field attribute which
> is
> > > > > mandatory.
> > > > > There should be only one or zero primary-index defined for
> a
> > > > region
> > > > >   
> > > > > 
> > > > > 
> > > > >/>
> > > > > 
> > > > >   
> > > > > 
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: Index on Region

[Jinmei Liao]

Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. Would it
make sense to start creating a cache-2.0.xsd? or better yet, a
server-cache-2.0.xsd and a client-cache-2.0.xsd?


On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg 
wrote:

> Some types / fields have their deprecation noted in their documentation,
> within the  block.  Alternatively / in addition, some
> xsd:element have the block
>
> 
>   deprecated
> 
>
>
> Although I don't know if these annotations count as "visible," but they are
> there.
>
> On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao  wrote:
>
> > I don't think we have a process for deprecating elements in cache.xml
> > yet All the changes we've had so far are additions, not removal.
> >
> > The reason I am asking is that we are creating POJO's (started by JAXB
> tool
> > from xsd file) that would generate the cluster configuration xml
> > automatically. As long as we know there are "new" ways to do things, we
> > should have these POJO's only generate XML that's in the new style.
> >
> > Thanks!
> >
> > On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh  wrote:
> >
> > > Hi Jinmei,
> > >
> > > I am not sure whether these elements were deprecated or not.  I know
> that
> > > they were at one time valid and a user could specify the following in
> > their
> > > app at one point:
> > >
> > > 
> > >
> > > 
> > >
> > > I believe the "new" way to do this would be:
> > >
> > > 
> > >
> > > How would deprecation for this work? Would your roll a new version of
> > > the new definition/scheme?
> > >
> > >
> > > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao 
> wrote:
> > >
> > > > From the cache-1.0.xsd, we noticed that an index can have element
> like
> > > > "functional" and "primary-key", but the docs did not mention anything
> > > about
> > > > it (
> > > >
> > > > https://geode.apache.org/docs/guide/13/reference/topics/
> > > cache_xml.html#region
> > > > ).
> > > > I am wondering if these are deprecated? Would it be better for the
> the
> > > xml
> > > > created by the cluster configuration not consist any of these?
> > > >
> > > > 
> > > >   
> > > > 
> > > >   
> > > > A functional type of index needs a from-clause, expression
> > > > which are mandatory.
> > > > The import string is used for specifying the type of Object
> in
> > > > the region or
> > > > the type of Object which the indexed expression evaluates to.
> > > >   
> > > > 
> > > > 
> > > >use="required"
> > > />
> > > >> use="required"
> > > />
> > > >/>
> > > > 
> > > >   
> > > >
> > > >   
> > > > 
> > > >   
> > > > A primary-key type of index needs a field attribute which is
> > > > mandatory.
> > > > There should be only one or zero primary-index defined for a
> > > region
> > > >   
> > > > 
> > > > 
> > > >   
> > > > 
> > > >   
> > > > 
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > >
> > > > Jinmei
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

Re: Index on Region

[Patrick Rhomberg]

Some types / fields have their deprecation noted in their documentation,
within the  block.  Alternatively / in addition, some
xsd:element have the block


  deprecated



Although I don't know if these annotations count as "visible," but they are
there.

On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao  wrote:

> I don't think we have a process for deprecating elements in cache.xml
> yet All the changes we've had so far are additions, not removal.
>
> The reason I am asking is that we are creating POJO's (started by JAXB tool
> from xsd file) that would generate the cluster configuration xml
> automatically. As long as we know there are "new" ways to do things, we
> should have these POJO's only generate XML that's in the new style.
>
> Thanks!
>
> On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh  wrote:
>
> > Hi Jinmei,
> >
> > I am not sure whether these elements were deprecated or not.  I know that
> > they were at one time valid and a user could specify the following in
> their
> > app at one point:
> >
> > 
> >
> > 
> >
> > I believe the "new" way to do this would be:
> >
> > 
> >
> > How would deprecation for this work? Would your roll a new version of
> > the new definition/scheme?
> >
> >
> > On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao  wrote:
> >
> > > From the cache-1.0.xsd, we noticed that an index can have element like
> > > "functional" and "primary-key", but the docs did not mention anything
> > about
> > > it (
> > >
> > > https://geode.apache.org/docs/guide/13/reference/topics/
> > cache_xml.html#region
> > > ).
> > > I am wondering if these are deprecated? Would it be better for the the
> > xml
> > > created by the cluster configuration not consist any of these?
> > >
> > > 
> > >   
> > > 
> > >   
> > > A functional type of index needs a from-clause, expression
> > > which are mandatory.
> > > The import string is used for specifying the type of Object in
> > > the region or
> > > the type of Object which the indexed expression evaluates to.
> > >   
> > > 
> > > 
> > >> />
> > >use="required"
> > />
> > >   
> > > 
> > >   
> > >
> > >   
> > > 
> > >   
> > > A primary-key type of index needs a field attribute which is
> > > mandatory.
> > > There should be only one or zero primary-index defined for a
> > region
> > >   
> > > 
> > > 
> > >   
> > > 
> > >   
> > > 
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: Index on Region

[Jinmei Liao]

I don't think we have a process for deprecating elements in cache.xml
yet All the changes we've had so far are additions, not removal.

The reason I am asking is that we are creating POJO's (started by JAXB tool
from xsd file) that would generate the cluster configuration xml
automatically. As long as we know there are "new" ways to do things, we
should have these POJO's only generate XML that's in the new style.

Thanks!

On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh  wrote:

> Hi Jinmei,
>
> I am not sure whether these elements were deprecated or not.  I know that
> they were at one time valid and a user could specify the following in their
> app at one point:
>
> 
>
> 
>
> I believe the "new" way to do this would be:
>
> 
>
> How would deprecation for this work? Would your roll a new version of
> the new definition/scheme?
>
>
> On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao  wrote:
>
> > From the cache-1.0.xsd, we noticed that an index can have element like
> > "functional" and "primary-key", but the docs did not mention anything
> about
> > it (
> >
> > https://geode.apache.org/docs/guide/13/reference/topics/
> cache_xml.html#region
> > ).
> > I am wondering if these are deprecated? Would it be better for the the
> xml
> > created by the cluster configuration not consist any of these?
> >
> > 
> >   
> > 
> >   
> > A functional type of index needs a from-clause, expression
> > which are mandatory.
> > The import string is used for specifying the type of Object in
> > the region or
> > the type of Object which the indexed expression evaluates to.
> >   
> > 
> > 
> >/>
> >/>
> >   
> > 
> >   
> >
> >   
> > 
> >   
> > A primary-key type of index needs a field attribute which is
> > mandatory.
> > There should be only one or zero primary-index defined for a
> region
> >   
> > 
> > 
> >   
> > 
> >   
> > 
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

Re: Index on Region

[Jason Huynh]

Hi Jinmei,

I am not sure whether these elements were deprecated or not.  I know that
they were at one time valid and a user could specify the following in their
app at one point:


   


I believe the "new" way to do this would be:



How would deprecation for this work? Would your roll a new version of
the new definition/scheme?


On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao  wrote:

> From the cache-1.0.xsd, we noticed that an index can have element like
> "functional" and "primary-key", but the docs did not mention anything about
> it (
>
> https://geode.apache.org/docs/guide/13/reference/topics/cache_xml.html#region
> ).
> I am wondering if these are deprecated? Would it be better for the the xml
> created by the cluster configuration not consist any of these?
>
> 
>   
> 
>   
> A functional type of index needs a from-clause, expression
> which are mandatory.
> The import string is used for specifying the type of Object in
> the region or
> the type of Object which the indexed expression evaluates to.
>   
> 
> 
>   
>   
>   
> 
>   
>
>   
> 
>   
> A primary-key type of index needs a field attribute which is
> mandatory.
> There should be only one or zero primary-index defined for a region
>   
> 
> 
>   
> 
>   
> 
>
>
>
> --
> Cheers
>
> Jinmei
>

Index on Region

[Jinmei Liao]

>From the cache-1.0.xsd, we noticed that an index can have element like
"functional" and "primary-key", but the docs did not mention anything about
it (
https://geode.apache.org/docs/guide/13/reference/topics/cache_xml.html#region).
I am wondering if these are deprecated? Would it be better for the the xml
created by the cluster configuration not consist any of these?


  

  
A functional type of index needs a from-clause, expression
which are mandatory.
The import string is used for specifying the type of Object in
the region or
the type of Object which the indexed expression evaluates to.
  


  
  
  

  

  

  
A primary-key type of index needs a field attribute which is mandatory.
There should be only one or zero primary-index defined for a region
  


  

  




-- 
Cheers

Jinmei

[jira] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16033289#comment-16033289
 ] 

ASF subversion and git services commented on GEODE-3014:


Commit 335c109d5c7d1ed427b345636c0af8b6c1636f3b in geode's branch 
refs/heads/release/1.2.0 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=335c109 ]

GEODE-3014 Document server/region/Lucene index start-up sequence

This closes #554


> 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] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16033274#comment-16033274
 ] 

ASF subversion and git services commented on GEODE-3014:


Commit 8c81965bec2c75f66b829e674ee7269d1ed2a8a6 in geode's branch 
refs/heads/develop from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8c81965 ]

GEODE-3014 Document server/region/Lucene index start-up sequence

This closes #554


> 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] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16033275#comment-16033275
 ] 

ASF GitHub Bot commented on GEODE-3014:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/554


> 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] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032257#comment-16032257
 ] 

ASF GitHub Bot commented on GEODE-3014:
---

Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/554
  
+1

On Wed, May 31, 2017 at 4:24 PM, Karen Miller <notificati...@github.com>
wrote:

> @joeymcallister <https://github.com/joeymcallister> @dihardman
> <https://github.com/dihardman> @boglesby <https://github.com/boglesby>
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/554
> Commit Summary
    >
    >- GEODE-3014 Document server/region/Lucene index start-up sequence
>
> File Changes
>
>- *M* geode-docs/tools_modules/lucene_integration.html.md.erb
><https://github.com/apache/geode/pull/554/files#diff-0> (12)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/554.patch
>- https://github.com/apache/geode/pull/554.diff
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/geode/pull/554>, or mute the thread
> 
<https://github.com/notifications/unsubscribe-auth/AUMy_X8Pcb9j90no6StKZWtSP9wWaKY1ks5r_fakgaJpZM4NsURC>
> .
>



> 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] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032208#comment-16032208
 ] 

ASF GitHub Bot commented on GEODE-3014:
---

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/554
  
+1


> 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] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032193#comment-16032193
 ] 

ASF GitHub Bot commented on GEODE-3014:
---

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode/pull/554

GEODE-3014 Document server/region/Lucene index start-up sequence

@joeymcallister @dihardman @boglesby Please review.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karensmolermiller/geode feature/GEODE-3014

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/554.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #554


commit 8d1a1e68ac8b062a2cb78aa6ce232e0c0e43adce
Author: Karen Miller <kmil...@pivotal.io>
Date:   2017-05-31T23:21:27Z

GEODE-3014 Document server/region/Lucene index start-up sequence




> 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] [Assigned] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[Karen Smoler Miller (JIRA)]

 [ 
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] [Created] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-3014:


 Summary: 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


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-2553) After deleting and recreating my Lucene index and region, my Lucene query hung.

[Barry Oglesby (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barry Oglesby resolved GEODE-2553.
--
Resolution: Fixed

> After deleting and recreating my Lucene index and region, my Lucene query 
> hung.
> ---
>
> Key: GEODE-2553
> URL: https://issues.apache.org/jira/browse/GEODE-2553
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
> Attachments: server50505.log, stack.log
>
>
> While manually testing in gfsh the process of deleting Lucene indexes, 
> deleting the region, creating new indexes and a new empty region, I was able 
> to hang gfsh while doing a Lucene search on the new region with no data.
> Here are the steps I used:
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  / 
>  / /__/ / /  _/ / // /  
> /__/_/  /__/_//_/1.2.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> gfsh>start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> gfsh>create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>put --key=1 --value=value1 --region=testRegion
> gfsh>put --key=2 --value=value2 --region=testRegion
> gfsh>put --key=3 --value=value3 --region=testRegion
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>destroy lucene index --region=/testRegion --name=testIndex
> gfsh>list lucene indexes --with-stats
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> 
> gfsh>destroy lucene index --region=/testRegion
> gfsh>list lucene indexes --with-stats
> gfsh>destroy region --name=/testRegion
> gfsh>create lucene index --name=testIndex --region=testRegion 
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> The gfsh process hangs at this point.
> I'll attach the stacktrace for the server.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2553) After deleting and recreating my Lucene index and region, my Lucene query hung.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15907936#comment-15907936
 ] 

ASF subversion and git services commented on GEODE-2553:


Commit 38cf13ffbbc912f78bdacb1caf835508abe1b5e3 in geode's branch 
refs/heads/GEODE-2290 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=38cf13f ]

GEODE-2553: Closed IndexRepositories when deleting an index


> After deleting and recreating my Lucene index and region, my Lucene query 
> hung.
> ---
>
> Key: GEODE-2553
> URL: https://issues.apache.org/jira/browse/GEODE-2553
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
> Fix For: 1.2.0
>
> Attachments: server50505.log, stack.log
>
>
> While manually testing in gfsh the process of deleting Lucene indexes, 
> deleting the region, creating new indexes and a new empty region, I was able 
> to hang gfsh while doing a Lucene search on the new region with no data.
> Here are the steps I used:
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  / 
>  / /__/ / /  _/ / // /  
> /__/_/  /__/_//_/1.2.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> gfsh>start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> gfsh>create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>put --key=1 --value=value1 --region=testRegion
> gfsh>put --key=2 --value=value2 --region=testRegion
> gfsh>put --key=3 --value=value3 --region=testRegion
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>destroy lucene index --region=/testRegion --name=testIndex
> gfsh>list lucene indexes --with-stats
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> 
> gfsh>destroy lucene index --region=/testRegion
> gfsh>list lucene indexes --with-stats
> gfsh>destroy region --name=/testRegion
> gfsh>create lucene index --name=testIndex --region=testRegion 
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> The gfsh process hangs at this point.
> I'll attach the stacktrace for the server.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2553) After deleting and recreating my Lucene index and region, my Lucene query hung.

[Diane Hardman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Diane Hardman updated GEODE-2553:
-
Summary: After deleting and recreating my Lucene index and region, my 
Lucene query hung.  (was: After deleting and recreating my Lucene index and 
region, my Lucene query should be successful.)

> After deleting and recreating my Lucene index and region, my Lucene query 
> hung.
> ---
>
> Key: GEODE-2553
> URL: https://issues.apache.org/jira/browse/GEODE-2553
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
> Fix For: 1.2.0
>
> Attachments: server50505.log, stack.log
>
>
> While manually testing in gfsh the process of deleting Lucene indexes, 
> deleting the region, creating new indexes and a new empty region, I was able 
> to hang gfsh while doing a Lucene search on the new region with no data.
> Here are the steps I used:
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  / 
>  / /__/ / /  _/ / // /  
> /__/_/  /__/_//_/1.2.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> gfsh>start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> gfsh>create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>put --key=1 --value=value1 --region=testRegion
> gfsh>put --key=2 --value=value2 --region=testRegion
> gfsh>put --key=3 --value=value3 --region=testRegion
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>destroy lucene index --region=/testRegion --name=testIndex
> gfsh>list lucene indexes --with-stats
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> 
> gfsh>destroy lucene index --region=/testRegion
> gfsh>list lucene indexes --with-stats
> gfsh>destroy region --name=/testRegion
> gfsh>create lucene index --name=testIndex --region=testRegion 
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> The gfsh process hangs at this point.
> I'll attach the stacktrace for the server.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2553) After deleting and recreating my Lucene index and region, my Lucene query should be successful.

[Diane Hardman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Diane Hardman updated GEODE-2553:
-
Summary: After deleting and recreating my Lucene index and region, my 
Lucene query should be successful.  (was: Lucene search hangs on recreated 
region with no data)

> After deleting and recreating my Lucene index and region, my Lucene query 
> should be successful.
> ---
>
> Key: GEODE-2553
> URL: https://issues.apache.org/jira/browse/GEODE-2553
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
> Fix For: 1.2.0
>
> Attachments: server50505.log, stack.log
>
>
> While manually testing in gfsh the process of deleting Lucene indexes, 
> deleting the region, creating new indexes and a new empty region, I was able 
> to hang gfsh while doing a Lucene search on the new region with no data.
> Here are the steps I used:
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  / 
>  / /__/ / /  _/ / // /  
> /__/_/  /__/_//_/1.2.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> gfsh>start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> gfsh>create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>put --key=1 --value=value1 --region=testRegion
> gfsh>put --key=2 --value=value2 --region=testRegion
> gfsh>put --key=3 --value=value3 --region=testRegion
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>destroy lucene index --region=/testRegion --name=testIndex
> gfsh>list lucene indexes --with-stats
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> 
> gfsh>destroy lucene index --region=/testRegion
> gfsh>list lucene indexes --with-stats
> gfsh>destroy region --name=/testRegion
> gfsh>create lucene index --name=testIndex --region=testRegion 
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> The gfsh process hangs at this point.
> I'll attach the stacktrace for the server.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)