[jira] [Resolved] (GEODE-289) Remove deprecated LicenseException

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-289.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove deprecated LicenseException
> --
>
> Key: GEODE-289
> URL: https://issues.apache.org/jira/browse/GEODE-289
> Project: Geode
>  Issue Type: Sub-task
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>
> com.gemstone.gemfire.LicenseException currently exists only for backwards 
> compatibility of user code. It should be removed from Geode.
> If GemFire requires it for backwards compatibility then it will be moved to 
> GemFire.



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

[jira] [Resolved] (GEODE-267) Remove deprecated ThreadInterruptedException

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-267.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove deprecated ThreadInterruptedException
> 
>
> Key: GEODE-267
> URL: https://issues.apache.org/jira/browse/GEODE-267
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The ThreadInterruptedException is deprecated and should be removed. None of 
> our product code nor our test code uses it so it should be easy to remove.



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

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

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-260.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> 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
> Fix For: 1.2.0
>
>   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] [Resolved] (GEODE-255) Remove deprecated DataSerializer.register(Class,byte)

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-255.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> 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
> Fix For: 1.2.0
>
>   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] [Resolved] (GEODE-266) Remove deprecated ObjectSizerImpl

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-266.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> 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
> Fix For: 1.2.0
>
>   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)

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

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-253.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> 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
> Fix For: 1.2.0
>
>   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] [Resolved] (GEODE-2723) remove "localCacheEnabled" dead code from PartitionedRegion

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-2723.
---
   Resolution: Fixed
Fix Version/s: 1.2.0

> remove "localCacheEnabled" dead code from PartitionedRegion
> ---
>
> Key: GEODE-2723
> URL: https://issues.apache.org/jira/browse/GEODE-2723
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>
> The PartionedRegion class has a final field named "localCacheEnabled". It is 
> always false and never set to true. We have 5 methods that test for it being 
> true and do a bunch of stuff. This dead code should be removed.



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

[jira] [Commented] (GEODE-2723) remove "localCacheEnabled" dead code from PartitionedRegion

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> remove "localCacheEnabled" dead code from PartitionedRegion
> ---
>
> Key: GEODE-2723
> URL: https://issues.apache.org/jira/browse/GEODE-2723
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> The PartionedRegion class has a final field named "localCacheEnabled". It is 
> always false and never set to true. We have 5 methods that test for it being 
> true and do a bunch of stuff. This dead code should be removed.



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

[jira] [Commented] (GEODE-2723) remove "localCacheEnabled" dead code from PartitionedRegion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2723:


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

GEODE-2723: Removed localCacheEnabled field, and associated dead code.
This closes #440

Signed-off-by: adongre 


> remove "localCacheEnabled" dead code from PartitionedRegion
> ---
>
> Key: GEODE-2723
> URL: https://issues.apache.org/jira/browse/GEODE-2723
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> The PartionedRegion class has a final field named "localCacheEnabled". It is 
> always false and never set to true. We have 5 methods that test for it being 
> true and do a bunch of stuff. This dead code should be removed.



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

Re: Client Commands and SecurityService

[Jacob Barrett]

+1

We are attempting the same on the non-Java clients too.


-Jake

On Mon, Apr 3, 2017 at 1:30 PM Kirk Lund  wrote:

> My primary goal is to defer instantiating the Command instances until after
> the Cache has initialized Security. I then have several options for
> handling Security within the Commands that has much less performance impact
> than it currently has. A major reconfiguration or lifecycle point, such as
> closing and then recreating the Cache should be the only source of garbage
> caused by throwing away the old instances and creating new ones.
>
> Removal of singletons primarily involves moving the instantiation code and
> the lifecycle of the class (that's a singleton) further up the layers of
> Geode code so it becomes driven by Cache initialization rather than by
> class loading. Conceptually, you would still only have one instance of
> SecurityService for the Cache, but the code that's responsible for that
> "singularity" are the collaborators that own and interact with the
> instance. This allows us to replace the instance very easily between unit
> tests or between lifecycles of the Cache (which is where a user would
> reconfigure things) or even make future changes to support multiple
> instances for some component types that are currently singletons.
>
> What I'm planning is just a first pass at reducing our dependency on
> singletons specifically to allow me to improve performance involving how
> client Commands interact with Security (when security is enabled or
> disabled).
>
> On Mon, Apr 3, 2017 at 11:02 AM, Bruce Schuchardt 
> wrote:
>
> > I'm not against refactoring the command classes.  They originated from
> the
> > refactoring of a very large method that attempted to handle all client
> > operations and, consequently, are currently stateless. You can't really
> > hurt anything by creating multiple instances of them but please avoid
> > creating unnecessary garbage.
> >
> >
> >
> > Le 4/3/2017 à 10:38 AM, Galen M O'Sullivan a écrit :
> >
> >> +1 to getting rid of singletons and non-constant use of static. Also to
> >> code where the ownership semantics are clear.
> >>
> >> On Mon, Apr 3, 2017 at 10:30 AM, Jacob Barrett 
> >> wrote:
> >>
> >> +1 refactor
> >>> On Mon, Apr 3, 2017 at 9:35 AM Michael William Dodge <
> mdo...@pivotal.io>
> >>> wrote:
> >>>
> >>> +1 to modular and questioning non-constant use of static
> 
>  On 3 Apr, 2017, at 09:27, Anthony Baker  wrote:
> >
> > Using singletons leads to very monolithic systems that are hard to
> test
> >
>  and hard to change.  Instead we should prefer modular services like
> Udo
>  proposed.
> 
> > I would go further and say that we should question any non-constant
> use
> >
>  of “static”.
> 
> > Anthony
> >
> > On Apr 3, 2017, at 9:01 AM, Udo Kohlmeyer 
> >>
> > wrote:
> 
> > Correct, that would be the definition.
> >>
> >> Yet, we find that our use of singletons within Geode is limiting to
> >>
> > say
> >>>
>  that least. With the idea of wanting to be able to create/run multiple
>  cache instance within the same JVM (especially for testing) a
> singleton
>  will be problematic.
> 
> > In addition to that, the alternative is not that hard to construct
> and
> >>
> > in many cases easier to manage.
> 
> > --Udo
> >>
> >>
> >> On 4/3/17 08:57, Jinmei Liao wrote:
> >>
> >>> Isn't "that instance is reused each invocation" my understanding
> of a
> >>> "singleton"?
> >>>
> >>> On Mon, Apr 3, 2017 at 11:49 AM, Udo Kohlmeyer <
> >>>
> >> ukohlme...@pivotal.io>
> >>>
>  wrote:
> >>>
> >>> -1 For using singletons
> 
>  Using a Factory pattern you can avoid having to create singletons
> in
>  addition to caching created commands to avoid the recreation of
> the
>  instance.
> 
>  The SSLConfigurationFactory is a simple example where you create
> an
>  instance when required. Once an instance is created, that instance
> 
> >>> is
> >>>
>  reused each invocation.
> 
>  --Udo
> 
> 
> 
>  On 4/3/17 08:30, Jinmei Liao wrote:
> 
>  I think the client commands needs to be singleton instances even
> >
>  after you
> 
> > change the sequence of initialization. We don't want to have each
> >
>  client
> 
> > operation ends up creating a new command instance, right? That
> >
>  would
> >>>
>  be a
> 
> > more performance drag.
> >
> > On Thu, Mar 30, 2017 at 2:14 PM, Kirk Lund 
> >
>  wrote:
> >>>
>  PS: I'll be writing and using JMH benchmarks to drive these
> >
>  changes.
> >>>
> 

Re: Simple Java Client

[Jacob Barrett]

The point to supporting standards is that if we have standard compliant
apis we can also plug into other libraries without custom effort. Yes some
effort is needed on the admin side but such is true for all the systems
that implement JSR-107. The goal was to make the usage, not the
administration, consistent.

Separate, and standard based, management is also a must. Configuration
based on MBeans opens the doors to many configuration and management tools
already in the marketplace that we don't have to write and support
ourselves. We can then focus on what we do best which is consistent
distributed data, not management platforms.

-Jake

On Thu, Apr 27, 2017 at 4:19 PM Swapnil Bawaskar 
wrote:

> We could have a simple wrapper around geode API for JSR-107, but I still
> don't see how this is helpful. I can read a book about JSR-107 and try to
> use geode, but then I wanted to create a PartitionedRegion in Geode, the
> book didn't tell me anything about that (since it is implementation
> specific), I then tried to use the EntryProcessor mentioned in the book,
> but Geode does not support that. Supporting a standard would only become an
> exercise in getting a checkmark in a feature comparison. BTW, we are stuck
> with "Region" because of the initial drafts of JSR-107. Geode is much more
> than a "Cache", a number of users treat it as a system of record.
> Implementing JSR-107 would be a step backward. I would have been onboard
> implementing JSR-347 "Data grids for Java
> , unfortunately, it was withdrawn.
> Rather than renaming "Region" to "Cache", if we do have to rename it, we
> should just call it a Map. Then add other data structures like Lists and
> Sorted Sets.
>
> On Thu, Apr 27, 2017 at 2:21 PM Kirk Lund  wrote:
>
> > "geode-client-api.jar" (not ai)
> >
> > On Thu, Apr 27, 2017 at 2:20 PM, Kirk Lund  wrote:
> >
> > > Different module or different repo is same thing I'm suggesting. Make
> it
> > > separate and independent such that a Client can be compiled only with
> > > geode-client-ai.jar.
> > >
> > > On Wed, Apr 26, 2017 at 4:52 PM, Bruce Schuchardt <
> > bschucha...@pivotal.io>
> > > wrote:
> > >
> > >> I don't think we should mix the old client code with a new API.  We
> > >> should keep the new client code separate from the server.  Maybe even
> > in a
> > >> different repo, as I think Fred suggested.
> > >>
> > >> Le 4/26/2017 à 3:12 PM, Kirk Lund a écrit :
> > >>
> > >>> If we want to add a new API then I suggest we create new API packages
> > and
> > >>> leave the "cache" package as the old deprecated API for backwards
> > >>> compatibility.
> > >>>
> > >>> The new APIs and implementation could be separated into different
> geode
> > >>> modules and packages (something like what follows):
> > >>>
> > >>> org.apache.geode.api -- the main rich API (geode-api module and jar)
> > >>> org.apache.geode.api.client -- the new thin client API
> > (geode-api-client
> > >>> module and jar)
> > >>> org.apache.geode.core -- the main implementation of api (geode-core
> > >>> module
> > >>> and jar which also currently contains the old API)
> > >>>
> > >>> 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 <
> jbarr...@pivotal.io>
> >  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:
> > 
> > 

