date:20170426

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-266) Remove deprecated ObjectSizerImpl


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

ASF GitHub Bot commented on GEODE-266:
--

Github user asfgit closed the pull request at:

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


> Remove deprecated ObjectSizerImpl
> -
>
> Key: GEODE-266
> URL: https://issues.apache.org/jira/browse/GEODE-266
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Remove the deprecated ObjectSizerImpl class. It can simply be replaced with 
> ObjectSizer.DEFAULT. It is used in some tests but should be easy to remove.



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

[GitHub] geode pull request #468: GEODE-260: Remove deprecated RemoteTransactionExcep...

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-260) Remove deprecated RemoteTransactionException

2017-04-26 Thread ASF subversion and git services (JIRA)


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

ASF GitHub Bot commented on GEODE-260:
--

Github user asfgit closed the pull request at:

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


> Remove deprecated RemoteTransactionException
> 
>
> Key: GEODE-260
> URL: https://issues.apache.org/jira/browse/GEODE-260
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> RemoteTransactionException is not used by any code so should be very easy to 
> remove.



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

[jira] [Commented] (GEODE-260) Remove deprecated RemoteTransactionException


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

ASF subversion and git services commented on GEODE-260:
---

Commit 49d9d6accae3267f3e7cb2599a6ed5b84f7f06d1 in geode's branch 
refs/heads/develop from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=49d9d6a ]

GEODE-260: Removed deprecated and not used RemoteTransactionException
This closes #468

Signed-off-by: adongre 


> Remove deprecated RemoteTransactionException
> 
>
> Key: GEODE-260
> URL: https://issues.apache.org/jira/browse/GEODE-260
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> RemoteTransactionException is not used by any code so should be very easy to 
> remove.



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

[GitHub] geode pull request #466: GEODE-255: Removed deprecated DataSerializer.regist...

2017-04-26 Thread ASF subversion and git services (JIRA)

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-255) Remove deprecated DataSerializer.register(Class,byte)


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

ASF subversion and git services commented on GEODE-255:
---

Commit 384970dabbcb8476a074b83f50052339ebba5bae in geode's branch 
refs/heads/develop from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=384970d ]

GEODE-255: Removed deprecated DataSerializer.register(Class,byte)
This closes #466

Signed-off-by: adongre 


> Remove deprecated DataSerializer.register(Class,byte)
> -
>
> Key: GEODE-255
> URL: https://issues.apache.org/jira/browse/GEODE-255
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Remove the deprecated DataSerializer.register(Class,byte) method.
> It should be simple to change all callers to DataSerializer.register(Class) 
> since the current implementation does that.



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

[jira] [Commented] (GEODE-255) Remove deprecated DataSerializer.register(Class,byte)


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

ASF GitHub Bot commented on GEODE-255:
--

Github user asfgit closed the pull request at:

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


> Remove deprecated DataSerializer.register(Class,byte)
> -
>
> Key: GEODE-255
> URL: https://issues.apache.org/jira/browse/GEODE-255
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Remove the deprecated DataSerializer.register(Class,byte) method.
> It should be simple to change all callers to DataSerializer.register(Class) 
> since the current implementation does that.



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

[GitHub] geode pull request #465: GEODE-253: Removed depreated and not used EntryNotF...

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-253) Remove deprecated EntryNotFoundInRegion

2017-04-26 Thread ASF subversion and git services (JIRA)


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

ASF GitHub Bot commented on GEODE-253:
--

Github user asfgit closed the pull request at:

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


> Remove deprecated EntryNotFoundInRegion
> ---
>
> Key: GEODE-253
> URL: https://issues.apache.org/jira/browse/GEODE-253
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The EntryNotFoundInRegion is not used at all so should be very easy to remove.



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

[jira] [Commented] (GEODE-253) Remove deprecated EntryNotFoundInRegion


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

ASF subversion and git services commented on GEODE-253:
---

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

GEODE-253: Removed depreated and not used EntryNotFoundInRegion class
This closes #465

Signed-off-by: adongre 


> Remove deprecated EntryNotFoundInRegion
> ---
>
> Key: GEODE-253
> URL: https://issues.apache.org/jira/browse/GEODE-253
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The EntryNotFoundInRegion is not used at all so should be very easy to remove.



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

[jira] [Commented] (GEODE-2681) Gfsh show missing-disk-stores command hangs when server is waiting for disk stores

2017-04-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2681:


Commit 809fd1aad30f66b724aecae7e5cbca2b9b9bf3a0 in geode's branch 
refs/heads/develop from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=809fd1a ]

GEODE-2681: prevent synchronization hang on getAnyInstance

Take advantage of recent refactoring to use the InternalCache interface API
instead of GemFireCahceImpl.


> Gfsh show missing-disk-stores command hangs when server is waiting for disk 
> stores
> --
>
> Key: GEODE-2681
> URL: https://issues.apache.org/jira/browse/GEODE-2681
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
>Assignee: Kenneth Howe
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> Similar to GEODE-2680:
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  
> When trying to show missing disk stores in a different gfsh process, this 
> command also hangs.  It is expected that this process should not be hung
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Attempt to start a separate gfsh process and run the following commands:
> 1.) connect
> 2.) show missing-disk-stores



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

Re: Simple Java Client

2017-04-26 Thread Wes Williams

Now we're getting some precision. Let's talk about the "raw" Geode
proprietary bad ass API!  Would that "raw" Geode proprietary bad ass API  "raw"
Geode proprietary bad ass API that we're talking about be centered around
the commands found here:
https://github.com/apache/geode/tree/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands

Or somewhere else?

*Wes Williams | Pivotal Advisory **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire

On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett  wrote:

> Java and its community have standards for all of these issue so why
> re-invent the wheel. The market doesn't want proprietary anymore, they want
> standards and mobility.
>
> Configuration of the server should happen through MBeans. You can wrap that
> in gfsh for command line, REST for remote web based admin, use JConsole or
> any other number of JMX based enterprise management tools. By using MBeans
> the server can easily expose new discovered services without the need to
> code specific gfsh commands, REST interfaces or APIs. There is no reason my
> SDG can't be retooled to "discover" the configuration from these MBeans as
> well rather than having to be touched every time we add or change
> something. There are tools and books already written that implementors can
> consult on MBeans. There isn't anything out there on gfsh commands.
>
> If we want to play in the Java community, especially J2EE (the other 50% of
> Java that isn't Spring), then we had better have a JSR-107 answer no matter
> what the pain is to provide it. I can pull dozens of books of the shelf
> that teach me how to effectively use a JCache, how many can I pull off the
> shelf that teach me Geode's API? How many engineers can I get applications
> form by saying "must have Geode API knowledge"? I can find people with
> JCache knowledge though. So from in implementor's perspective having
> standards is a must. Now I don't think the JSR-107 interface should be the
> root interface but rather a facade on the "raw" Geode proprietary bad ass
> API. That API should be 100% asynchronous (reactive, SEDA, whatever the
> current buzzword for asynchronous is today). Around that API we can provide
> facades for JSR 107, ConcurrentMap (our current yet not so well behaving
> API), List, Queue, etc. Maybe even JPA, JCA, etc. The thought of putting
> all those features into a single API makes my head exploded and they don't
> need to be like they are today.
>
>
>
> On Tue, Apr 25, 2017 at 8:25 PM Wes Williams  wrote:
>
> > A couple of points to interact with John's points.
> >
> > GFSH as API
> >
> > We agree that GFSH is a DSL, and a really good and useful one. We agree
> > that we don't want our API tied to GFSH syntax. I view the valuable part
> of
> > GemFire admin as the Java code underneath GFSH, or the "Commands."
> >
> > For example, to create a JAVA API to "Create Region",  why not create a
> > Java API around CreateAlterDestroyRegionCommands? In this way, GFSH and
> the
> > JAVA API share the same code. It seems too obvious yet I don't see it
> being
> > recommended.  Why not?  (Note: the hard-coded formatting would need to be
> > removed).
> >
> > Once you have the Java/GFSH/REST API as common code, you then refactor
> it.
> > What's the objection to this approach? Once you open Java API's to do
> > everything that GFSH does, then you have now unshackled the power of the
> > developer (the JAVA API) and the admin (GFSH API).
> >
> >
> > REST API
> >
> > I've found that most don't want to use the Dev REST API because it's
> > attached to a server rather than the cluster. HA?
> >
> >
> > *Wes Williams | Pivotal Advisory **Data Engineer*
> > 781.606.0325 <(781)%20606-0325>
> > http://pivotal.io/big-data/pivotal-gemfire
> >
> > On Tue, Apr 25, 2017 at 7:01 PM, Fred Krone  wrote:
> >
> > > Good feedback.
> > >
> > > This would use the new protocol.  I should have mentioned that.
> > >
> > > The original driver for this was the Region API needs either an update
> or
> > > an alternative.  Updating has a few drawbacks: Region wasn't designed
> > with
> > > open source in-mind and as Swap mentioned it is naturally tightly
> > coupled.
> > > Members of the community are already working to update Region but
> > something
> > > gets fixed and it breaks something for someone else.  I think it's much
> > > better to provide a new interface that implements the first part of JSR
> > 107
> > > (javax.cache) and get the ball rolling for the community and, perhaps,
> > over
> > > time deprecate Region (although that's not a primary objective).
> > >
> > > A Java driver will probably get built regardless just to give the new
> > > protocol some legs. That driver also needs a decent caching interface.
> > JSR
> > > 107 has already solved that part.  So let's get started on it.  If the
> > > community wants to go the whole way and continue JSR 107 implementation
> > > after that that's awesome.  Functions can also

Re: Simple Java Client

2017-04-26 Thread Jacob Barrett

Wes,

Those are almost all administrative commands and have no place on the
client API. They belong on an administrative API or as I'm arguing a series
of MBeans/JMX as it is already an established standard.

-Jake

On Wed, Apr 26, 2017 at 8:09 AM Wes Williams  wrote:

> Now we're getting some precision. Let's talk about the "raw" Geode
> proprietary bad ass API!  Would that "raw" Geode proprietary bad ass API
> "raw"
> Geode proprietary bad ass API that we're talking about be centered around
> the commands found here:
>
> https://github.com/apache/geode/tree/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands
>
> Or somewhere else?
>
> *Wes Williams | Pivotal Advisory **Data Engineer*
> 781.606.0325
> http://pivotal.io/big-data/pivotal-gemfire
>
> On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett 
> wrote:
>
> > Java and its community have standards for all of these issue so why
> > re-invent the wheel. The market doesn't want proprietary anymore, they
> want
> > standards and mobility.
> >
> > Configuration of the server should happen through MBeans. You can wrap
> that
> > in gfsh for command line, REST for remote web based admin, use JConsole
> or
> > any other number of JMX based enterprise management tools. By using
> MBeans
> > the server can easily expose new discovered services without the need to
> > code specific gfsh commands, REST interfaces or APIs. There is no reason
> my
> > SDG can't be retooled to "discover" the configuration from these MBeans
> as
> > well rather than having to be touched every time we add or change
> > something. There are tools and books already written that implementors
> can
> > consult on MBeans. There isn't anything out there on gfsh commands.
> >
> > If we want to play in the Java community, especially J2EE (the other 50%
> of
> > Java that isn't Spring), then we had better have a JSR-107 answer no
> matter
> > what the pain is to provide it. I can pull dozens of books of the shelf
> > that teach me how to effectively use a JCache, how many can I pull off
> the
> > shelf that teach me Geode's API? How many engineers can I get
> applications
> > form by saying "must have Geode API knowledge"? I can find people with
> > JCache knowledge though. So from in implementor's perspective having
> > standards is a must. Now I don't think the JSR-107 interface should be
> the
> > root interface but rather a facade on the "raw" Geode proprietary bad ass
> > API. That API should be 100% asynchronous (reactive, SEDA, whatever the
> > current buzzword for asynchronous is today). Around that API we can
> provide
> > facades for JSR 107, ConcurrentMap (our current yet not so well behaving
> > API), List, Queue, etc. Maybe even JPA, JCA, etc. The thought of putting
> > all those features into a single API makes my head exploded and they
> don't
> > need to be like they are today.
> >
> >
> >
> > On Tue, Apr 25, 2017 at 8:25 PM Wes Williams 
> wrote:
> >
> > > A couple of points to interact with John's points.
> > >
> > > GFSH as API
> > >
> > > We agree that GFSH is a DSL, and a really good and useful one. We agree
> > > that we don't want our API tied to GFSH syntax. I view the valuable
> part
> > of
> > > GemFire admin as the Java code underneath GFSH, or the "Commands."
> > >
> > > For example, to create a JAVA API to "Create Region",  why not create a
> > > Java API around CreateAlterDestroyRegionCommands? In this way, GFSH and
> > the
> > > JAVA API share the same code. It seems too obvious yet I don't see it
> > being
> > > recommended.  Why not?  (Note: the hard-coded formatting would need to
> be
> > > removed).
> > >
> > > Once you have the Java/GFSH/REST API as common code, you then refactor
> > it.
> > > What's the objection to this approach? Once you open Java API's to do
> > > everything that GFSH does, then you have now unshackled the power of
> the
> > > developer (the JAVA API) and the admin (GFSH API).
> > >
> > >
> > > REST API
> > >
> > > I've found that most don't want to use the Dev REST API because it's
> > > attached to a server rather than the cluster. HA?
> > >
> > >
> > > *Wes Williams | Pivotal Advisory **Data Engineer*
> > > 781.606.0325 <(781)%20606-0325>
> > > http://pivotal.io/big-data/pivotal-gemfire
> > >
> > > On Tue, Apr 25, 2017 at 7:01 PM, Fred Krone  wrote:
> > >
> > > > Good feedback.
> > > >
> > > > This would use the new protocol.  I should have mentioned that.
> > > >
> > > > The original driver for this was the Region API needs either an
> update
> > or
> > > > an alternative.  Updating has a few drawbacks: Region wasn't designed
> > > with
> > > > open source in-mind and as Swap mentioned it is naturally tightly
> > > coupled.
> > > > Members of the community are already working to update Region but
> > > something
> > > > gets fixed and it breaks something for someone else.  I think it's
> much
> > > > better to provide a new interface that implements the first part of
> JSR
> > > 107
> > > > (javax.cache)

[jira] [Closed] (GEODE-2813) Incorrect Error Message for REST API, Doc Doesn

2017-04-26 Thread Dave Barnes (JIRA)


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

Dave Barnes closed GEODE-2813.
--

> Incorrect Error Message for REST API, Doc Doesn
> ---
>
> Key: GEODE-2813
> URL: https://issues.apache.org/jira/browse/GEODE-2813
> Project: Geode
>  Issue Type: Bug
>Reporter: Michael Martell
>




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

[jira] [Resolved] (GEODE-2813) Incorrect Error Message for REST API, Doc Doesn

2017-04-26 Thread Dave Barnes (JIRA)


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

Dave Barnes resolved GEODE-2813.

Resolution: Duplicate

Duplicate of GEODE-2815.

> Incorrect Error Message for REST API, Doc Doesn
> ---
>
> Key: GEODE-2813
> URL: https://issues.apache.org/jira/browse/GEODE-2813
> Project: Geode
>  Issue Type: Bug
>Reporter: Michael Martell
>




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

[jira] [Commented] (GEODE-2689) If a region containing a Lucene index is created in one group and altered in another, a member in the other group will fail to start

2017-04-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2689:


Commit c8afc87b420ed55a09f131f1c69f534d89fd61c9 in geode's branch 
refs/heads/develop from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c8afc87 ]

GEODE-2689: Modified to ignore duplicate index definition


> If a region containing a Lucene index is created in one group and altered in 
> another, a member in the other group will fail to start
> 
>
> Key: GEODE-2689
> URL: https://issues.apache.org/jira/browse/GEODE-2689
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>
> Steps to reproduce:
> - create lucene index --name=full_index --region=data --field=field1
> - create region --name=data --type=PARTITION_REDUNDANT
> - alter region --name=data --cache-listener=TestCacheListener --group=group1
> At this point, the cluster config xml looks like:
> {noformat}
> [info 2017/03/15 17:04:17.375 PDT server3  tid=0x1] 
>   ***
>   Configuration for  'cluster'
>   
>   Jar files to deployed
>   
>   http://geode.apache.org/schema/cache"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" 
> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
> http://geode.apache.org/schema/cache/cache-1.0.xsd";>
>   
>data-policy="partition">
> 
>   
>   http://geode.apache.org/schema/lucene"; 
> name="full_index">
>  analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer" 
> name="field1"/>
>   
> 
>   
>   
>   ***
>   Configuration for  'group1'
>   
>   Jar files to deployed
>   
>   http://geode.apache.org/schema/cache"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" 
> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
> http://geode.apache.org/schema/cache/cache-1.0.xsd";>
>   
>data-policy="partition">
> 
> 
>   TestCacheListener
> 
>   
>   http://geode.apache.org/schema/lucene"; 
> name="full_index">
>  analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer" 
> name="field1"/>
>   
> 
>   
> {noformat}
> If a member is started in the group (group1 in this case), it will fail to 
> start with the following error:
> {noformat}
> [error 2017/03/15 17:04:19.715 PDT  tid=0x1] Lucene index already 
> exists in region
> Exception in thread "main" java.lang.IllegalArgumentException: Lucene index 
> already exists in region
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.registerDefinedIndex(LuceneServiceImpl.java:201)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.createIndex(LuceneServiceImpl.java:154)
>   at 
> org.apache.geode.cache.lucene.internal.xml.LuceneIndexCreation.beforeCreate(LuceneIndexCreation.java:85)
>   at 
> org.apache.geode.internal.cache.extension.SimpleExtensionPoint.beforeCreate(SimpleExtensionPoint.java:77)
>   at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:252)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:544)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:495)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:343)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4479)
>   at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:129)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1243)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:798)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:783)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:178)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:218)
>   at TestBase.initializeServerCache(TestBase.java:22)
>   at TestServer.main(TestServer.java:7)
> {noformat}
> I made a quick change in {{LuceneIndexCreation beforeCreate}} to just log the 
> {{IllegalArgumentExc

[jira] [Resolved] (GEODE-2689) If a region containing a Lucene index is created in one group and altered in another, a member in the other group will fail to start

2017-04-26 Thread Barry Oglesby (JIRA)


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

Barry Oglesby resolved GEODE-2689.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> If a region containing a Lucene index is created in one group and altered in 
> another, a member in the other group will fail to start
> 
>
> Key: GEODE-2689
> URL: https://issues.apache.org/jira/browse/GEODE-2689
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> Steps to reproduce:
> - create lucene index --name=full_index --region=data --field=field1
> - create region --name=data --type=PARTITION_REDUNDANT
> - alter region --name=data --cache-listener=TestCacheListener --group=group1
> At this point, the cluster config xml looks like:
> {noformat}
> [info 2017/03/15 17:04:17.375 PDT server3  tid=0x1] 
>   ***
>   Configuration for  'cluster'
>   
>   Jar files to deployed
>   
>   http://geode.apache.org/schema/cache"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" 
> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
> http://geode.apache.org/schema/cache/cache-1.0.xsd";>
>   
>data-policy="partition">
> 
>   
>   http://geode.apache.org/schema/lucene"; 
> name="full_index">
>  analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer" 
> name="field1"/>
>   
> 
>   
>   
>   ***
>   Configuration for  'group1'
>   
>   Jar files to deployed
>   
>   http://geode.apache.org/schema/cache"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; copy-on-read="false" 
> is-server="false" lock-lease="120" lock-timeout="60" search-timeout="300" 
> version="1.0" xsi:schemaLocation="http://geode.apache.org/schema/cache 
> http://geode.apache.org/schema/cache/cache-1.0.xsd";>
>   
>data-policy="partition">
> 
> 
>   TestCacheListener
> 
>   
>   http://geode.apache.org/schema/lucene"; 
> name="full_index">
>  analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer" 
> name="field1"/>
>   
> 
>   
> {noformat}
> If a member is started in the group (group1 in this case), it will fail to 
> start with the following error:
> {noformat}
> [error 2017/03/15 17:04:19.715 PDT  tid=0x1] Lucene index already 
> exists in region
> Exception in thread "main" java.lang.IllegalArgumentException: Lucene index 
> already exists in region
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.registerDefinedIndex(LuceneServiceImpl.java:201)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.createIndex(LuceneServiceImpl.java:154)
>   at 
> org.apache.geode.cache.lucene.internal.xml.LuceneIndexCreation.beforeCreate(LuceneIndexCreation.java:85)
>   at 
> org.apache.geode.internal.cache.extension.SimpleExtensionPoint.beforeCreate(SimpleExtensionPoint.java:77)
>   at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:252)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:544)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:495)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:343)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4479)
>   at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:129)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1243)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:798)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:783)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:178)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:218)
>   at TestBase.initializeServerCache(TestBase.java:22)
>   at TestServer.main(TestServer.java:7)
> {noformat}
> I made a quick change in {{LuceneIndexCreation beforeCreate}} to just log the 
> {{IllegalArgumentException}}. I'm not sure if this is good enough or not.
> {noformat}
> public void beforeCreate(Extensible> source, Cache cache) {
>   LuceneServiceImpl service = (LuceneServiceImpl) 
> LuceneServiceProvider.get(cache);
>   Analyzer analyzer = thi

Re: Review Request 58712: GEODE-2632: partial cleanup of GemFireCacheImpl

2017-04-26 Thread ASF subversion and git services (JIRA)


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58712/
---

(Updated April 26, 2017, 4:39 p.m.)


Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Ken 
Howe, and Patrick Rhomberg.


Changes
---

I have a green precheckin again. I'm going to take the first commit and push 
that, then push the second commit with changes for review issues after it 
passes precheckin too.


Bugs: GEODE-2632
https://issues.apache.org/jira/browse/GEODE-2632


Repository: geode


Description
---

Fixup GemFireCacheImpl code. Also fix some affected collaborator classes and 
tests.

* change SecurityService from static constant to final member field
* fix typos and javadocs
* narrow scope of constants, variables, methods
* remove deadcode and useless comments/javadocs
* fix misc IntelliJ warnings
* add @Override annotations
* improve some variable names
* fix (some) generics and types
* add TODOs for a couple problem areas that need further fixing


Diffs
-

  geode-core/src/main/java/org/apache/geode/CancelCriterion.java 
e4f9a41599e521ce4bfbca9538d04dcc8edaa49b 
  geode-core/src/main/java/org/apache/geode/cache/Cache.java 
bc4aa19eb99e4758512934c9b9c43bb18d4c20d8 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyCache.java 
76306f51fc9479c7d9acaa28022ed908b674b7c0 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryMonitor.java
 d6acfbfc769af1cddd247dc0c3584cef00ea6f28 
  geode-core/src/main/java/org/apache/geode/distributed/internal/DM.java 
328a4f8265e54483c6bf34c2ad967f483661f155 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 2ae86e65188b02ec6b8cbddc49ccbc73c55bfad1 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 987e4911272ba6c37046d8e39a1187b71556736d 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/LonerDistributionManager.java
 af4e674cf3c8c58ff23ae2e9ea620b94c81ce81b 
  geode-core/src/main/java/org/apache/geode/internal/cache/DistTXState.java 
6df26233417ea617e31d1928081c0719e26efd99 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
56243e1b544f5958204e64c2ca391003aa1fd098 
  geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
709308b57da847845ef9319bece18ebe9f25e569 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
45035d725241d60cbf6ed4f5417971c967925e86 
  
geode-core/src/main/java/org/apache/geode/internal/cache/execute/util/FindRestEnabledServersFunction.java
 5da63adae8f3c0be4c2548034598d566efc517aa 
  
geode-core/src/main/java/org/apache/geode/internal/cache/persistence/PersistenceAdvisorImpl.java
 7e30141c63a446852eea67aa4594241fca362668 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
 a5f0fc2bc7cf4250565aa8dd139004890b8da07d 
  
geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBeanBridge.java
 d6a1efa73028e1b9514db67d2e3a4b564abee632 
  geode-core/src/test/java/org/apache/geode/TXJUnitTest.java 
54d9e503f2645d045487cea51011143602764f62 
  geode-core/src/test/java/org/apache/geode/TXWriterTestCase.java 
987f22f688ca695a8b37eacf239c69c329bb3b3b 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/ResourceManagerWithQueryMonitorDUnitTest.java
 903b2123097bac83045d887050f7eb955b27e3cd 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/NewDeclarativeIndexCreationJUnitTest.java
 8a0f31cc87aa18b7b0928ab0e02405fd3ad75a7f 
  geode-core/src/test/java/org/apache/geode/disttx/DistTXDebugDUnitTest.java 
0d2f2b6f41e1b1dd829a41472206d0ccb6589a5e 
  geode-core/src/test/java/org/apache/geode/disttx/DistTXJUnitTest.java 
8abccc6c1ab447ffbd77379d7cf3d1c32905728e 
  
geode-core/src/test/java/org/apache/geode/disttx/DistTXPersistentDebugDUnitTest.java
 5753f5c28de31353cdfb5235a981c1c9a88d75bd 
  geode-core/src/test/java/org/apache/geode/disttx/DistTXWriterJUnitTest.java 
0a61b1f258d090090321c9ccff1a25781da7c8d1 
  
geode-core/src/test/java/org/apache/geode/disttx/DistTXWriterOOMEJUnitTest.java 
b99d3fd25cdac5f1862927d098d9d6381894510e 
  
geode-core/src/test/java/org/apache/geode/disttx/DistributedTransactionDUnitTest.java
 54715659a389c01b1b4b3fa79642d68f00b52b48 
  geode-core/src/test/java/org/apache/geode/disttx/PRDistTXJUnitTest.java 
f27c0993a872b9879f5ee93b577939ee2b6919d9 
  geode-core/src/test/java/org/apache/geode/internal/cache/PRTXJUnitTest.java 
d2bad641a47f68edb22da0f89a04c462ab48cd33 
  
geode-core/src/test/java/org/apache/geode/internal/cache/wan/parallel/ParallelQueueRemovalMessageJUnitTest.java
 d57ce125b9498f6439dbd0b13c72c67db6badb30 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceImpl.java
 570c06c5a4266b84c73e774bc3a021b39fa37b29 
  
geode-cq/src/test/j

Re: Simple Java Client

2017-04-26 Thread William Markito Oliveira

This is an awesome discussion and Jake's hitting all the right notes about
why JCache is a good idea! I've fought that fight in the past and lost it
but I'm happy to see it coming back...

What's really nice about Geode is that the functionalities and capabilities
are all there, they're just not that well exposed, known by others or
obscured by some decisions that doesn't apply anymore.

It's the same conversation about monitoring and statistics...  All the
capability is there with JMX and Stats, but using an unknown custom format
or tool to display that data makes it not very appealing for OSS and
enterprise users that need workarounds and hacks to integrate with common
monitoring tools.

Refactoring API Client APIs, documentation and implementation of a new
Protocol, Reactive APIs, better integration with standard monitoring tools
-  Sounds like good points for a 2.0 roadmap IMHO.


On Wed, Apr 26, 2017 at 10:28 AM, Jacob Barrett  wrote:

> Wes,
>
> Those are almost all administrative commands and have no place on the
> client API. They belong on an administrative API or as I'm arguing a series
> of MBeans/JMX as it is already an established standard.
>
> -Jake
>
> On Wed, Apr 26, 2017 at 8:09 AM Wes Williams  wrote:
>
> > Now we're getting some precision. Let's talk about the "raw" Geode
> > proprietary bad ass API!  Would that "raw" Geode proprietary bad ass API
> > "raw"
> > Geode proprietary bad ass API that we're talking about be centered around
> > the commands found here:
> >
> > https://github.com/apache/geode/tree/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/cli/commands
> >
> > Or somewhere else?
> >
> > *Wes Williams | Pivotal Advisory **Data Engineer*
> > 781.606.0325
> > http://pivotal.io/big-data/pivotal-gemfire
> >
> > On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett 
> > wrote:
> >
> > > Java and its community have standards for all of these issue so why
> > > re-invent the wheel. The market doesn't want proprietary anymore, they
> > want
> > > standards and mobility.
> > >
> > > Configuration of the server should happen through MBeans. You can wrap
> > that
> > > in gfsh for command line, REST for remote web based admin, use JConsole
> > or
> > > any other number of JMX based enterprise management tools. By using
> > MBeans
> > > the server can easily expose new discovered services without the need
> to
> > > code specific gfsh commands, REST interfaces or APIs. There is no
> reason
> > my
> > > SDG can't be retooled to "discover" the configuration from these MBeans
> > as
> > > well rather than having to be touched every time we add or change
> > > something. There are tools and books already written that implementors
> > can
> > > consult on MBeans. There isn't anything out there on gfsh commands.
> > >
> > > If we want to play in the Java community, especially J2EE (the other
> 50%
> > of
> > > Java that isn't Spring), then we had better have a JSR-107 answer no
> > matter
> > > what the pain is to provide it. I can pull dozens of books of the shelf
> > > that teach me how to effectively use a JCache, how many can I pull off
> > the
> > > shelf that teach me Geode's API? How many engineers can I get
> > applications
> > > form by saying "must have Geode API knowledge"? I can find people with
> > > JCache knowledge though. So from in implementor's perspective having
> > > standards is a must. Now I don't think the JSR-107 interface should be
> > the
> > > root interface but rather a facade on the "raw" Geode proprietary bad
> ass
> > > API. That API should be 100% asynchronous (reactive, SEDA, whatever the
> > > current buzzword for asynchronous is today). Around that API we can
> > provide
> > > facades for JSR 107, ConcurrentMap (our current yet not so well
> behaving
> > > API), List, Queue, etc. Maybe even JPA, JCA, etc. The thought of
> putting
> > > all those features into a single API makes my head exploded and they
> > don't
> > > need to be like they are today.
> > >
> > >
> > >
> > > On Tue, Apr 25, 2017 at 8:25 PM Wes Williams 
> > wrote:
> > >
> > > > A couple of points to interact with John's points.
> > > >
> > > > GFSH as API
> > > >
> > > > We agree that GFSH is a DSL, and a really good and useful one. We
> agree
> > > > that we don't want our API tied to GFSH syntax. I view the valuable
> > part
> > > of
> > > > GemFire admin as the Java code underneath GFSH, or the "Commands."
> > > >
> > > > For example, to create a JAVA API to "Create Region",  why not
> create a
> > > > Java API around CreateAlterDestroyRegionCommands? In this way, GFSH
> and
> > > the
> > > > JAVA API share the same code. It seems too obvious yet I don't see it
> > > being
> > > > recommended.  Why not?  (Note: the hard-coded formatting would need
> to
> > be
> > > > removed).
> > > >
> > > > Once you have the Java/GFSH/REST API as common code, you then
> refactor
> > > it.
> > > > What's the objection to this approach? Once you open Java API's to do
> > > > everythin

[jira] [Assigned] (GEODE-2661) CacheListener gets invoked when an non-existent entry is removed using removeAll

2017-04-26 Thread Lynn Gallinat (JIRA)


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

Lynn Gallinat reassigned GEODE-2661:


Assignee: Lynn Gallinat

> CacheListener gets invoked when an non-existent entry is removed using 
> removeAll
> 
>
> Key: GEODE-2661
> URL: https://issues.apache.org/jira/browse/GEODE-2661
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Lynn Gallinat
>  Labels: storage_2
>
> When a non-existing entry is removed using removeAll from PartitionedRegion 
> (need to verify this on replicated), the CacheListener's aftrerDestroy 
> callback method gets invoked. The afterDestroy should not be invoked for 
> entry which is not present.
> How to reproduce.
> region.put (k1, v1)
> region.put (k2, v2)
> List keys= Arrays.asList("k1", "k2", "k8");
> region.removeAll(l);
> The afterDestroy call back will be invoked for k8.



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

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements


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

ASF subversion and git services commented on GEODE-2632:


Commit ba2a2d2ceebd7f69eb04824d4fda6cb3ea8c16f5 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ba2a2d2 ]

GEODE-2632: cleanup GemFireCacheImpl

* change SecurityService from static constant to final member field
* fix typos and javadocs
* narrow scope of constants, variables, methods
* remove deadcode and useless comments/javadocs
* fix misc IntelliJ warnings
* add @Override annotations
* improve some variable names
* fix (some) generics and types
* add TODOs for a couple problem areas that need further fixing


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[GitHub] geode pull request #479: GEM-1331: AEQ created before the user region

GitHub user nabarunnag opened a pull request:

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

GEM-1331: AEQ created before the user region

Potential reviewers
@gesterzhou @upthewaterspout @jhuynh1 @ladyVader 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2828

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

https://github.com/apache/geode/pull/479.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 #479


commit 01e70078cec53536807b0e85dd30fca7ad790de2
Author: nabarun 
Date:   2017-04-26T01:20:37Z

GEODE-2828: AEQ being created before the user region




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Review Request 58742: GEODE-2632: minor fixes from code review

2017-04-26 Thread ASF subversion and git services (JIRA)


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58742/
---

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


Bugs: GEODE-2632
https://issues.apache.org/jira/browse/GEODE-2632


Repository: geode


Description
---

Apply fixes for issues from code review. Add TODO comments for larger issues.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 69203117da71e80c753338b048e93de0f6859443 
  geode-core/src/main/java/org/apache/geode/internal/cache/DistTXState.java 
226ffa6cfa3636437011ed41ceadf69b08155a70 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
74ec96c23076b88d009583a5cb778e147b829c09 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/NewDeclarativeIndexCreationJUnitTest.java
 e7f5c08cb3451e82dc1d3b23d777665b8fd05884 


Diff: https://reviews.apache.org/r/58742/diff/1/


Testing
---

precheckin in progress


Thanks,

Kirk Lund

Re: Simple Java Client

2017-04-26 Thread Anilkumar Gingade

The conservation on this thread is getting more focused on adopting JCache
(JSR107) standard...

Fred started this conversation to see if some of the admin APIs can be
supported as part of Java API, to help devs who wants to combine both admin
and business logic in the same application...

Currently Geode has separated admin/configuration tasks into cache.xml and
gfsh (as with traditional database tools)

For the use-cases asking for admin apis in java:
- What is preventing them to use gfsh/cache.xml
- Will the project/wrapper similar to what Wes has built, works for those
use-cases
- If spring supports these apis, can they use it.
- Can these requirement be satisfied by having wrapper or additional APIs
in the existing geode java/native clients.

Based on the discussion here on this thread, there is more inclination
towards solving this through JSR support, which may take longer time and
investment...

-Anil.












On Wed, Apr 26, 2017 at 9:41 AM, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> This is an awesome discussion and Jake's hitting all the right notes about
> why JCache is a good idea! I've fought that fight in the past and lost it
> but I'm happy to see it coming back...
>
> What's really nice about Geode is that the functionalities and capabilities
> are all there, they're just not that well exposed, known by others or
> obscured by some decisions that doesn't apply anymore.
>
> It's the same conversation about monitoring and statistics...  All the
> capability is there with JMX and Stats, but using an unknown custom format
> or tool to display that data makes it not very appealing for OSS and
> enterprise users that need workarounds and hacks to integrate with common
> monitoring tools.
>
> Refactoring API Client APIs, documentation and implementation of a new
> Protocol, Reactive APIs, better integration with standard monitoring tools
> -  Sounds like good points for a 2.0 roadmap IMHO.
>
>
> On Wed, Apr 26, 2017 at 10:28 AM, Jacob Barrett 
> wrote:
>
> > Wes,
> >
> > Those are almost all administrative commands and have no place on the
> > client API. They belong on an administrative API or as I'm arguing a
> series
> > of MBeans/JMX as it is already an established standard.
> >
> > -Jake
> >
> > On Wed, Apr 26, 2017 at 8:09 AM Wes Williams 
> wrote:
> >
> > > Now we're getting some precision. Let's talk about the "raw" Geode
> > > proprietary bad ass API!  Would that "raw" Geode proprietary bad ass
> API
> > > "raw"
> > > Geode proprietary bad ass API that we're talking about be centered
> around
> > > the commands found here:
> > >
> > > https://github.com/apache/geode/tree/rel/v1.1.1/geode-
> > core/src/main/java/org/apache/geode/management/internal/cli/commands
> > >
> > > Or somewhere else?
> > >
> > > *Wes Williams | Pivotal Advisory **Data Engineer*
> > > 781.606.0325
> > > http://pivotal.io/big-data/pivotal-gemfire
> > >
> > > On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett 
> > > wrote:
> > >
> > > > Java and its community have standards for all of these issue so why
> > > > re-invent the wheel. The market doesn't want proprietary anymore,
> they
> > > want
> > > > standards and mobility.
> > > >
> > > > Configuration of the server should happen through MBeans. You can
> wrap
> > > that
> > > > in gfsh for command line, REST for remote web based admin, use
> JConsole
> > > or
> > > > any other number of JMX based enterprise management tools. By using
> > > MBeans
> > > > the server can easily expose new discovered services without the need
> > to
> > > > code specific gfsh commands, REST interfaces or APIs. There is no
> > reason
> > > my
> > > > SDG can't be retooled to "discover" the configuration from these
> MBeans
> > > as
> > > > well rather than having to be touched every time we add or change
> > > > something. There are tools and books already written that
> implementors
> > > can
> > > > consult on MBeans. There isn't anything out there on gfsh commands.
> > > >
> > > > If we want to play in the Java community, especially J2EE (the other
> > 50%
> > > of
> > > > Java that isn't Spring), then we had better have a JSR-107 answer no
> > > matter
> > > > what the pain is to provide it. I can pull dozens of books of the
> shelf
> > > > that teach me how to effectively use a JCache, how many can I pull
> off
> > > the
> > > > shelf that teach me Geode's API? How many engineers can I get
> > > applications
> > > > form by saying "must have Geode API knowledge"? I can find people
> with
> > > > JCache knowledge though. So from in implementor's perspective having
> > > > standards is a must. Now I don't think the JSR-107 interface should
> be
> > > the
> > > > root interface but rather a facade on the "raw" Geode proprietary bad
> > ass
> > > > API. That API should be 100% asynchronous (reactive, SEDA, whatever
> the
> > > > current buzzword for asynchronous is today). Around that API we can
> > > provide
> > > > facades for JSR 107, ConcurrentMap (our c

Re: Review Request 58742: GEODE-2632: minor fixes from code review

2017-04-26 Thread Jinmei Liao


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58742/#review173065
---




geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
Line 2411 (original), 2412 (patched)


I know this is the original logic, but why we would do something like this:

if (cache==this), return null?


- Jinmei Liao


On April 26, 2017, 5:17 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58742/
> ---
> 
> (Updated April 26, 2017, 5:17 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Apply fixes for issues from code review. Add TODO comments for larger issues.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  69203117da71e80c753338b048e93de0f6859443 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DistTXState.java 
> 226ffa6cfa3636437011ed41ceadf69b08155a70 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  74ec96c23076b88d009583a5cb778e147b829c09 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/NewDeclarativeIndexCreationJUnitTest.java
>  e7f5c08cb3451e82dc1d3b23d777665b8fd05884 
> 
> 
> Diff: https://reviews.apache.org/r/58742/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58742: GEODE-2632: minor fixes from code review

2017-04-26 Thread Jinmei Liao


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58742/#review173066
---


Ship it!




Ship It!

- Jinmei Liao


On April 26, 2017, 5:17 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58742/
> ---
> 
> (Updated April 26, 2017, 5:17 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Apply fixes for issues from code review. Add TODO comments for larger issues.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  69203117da71e80c753338b048e93de0f6859443 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DistTXState.java 
> 226ffa6cfa3636437011ed41ceadf69b08155a70 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  74ec96c23076b88d009583a5cb778e147b829c09 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/NewDeclarativeIndexCreationJUnitTest.java
>  e7f5c08cb3451e82dc1d3b23d777665b8fd05884 
> 
> 
> Diff: https://reviews.apache.org/r/58742/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements


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

ASF subversion and git services commented on GEODE-2632:


Commit 42a7d5f5d96d2a804f8dfaecf54f5344e078a628 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=42a7d5f ]

GEODE-2632: fix ParallelQueueRemovalMessageJUnitTest

Fakes.cache() mocks GemFireCacheImpl without specifying a "when"
for getRegion(String). When that method is final, Mockito can't
override it, so it ends up calling getRegion(String, boolean)
which is overridden by the test. When it's non-final Mockito
overrides it but the test doesn't specify a "when" so the
getRegion(String) method becomes a no-op.

This change restores final on getRegion(String) and removes
@Ignore from the test.


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[jira] [Commented] (GEODE-2825) Lucene query may stackoverflow if enough function execution retries are executed

2017-04-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2825:


Commit fb01b37ce8b7acda184daabc40de969a15c933c4 in geode's branch 
refs/heads/feature/GEODE-2825 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fb01b37 ]

GEODE-2825: Lucene query waits for defined index to be created

* If an index is in a defined state but not yet created, the
  query will now wait until the index is created or no longer
  defined.  Instead of throwing an exception and possibly
  getting a stack overflow


> Lucene query may stackoverflow if enough function execution retries are 
> executed
> 
>
> Key: GEODE-2825
> URL: https://issues.apache.org/jira/browse/GEODE-2825
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> It is possible that a LuceneQueryFunction fails to obtain the lucene index, 
> this will cause a retry.  If this occurs enough, a stack overflow will occur 
> based on the way the function execution code is currently written.
> Instead we can detect if the index has been defined, if so, wait until the 
> index is created.  This will cause the query to block/wait until the index is 
> ready.  It is possible to get stuck in a loop like this, but this scenario 
> should only occur when an index is being created but has yet to complete.



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

Re: Review Request 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.

2017-04-26 Thread Patrick Rhomberg



> On April 25, 2017, 9:10 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
> > Line 301 (original), 317 (patched)
> > 
> >
> > Should probably lower this below FATAL. WARN might be a good log level.
> > 
> > I think we've generally said that FATAL means the cache server is DOA 
> > and cannot recover or may lose data.

What do you think about using ERROR, since the command in this case will not 
execute as expected?


- Patrick


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58682/#review172973
---


On April 24, 2017, 8:06 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58682/
> ---
> 
> (Updated April 24, 2017, 8:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added unittests to capture failing behavior.
> 
> Corrected buildTable shifting columns when adding values with additional keys.
> 
> 
> Refactoring of DataCommandResult and DataCommandFunction
> 
> --
> 
> The majority of changes to DataCommandFunction and DataCommandResult are 
> refactoring.  Two ignored exceptions have been explicitly noted in the logger.
> 
> - In DataCommandFunction:423, there's an empty if block.  I imagine I should 
> remove that, since empty code is a waste.  Looking for it, I couldn't find 
> the comment-hinted separate method, though. Anyone familiar with this corner 
> of the code know if that actuall happens?
> 
> - Qualitative changes are in DataCommandResult.buildTable.  Items in the 
> table are scanned to build an agggregate key set, and those items missing any 
> of these keys are padded with `MISSING_VALUE`.
> 
> - I moved some of the more cumbersome blocks of code to subfunctions, but may 
> have done this more than necessary.  Opinions?
> 
> - Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive 
> development / note the bug in GEODE-2662.  Are there additional tests that 
> would fit naturally in this file?
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle f07444a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  6324b5c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  423d781 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  bb77466 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
>  e72654e 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
>  1af6261 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  0e65354 
> 
> 
> Diff: https://reviews.apache.org/r/58682/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin currently running.
> 
> DistributedTest still pending.  All others returned green.
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

ASF review board down?

I'm unable to submit any review board reviews on https://reviews.apache.org/.
I was able to submit a review an hour or so ago, but now I get this cryptic
message:

"fatal: git cat-file: could not get object info
Line undefined: undefined"

Is anyone else still able to submit a review?

The diff looks good to me and I've tried another diff with the same results.

Re: Review Request 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.

2017-04-26 Thread Patrick Rhomberg

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58682/
---

(Updated April 26, 2017, 6:25 p.m.)

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, and
Swapnil Bawaskar.

Repository: geode

Description
---

Added unittests to capture failing behavior.

Corrected buildTable shifting columns when adding values with additional keys.

Refactoring of DataCommandResult and DataCommandFunction

The majority of changes to DataCommandFunction and DataCommandResult are
refactoring. Two ignored exceptions have been explicitly noted in the logger.

- In DataCommandFunction:423, there's an empty if block. I imagine I should
remove that, since empty code is a waste. Looking for it, I couldn't find the
comment-hinted separate method, though. Anyone familiar with this corner of the
code know if that actuall happens?

- Qualitative changes are in DataCommandResult.buildTable. Items in the table
are scanned to build an agggregate key set, and those items missing any of
these keys are padded with `MISSING_VALUE`.

- I moved some of the more cumbersome blocks of code to subfunctions, but may
have done this more than necessary. Opinions?

- Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive
development / note the bug in GEODE-2662. Are there additional tests that
would fit naturally in this file?

Diffs (updated)
-

geode-core/build.gradle f07444a

geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
6324b5c

geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
423d781

geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
bb77466

geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
e72654e

geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
1af6261

geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
PRE-CREATION

geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
ead1047

Diff: https://reviews.apache.org/r/58682/diff/4/

Changes: https://reviews.apache.org/r/58682/diff/3-4/

Testing
---

precheckin currently running.

DistributedTest still pending. All others returned green.

Thanks,

Patrick Rhomberg

ParallelQueueRemovalMessageJUnitTest

2017-04-26 Thread ASF subversion and git services (JIRA)

FYI,

I broke ParallelQueueRemovalMessageJUnitTest with a recent checkin and then
I committed a temporary fix. So it should be back to passing.

I now have a more complete fix ready to submit for review, but I'm unable
to submit new requests on https://reviews.apache.org. Not sure what's wrong
with the site.

[jira] [Commented] (GEODE-2802) TombstoneMessage can throw SerializationException when region is configured as persistent and non-persistent in cluster (in different nodes).


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

ASF subversion and git services commented on GEODE-2802:


Commit 9887cfd5ca2e0a65f2ebe576060b92c0de91fa30 in geode's branch 
refs/heads/develop from [~agingade]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9887cfd ]

GEODE-2802 Tombstone version vector to contain only the members that generate 
the tombstone

TombstoneMessage serialization code assumes the member info in RVV to be either
membership-id or disk-id and uses this info while de-serializing.
When there is a mix of persistent and non-persistent region in the cluster
(between nodes), the above assumption will not hold good; resulting in data
serialization exception.

When there is a mix of persistent and non-persistent region, the version info
is always generated from the persistent member. While constructing the tombstone
message, even though there is no tombstone version generated on non-persistent
member, it was added into the tombstone message, resulting in mixed version
source, causing deserialization failure.


> TombstoneMessage can throw SerializationException when region is configured 
> as persistent and non-persistent in cluster (in different nodes).
> -
>
> Key: GEODE-2802
> URL: https://issues.apache.org/jira/browse/GEODE-2802
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
>  Labels: storage_2
>
> TombstoneMessage serialization code assumes the member info in RVV to be 
> either membership-id or disk-id and uses this info while de-serializing.
> When there is a mix of persistent and non-persistent region in the cluster 
> (between nodes), the above assumption will not hold good; resulting in data 
> serialization exception.
> DistributedTombstoneOperation$TombstoneMessage
> toData() {
> -
> -
>  if (persistent) {
>   DiskStoreID id = new DiskStoreID();
>   InternalDataSerializer.invokeFromData(id, in);
>   mbr = id;
> } 
> -
> -



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

[jira] [Created] (GEODE-2829) VMRegionVersionVector allows/stores DiskStoreId as its member id

2017-04-26 Thread Anilkumar Gingade (JIRA)

Anilkumar Gingade created GEODE-2829:


 Summary: VMRegionVersionVector allows/stores DiskStoreId as its 
member id
 Key: GEODE-2829
 URL: https://issues.apache.org/jira/browse/GEODE-2829
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Anilkumar Gingade


The VMRegionVersionVector is a region version vector for regions without 
persistent data. This region version vector suppose to allow the 
InternalDistributedMember as the member id, but currently it allows both 
DiskStoreId and InternalDistributedMember as member ids.

This is in relation to ticket# GEODE-2802

The issue can be reproduced by having persistent and non-persistent region in 
the cluster (same region name). 



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

Re: Review Request 58589: GEODE-1597: use Spring shell's parser and delete our own parsing code

2017-04-26 Thread Jinmei Liao


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58589/
---

(Updated April 26, 2017, 7:48 p.m.)


Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

GEODE-1597: use Spring shell's parser and delete our own parsing code

* deleted usage of jopsimple and our own parser code
* reworked help/hint

The biggest change is in GfshParser, instead of directly implement 
SpringShell's Parser, now it's just a simple wrapper around SpringShell's 
SimpleParser so that we can use spring's parsing code. The challenge is that 
SimpleParser expects the user inupt to be in the format of "command option1 
value1 option2 value2", while gfsh expects the format to be like "command 
option1=value1 option2=value2", so most of the code in GfshParser is to turn 
the input into the SimpleParser input format and then feed it into SimpleParser 
to get the validation and autocompletion we needed.

So far the difference I noticed with this new implementation are:
1) option validation is what we gain from directly using SpringShell.
2) SpringShell doesn't allow you to specify an option twice, so for multivalued 
parameters, our old parser can accept command like "change loglevel 
--member=member1 --member=member2", but now the parser will give you an error, 
and you should only do "change loglevel --member=member1,member2". The new 
parser did something speical for --J option though, so for --J, you can specify 
it multiple times. 
3) For value separator, springShell default's to ",", you can only overwrite it 
with option context "splittingRegex", we do not honor the 
@CliMetaData(valueSepartor=) anymore. All of our commands uses "," for 
separators, so this won't break our commands, but if there is any command out 
there that would define a different @CliMetaData(valueSepartor=) other than 
",", SpringShell would not know how to parse it.
4) To specify empty string as parameter value, before you will need to to (put 
region=A key="''" value="''"), spring shell would think the value you are 
trying to pass in are two single quotes instead of empty strings, now, you 
should only do (put region=A key="" value="")


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
 44004454ef1646bfeca8a7af3cffb109fd83e7d7 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
 a1d03e45dd4d6559bd9a0869c7dd95908d1858ca 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/GfshHelpCommands.java
 1d1b28e568a1e175690fea5cde1a45a318b6db5d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
 b37feabe6ed61c081e9653c94128f092ad189d10 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/help/Helper.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c346eaf77087102f51952a567ecd7ec036593a13 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
 bcf1b415e9ee85822c470ae6888920f0a90159fd 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/CommandManagerJUnitTest.java
 503ffb2929758d617e8539e6aefb3f7b545de9b6 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserIntegrationTest.java
 f3e3bd8754e18d7a75faf4b75e3ba75b778fc9d7 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserJUnitTest.java
 44e99f461b9efc5a439e629751011a6d0edd9213 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/CliCommandTestBase.java
 165f66482758dadb75ae95d23443973e9de05891 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/help/HelpBlockUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/help/HelperUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategyJUnitTest.java
 54c7cf7074435b48232b61916627eed69a201f09 