[GitHub] geode-examples issue #4: Updating and simplifying examples

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode-examples/pull/4
  
Added a cache loader example to test drive the approach.


---
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 58813: GEODE-2776 After region is updated with loader, the ClientEvent is set with current entry version tag

[Darrel Schneider]

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




geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
Line 2352 (original), 2357 (patched)


I think this code needs to also update clientEvent by calling 
rs.getVersionStamp().asVersionTag()


- Darrel Schneider


On April 27, 2017, 12:44 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58813/
> ---
> 
> (Updated April 27, 2017, 12:44 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, and Lynn Gallinat.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When client does a get() which results in adding an entry by calling loader 
> on server side, the client event returned back is not updated with the 
> version tag that is created with the new entry on server. This results in 
> client having a different version tag than the server side entry. If client 
> has registered event, and is concurrently updating the entry (from get() call 
> and an register-event from server), it could result in data consistency 
> between client and server.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
>  8cdc517 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/AbstractDistributedRegionJUnitTest.java
>  ba2f794 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DistributedRegionJUnitTest.java
>  7525f35 
> 
> 
> Diff: https://reviews.apache.org/r/58813/diff/1/
> 
> 
> Testing
> ---
> 
> Manual testing.
> Running new unit test (added) with and without changes.
> precheckin in progress.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #537 was SUCCESSFUL (with 1843 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #537 was successful (rerun 2 times).
---
This build was rerun by John Blum.
1845 tests in total.

https://build.spring.io/browse/SGF-NAG-537/





--
This message is automatically generated by Atlassian Bamboo

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #537 has FAILED (1 tests failed)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #537 failed (rerun once).
---
This build was rerun by John Blum.
1/1845 tests failed.

https://build.spring.io/browse/SGF-NAG-537/

-
Currently Responsible
-

No one is responsible for fixing this build.



--
Failing Jobs
--
  - Default Job (Default Stage): 1 of 1845 tests failed.




--
Tests
--
New Test Failures (1)
   - ApacheGeodeSecurityManagerGeodeSecurityIntegrationTests: Authorized user

--
This message is automatically generated by Atlassian Bamboo

Re: Simple Java Client

[Swapnil Bawaskar]

We could have a simple wrapper around geode API for JSR-107, but I still
don't see how this is helpful. I can read a book about JSR-107 and try to
use geode, but then I wanted to create a PartitionedRegion in Geode, the
book didn't tell me anything about that (since it is implementation
specific), I then tried to use the EntryProcessor mentioned in the book,
but Geode does not support that. Supporting a standard would only become an
exercise in getting a checkmark in a feature comparison. BTW, we are stuck
with "Region" because of the initial drafts of JSR-107. Geode is much more
than a "Cache", a number of users treat it as a system of record.
Implementing JSR-107 would be a step backward. I would have been onboard
implementing JSR-347 "Data grids for Java
, unfortunately, it was withdrawn.
Rather than renaming "Region" to "Cache", if we do have to rename it, we
should just call it a Map. Then add other data structures like Lists and
Sorted Sets.

On Thu, Apr 27, 2017 at 2:21 PM Kirk Lund  wrote:

> "geode-client-api.jar" (not ai)
>
> On Thu, Apr 27, 2017 at 2:20 PM, Kirk Lund  wrote:
>
> > Different module or different repo is same thing I'm suggesting. Make it
> > separate and independent such that a Client can be compiled only with
> > geode-client-ai.jar.
> >
> > On Wed, Apr 26, 2017 at 4:52 PM, Bruce Schuchardt <
> bschucha...@pivotal.io>
> > wrote:
> >
> >> I don't think we should mix the old client code with a new API.  We
> >> should keep the new client code separate from the server.  Maybe even
> in a
> >> different repo, as I think Fred suggested.
> >>
> >> Le 4/26/2017 à 3:12 PM, Kirk Lund a écrit :
> >>
> >>> If we want to add a new API then I suggest we create new API packages
> and
> >>> leave the "cache" package as the old deprecated API for backwards
> >>> compatibility.
> >>>
> >>> The new APIs and implementation could be separated into different geode
> >>> modules and packages (something like what follows):
> >>>
> >>> org.apache.geode.api -- the main rich API (geode-api module and jar)
> >>> org.apache.geode.api.client -- the new thin client API
> (geode-api-client
> >>> module and jar)
> >>> org.apache.geode.core -- the main implementation of api (geode-core
> >>> module
> >>> and jar which also currently contains the old API)
> >>>
> >>> 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 <(781)%20606-0325>
> >> http://pivotal.io/big-data/pivotal-gemfire
> >>
> >> On Tue, Apr 25, 2017 at 11:41 PM, Jacob Barrett <
> jbarr...@pivotal.io>
> >> wrote:
> >>
> >> Java and its community have standards for all of these issue so why
> >>> re-invent the wheel. The market doesn't want 

[jira] [Assigned] (GEODE-2837) Start server fails if specified `--dir` does not exist

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2837:


Assignee: Jared Stewart

> Start server fails if specified `--dir` does not exist
> --
>
> Key: GEODE-2837
> URL: https://issues.apache.org/jira/browse/GEODE-2837
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> When you execute {{gfsh> start server --name=server1}}, the default working 
> directory will be {{./server1}}, and gfsh will create that directory if 
> necessary.  However, {{gfsh> start server --name=server1 --dir=foo}} will 
> fail if the directory {{./foo}} does not exist. 
> For consistency ease of use, we should instead have gfsh attempt to create 
> the specified directory if necessary.  {{start locator}} may or may not have 
> the same deficiency.  



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

[jira] [Created] (GEODE-2837) Start server fails if specified `--dir` does not exist

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2837:


 Summary: Start server fails if specified `--dir` does not exist
 Key: GEODE-2837
 URL: https://issues.apache.org/jira/browse/GEODE-2837
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Jared Stewart


When you execute {{gfsh> start server --name=server1}}, the default working 
directory will be {{./server1}}, and gfsh will create that directory if 
necessary.  However, {{gfsh> start server --name=server1 --dir=foo}} will fail 
if the directory {{./foo}} does not exist. 

For consistency ease of use, we should instead have gfsh attempt to create the 
specified directory if necessary.  {{start locator}} may or may not have the 
same deficiency.  



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

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #537 has FAILED (1 tests failed)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #537 failed.
---
Scheduled
1/1845 tests failed.

https://build.spring.io/browse/SGF-NAG-537/

-
Currently Responsible
-

No one is responsible for fixing this build.



--
Failing Jobs
--
  - Default Job (Default Stage): 1 of 1845 tests failed.




--
Tests
--
New Test Failures (1)
   - ApacheGeodeSecurityManagerGeodeSecurityIntegrationTests: Authorized user

--
This message is automatically generated by Atlassian Bamboo

[jira] [Assigned] (GEODE-2836) CacheLoader should extend Declarable

[Anthony Baker (JIRA)]

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

Anthony Baker reassigned GEODE-2836:


Assignee: Jinmei Liao

> CacheLoader should extend Declarable
> 
>
> Key: GEODE-2836
> URL: https://issues.apache.org/jira/browse/GEODE-2836
> Project: Geode
>  Issue Type: Improvement
>  Components: configuration
>Reporter: Anthony Baker
>Assignee: Jinmei Liao
>
> In order to implement a {{CacheLoader}} that is usable from {{cache.xml}} the 
> developer should also implement {{Declarable}}.  It would be nice to make 
> {{CacheLoader}} extend from {{Declarable}} with a default implementation for 
> {{init}} to simplify this requirement.
> Note that this could be applied to all user callbacks like {{CacheListener}} 
> and friends.
> If a developer does not implement {{Declarable}} and uses {{gfsh}} to add the 
> callback to the region, it's possible to get a startup failure since the 
> cluster config service uses {{cache.xml}} to persist config changes.  This is 
> BAD.



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

[jira] [Created] (GEODE-2836) CacheLoader should extend Declarable

[Anthony Baker (JIRA)]

Anthony Baker created GEODE-2836:


 Summary: CacheLoader should extend Declarable
 Key: GEODE-2836
 URL: https://issues.apache.org/jira/browse/GEODE-2836
 Project: Geode
  Issue Type: Improvement
  Components: configuration
Reporter: Anthony Baker


In order to implement a {{CacheLoader}} that is usable from {{cache.xml}} the 
developer should also implement {{Declarable}}.  It would be nice to make 
{{CacheLoader}} extend from {{Declarable}} with a default implementation for 
{{init}} to simplify this requirement.

Note that this could be applied to all user callbacks like {{CacheListener}} 
and friends.

If a developer does not implement {{Declarable}} and uses {{gfsh}} to add the 
callback to the region, it's possible to get a startup failure since the 
cluster config service uses {{cache.xml}} to persist config changes.  This is 
BAD.



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

[jira] [Created] (GEODE-2835) Autoboxing unsigned primitives in .NET results in stack overflow.

[Jacob S. Barrett (JIRA)]

Jacob S. Barrett created GEODE-2835:
---

 Summary: Autoboxing unsigned primitives in .NET results in stack 
overflow.
 Key: GEODE-2835
 URL: https://issues.apache.org/jira/browse/GEODE-2835
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Jacob S. Barrett


When using a PdxSerializer, like ReflectionBasedPdxSerializer that writes 
unsigned primitive types to fields it results in autoboxing those types and 
looping them back to the PdxSerializer. This can result in an infinite 
recursion and stack overflow. 

{noformat}
Serializer.RegisterPdxSerializer(new ReflectionBasedPdxSerializer());
region.put("a", new Guid());
{noformat}

Guid contains several fields, some of which are {{unsigned char}} which autobox 
to {{System::Byte}}, this gets forwarded back to the auto pdx serializer which 
sees field {{unsigned char m_value}} and autoboxes it again to {{System::Byte}} 
and ..





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

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

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade updated GEODE-2661:
-
Description: 
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)

// Remove all from client
List keys= Arrays.asList("k1", "k2", "k8");
region.removeAll(l); 

The afterDestroy call back will be invoked for k8. On server.


  was:
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.



> 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)
> // Remove all from client
> List keys= Arrays.asList("k1", "k2", "k8");
> region.removeAll(l); 
> The afterDestroy call back will be invoked for k8. On server.



--
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.

[Kirk Lund]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
Line 167 (original), 170 (patched)


Delete these two unused HashSets. I know it's not part of your change, but 
yuck this is bad!


- Kirk Lund


On April 27, 2017, 6:30 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58682/
> ---
> 
> (Updated April 27, 2017, 6:30 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/5/
> 
> 
> Testing
> ---
> 
> Previous precheckin returned fully green.  Running with new refactoring but 
> expect no issues.  (Common last words.)
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

Re: Simple Java Client

[Kirk Lund]

"geode-client-api.jar" (not ai)

On Thu, Apr 27, 2017 at 2:20 PM, Kirk Lund  wrote:

> Different module or different repo is same thing I'm suggesting. Make it
> separate and independent such that a Client can be compiled only with
> geode-client-ai.jar.
>
> On Wed, Apr 26, 2017 at 4:52 PM, Bruce Schuchardt 
> wrote:
>
>> I don't think we should mix the old client code with a new API.  We
>> should keep the new client code separate from the server.  Maybe even in a
>> different repo, as I think Fred suggested.
>>
>> Le 4/26/2017 à 3:12 PM, Kirk Lund a écrit :
>>
>>> If we want to add a new API then I suggest we create new API packages and
>>> leave the "cache" package as the old deprecated API for backwards
>>> compatibility.
>>>
>>> The new APIs and implementation could be separated into different geode
>>> modules and packages (something like what follows):
>>>
>>> org.apache.geode.api -- the main rich API (geode-api module and jar)
>>> org.apache.geode.api.client -- the new thin client API (geode-api-client
>>> module and jar)
>>> org.apache.geode.core -- the main implementation of api (geode-core
>>> module
>>> and jar which also currently contains the old API)
>>>
>>> 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. 

Re: Simple Java Client

[Kirk Lund]

Different module or different repo is same thing I'm suggesting. Make it
separate and independent such that a Client can be compiled only with
geode-client-ai.jar.

On Wed, Apr 26, 2017 at 4:52 PM, Bruce Schuchardt 
wrote:

> I don't think we should mix the old client code with a new API.  We should
> keep the new client code separate from the server.  Maybe even in a
> different repo, as I think Fred suggested.
>
> Le 4/26/2017 à 3:12 PM, Kirk Lund a écrit :
>
>> If we want to add a new API then I suggest we create new API packages and
>> leave the "cache" package as the old deprecated API for backwards
>> compatibility.
>>
>> The new APIs and implementation could be separated into different geode
>> modules and packages (something like what follows):
>>
>> org.apache.geode.api -- the main rich API (geode-api module and jar)
>> org.apache.geode.api.client -- the new thin client API (geode-api-client
>> module and jar)
>> org.apache.geode.core -- the main implementation of api (geode-core module
>> and jar which also currently contains the old API)
>>
>> 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 

[jira] [Created] (GEODE-2834) Query with WHERE clause unable to return values that include single-quotes inside strings

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2834:


 Summary: Query with WHERE clause unable to return values that 
include single-quotes inside strings
 Key: GEODE-2834
 URL: https://issues.apache.org/jira/browse/GEODE-2834
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Michael Dodge


If one was to create a region and insert JSON values via the REST API and one 
of those values happened to include a single-quote character inside a string, 
e.g.,:
{
   "PizzaType":"meat lover's",
   "Quantity":"1"
}

And then one was to execute a query using gfsh, e.g.:
gfsh>query --query="SELECT * FROM /orderrequests o WHERE o.PizzaType LIKE 
'meat%'"

Then one would see an error as follows:
Error getting bean properties Expected a ',' or '}' at 26 [character 27 line 1]



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

Re: Simple Java Client

[Mark Bretl]

A little late to the party...a great thread for discussing options and
there is nothing 'simple' about it ;)