Diff: https://reviews.apache.org/r/58589/diff/4/


Testing (updated)
---

precheckin successful with the latest changes.


Thanks,

Jinmei Liao

[jira] [Created] (GEODE-2830) Required permission for executing a function should be DATA:WRITE

2017-04-26 Thread Diane Hardman (JIRA)

Diane Hardman created GEODE-2830:


 Summary: Required permission for executing a function should be 
DATA:WRITE
 Key: GEODE-2830
 URL: https://issues.apache.org/jira/browse/GEODE-2830
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Diane Hardman


The required permission for executing a function as listed in the gfsh command 
table (2nd table) is wrong in the docs:
http://gemfire.docs.pivotal.io/geode/managing/security/implementing_authorization.html

It is listed as DATA:MANAGE in the gfsh command table, but should be DATA:WRITE.
The correct permission is listed in the client operation table above the gfsh 
table.



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

Re: Finer grained security

2017-04-26 Thread Diane Rose Hardman

One more possible complication is that creating a Lucene index will also
create an AsyncEventQueue. Today the required permission to create the AEQ
is DATA:MANAGE which coincidentally nicely matches the permission required
to create an OQL index.
Pulling out the AEQ as a separate resource will affect Lucene index
creation. FYI.

On Tue, Apr 25, 2017 at 3:10 PM, Jinmei Liao  wrote:

> DATA:*:RegionA would allow you to only operate that region but not all of
> them.
>
> if we want to control a specific wan, maybe we add a fourth parameter:
> cluster:*:wan:wanName, same goes for Disk etc.
>
> On Tue, Apr 25, 2017 at 3:03 PM, Jacob Barrett 
> wrote:
>
> > Think further, what about the team that ask that I be able to mange a
> > region not all regions, or a wan not all wan. It may be time to think
> about
> > a full per instance /
> > named resource based security model.
> >
> > On Tue, Apr 25, 2017 at 2:59 PM Jared Stewart 
> wrote:
> >
> > > +1
> > >
> > > I think it would also be a good idea to move the current operations
> > > permitted by CLUSTER:MANAGE ( stop server, alter runtime, etc) to
> require
> > > the more specific CLUSTER:MANAGE:MEMBER in order to avoid ambiguity.
> > (This
> > > is not a breaking change since CLUSTER:MANAGE implies
> > > CLUSTER:MANAGE:MEMBER.)
> > >
> > > > On Apr 25, 2017, at 2:48 PM, Swapnil Bawaskar 
> > > wrote:
> > > >
> > > > In our current security model, a user with DATA:MANAGE can create
> > > regions,
> > > > create disk stores, WAN gateways etc. I think this is a very wide
> > scope,
> > > > because an administrator may want to give create region privilege to
> a
> > > > developer, but not necessarily give them the ability to create disk
> > > stores
> > > > or send the data in that region over WAN. I propose that we refine
> the
> > > > security model to make it finer grained.
> > > >
> > > > I propose that Disk, WAN and AsyncQueue be treated as resources in
> the
> > > > security framework. These resources will be controlled at the CLUSTER
> > > > level. As with any other resource, admins will be able to grant READ,
> > > WRITE
> > > > and MANAGE permissions to these resources. In terms of shiro, this
> will
> > > > take the form: CLUSTER:READ/WRITE/MANAGE:DISK,WAN,ASYNCQUEUE.
> > > >
> > > > Here is how it will work out for each resource:
> > > > DISK
> > > > 1. CLUSTER:MANAGE:DISK - allows users to create/manage disk stores
> > > > 2. CLUSTER:WRITE:DISK - allows users to create regions that
> > > write/overflow
> > > > to disk stores
> > > > 3. CLUSTER:READ:DISK - should be covered by DATA:READ, does not make
> > > sense
> > > > here
> > > >
> > > > WAN:
> > > > 1. CLUSTER:MANAGE:WAN - allows users to create gateway senders and
> > > receivers
> > > > 2. CLUSTER:WRITE:WAN - allows users to create regions that write data
> > to
> > > > gateway senders
> > > > 3. CLUSTER:READ:WAN - allows users to create regions that read data
> > from
> > > > gateway receivers
> > > >
> > > > We can add other things like functions here as well.
> > > >
> > > > Thoughts?
> > >
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: Review Request 58742: GEODE-2632: minor fixes from code review