I agree with Jake to follow closer to industry protocols and standards
rather than creating our own. If we want to grow and sustain the Geode
community, adding 'features' which integrate with other communities seems
to be a viable approach.

--Mark

On Wed, Apr 26, 2017 at 5:51 PM, Michael William Dodge 
wrote:

> I like the idea of a separate code base (including repo) for separate
> problem domains. I think trying to fit a new API inside or parallel to the
> existing API has too high of a likelihood of confusion.
>
> Sarge
>
> > On 26 Apr, 2017, at 16:52, Bruce Schuchardt 
> wrote:
> >
> > I don't think we should mix the old client code with a new API.  We
> should keep the new client code separate from the server.  Maybe even in a
> different repo, as I think Fred suggested.
> >
> > Le 4/26/2017 à 3:12 PM, Kirk Lund a écrit :
> >> If we want to add a new API then I suggest we create new API packages
> and
> >> leave the "cache" package as the old deprecated API for backwards
> >> compatibility.
> >>
> >> The new APIs and implementation could be separated into different geode
> >> modules and packages (something like what follows):
> >>
> >> org.apache.geode.api -- the main rich API (geode-api module and jar)
> >> org.apache.geode.api.client -- the new thin client API (geode-api-client
> >> module and jar)
> >> org.apache.geode.core -- the main implementation of api (geode-core
> module
> >> and jar which also currently contains the old API)
> >>
> >> 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.
> >>
> >> 

[jira] [Commented] (GEODE-2833) IPdxSerializable objects don't deserialize after custom PdxSerializer is registered.

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett commented on GEODE-2833:
-

See clicache/Serializable.cpp:getPdxType.

> IPdxSerializable objects don't deserialize after custom PdxSerializer is 
> registered.
> 
>
> Key: GEODE-2833
> URL: https://issues.apache.org/jira/browse/GEODE-2833
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Jacob S. Barrett
>
> Registing a {IPdxSerializer} disables deserialization of {IPdxSerializable} 
> classes.



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

[jira] [Created] (GEODE-2833) IPdxSerializable objects don't deserialize after custom PdxSerializer is registered.

[Jacob S. Barrett (JIRA)]

Jacob S. Barrett created GEODE-2833:
---

 Summary: IPdxSerializable objects don't deserialize after custom 
PdxSerializer is registered.
 Key: GEODE-2833
 URL: https://issues.apache.org/jira/browse/GEODE-2833
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Jacob S. Barrett


Registing a {IPdxSerializer} disables deserialization of {IPdxSerializable} 
classes.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: minor fixes from code review

* add TODO comments for some larger fixes from review


> 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-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

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

* mock getRegion(String) in ParallelQueueRemovalMessageJUnitTest


> 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)

Re: Build failed in Jenkins: Geode-nightly #817

[Mark Bretl]

I have added an exclude for any machines with the 'couchdb' label and
restarted the nightly build.

--Mark

On Thu, Apr 27, 2017 at 1:05 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> --
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on couchdb-macos1 (couchdb) in workspace <
> https://builds.apache.org/job/Geode-nightly/ws/>
> java.io.IOException: Failed to mkdirs:  job/Geode-nightly/ws/>
> at hudson.FilePath.mkdirs(FilePath.java:1169)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:
> 1276)
> at hudson.model.AbstractBuild$AbstractBuildExecution.
> defaultCheckout(AbstractBuild.java:604)
> at jenkins.scm.SCMCheckoutStrategy.checkout(
> SCMCheckoutStrategy.java:86)
> at hudson.model.AbstractBuild$AbstractBuildExecution.run(
> AbstractBuild.java:529)
> at hudson.model.Run.execute(Run.java:1728)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
> at hudson.model.ResourceController.execute(
> ResourceController.java:98)
> at hudson.model.Executor.run(Executor.java:404)
> Retrying after 10 seconds
> java.io.IOException: Failed to mkdirs:  job/Geode-nightly/ws/>
> at hudson.FilePath.mkdirs(FilePath.java:1169)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:
> 1276)
> at hudson.model.AbstractBuild$AbstractBuildExecution.
> defaultCheckout(AbstractBuild.java:604)
> at jenkins.scm.SCMCheckoutStrategy.checkout(
> SCMCheckoutStrategy.java:86)
> at hudson.model.AbstractBuild$AbstractBuildExecution.run(
> AbstractBuild.java:529)
> at hudson.model.Run.execute(Run.java:1728)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
> at hudson.model.ResourceController.execute(
> ResourceController.java:98)
> at hudson.model.Executor.run(Executor.java:404)
> Retrying after 10 seconds
> java.io.IOException: Failed to mkdirs:  job/Geode-nightly/ws/>
> at hudson.FilePath.mkdirs(FilePath.java:1169)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:
> 1276)
> at hudson.model.AbstractBuild$AbstractBuildExecution.
> defaultCheckout(AbstractBuild.java:604)
> at jenkins.scm.SCMCheckoutStrategy.checkout(
> SCMCheckoutStrategy.java:86)
> at hudson.model.AbstractBuild$AbstractBuildExecution.run(
> AbstractBuild.java:529)
> at hudson.model.Run.execute(Run.java:1728)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
> at hudson.model.ResourceController.execute(
> ResourceController.java:98)
> at hudson.model.Executor.run(Executor.java:404)
> Archiving artifacts
> ERROR: Build step failed with exception
>  does not exist.
> at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(
> AbstractFileSet.java:483)
> at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(
> AbstractFileSet.java:460)
> at hudson.tasks.ArtifactArchiver$ListFiles.invoke(
> ArtifactArchiver.java:292)
> at hudson.tasks.ArtifactArchiver$ListFiles.invoke(
> ArtifactArchiver.java:272)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2731)
> at hudson.remoting.UserRequest.perform(UserRequest.java:153)
> at hudson.remoting.UserRequest.perform(UserRequest.java:50)
> at hudson.remoting.Request$2.run(Request.java:336)
> at hudson.remoting.InterceptingExecutorService$1.call(
> InterceptingExecutorService.java:68)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at hudson.remoting.Engine$1$1.run(Engine.java:94)
> at java.lang.Thread.run(Thread.java:745)
> at ..remote call to Channel to /91.65.50.62(Native Method)
> at hudson.remoting.Channel.attachCallSiteStackTrace(
> Channel.java:1537)
> at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
> at hudson.remoting.Channel.call(Channel.java:822)
> at hudson.FilePath.act(FilePath.java:985)
> at hudson.FilePath.act(FilePath.java:974)
> at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:
> 237)
> at hudson.tasks.BuildStepCompatibilityLayer.perform(
> BuildStepCompatibilityLayer.java:78)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.
> java:20)
> at hudson.model.AbstractBuild$AbstractBuildExecution.
> perform(AbstractBuild.java:779)
> at 

Re: Finer grained security

[John Blum]

+1 to Jake's comments, and is a fundamental property of Java's security
internally.

On Thu, Apr 27, 2017 at 1:09 PM, Jacob Barrett  wrote:

> Typical solution to the X service needs to create something it service Y
> where user has permission to X but not to Y is to treat the actions on Y
> performed by X to be trusted. Often I have seen this implemented such that
> after asserting permission on "create" on X that X performs actions on Y as
> a trusted principal, like a "SYSTEM" user. The other option is to give each
> service a trusted account and elevate to "SERVICE-X" where Y would allow
> "SERVICE-X" to perform some set of operations.
>
> See
> https://docs.oracle.com/javase/7/docs/api/javax/
> security/auth/Subject.html#doAs(javax.security.auth.
> Subject,%20java.security.PrivilegedAction
> )
>
> -Jake
>
>
> On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz  wrote:
>
> > We have seen users who need per-Region permission for Data read/write, so
> > there is precedent there at least.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >
> > On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra <
> pulkit.chan...@gmail.com>
> > wrote:
> >
> > > For per instance permission, I would say look for the evidence. Do we
> > have
> > > evidence that customers want per instance permission? If not may be
> > > implement minimally in the first cut and validate with customers if
> they
> > > want per instance model?
> > >
> > > About Lucene concern, It is in fact good to provide permission for per
> > > logical operation that implementation is doing. This will align the
> > > security permission with operations performed and provide better design
> > of
> > > a role. I would argue if you are able to perform 2 logically separate
> > > operations with single permission is perhaps a smell that you might not
> > > have enough permissions.
> > >
> > > my $0.02
> > >
> > > On Wed, 26 Apr 2017 at 16:54 Dan Smith  wrote:
> > >
> > > > 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 <
> > > dhard...@pivotal.io>
> > > > 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 <
> > jbarr...@pivotal.io>
> > > > > > 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 <
> > jstew...@pivotal.io
> > > >
> > > > > > 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 

[jira] [Commented] (GEODE-1597) gfsh parameters are not validated

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1597:


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

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

* Use Spring's SimpleParser as a basis for command parsing
* reworked help/hint
* removing singleton CommandManager


> gfsh parameters are not validated
> -
>
> Key: GEODE-1597
> URL: https://issues.apache.org/jira/browse/GEODE-1597
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>
> As a result of fixing GEODE-835, we now do not validate parameters passed 
> into gfsh. For example
> {noformat}
> >gfsh start locator foo --name=loc1
> {noformat}
> will succeed even though foo is not a valid parameter. All options are 
> correctly validated though, so:
> {noformat}
> >gfsh start locator --name=loc1 --foo
> {noformat}
> will result in an error.



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

Re: Finer grained security

[Jacob Barrett]

Typical solution to the X service needs to create something it service Y
where user has permission to X but not to Y is to treat the actions on Y
performed by X to be trusted. Often I have seen this implemented such that
after asserting permission on "create" on X that X performs actions on Y as
a trusted principal, like a "SYSTEM" user. The other option is to give each
service a trusted account and elevate to "SERVICE-X" where Y would allow
"SERVICE-X" to perform some set of operations.

See
https://docs.oracle.com/javase/7/docs/api/javax/security/auth/Subject.html#doAs(javax.security.auth.Subject,%20java.security.PrivilegedAction
)

-Jake


On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz  wrote:

> We have seen users who need per-Region permission for Data read/write, so
> there is precedent there at least.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra 
> wrote:
>
> > For per instance permission, I would say look for the evidence. Do we
> have
> > evidence that customers want per instance permission? If not may be
> > implement minimally in the first cut and validate with customers if they
> > want per instance model?
> >
> > About Lucene concern, It is in fact good to provide permission for per
> > logical operation that implementation is doing. This will align the
> > security permission with operations performed and provide better design
> of
> > a role. I would argue if you are able to perform 2 logically separate
> > operations with single permission is perhaps a smell that you might not
> > have enough permissions.
> >
> > my $0.02
> >
> > On Wed, 26 Apr 2017 at 16:54 Dan Smith  wrote:
> >
> > > 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 <
> > dhard...@pivotal.io>
> > > 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 <
> jbarr...@pivotal.io>
> > > > > 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 <
> jstew...@pivotal.io
> > >
> > > > > 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
> > > > 

Build failed in Jenkins: Geode-nightly #817

[Apache Jenkins Server]

See 

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on couchdb-macos1 (couchdb) in workspace 

java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Archiving artifacts
ERROR: Build step failed with exception
 does not exist.
at 
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:483)
at 
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:460)
at 
hudson.tasks.ArtifactArchiver$ListFiles.invoke(ArtifactArchiver.java:292)
at 
hudson.tasks.ArtifactArchiver$ListFiles.invoke(ArtifactArchiver.java:272)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2731)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at hudson.remoting.Engine$1$1.run(Engine.java:94)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to Channel to /91.65.50.62(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:822)
at hudson.FilePath.act(FilePath.java:985)
at hudson.FilePath.act(FilePath.java:974)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:237)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:78)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:665)
at hudson.model.Run.execute(Run.java:1753)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)

[jira] [Updated] (GEODE-2642) Sometime client doesn't ping server in ping-interval

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra updated GEODE-2642:
---
Fix Version/s: 1.2.0

> Sometime client doesn't ping server in ping-interval
> 
>
> Key: GEODE-2642
> URL: https://issues.apache.org/jira/browse/GEODE-2642
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.2.0
>
>
> Client ping thread wakes up every "ping-interval" and then it checks whether 
> someone already did some operation on that server or not, in the last 
> ping-interval. If there is some operation, then it doesn't ping server and 
> wakes up again after ping-interval. But if operation happens just start of 
> the previous ping-interval then client thread will ping server after more 
> then ping-interval. This can cause an issue.  Thus to avoid this race 
> condition, now ping thread will wake up in ping-interval/2 and will make sure 
> it pings server.



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

[jira] [Resolved] (GEODE-2642) Sometime client doesn't ping server in ping-interval

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra resolved GEODE-2642.

Resolution: Fixed

> Sometime client doesn't ping server in ping-interval
> 
>
> Key: GEODE-2642
> URL: https://issues.apache.org/jira/browse/GEODE-2642
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.2.0
>
>
> Client ping thread wakes up every "ping-interval" and then it checks whether 
> someone already did some operation on that server or not, in the last 
> ping-interval. If there is some operation, then it doesn't ping server and 
> wakes up again after ping-interval. But if operation happens just start of 
> the previous ping-interval then client thread will ping server after more 
> then ping-interval. This can cause an issue.  Thus to avoid this race 
> condition, now ping thread will wake up in ping-interval/2 and will make sure 
> it pings server.



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

Fwd: ASF Board Report for Geode - Initial Reminder for May 2017

[Mark Bretl]

Hi Everyone,

Amazing how three months goes by so fast! We are approaching six months
since our TLP graduation and its time for another board report.

Do we have any volunteers to create a draft? No need to be a PMC member
either, anyone can be involved with writing the report. There is a template
on the Geode wiki [1].

Best regards,

--Mark

[1]:
https://cwiki.apache.org/confluence/display/GEODE/ASF+Board+Report+Template


-- Forwarded message --
From: Brett Porter 
Date: Wed, Apr 26, 2017 at 6:16 AM
Subject: ASF Board Report for Geode - Initial Reminder for May 2017
To: Mark Bretl 
Cc: priv...@geode.apache.org


This email was sent on behalf of the ASF Board.  It is an initial reminder
to
give you plenty of time to prepare the report.

According to board records, you are listed as the chair of a committee that
is
due to submit a report this month. [1] [2]

The meeting is scheduled for Wed, 17 May 2017 at 10:30 PDT and the deadline
for
submitting your report is 1 full week prior to that (Wed May 10th)!

Meeting times in other time zones:

  https://timeanddate.com/s/38ta

Please submit your report with sufficient time to allow the board members
to review and digest. Again, the very latest you should submit your report
is 1 full week (7days) prior to the board meeting (Wed May 10th).

If you feel that an error has been made, please consult [1] and if there
is still an issue then contact the board directly.

As always, PMC chairs are welcome to attend the board meeting.

Thanks,
The ASF Board

[1] - https://svn.apache.org/repos/private/committers/board/
committee-info.txt
[2] - https://svn.apache.org/repos/private/committers/board/calendar.txt
[3] - https://svn.apache.org/repos/private/committers/board/templates
[4] - https://reporter.apache.org/

Review Request 58813: GEODE-2776 After region is updated with loader, the ClientEvent is set with current entry version tag

[anilkumar gingade]

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

Review request for geode, Darrel Schneider, Eric Shu, and Lynn Gallinat.


Repository: geode


Description
---

When client does a get() which results in adding an entry by calling loader on 
server side, the client event returned back is not updated with the version tag 
that is created with the new entry on server. This results in client having a 
different version tag than the server side entry. If client has registered 
event, and is concurrently updating the entry (from get() call and an 
register-event from server), it could result in data consistency between client 
and server.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java 
8cdc517 
  
geode-core/src/test/java/org/apache/geode/internal/cache/AbstractDistributedRegionJUnitTest.java
 ba2f794 
  
geode-core/src/test/java/org/apache/geode/internal/cache/DistributedRegionJUnitTest.java
 7525f35 


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


Testing
---

Manual testing.
Running new unit test (added) with and without changes.
precheckin in progress.


Thanks,

anilkumar gingade

[jira] [Commented] (GEODE-2801) disk store backup can fail with ArrayIndexOutOfBoundsException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2801:


Commit c98bc8bdbf6a6f1f32031a1aba390a3b14edd6b4 in geode's branch 
refs/heads/feature/GEM-1299 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c98bc8b ]

GEODE-2801: change krfIds to be thread safe


> disk store backup can fail with ArrayIndexOutOfBoundsException
> --
>
> Key: GEODE-2801
> URL: https://issues.apache.org/jira/browse/GEODE-2801
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> A race condition exists in which a disk store backup may fail with an 
> ArrayIndexOutOfBoundsException when calling hasKrf. Here is an example call 
> stack:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 24
> at 
> it.unimi.dsi.fastutil.longs.LongOpenHashSet.contains(LongOpenHashSet.java:315)
> at 
> org.apache.geode.internal.cache.DiskInitFile.hasKrf(DiskInitFile.java:814)
> at org.apache.geode.internal.cache.Oplog.copyTo(Oplog.java:5724)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.finishBackup(DiskStoreImpl.java:4218)
> at 
> org.apache.geode.internal.cache.persistence.BackupManager.finishBackup(BackupManager.java:206)
> at 
> org.apache.geode.admin.internal.FinishBackupRequest.createResponse(FinishBackupRequest.java:101)
> {code}



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2816:


Commit 70340783a4617f141b937ee960a0a373ebe0f46e in geode's branch 
refs/heads/feature/GEM-1299 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)

Re: Finer grained security

[Michael Stolz]

We have seen users who need per-Region permission for Data read/write, so
there is precedent there at least.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra 
wrote:

> For per instance permission, I would say look for the evidence. Do we have
> evidence that customers want per instance permission? If not may be
> implement minimally in the first cut and validate with customers if they
> want per instance model?
>
> About Lucene concern, It is in fact good to provide permission for per
> logical operation that implementation is doing. This will align the
> security permission with operations performed and provide better design of
> a role. I would argue if you are able to perform 2 logically separate
> operations with single permission is perhaps a smell that you might not
> have enough permissions.
>
> my $0.02
>
> On Wed, 26 Apr 2017 at 16:54 Dan Smith  wrote:
>
> > 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 <
> dhard...@pivotal.io>
> > 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 

[jira] [Commented] (GEODE-2723) remove "localCacheEnabled" dead code from PartitionedRegion

[ASF GitHub Bot (JIRA)]

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

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

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/440
  
Looks good to merge


> remove "localCacheEnabled" dead code from PartitionedRegion
> ---
>
> Key: GEODE-2723
> URL: https://issues.apache.org/jira/browse/GEODE-2723
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> The PartionedRegion class has a final field named "localCacheEnabled". It is 
> always false and never set to true. We have 5 methods that test for it being 
> true and do a bunch of stuff. This dead code should be removed.



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

[GitHub] geode issue #440: GEODE-2723: Removed localCacheEnabled field, and associate...

[dschneider-pivotal]

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/440
  
Looks good to merge


---
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] [Updated] (GEODE-2786) CI failure: DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles_nameWithHyphen

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2786:

Component/s: (was: persistence)
 management

> CI failure: 
> DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles_nameWithHyphen
> --
>
> Key: GEODE-2786
> URL: https://issues.apache.org/jira/browse/GEODE-2786
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Lynn Gallinat
>  Labels: CI
>
> Failed in concourse GemFireIntegrationTest #706
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest > 
> aboveZeroDeletesPreviousFiles_nameWithHyphen FAILED
> org.junit.ComparisonFailure: [Unexpected files: 
> [/tmp/junit88809687228487/psin8p724_cache1-statistics-02-01.gfs, 
> /tmp/junit88809687228487/psin8p724_cache1-statistics-02-02.gfs, 
> /tmp/junit88809687228487/psin8p724_cache1-statistics.gfs]] expected:<[2]> 
> but was:<[3]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.validateNumberFiles(DiskSpaceLimitIntegrationTest.java:263)
> at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles_nameWithHyphen(DiskSpaceLimitIntegrationTest.java:251)



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

Re: Finer grained security

[pulkit chandra]

For per instance permission, I would say look for the evidence. Do we have
evidence that customers want per instance permission? If not may be
implement minimally in the first cut and validate with customers if they
want per instance model?

About Lucene concern, It is in fact good to provide permission for per
logical operation that implementation is doing. This will align the
security permission with operations performed and provide better design of
a role. I would argue if you are able to perform 2 logically separate
operations with single permission is perhaps a smell that you might not
have enough permissions.

my $0.02

On Wed, 26 Apr 2017 at 16:54 Dan Smith  wrote:

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

[jira] [Updated] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-2811:

Affects Version/s: 1.0.0-incubating
   1.1.0
   1.1.1

> Thread leak when offheap memory is configured
> -
>
> Key: GEODE-2811
> URL: https://issues.apache.org/jira/browse/GEODE-2811
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> If you are using offheap memory and keep creating and close the cache over 
> and over then you may run out of threads.
> Each time the cache is initialized it creates a thread pool to handle offheap 
> LRU eviction. The thread pool should be closed when the cache is closed but 
> is not.
> The can lead to an exception like this:
> {quote}
> java.lang.OutOfMemoryError: unable to create new native thread
> {quote}
> The threads will be cleaned up if the garbage collector has a major enough 
> collection to force java object finalization but that may never happen since 
> offheap is being used.



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

[jira] [Resolved] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

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

Darrel Schneider resolved GEODE-2811.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> Thread leak when offheap memory is configured
> -
>
> Key: GEODE-2811
> URL: https://issues.apache.org/jira/browse/GEODE-2811
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> If you are using offheap memory and keep creating and close the cache over 
> and over then you may run out of threads.
> Each time the cache is initialized it creates a thread pool to handle offheap 
> LRU eviction. The thread pool should be closed when the cache is closed but 
> is not.
> The can lead to an exception like this:
> {quote}
> java.lang.OutOfMemoryError: unable to create new native thread
> {quote}
> The threads will be cleaned up if the garbage collector has a major enough 
> collection to force java object finalization but that may never happen since 
> offheap is being used.



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

[jira] [Commented] (GEODE-2811) Thread leak when offheap memory is configured

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2811:


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

GEODE-2811: close OffHeapEvictor when cache is closed

Rejected executions are now ignored if shutting down.
execute now used instead of submit.
Close logic on HeapEvictor improved to prevent race conditions and NPEs.


> Thread leak when offheap memory is configured
> -
>
> Key: GEODE-2811
> URL: https://issues.apache.org/jira/browse/GEODE-2811
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>  Labels: storage_2
>
> If you are using offheap memory and keep creating and close the cache over 
> and over then you may run out of threads.
> Each time the cache is initialized it creates a thread pool to handle offheap 
> LRU eviction. The thread pool should be closed when the cache is closed but 
> is not.
> The can lead to an exception like this:
> {quote}
> java.lang.OutOfMemoryError: unable to create new native thread
> {quote}
> The threads will be cleaned up if the garbage collector has a major enough 
> collection to force java object finalization but that may never happen since 
> offheap is being used.



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

[jira] [Updated] (GEODE-2554) Geode incubator docs are still up

[Joey McAllister (JIRA)]

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

Joey McAllister updated GEODE-2554:
---
Priority: Minor  (was: Major)

> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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

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

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

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-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

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)

[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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2689:


Commit 6f33bbc8eed60c99cc511d781f3d984766e02eb1 in geode's branch 
refs/heads/feature/GEM-1299 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6f33bbc ]

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2802:


Commit f3bd4d8d57bdbed0956f1117983fdd22deb717f8 in geode's branch 
refs/heads/feature/GEM-1299 from [~agingade]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f3bd4d8 ]

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] [Commented] (GEODE-2821) Geode User Guide: Add running heads with logo

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2821:


Commit 668f8f4e9de05a22f16b0903050e490edddc6a2d in geode's branch 
refs/heads/feature/GEM-1299 from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=668f8f4 ]

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)

[jira] [Commented] (GEODE-2801) disk store backup can fail with ArrayIndexOutOfBoundsException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2801:


Commit 003de33f217f854a9090386ae704d50bac57fe09 in geode's branch 
refs/heads/feature/GEM-1299 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=003de33 ]

GEODE-2801: change krfIds to be thread safe


> disk store backup can fail with ArrayIndexOutOfBoundsException
> --
>
> Key: GEODE-2801
> URL: https://issues.apache.org/jira/browse/GEODE-2801
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> A race condition exists in which a disk store backup may fail with an 
> ArrayIndexOutOfBoundsException when calling hasKrf. Here is an example call 
> stack:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 24
> at 
> it.unimi.dsi.fastutil.longs.LongOpenHashSet.contains(LongOpenHashSet.java:315)
> at 
> org.apache.geode.internal.cache.DiskInitFile.hasKrf(DiskInitFile.java:814)
> at org.apache.geode.internal.cache.Oplog.copyTo(Oplog.java:5724)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.finishBackup(DiskStoreImpl.java:4218)
> at 
> org.apache.geode.internal.cache.persistence.BackupManager.finishBackup(BackupManager.java:206)
> at 
> org.apache.geode.admin.internal.FinishBackupRequest.createResponse(FinishBackupRequest.java:101)
> {code}



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

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

[ASF subversion and git services (JIRA)]

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

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

Commit 9e5dfa45a6ffb25dcebb77bbfe55205784ce8e5d in geode's branch 
refs/heads/feature/GEM-1299 from [~adongre]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9e5dfa4 ]

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2681:


Commit b9c007b60a65be10f7b430e855df842d51f83239 in geode's branch 
refs/heads/feature/GEM-1299 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b9c007b ]

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)

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2816:


Commit c1a69140792b1d23ab9c467bb54c746550368b60 in geode's branch 
refs/heads/feature/GEM-1299 from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c1a6914 ]

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)

[jira] [Commented] (GEODE-2723) remove "localCacheEnabled" dead code from PartitionedRegion

[ASF GitHub Bot (JIRA)]

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

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

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/440
  
Is this ok to merge ?


> remove "localCacheEnabled" dead code from PartitionedRegion
> ---
>
> Key: GEODE-2723
> URL: https://issues.apache.org/jira/browse/GEODE-2723
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> The PartionedRegion class has a final field named "localCacheEnabled". It is 
> always false and never set to true. We have 5 methods that test for it being 
> true and do a bunch of stuff. This dead code should be removed.



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

[GitHub] geode issue #440: GEODE-2723: Removed localCacheEnabled field, and associate...

[davinash]

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/440
  
Is this ok to merge ?


---
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-2832) Fixing the link of README.md

[ASF GitHub Bot (JIRA)]

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

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

GitHub user masaki-yamakawa opened a pull request:

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

GEODE-2832: Fixing the link of README.md

Fixed an error in Markdown link notation of README.md.
- Delete the space between the display name and the destination URL.
- Fixed link destination of native-client-intro.html
- Fixed link of BUILDING.md

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

$ git pull https://github.com/masaki-yamakawa/geode-native 
feature/GEODE-2832

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

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


commit 1b0906193ce9f017aae1bd4906d749fd3e3e4c6e
Author: masaki.yamakawa 
Date:   2017-04-27T16:09:10Z

Fixing the link of README.md

Fixed an error in Markdown link notation of README.md.
Delete the space between the display name and the destination URL.

commit e87149a1b5bd68f67c6fe9886a7e921a5d93872c
Author: masaki.yamakawa 
Date:   2017-04-27T16:24:56Z

Fixing the link of README.md

Fixed an error in Markdown link notation of README.md.
- Fixed link destination of native-client-intro.html
- Fixed link of BUILDING.md




> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



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

[GitHub] geode-native pull request #95: GEODE-2832: Fixing the link of README.md

[masaki-yamakawa]

GitHub user masaki-yamakawa opened a pull request:

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

GEODE-2832: Fixing the link of README.md

Fixed an error in Markdown link notation of README.md.
- Delete the space between the display name and the destination URL.
- Fixed link destination of native-client-intro.html
- Fixed link of BUILDING.md

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

$ git pull https://github.com/masaki-yamakawa/geode-native 
feature/GEODE-2832

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

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


commit 1b0906193ce9f017aae1bd4906d749fd3e3e4c6e
Author: masaki.yamakawa 
Date:   2017-04-27T16:09:10Z

Fixing the link of README.md

Fixed an error in Markdown link notation of README.md.
Delete the space between the display name and the destination URL.

commit e87149a1b5bd68f67c6fe9886a7e921a5d93872c
Author: masaki.yamakawa 
Date:   2017-04-27T16:24:56Z

Fixing the link of README.md

Fixed an error in Markdown link notation of README.md.
- Fixed link destination of native-client-intro.html
- Fixed link of BUILDING.md




---
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 58751: GEODE-2632: make GemFireCacheImpl.getRegion(String) non-final

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On April 26, 2017, 8:54 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58751/
> ---
> 
> (Updated April 26, 2017, 8:54 p.m.)
> 
> 
> 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
> 
>

[jira] [Created] (GEODE-2832) Fixing the link of README.md

[Masaki Yamakawa (JIRA)]

Masaki Yamakawa created GEODE-2832:
--

 Summary: Fixing the link of README.md
 Key: GEODE-2832
 URL: https://issues.apache.org/jira/browse/GEODE-2832
 Project: Geode
  Issue Type: Bug
  Components: docs, native client
Reporter: Masaki Yamakawa


Fixed an error in Markdown link notation of README.md.
- Delete the space between the display name and the destination URL.
- Fixed link destination of native-client-intro.html
- Fixed link of BUILDING.md



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

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

[Barry Oglesby]

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


Ship it!




Ship It!

- Barry Oglesby


On April 26, 2017, 8:54 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58751/
> ---
> 
> (Updated April 26, 2017, 8:54 p.m.)
> 
> 
> 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
> 
>

Build failed in Jenkins: Geode-nightly #816

[Apache Jenkins Server]

See 

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on couchdb-macos1 (couchdb) in workspace 

java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Archiving artifacts
ERROR: Build step failed with exception
 does not exist.
at 
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:483)
at 
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:460)
at 
hudson.tasks.ArtifactArchiver$ListFiles.invoke(ArtifactArchiver.java:292)
at 
hudson.tasks.ArtifactArchiver$ListFiles.invoke(ArtifactArchiver.java:272)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2731)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at hudson.remoting.Engine$1$1.run(Engine.java:94)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to Channel to /91.65.50.62(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:822)
at hudson.FilePath.act(FilePath.java:985)
at hudson.FilePath.act(FilePath.java:974)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:237)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:78)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:665)
at hudson.model.Run.execute(Run.java:1753)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)

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

[nabarunnag]

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

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

Removed the flag and lucene precheckin was success.
Futher testing is ongoing


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

[ASF GitHub Bot (JIRA)]

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

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

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

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

Removed the flag and lucene precheckin was success.
Futher testing is ongoing


> 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)

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

[ASF GitHub Bot (JIRA)]

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

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

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

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

Changed it to createIndexObject - any better suggestion is welcomed 


> 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

[nabarunnag]

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

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

Changed it to createIndexObject - any better suggestion is welcomed 


---
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-2799) ClassCastException: java.lang.Long cannot be cast to org.apache.geode.internal.cache.AbstractRegionEntry could occur in race condition

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2799:


Commit b78a86edf180fd04fb797acc342206f4455e2257 in geode's branch 
refs/heads/feature/GEM-1299 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b78a86e ]

GEODE-2799: Handle different types of KeyInfo set when creating the KeySet 
Iterator.


> ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry could occur in race 
> condition
> --
>
> Key: GEODE-2799
> URL: https://issues.apache.org/jira/browse/GEODE-2799
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.2.0
>
>
> {noformat}
> java.lang.ClassCastException: java.lang.Long cannot be cast to 
> org.apache.geode.internal.cache.AbstractRegionEntry
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.getKeyForIterator(LocalRegionDataView.java:203)
> at 
> org.apache.geode.internal.cache.TXStateProxyImpl.getKeyForIterator(TXStateProxyImpl.java:766)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:159)
> at 
> org.apache.geode.internal.cache.EntriesSet$EntriesIterator.(EntriesSet.java:118)
> at org.apache.geode.internal.cache.EntriesSet.iterator(EntriesSet.java:83)
> at java.util.AbstractCollection.addAll(AbstractCollection.java:343)
> at java.util.TreeSet.addAll(TreeSet.java:312)
> at java.util.TreeSet.(TreeSet.java:160)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.initializeEventSeqNumQueue(BucketRegionQueue.java:145)
> at 
> org.apache.geode.internal.cache.BucketRegionQueue.cleanUpDestroyedTokensAndMarkGIIComplete(BucketRegionQueue.java:108)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1288)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:251)
> at 
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:960)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:736)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:424)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:282)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2860)
> at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.handleManageBucketRequest(PartitionedRegionDataStore.java:1001)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketOnMember(PRHARedundancyProvider.java:1214)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketInstance(PRHARedundancyProvider.java:390)
> at 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:578)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.createBucket(PartitionedRegion.java:3257)
> at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor$BucketSet$BucketSetIterator.next(RegionAdvisor.java:1422)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.getNextBucketIter(PartitionedRegion.java:6247)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterator.hasNext(PartitionedRegion.java:6220)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6322)
> at 
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet.toArray(PartitionedRegion.java:6316)
> at java.util.Collections$UnmodifiableCollection.toArray(Collections.java:1033)
> at java.util.ArrayList.addAll(ArrayList.java:577)
> {noformat}
> KeySet createIterator in transaction always creates keyset(). When a 
> transaction accesses the items, it suspends the transaction and assumes the 
> items provided by iterator are AbrstractRegionEntry.
> private void createIterator(final LocalRegion rgn) {
>   // TX iterates over KEYS.
>   // NonTX iterates over RegionEntry instances
>   this.currRgn = rgn;
>   this.currItr = view.getRegionKeysForIteration(rgn).iterator();
>   this.additionalKeysFromView = view.getAdditionalKeysForIterator(rgn);
> }



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: refactor code to use InternalCache instead of GemFireCacheImpl

* minor cleanup also


> 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-576) CI Failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction

[ASF subversion and git services (JIRA)]

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

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

Commit bc29d64b1486eeec0f019134d8b6d6f44fe852de in geode's branch 
refs/heads/feature/GEM-1299 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc29d64 ]

GEODE-576 & GEODE-516: GemFireDeadlockDetectorDUnitTest failures

Replaced pauses with Awaitility.  Modified asyncs to use the DUnit
blackboard to synchronize their actions for repeatable behavior.
Cleaned up static locks to allow their reuse in other tests or in
repeating the same test.


> CI Failure: 
> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction
> 
>
> Key: GEODE-576
> URL: https://issues.apache.org/jira/browse/GEODE-576
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Barry Oglesby
>  Labels: CI, Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests
> Private Build #612 (Nov 17, 2015 5:09:11 PM)
> Revision: 90b9a632b9738319fc7a7fddb93b6bef9ff57f7d
> Error Message
> {noformat}
> java.lang.Exception: An exception occured during async invocation
> {noformat}
> Stacktrace
> {noformat}
> java.lang.Exception: An exception occured during async invocation
>   at dunit.AsyncInvocation.getResult(AsyncInvocation.java:195)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:121)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> 

[jira] [Commented] (GEODE-516) GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has NullPointerException

[ASF subversion and git services (JIRA)]

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

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

Commit bc29d64b1486eeec0f019134d8b6d6f44fe852de in geode's branch 
refs/heads/feature/GEM-1299 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc29d64 ]

GEODE-576 & GEODE-516: GemFireDeadlockDetectorDUnitTest failures

Replaced pauses with Awaitility.  Modified asyncs to use the DUnit
blackboard to synchronize their actions for repeatable behavior.
Cleaned up static locks to allow their reuse in other tests or in
repeating the same test.


> GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction has 
> NullPointerException
> -
>
> Key: GEODE-516
> URL: https://issues.apache.org/jira/browse/GEODE-516
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: xiaojian zhou
>  Labels: Flaky, ShowDeadlockCommand
> Fix For: 1.2.0
>
>
> revision 0cc9d895b9f4465138d0fa223b0a0cadc1107893
> {noformat}
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.DeadlockDetector.prettyFormat(DeadlockDetector.java:151)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:118)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor215.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA

[jira] [Commented] (GEODE-2808) Deadlock in tomcat session module during session expiration

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2808:


Commit 80a95f6047ad64d165744f5ae4088b409484d50f in geode's branch 
refs/heads/feature/GEM-1299 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=80a95f6 ]

GEODE-2808 - Fixing lock ordering issues in DeltaSession

Region expiration of sessions and explicit expiration of sessions had
lock ordering issues. Fixing the code so that expiration goes through
the region entry lock first, before getting the lock on StandardSession.

Adding a workaround for the fact that liferay calls removeAttribute
from within session expiration by ignoreing remoteAttribute calls during
expiration.

This closes #472


> Deadlock in tomcat session module during session expiration
> ---
>
> Key: GEODE-2808
> URL: https://issues.apache.org/jira/browse/GEODE-2808
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> We observed a deadlock in the tomcat session state replication module due to 
> the way we do expiration. Here are the threads that are involved:
> {noformat}
> Found one Java-level deadlock:
> =
> "http-nio-21064-exec-2":
>   waiting to lock monitor 0x7f9a04bde298 (object 0x0007947da1f0, a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey),
>   which is held by "Timer-1"
> "Timer-1":
>   waiting to lock monitor 0x7f99a4004e38 (object 0x0007947da240, a 
> org.apache.geode.modules.session.catalina.DeltaSession8),
>   which is held by "http-nio-21064-exec-2"
> Java stack information for the threads listed above:
> ===
> "http-nio-21064-exec-2":
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1228)
>   - waiting to lock <0x0007947da1f0> (a 
> org.apache.geode.internal.cache.VersionedStatsLRURegionEntryHeapObjectKey)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6785)
>   at 
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6762)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:55)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6724)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1110)
>   at 
> org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1095)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:271)
>   at 
> org.apache.geode.modules.session.catalina.AbstractSessionCache.destroySession(AbstractSessionCache.java:72)
>   at 
> org.apache.geode.modules.session.catalina.DeltaSessionManager.remove(DeltaSessionManager.java:405)
>   at 
> org.apache.catalina.session.StandardSession.expire(StandardSession.java:850)
>   - locked <0x0007947da240> (a 
> org.apache.geode.modules.session.catalina.DeltaSession8)
>   at 
> org.apache.catalina.session.StandardSession.isValid(StandardSession.java:682)
>   at org.apache.catalina.connector.Request.doGetSession(Request.java:2917)
>   at org.apache.catalina.connector.Request.getSession(Request.java:2367)
>   at 
> org.apache.geode.modules.session.catalina.CommitSessionValve.invoke(CommitSessionValve.java:50)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>   at 
> org.apache.geode.modules.session.catalina.JvmRouteBinderValve.invoke(JvmRouteBinderValve.java:46)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
>   at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
>   at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>   at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1437)
>   at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>   - locked 

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


Commit 5a8d03d740bb586cf4d3197c1052ca0952fb1714 in geode's branch 
refs/heads/feature/GEM-1299 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5a8d03d ]

GEODE-2632: refactor code to reduce GemFireCacheImpl dependencies

* extract fetching GemFireCacheImpl to Provider interface/class
* use InternalCache instead of casting to Impl
* delete useless javadocs and comments
* reduce scope of constants, vars and methods


> 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)