2017-04-26 Thread Patrick Rhomberg


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58742/#review173094
---


Ship it!




Ship It!

- Patrick Rhomberg


On April 26, 2017, 5:17 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58742/
> ---
> 
> (Updated April 26, 2017, 5:17 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Apply fixes for issues from code review. Add TODO comments for larger issues.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  69203117da71e80c753338b048e93de0f6859443 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DistTXState.java 
> 226ffa6cfa3636437011ed41ceadf69b08155a70 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  74ec96c23076b88d009583a5cb778e147b829c09 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/NewDeclarativeIndexCreationJUnitTest.java
>  e7f5c08cb3451e82dc1d3b23d777665b8fd05884 
> 
> 
> Diff: https://reviews.apache.org/r/58742/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[GitHub] geode pull request #480: GEODE-2825: Lucene query waits for defined index to...

2017-04-26 Thread jhuynh1

GitHub user jhuynh1 opened a pull request:

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

GEODE-2825: Lucene query waits for defined index to be created

* If an index is in a defined state but not yet created, the
  query will now wait until the index is created or no longer
  defined.  Instead of throwing an exception and possibly
  getting a stack overflow

Review request list:
@upthewaterspout @nabarunnag @boglesby @ladyVader @gesterzhou 

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

$ git pull https://github.com/apache/geode feature/GEODE-2825

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

https://github.com/apache/geode/pull/480.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 #480


commit fb01b37ce8b7acda184daabc40de969a15c933c4
Author: Jason Huynh 
Date:   2017-04-26T18:13:53Z

GEODE-2825: Lucene query waits for defined index to be created

* If an index is in a defined state but not yet created, the
  query will now wait until the index is created or no longer
  defined.  Instead of throwing an exception and possibly
  getting a stack overflow




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2825) Lucene query may stackoverflow if enough function execution retries are executed

2017-04-26 Thread ASF subversion and git services (JIRA)


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

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

GitHub user jhuynh1 opened a pull request:

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

GEODE-2825: Lucene query waits for defined index to be created

* If an index is in a defined state but not yet created, the
  query will now wait until the index is created or no longer
  defined.  Instead of throwing an exception and possibly
  getting a stack overflow

Review request list:
@upthewaterspout @nabarunnag @boglesby @ladyVader @gesterzhou 

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

$ git pull https://github.com/apache/geode feature/GEODE-2825

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

https://github.com/apache/geode/pull/480.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 #480


commit fb01b37ce8b7acda184daabc40de969a15c933c4
Author: Jason Huynh 
Date:   2017-04-26T18:13:53Z

GEODE-2825: Lucene query waits for defined index to be created

* If an index is in a defined state but not yet created, the
  query will now wait until the index is created or no longer
  defined.  Instead of throwing an exception and possibly
  getting a stack overflow




> Lucene query may stackoverflow if enough function execution retries are 
> executed
> 
>
> Key: GEODE-2825
> URL: https://issues.apache.org/jira/browse/GEODE-2825
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> It is possible that a LuceneQueryFunction fails to obtain the lucene index, 
> this will cause a retry.  If this occurs enough, a stack overflow will occur 
> based on the way the function execution code is currently written.
> Instead we can detect if the index has been defined, if so, wait until the 
> index is created.  This will cause the query to block/wait until the index is 
> ready.  It is possible to get stuck in a loop like this, but this scenario 
> should only occur when an index is being created but has yet to complete.



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

[jira] [Commented] (GEODE-2821) Geode User Guide: Add running heads with logo


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

ASF subversion and git services commented on GEODE-2821:


Commit 13824f486f4b3a78859cd3c1de96f367a4ed52d2 in geode's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=13824f4 ]

GEODE-2821 - Geode User Guide: Add running heads with logo


> Geode User Guide: Add running heads with logo
> -
>
> Key: GEODE-2821
> URL: https://issues.apache.org/jira/browse/GEODE-2821
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> In the Geode User Guide, add running heads with the Geode logo as in the 
> Client Guide.



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

Review Request 58751: GEODE-2632: make GemFireCacheImpl.getRegion(String) non-final


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58751/
---

Review request for geode, Barry Oglesby, Jinmei Liao, Jared Stewart, Ken Howe, 
and Patrick Rhomberg.


Bugs: GEODE-2632
https://issues.apache.org/jira/browse/GEODE-2632


Repository: geode


Description
---

GEODE-2632: make GemFireCacheImpl.getRegion(String) non-final

* mock getRegion(String) in ParallelQueueRemovalMessageJUnitTest


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
978e86341035d8aa988624361889afe4743dbdbe 
  
geode-core/src/test/java/org/apache/geode/internal/cache/wan/parallel/ParallelQueueRemovalMessageJUnitTest.java
 b7ee5c8001b8c6806ddceeab88bc1ae88502a976 


Diff: https://reviews.apache.org/r/58751/diff/1/


Testing
---

precheckin in progress


Thanks,

Kirk Lund

Re: Finer grained security

2017-04-26 Thread Dan Smith

I agree that async event queues seem like a different case than wan or
disk. In that case you are not using anything that creating a region
doesn't do.

Shouldn't creating a region be DATA:MANAGE:DISK? Requiring DATA privileges
for a region without disk and CLUSTER privileges for a region with disk
seems weird. Same issues with creating a region that uses WAN.

-Dan

On Wed, Apr 26, 2017 at 12:53 PM, Diane Rose Hardman 
wrote:

> One more possible complication is that creating a Lucene index will also
> create an AsyncEventQueue. Today the required permission to create the AEQ
> is DATA:MANAGE which coincidentally nicely matches the permission required
> to create an OQL index.
> Pulling out the AEQ as a separate resource will affect Lucene index
> creation. FYI.
>
> On Tue, Apr 25, 2017 at 3:10 PM, Jinmei Liao  wrote:
>
> > DATA:*:RegionA would allow you to only operate that region but not all of
> > them.
> >
> > if we want to control a specific wan, maybe we add a fourth parameter:
> > cluster:*:wan:wanName, same goes for Disk etc.
> >
> > On Tue, Apr 25, 2017 at 3:03 PM, Jacob Barrett 
> > wrote:
> >
> > > Think further, what about the team that ask that I be able to mange a
> > > region not all regions, or a wan not all wan. It may be time to think
> > about
> > > a full per instance /
> > > named resource based security model.
> > >
> > > On Tue, Apr 25, 2017 at 2:59 PM Jared Stewart 
> > wrote:
> > >
> > > > +1
> > > >
> > > > I think it would also be a good idea to move the current operations
> > > > permitted by CLUSTER:MANAGE ( stop server, alter runtime, etc) to
> > require
> > > > the more specific CLUSTER:MANAGE:MEMBER in order to avoid ambiguity.
> > > (This
> > > > is not a breaking change since CLUSTER:MANAGE implies
> > > > CLUSTER:MANAGE:MEMBER.)
> > > >
> > > > > On Apr 25, 2017, at 2:48 PM, Swapnil Bawaskar <
> sbawas...@pivotal.io>
> > > > wrote:
> > > > >
> > > > > In our current security model, a user with DATA:MANAGE can create
> > > > regions,
> > > > > create disk stores, WAN gateways etc. I think this is a very wide
> > > scope,
> > > > > because an administrator may want to give create region privilege
> to
> > a
> > > > > developer, but not necessarily give them the ability to create disk
> > > > stores
> > > > > or send the data in that region over WAN. I propose that we refine
> > the
> > > > > security model to make it finer grained.
> > > > >
> > > > > I propose that Disk, WAN and AsyncQueue be treated as resources in
> > the
> > > > > security framework. These resources will be controlled at the
> CLUSTER
> > > > > level. As with any other resource, admins will be able to grant
> READ,
> > > > WRITE
> > > > > and MANAGE permissions to these resources. In terms of shiro, this
> > will
> > > > > take the form: CLUSTER:READ/WRITE/MANAGE:DISK,WAN,ASYNCQUEUE.
> > > > >
> > > > > Here is how it will work out for each resource:
> > > > > DISK
> > > > > 1. CLUSTER:MANAGE:DISK - allows users to create/manage disk stores
> > > > > 2. CLUSTER:WRITE:DISK - allows users to create regions that
> > > > write/overflow
> > > > > to disk stores
> > > > > 3. CLUSTER:READ:DISK - should be covered by DATA:READ, does not
> make
> > > > sense
> > > > > here
> > > > >
> > > > > WAN:
> > > > > 1. CLUSTER:MANAGE:WAN - allows users to create gateway senders and
> > > > receivers
> > > > > 2. CLUSTER:WRITE:WAN - allows users to create regions that write
> data
> > > to
> > > > > gateway senders
> > > > > 3. CLUSTER:READ:WAN - allows users to create regions that read data
> > > from
> > > > > gateway receivers
> > > > >
> > > > > We can add other things like functions here as well.
> > > > >
> > > > > Thoughts?
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

[GitHub] geode pull request #478: GEODE-2821 - Geode User Guide: Add running heads wi...

2017-04-26 Thread davebarnes97

Github user davebarnes97 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #478: GEODE-2821 - Geode User Guide: Add running heads with logo

2017-04-26 Thread davebarnes97

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/478
  
Changes merged to develop branch.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2821) Geode User Guide: Add running heads with logo


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

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

Github user davebarnes97 closed the pull request at:

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


> Geode User Guide: Add running heads with logo
> -
>
> Key: GEODE-2821
> URL: https://issues.apache.org/jira/browse/GEODE-2821
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> In the Geode User Guide, add running heads with the Geode logo as in the 
> Client Guide.



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

[jira] [Commented] (GEODE-2821) Geode User Guide: Add running heads with logo


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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/478
  
Changes merged to develop branch.


> Geode User Guide: Add running heads with logo
> -
>
> Key: GEODE-2821
> URL: https://issues.apache.org/jira/browse/GEODE-2821
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> In the Geode User Guide, add running heads with the Geode logo as in the 
> Client Guide.



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

Review Request 58752: GEODE-236: Removed deprecated CacheEvent methods

2017-04-26 Thread Dan Smith


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58752/
---

Review request for geode.


Repository: geode


Description
---

Signed-off-by: adongre 

GEODE-236: Spotless error fix.

This closes #463

Signed-off-by: adongre 


Diffs
-

  geode-core/src/main/java/org/apache/geode/cache/CacheEvent.java 
fc4cfc4847fb395403587a3107ef31e6734ddb88 
  geode-core/src/test/java/org/apache/geode/TXJUnitTest.java 
54d9e503f2645d045487cea51011143602764f62 
  geode-core/src/test/java/org/apache/geode/cache/CacheListenerJUnitTest.java 
1fe6bb3c926791a26b23529b71e841f78d443b62 
  geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
8cd68dc2a5d91cc2e9e165d27189607624a8ee07 
  geode-core/src/test/java/org/apache/geode/cache30/CacheListenerTestCase.java 
69cb0b5f45afc4b04dab2643e58d2d5db0067d90 
  geode-core/src/test/java/org/apache/geode/cache30/MultiVMRegionTestCase.java 
e3fb8976b3dc6475b62ec6e338e637a75cb934d9 
  
geode-core/src/test/java/org/apache/geode/cache30/RegionMembershipListenerDUnitTest.java
 72ce6c63c1b3673d2cbccf57f4b507fe168f810a 


Diff: https://reviews.apache.org/r/58752/diff/1/


Testing
---


Thanks,

Dan Smith

Re: ASF review board down?

2017-04-26 Thread Dan Smith

Works for me now.

-Dan

On Wed, Apr 26, 2017 at 11:22 AM, Kirk Lund  wrote:

> I'm unable to submit any review board reviews on
> https://reviews.apache.org/.
> I was able to submit a review an hour or so ago, but now I get this cryptic
> message:
>
> "fatal: git cat-file: could not get object info
> Line undefined: undefined"
>
> Is anyone else still able to submit a review?
>
> The diff looks good to me and I've tried another diff with the same
> results.
>

Re: Review Request 58742: GEODE-2632: minor fixes from code review

2017-04-26 Thread ASF subversion and git services (JIRA)



> On April 26, 2017, 5:51 p.m., Jinmei Liao wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
> > Line 2411 (original), 2412 (patched)
> > 
> >
> > I know this is the original logic, but why we would do something like 
> > this:
> > 
> > if (cache==this), return null?

I'm not 100% sure but that's part of the reconnect logic. During reconnect, the 
Geode member closes its Cache and then goes into a mode where it keeps trying 
to reconnect. When it can finally reconnect the Cache comes back up. It's 
possible that the Cache instance still exists during reconnect but is detached 
(ie not available to other classes) in some way (I'm just guessing though). 
Bruce is the best one to ask about this.


- Kirk


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58742/#review173065
---


On April 26, 2017, 5:17 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58742/
> ---
> 
> (Updated April 26, 2017, 5:17 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Apply fixes for issues from code review. Add TODO comments for larger issues.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  69203117da71e80c753338b048e93de0f6859443 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DistTXState.java 
> 226ffa6cfa3636437011ed41ceadf69b08155a70 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  74ec96c23076b88d009583a5cb778e147b829c09 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/NewDeclarativeIndexCreationJUnitTest.java
>  e7f5c08cb3451e82dc1d3b23d777665b8fd05884 
> 
> 
> Diff: https://reviews.apache.org/r/58742/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58752: GEODE-236: Removed deprecated CacheEvent methods

2017-04-26 Thread Darrel Schneider


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58752/#review173096
---


Ship it!




Ship It!

- Darrel Schneider


On April 26, 2017, 1:56 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58752/
> ---
> 
> (Updated April 26, 2017, 1:56 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Signed-off-by: adongre 
> 
> GEODE-236: Spotless error fix.
> 
> This closes #463
> 
> Signed-off-by: adongre 
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheEvent.java 
> fc4cfc4847fb395403587a3107ef31e6734ddb88 
>   geode-core/src/test/java/org/apache/geode/TXJUnitTest.java 
> 54d9e503f2645d045487cea51011143602764f62 
>   geode-core/src/test/java/org/apache/geode/cache/CacheListenerJUnitTest.java 
> 1fe6bb3c926791a26b23529b71e841f78d443b62 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 8cd68dc2a5d91cc2e9e165d27189607624a8ee07 
>   
> geode-core/src/test/java/org/apache/geode/cache30/CacheListenerTestCase.java 
> 69cb0b5f45afc4b04dab2643e58d2d5db0067d90 
>   
> geode-core/src/test/java/org/apache/geode/cache30/MultiVMRegionTestCase.java 
> e3fb8976b3dc6475b62ec6e338e637a75cb934d9 
>   
> geode-core/src/test/java/org/apache/geode/cache30/RegionMembershipListenerDUnitTest.java
>  72ce6c63c1b3673d2cbccf57f4b507fe168f810a 
> 
> 
> Diff: https://reviews.apache.org/r/58752/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

[jira] [Commented] (GEODE-2816) Redundancy recovery must also kick in when redundancy recovery is set to 0


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

ASF subversion and git services commented on GEODE-2816:


Commit 70340783a4617f141b937ee960a0a373ebe0f46e in geode's branch 
refs/heads/develop from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7034078 ]

GEODE-2816: Redundancy recovery inititated even if redundancy set to 0


> Redundancy recovery must also kick in when redundancy recovery is set to 0 
> ---
>
> Key: GEODE-2816
> URL: https://issues.apache.org/jira/browse/GEODE-2816
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> In methods {noformat}scheduleRedundancyRecovery{noformat} and 
> {noformat}initPRInternals{noformat} redundancy recovery is initiated only 
> when redundancy is set to a value greater than zero.
> This leads to issues where a bucket is hosted in multiple datastores when the 
> redundancy is set to 0 as redundancy recovery never removes the extra buckets.
> Solution:
> remove the checks where the redundancy recovery is initiated only when the 
> redundancy is set to a value greater than 0.



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

[GitHub] geode pull request #479: GEM-1331: AEQ created before the user region

Github user nabarunnag closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #479: GEM-1331: AEQ created before the user region

GitHub user nabarunnag reopened a pull request:

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

GEM-1331: AEQ created before the user region

Potential reviewers
@gesterzhou @upthewaterspout @jhuynh1 @ladyVader 

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2828

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

https://github.com/apache/geode/pull/479.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 #479


commit 01e70078cec53536807b0e85dd30fca7ad790de2
Author: nabarun 
Date:   2017-04-26T01:20:37Z

GEODE-2828: AEQ being created before the user region




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: ASF review board down?

It's working for me now too.

On Wed, Apr 26, 2017 at 1:56 PM, Dan Smith  wrote:

> Works for me now.
>
> -Dan
>
> On Wed, Apr 26, 2017 at 11:22 AM, Kirk Lund  wrote:
>
> > I'm unable to submit any review board reviews on
> > https://reviews.apache.org/.
> > I was able to submit a review an hour or so ago, but now I get this
> cryptic
> > message:
> >
> > "fatal: git cat-file: could not get object info
> > Line undefined: undefined"
> >
> > Is anyone else still able to submit a review?
> >
> > The diff looks good to me and I've tried another diff with the same
> > results.
> >
>

[GitHub] geode issue #479: GEM-1331: AEQ created before the user region

Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/479
  
Pushed to develop
Failure in Travis fixed in GEODE-2632


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 58589: GEODE-1597: use Spring shell's parser and delete our own parsing code



> On April 25, 2017, 5:43 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
> > Lines 238 (patched)
> > 
> >
> > Insert one line above the throw to restore the interrupt bit on the 
> > current thread:
> > ```java
> > Thread.currentThread().interrupt();
> > ```
> 
> Jinmei Liao wrote:
> You mean like this?
> .
> } catch (final InterruptedException e) {
>   Thread.currentThread().interrupt();
>   throw new IllegalStateException(e.getMessage(), e);
> }
> 
> What would this do?

Yep, that's correct. That just resets the interrupt bit. Anytime you catch 
InterruptedException you're supposed to reset the interrupt bit like that. I 
can probably find some more info online. If you own the Thread and the Thread 
is going to completely terminate (exit its run() method) then you don't need to 
reset the bit.

If the bit is reset, then the next time that Thread invokes a call that checks 
the interrupt bit, the Thread will once again throw InterruptedException. This 
should bring up more examples in Geode:

git grep "Thread.currentThread().interrupt()"


- Kirk


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58589/#review172950
---


On April 26, 2017, 7:48 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58589/
> ---
> 
> (Updated April 26, 2017, 7:48 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1597: use Spring shell's parser and delete our own parsing code
> 
> * deleted usage of jopsimple and our own parser code
> * reworked help/hint
> 
> The biggest change is in GfshParser, instead of directly implement 
> SpringShell's Parser, now it's just a simple wrapper around SpringShell's 
> SimpleParser so that we can use spring's parsing code. The challenge is that 
> SimpleParser expects the user inupt to be in the format of "command option1 
> value1 option2 value2", while gfsh expects the format to be like "command 
> option1=value1 option2=value2", so most of the code in GfshParser is to turn 
> the input into the SimpleParser input format and then feed it into 
> SimpleParser to get the validation and autocompletion we needed.
> 
> So far the difference I noticed with this new implementation are:
> 1) option validation is what we gain from directly using SpringShell.
> 2) SpringShell doesn't allow you to specify an option twice, so for 
> multivalued parameters, our old parser can accept command like "change 
> loglevel --member=member1 --member=member2", but now the parser will give you 
> an error, and you should only do "change loglevel --member=member1,member2". 
> The new parser did something speical for --J option though, so for --J, you 
> can specify it multiple times. 
> 3) For value separator, springShell default's to ",", you can only overwrite 
> it with option context "splittingRegex", we do not honor the 
> @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for 
> separators, so this won't break our commands, but if there is any command out 
> there that would define a different @CliMetaData(valueSepartor=) other than 
> ",", SpringShell would not know how to parse it.
> 4) To specify empty string as parameter value, before you will need to to 
> (put region=A key="''" value="''"), spring shell would think the value you 
> are trying to pass in are two single quotes instead of empty strings, now, 
> you should only do (put region=A key="" value="")
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
>  44004454ef1646bfeca8a7af3cffb109fd83e7d7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  a1d03e45dd4d6559bd9a0869c7dd95908d1858ca 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/GfshHelpCommands.java
>  1d1b28e568a1e175690fea5cde1a45a318b6db5d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
>  b37feabe6ed61c081e9653c94128f092ad189d10 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/help/Helper.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c346eaf77087102f51952a567ecd7ec036593a13 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
>  bcf1b415e9ee85822c470ae6888920f0a

[GitHub] geode pull request #476: GEODE-2816: Redundancy recovery inititiated even if...

Github user nabarunnag closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2816) Redundancy recovery must also kick in when redundancy recovery is set to 0


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

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

Github user nabarunnag closed the pull request at:

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


> Redundancy recovery must also kick in when redundancy recovery is set to 0 
> ---
>
> Key: GEODE-2816
> URL: https://issues.apache.org/jira/browse/GEODE-2816
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> In methods {noformat}scheduleRedundancyRecovery{noformat} and 
> {noformat}initPRInternals{noformat} redundancy recovery is initiated only 
> when redundancy is set to a value greater than zero.
> This leads to issues where a bucket is hosted in multiple datastores when the 
> redundancy is set to 0 as redundancy recovery never removes the extra buckets.
> Solution:
> remove the checks where the redundancy recovery is initiated only when the 
> redundancy is set to a value greater than 0.



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

Re: Review Request 58589: GEODE-1597: use Spring shell's parser and delete our own parsing code


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58589/#review173100
---


Ship it!




Ship It!

- Kirk Lund


On April 26, 2017, 7:48 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58589/
> ---
> 
> (Updated April 26, 2017, 7:48 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1597: use Spring shell's parser and delete our own parsing code
> 
> * deleted usage of jopsimple and our own parser code
> * reworked help/hint
> 
> The biggest change is in GfshParser, instead of directly implement 
> SpringShell's Parser, now it's just a simple wrapper around SpringShell's 
> SimpleParser so that we can use spring's parsing code. The challenge is that 
> SimpleParser expects the user inupt to be in the format of "command option1 
> value1 option2 value2", while gfsh expects the format to be like "command 
> option1=value1 option2=value2", so most of the code in GfshParser is to turn 
> the input into the SimpleParser input format and then feed it into 
> SimpleParser to get the validation and autocompletion we needed.
> 
> So far the difference I noticed with this new implementation are:
> 1) option validation is what we gain from directly using SpringShell.
> 2) SpringShell doesn't allow you to specify an option twice, so for 
> multivalued parameters, our old parser can accept command like "change 
> loglevel --member=member1 --member=member2", but now the parser will give you 
> an error, and you should only do "change loglevel --member=member1,member2". 
> The new parser did something speical for --J option though, so for --J, you 
> can specify it multiple times. 
> 3) For value separator, springShell default's to ",", you can only overwrite 
> it with option context "splittingRegex", we do not honor the 
> @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for 
> separators, so this won't break our commands, but if there is any command out 
> there that would define a different @CliMetaData(valueSepartor=) other than 
> ",", SpringShell would not know how to parse it.
> 4) To specify empty string as parameter value, before you will need to to 
> (put region=A key="''" value="''"), spring shell would think the value you 
> are trying to pass in are two single quotes instead of empty strings, now, 
> you should only do (put region=A key="" value="")
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
>  44004454ef1646bfeca8a7af3cffb109fd83e7d7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  a1d03e45dd4d6559bd9a0869c7dd95908d1858ca 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/GfshHelpCommands.java
>  1d1b28e568a1e175690fea5cde1a45a318b6db5d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
>  b37feabe6ed61c081e9653c94128f092ad189d10 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/help/Helper.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c346eaf77087102f51952a567ecd7ec036593a13 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
>  bcf1b415e9ee85822c470ae6888920f0a90159fd 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/CommandManagerJUnitTest.java
>  503ffb2929758d617e8539e6aefb3f7b545de9b6 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserIntegrationTest.java
>  f3e3bd8754e18d7a75faf4b75e3ba75b778fc9d7 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserJUnitTest.java
>  44e99f461b9efc5a439e629751011a6d0edd9213 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/CliCommandTestBase.java
>  165f66482758dadb75ae95d23443973e9de05891 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/help/HelpBlockUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/help/HelperUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategyJUnitTest.java
>  54c7cf7074435b48232b61916627eed69a201f09 
> 
> 
> Diff: https://reviews.apache.org/r/58589/diff/4/
> 
> 
> Testing
> ---
> 
> precheckin successful with the latest changes.
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.



> On April 25, 2017, 9:10 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
> > Line 301 (original), 317 (patched)
> > 
> >
> > Should probably lower this below FATAL. WARN might be a good log level.
> > 
> > I think we've generally said that FATAL means the cache server is DOA 
> > and cannot recover or may lose data.
> 
> Patrick Rhomberg wrote:
> What do you think about using ERROR, since the command in this case will 
> not execute as expected?

ERROR should be fine as well.


- Kirk


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58682/#review172973
---


On April 26, 2017, 6:25 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58682/
> ---
> 
> (Updated April 26, 2017, 6:25 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added unittests to capture failing behavior.
> 
> Corrected buildTable shifting columns when adding values with additional keys.
> 
> 
> Refactoring of DataCommandResult and DataCommandFunction
> 
> --
> 
> The majority of changes to DataCommandFunction and DataCommandResult are 
> refactoring.  Two ignored exceptions have been explicitly noted in the logger.
> 
> - In DataCommandFunction:423, there's an empty if block.  I imagine I should 
> remove that, since empty code is a waste.  Looking for it, I couldn't find 
> the comment-hinted separate method, though. Anyone familiar with this corner 
> of the code know if that actuall happens?
> 
> - Qualitative changes are in DataCommandResult.buildTable.  Items in the 
> table are scanned to build an agggregate key set, and those items missing any 
> of these keys are padded with `MISSING_VALUE`.
> 
> - I moved some of the more cumbersome blocks of code to subfunctions, but may 
> have done this more than necessary.  Opinions?
> 
> - Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive 
> development / note the bug in GEODE-2662.  Are there additional tests that 
> would fit naturally in this file?
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle f07444a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  6324b5c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  423d781 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  bb77466 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
>  e72654e 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
>  1af6261 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  ead1047 
> 
> 
> Diff: https://reviews.apache.org/r/58682/diff/4/
> 
> 
> Testing
> ---
> 
> Previous precheckin returned fully green.  Running with new refactoring but 
> expect no issues.  (Common last words.)
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

Re: Review Request 58682: GEODE-2662: Missing keys cause columns to shift in gfsh table display.



> On April 25, 2017, 9:10 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
> > Lines 154 (patched)
> > 
> >
> > Usually you can use this flavor:
> > ```java
> > assertThat(tableJson.getJSONArray(k)).hasSize(4);
> > ```
> 
> Patrick Rhomberg wrote:
> Apparently no `hasSize` for JSONArray.

Oops! Yeah that's for Collections and arrays.


- Kirk


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58682/#review172973
---


On April 26, 2017, 6:25 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58682/
> ---
> 
> (Updated April 26, 2017, 6:25 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added unittests to capture failing behavior.
> 
> Corrected buildTable shifting columns when adding values with additional keys.
> 
> 
> Refactoring of DataCommandResult and DataCommandFunction
> 
> --
> 
> The majority of changes to DataCommandFunction and DataCommandResult are 
> refactoring.  Two ignored exceptions have been explicitly noted in the logger.
> 
> - In DataCommandFunction:423, there's an empty if block.  I imagine I should 
> remove that, since empty code is a waste.  Looking for it, I couldn't find 
> the comment-hinted separate method, though. Anyone familiar with this corner 
> of the code know if that actuall happens?
> 
> - Qualitative changes are in DataCommandResult.buildTable.  Items in the 
> table are scanned to build an agggregate key set, and those items missing any 
> of these keys are padded with `MISSING_VALUE`.
> 
> - I moved some of the more cumbersome blocks of code to subfunctions, but may 
> have done this more than necessary.  Opinions?
> 
> - Introduced DataCommandFunctionWithPDXJUnitTest to explicitly drive 
> development / note the bug in GEODE-2662.  Are there additional tests that 
> would fit naturally in this file?
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle f07444a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  6324b5c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  423d781 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  bb77466 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/TabularResultData.java
>  e72654e 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
>  1af6261 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/DataCommandFunctionWithPDXJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  ead1047 
> 
> 
> Diff: https://reviews.apache.org/r/58682/diff/4/
> 
> 
> Testing
> ---
> 
> Previous precheckin returned fully green.  Running with new refactoring but 
> expect no issues.  (Common last words.)
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

[GitHub] geode pull request #479: GEODE-2828: AEQ created before the user region

2017-04-26 Thread upthewaterspout

Github user upthewaterspout commented on a diff in the pull request:

https://github.com/apache/geode/pull/479#discussion_r113564312
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
 ---
@@ -53,6 +54,8 @@
   Logger logger = LogService.getLogger();
 
   private final RepositoryManager repositoryManager;
+  private CountDownLatch isFileAndChunkRegionReady = new CountDownLatch(1);
+  private boolean ready = false;
--- End diff --

Does this need to be a separate flag? Seems like the CoutDownLatch already 
has the flag. If not this should be volatile.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2828) AEQ needs to be created before the user region


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

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

Github user upthewaterspout commented on a diff in the pull request:

https://github.com/apache/geode/pull/479#discussion_r113564312
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
 ---
@@ -53,6 +54,8 @@
   Logger logger = LogService.getLogger();
 
   private final RepositoryManager repositoryManager;
+  private CountDownLatch isFileAndChunkRegionReady = new CountDownLatch(1);
+  private boolean ready = false;
--- End diff --

Does this need to be a separate flag? Seems like the CoutDownLatch already 
has the flag. If not this should be volatile.


> AEQ needs to be created before the user region
> --
>
> Key: GEODE-2828
> URL: https://issues.apache.org/jira/browse/GEODE-2828
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>
> Issue:
> Events are lost as the region is being created, because the AEQ gets created 
> after the user region is created, and the indexes are not being created via 
> AEQ.
> Solution:
> 1. AEQ being created before the user region.
> 2. Processing of lucene events are being halted by a countdown latch and 
> starts processing after the user region is created.



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

[GitHub] geode pull request #479: GEODE-2828: AEQ created before the user region

2017-04-26 Thread jhuynh1

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/479#discussion_r113565230
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
 ---
@@ -166,28 +166,28 @@ public void createIndex(final String indexName, 
String regionPath, final Analyze
* 
* Public because this is called by the Xml parsing code
*/
-  public void afterDataRegionCreated(final String indexName, final 
Analyzer analyzer,
-  final String dataRegionPath, final Map 
fieldAnalyzers,
-  final String... fields) {
-LuceneIndexImpl index = createIndexRegions(indexName, dataRegionPath);
-index.setSearchableFields(fields);
-index.setAnalyzer(analyzer);
-index.setFieldAnalyzers(fieldAnalyzers);
+  public void afterDataRegionCreated(LuceneIndexImpl index) {
 index.initialize();
 registerIndex(index);
 if (this.managementListener != null) {
   this.managementListener.afterIndexCreated(index);
 }
+
+  }
+
+  public LuceneIndexImpl beforeDataRegionCreated(final String indexName, 
final String regionPath,
+  RegionAttributes attributes, final Analyzer analyzer,
+  final Map fieldAnalyzers, String aeqId, final 
String... fields) {
+LuceneIndexImpl index = createIndexRegions(indexName, regionPath);
--- End diff --

This wasn't introduced with this diff, but we probably want to rename this 
method.  I don't think the method is creating any index regions.  I think it's 
just creating the index object but none of the file/chunk or aeq region or 
buckets


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2828) AEQ needs to be created before the user region


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

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

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/479#discussion_r113565230
  
--- Diff: 
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
 ---
@@ -166,28 +166,28 @@ public void createIndex(final String indexName, 
String regionPath, final Analyze
* 
* Public because this is called by the Xml parsing code
*/
-  public void afterDataRegionCreated(final String indexName, final 
Analyzer analyzer,
-  final String dataRegionPath, final Map 
fieldAnalyzers,
-  final String... fields) {
-LuceneIndexImpl index = createIndexRegions(indexName, dataRegionPath);
-index.setSearchableFields(fields);
-index.setAnalyzer(analyzer);
-index.setFieldAnalyzers(fieldAnalyzers);
+  public void afterDataRegionCreated(LuceneIndexImpl index) {
 index.initialize();
 registerIndex(index);
 if (this.managementListener != null) {
   this.managementListener.afterIndexCreated(index);
 }
+
+  }
+
+  public LuceneIndexImpl beforeDataRegionCreated(final String indexName, 
final String regionPath,
+  RegionAttributes attributes, final Analyzer analyzer,
+  final Map fieldAnalyzers, String aeqId, final 
String... fields) {
+LuceneIndexImpl index = createIndexRegions(indexName, regionPath);
--- End diff --

This wasn't introduced with this diff, but we probably want to rename this 
method.  I don't think the method is creating any index regions.  I think it's 
just creating the index object but none of the file/chunk or aeq region or 
buckets


> AEQ needs to be created before the user region
> --
>
> Key: GEODE-2828
> URL: https://issues.apache.org/jira/browse/GEODE-2828
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>
> Issue:
> Events are lost as the region is being created, because the AEQ gets created 
> after the user region is created, and the indexes are not being created via 
> AEQ.
> Solution:
> 1. AEQ being created before the user region.
> 2. Processing of lucene events are being halted by a countdown latch and 
> starts processing after the user region is created.



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

[GitHub] geode-native pull request #94: GEODE-2826: Client docs - Delta Propagation A...

2017-04-26 Thread ASF subversion and git services (JIRA)

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/94


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2826) Client docs - Delta Propagation API, correct .NET namespace notation


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

ASF subversion and git services commented on GEODE-2826:


Commit 2e2f0f8aef85e464700f521a55946d18c40988f5 in geode-native's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=2e2f0f8 ]

GEODE-2826: Client docs - Delta Propagation API, correct .NET namespace notation
This closes #94


> Client docs - Delta Propagation API, correct .NET namespace notation
> 
>
> Key: GEODE-2826
> URL: https://issues.apache.org/jira/browse/GEODE-2826
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Reported by [~karensmolermiller]:
> file delta-propagation/delta-propagation-api.html
> The namespaces shown for .NET should be separated by a period (.), not two 
> colons "::".



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

[jira] [Commented] (GEODE-2826) Client docs - Delta Propagation API, correct .NET namespace notation


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

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

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/94


> Client docs - Delta Propagation API, correct .NET namespace notation
> 
>
> Key: GEODE-2826
> URL: https://issues.apache.org/jira/browse/GEODE-2826
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Reported by [~karensmolermiller]:
> file delta-propagation/delta-propagation-api.html
> The namespaces shown for .NET should be separated by a period (.), not two 
> colons "::".



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

Re: Simple Java Client