[jira] [Created] (GEODE-2487) SSL should not require external security library

[Jacob S. Barrett (JIRA)]

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

 Summary: SSL should not require external security library
 Key: GEODE-2487
 URL: https://issues.apache.org/jira/browse/GEODE-2487
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Jacob S. Barrett


Geode Native requires that securityImpl library be compiled by the end user to 
support SSL. The rational for this has been lost but was likely to avoid either 
export control, which it does not, or to make dynamic loading of OpenSSL 
easier, which I am not sure it does.

Refactor SSL sockets to initialize and use OpenSSL (via ACE_SSL) directly and 
remove it from securityImpl library. If there is no other purpose for 
securityImpl library then purge it.



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

[jira] [Commented] (GEODE-2486) SSL ciphers other than NULL not supported

[ASF GitHub Bot (JIRA)]

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

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

GitHub user pivotal-jbarrett opened a pull request:

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

GEODE-2486: Initialize OpenSSL for DEFAULT cipher support.

- Init SSLv23_client mode to support negotiation of all SSL/TLS
  versions.
- Cleanup C++ style issues.
- Update tests to use NON-NULL cipher.

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

$ git pull https://github.com/pivotal-jbarrett/geode-native 
feature/GEODE-2486

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

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


commit ad8b5a83bac8d972d7ad46bbee201b056c1d436d
Author: Jacob Barrett 
Date:   2017-02-15T06:28:05Z

GEODE-2486: Initialize OpenSSL for DEFAULT cipher support.

- Init SSLv23_client mode to support negotiation of all SSL/TLS
  versions.
- Cleanup C++ style issues.
- Update tests to use NON-NULL cipher.




> SSL ciphers other than NULL not supported
> -
>
> Key: GEODE-2486
> URL: https://issues.apache.org/jira/browse/GEODE-2486
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Jacob S. Barrett
>
> SSLImpl does not correctly initialize the OpenSSL library so ciphers other 
> than the NULL cipher can be used.



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

[GitHub] geode-native pull request #11: GEODE-2486: Initialize OpenSSL for DEFAULT ci...

[pivotal-jbarrett]

GitHub user pivotal-jbarrett opened a pull request:

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

GEODE-2486: Initialize OpenSSL for DEFAULT cipher support.

- Init SSLv23_client mode to support negotiation of all SSL/TLS
  versions.
- Cleanup C++ style issues.
- Update tests to use NON-NULL cipher.

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

$ git pull https://github.com/pivotal-jbarrett/geode-native 
feature/GEODE-2486

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

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


commit ad8b5a83bac8d972d7ad46bbee201b056c1d436d
Author: Jacob Barrett 
Date:   2017-02-15T06:28:05Z

GEODE-2486: Initialize OpenSSL for DEFAULT cipher support.

- Init SSLv23_client mode to support negotiation of all SSL/TLS
  versions.
- Cleanup C++ style issues.
- Update tests to use NON-NULL cipher.




---
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] [Created] (GEODE-2486) SSL ciphers other than NULL not supported

[Jacob S. Barrett (JIRA)]

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

 Summary: SSL ciphers other than NULL not supported
 Key: GEODE-2486
 URL: https://issues.apache.org/jira/browse/GEODE-2486
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Jacob S. Barrett


SSLImpl does not correctly initialize the OpenSSL library so ciphers other than 
the NULL cipher can be used.




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

Re: [DISCUSS] JIRA guidelines

[William Markito Oliveira]

+1 

Finally!! ;)

Sent from my iPhone

> On Feb 14, 2017, at 7:59 PM, Galen M O'Sullivan  wrote:
> 
> +1 to the article and removing the draft label
> 
>> On Tue, Feb 14, 2017 at 4:05 PM, Akihiro Kitada  wrote:
>> 
>> I agree!
>> 
>> 
>> --
>> Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
>> Support.Pivotal.io   |  Mon-Fri  9:00am to
>> 5:30pm JST  |  1-877-477-2269
>> [image: support]  [image: twitter]
>>  [image: linkedin]
>>  [image: facebook]
>>  [image: google plus]
>>  [image: youtube]
>> 
>> 
>> 
>> 2017-02-15 8:47 GMT+09:00 Dan Smith :
>> 
>>> We have this draft of JIRA guidelines sitting on the wiki. I updated it
>>> slightly. Can we agree on these guidelines and remove the draft label? Is
>>> there more that needs to be here?
>>> 
>>> https://cwiki.apache.org/confluence/pages/viewpage.
>> action?pageId=57311462
>>> 
>>> -Dan
>>> 
>> 

Re: GeodeRedisAdapter improvments/feedback

[Hitesh Khamesra]

How's going on. What are you working these days.

Sent from Yahoo Mail on Android 
 
  On Tue, Feb 14, 2017 at 4:16 PM, William Markito 
Oliveira wrote:   Definitely not by asking in the 
middle of on-going  discussion threads. 

Instructions: http://bfy.tw/A5ub :)

Sent from my iPhone

> On Feb 14, 2017, at 6:38 PM, Michael Vos  wrote:
> 
> How do I unsubscribe from this email list?
> 
> Thank you, 
> 
> Michael Vos
> Strategic Partnerships
> 310-804-7223 | m...@pivotal.io
> 
> 
> 
> 
> 
>> On Feb 14, 2017, at 3:37 PM, Dan Smith  wrote:
>> 
>> I also had a hard time reading this. It sounds like the tl;dr is that your 
>> are proposing storing each redis collection in a single region entry, rather 
>> than a a partition region? I guess the question is whether users will have a 
>> few very large collections that need to be partitioned, or lots and lots of 
>> really tiny collections. I'm not quite sure what the more common use case is.
>> 
>> -Dan
>> 
>>> On Tue, Feb 14, 2017 at 3:22 PM, Swapnil Bawaskar  
>>> wrote:
>>> The Redis adapter was designed so that we can scale all the Redis data 
>>> structures horizontally. If you bring the data structures to region entry 
>>> level, there is no reason for anyone to use our implementation over Redis.
>>> 
 On Tue, Feb 14, 2017 at 3:15 PM Jason Huynh  wrote:
 Hi Hitesh,
 
 Not sure about everyone else, but I had a hard time reading this,  however 
 I think I figured out what you were describing... the only part I still am 
 unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean 
 you want feedback and voting on whether both behaviors are desired?  As in 
 old implementation and new implementation?
 
 2,3,4)  The new implementation would mean all the data for a specific data 
 structure is contained in a single bucket.  So the individual data 
 structures are not quite scalable.  How would you allow scaling of a 
 single data structure?
 
 On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:
 In what format do you want the feedback Hitesh?  For now I’ll just comment:
 
 1. Redis Type String
 No comments except that a future Geode value-add would be to extend the 
 Jedis client so that the K/V’s are not compressed. In this way OQL and CQ 
 will work.  The tradeoff of this is that the data cannot be read by a 
 native redis client but for Geode users it’s great. Call the new client 
 Geodis.
 
 2. List/ Hash/ Set/ SortedSet
 Creating a separate region for each creates a constraint that the keys are 
 limited to the characters for region names, which are A-z/0-9/ - and _.  
 Everything else is out. Redis users might start asking questions why their 
 list named ++^^/## throws an error. Your suggestion to make it a key 
 rather than a region solves this. Furthermore, creating a new region every 
 time a new Redis collection is created is going to be slow. I’m not sure 
 why a region was created but I’m sure it made sense to the developer at 
 the time.
 
 7. Default Config
 Can’t we configure a gfsh option to default to the region types we want?  
 Customer A will want PARTITION but Customer B will want 
 PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a 
 geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT 
 that makes _all_ Redis regions of that type?
 
 
 
 On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra 
 mailto:hitesh...@yahoo.com>> wrote:
 
 Current GeodeRedisAdapter implementation is based on 
 https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal.
 We are looking for some feedback on Redis commands and their mapping to 
 geode region.
 
 1. Redis Type String
  a. Usage Set k1 v1
  b. Current implementation creates "STRING_REGION" geode-partition-region 
upfront
  c. This k1/v1 are geode-region key/value
  d. Any feedback?
 
 2. List Type
  a. usage "rpush mylist A"
  b. Current implementation maps each list to geode-partition-region(i.e. 
mylist is geode-partition-region); with the ability to get item from 
head/tail
  c. Feedback/vote
      -- List type operation at region-entry level;
      -- region-key = "mylist"
      -- region-value = Arraylist (will support all redis list ops)
  d. Feedback/vote: both behavior is desirable
 
 
 3. Hashes
  a. this represents field-value or java bean object
  b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
  c. Current implementation maps each hashes to geode-partition-region(i.e. 
user1000 is geode-partition-region)
  d. Feedback/vote
    -- Should we map hashes to region-entry
    -- region-key = user1000
    -- region-value = map
    -- This will provide java bean sort to behaviour with 10s of field-

Re: GeodeRedisAdapter improvments/feedback

[Jason Huynh]

The concern about the threshold to spill over would be do you "unspill"
over?  Like what if the collection contracts under the threshold and
teeters around the threshold.  If the user can configure this size, then
wouldn't they just know they want a "large" vs a "small?"

I think Swapnil makes a good point that our value add would be that we can
scale those structures, whereas redis can already do what the "new"
implementation is doing.



On Tue, Feb 14, 2017 at 4:59 PM Galen M O'Sullivan 
wrote:

> If we put them in separate regions, we'll have the overhead of looking up
> in two regions added to each and every operation, and the overhead of
> creating all these regions.
>
> If we really wanted to we could have some threshold at which we spill
> collections over into their own regions, and have something like the best
> of both worlds. It's more complex, though, and I don't know how many people
> actually use truly huge collections.
>
> On Tue, Feb 14, 2017 at 4:21 PM, Hitesh Khamesra <
> hitesh...@yahoo.com.invalid> wrote:
>
> > Jason/Dan: Sorry to hear about that. But both of you have asked the right
> > question.
> > it depends on your use-case(item 2,3,4,5) . For example "hashes" can be
> > use to define key-value pair or java bean. In this case  probably it is
> > better to keep that hash at region-entry level.  But if you want to know
> > top 10 tweets which are trending then probably you want use
> > partition-region for "sorted-set".
> >
> >
> >   From: Jason Huynh 
> >  To: dev@geode.apache.org; "u...@geode.apache.org" <
> u...@geode.apache.org>;
> > Hitesh Khamesra 
> >  Sent: Tuesday, February 14, 2017 3:15 PM
> >  Subject: Re: GeodeRedisAdapter improvments/feedback
> >
> > Hi Hitesh,
> >
> > Not sure about everyone else, but I had a hard time reading this,
> however
> > I think I figured out what you were describing... the only part I still
> am
> > unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean
> > you want feedback and voting on whether both behaviors are desired?  As
> in
> > old implementation and new implementation?
> >
> > 2,3,4)  The new implementation would mean all the data for a specific
> data
> > structure is contained in a single bucket.  So the individual data
> > structures are not quite scalable.  How would you allow scaling of a
> single
> > data structure?
> >
> > On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:
> >
> > > In what format do you want the feedback Hitesh?  For now I’ll just
> > comment:
> > >
> > > 1. Redis Type String
> > > No comments except that a future Geode value-add would be to extend the
> > > Jedis client so that the K/V’s are not compressed. In this way OQL and
> CQ
> > > will work.  The tradeoff of this is that the data cannot be read by a
> > > native redis client but for Geode users it’s great. Call the new client
> > > Geodis.
> > >
> > > 2. List/ Hash/ Set/ SortedSet
> > > Creating a separate region for each creates a constraint that the keys
> > are
> > > limited to the characters for region names, which are A-z/0-9/ - and _.
> > > Everything else is out. Redis users might start asking questions why
> > their
> > > list named ++^^/## throws an error. Your suggestion to make it a key
> > rather
> > > than a region solves this. Furthermore, creating a new region every
> time
> > a
> > > new Redis collection is created is going to be slow. I’m not sure why a
> > > region was created but I’m sure it made sense to the developer at the
> > time.
> > >
> > > 7. Default Config
> > > Can’t we configure a gfsh option to default to the region types we
> want?
> > > Customer A will want PARTITION but Customer B will want
> > > PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider
> > a
> > > geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_
> > PERSISTENT
> > > that makes _all_ Redis regions of that type?
> > >
> > >
> > >
> > > On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra  >  > > hitesh...@yahoo.com>> wrote:
> > >
> > > Current GeodeRedisAdapter implementation is based on
> > > https://cwiki.apache.org/confluence/display/GEODE/
> > Geode+Redis+Adapter+Proposal
> > > .
> > > We are looking for some feedback on Redis commands and their mapping to
> > > geode region.
> > >
> > > 1. Redis Type String
> > >  a. Usage Set k1 v1
> > >  b. Current implementation creates "STRING_REGION"
> geode-partition-region
> > > upfront
> > >  c. This k1/v1 are geode-region key/value
> > >  d. Any feedback?
> > >
> > > 2. List Type
> > >  a. usage "rpush mylist A"
> > >  b. Current implementation maps each list to
> geode-partition-region(i.e.
> > > mylist is geode-partition-region); with the ability to get item from
> > > head/tail
> > >  c. Feedback/vote
> > >  -- List type operation at region-entry level;
> > >  -- region-key = "mylist"
> > >  -- region-value = Arraylist (will support all redis list ops)
> > >  d. Feedback/vote: both behavior is desirable
> > >
> > >
> > > 3. Hashes
> > >  a. this re

[jira] [Commented] (GEODE-2052) Docs to segregate types of properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2052:


Commit 09a92304a9e2373933c758744c6397fadb1f02d5 in geode's branch 
refs/heads/feature/GEODE-2052 from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=09a9230 ]

GEODE-2052: Docs to segregate types of properties
Added Server / Locator / Client labels to the list of GemFire properties.


> Docs to segregate types of properties
> -
>
> Key: GEODE-2052
> URL: https://issues.apache.org/jira/browse/GEODE-2052
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Pulkit Chandra
>Assignee: Dave Barnes
>
> Geode has a lot of properties. But they are not mentioned in context but 
> rather listed as geode properties which can go in geode.properties and 
> gfsecurity.properties.
> It would nice to have a segregation by Locator and Server under 
> geode.properties. The reason for this ask is that some properties do not 
> apply to both locator and server. Currently the only way to know this is by 
> experience or trial and error.
> ~~We also found out that some of the gemfire.properties do not get applied 
> when supplied in geode.properties but rather have to be passed as command 
> line properties. e.g. enabling rest api.
> It would be nice to call that out clearly in docs.~~
> ~~There are example of properties which have to be applied together in order 
> to enable a functionality e.g. rest api needs bind address property and 
> http-service-port. Its not called out clearly in the docs that they are 
> *mandatory*. ~~
> [link to docs 
> section](http://geode.incubator.apache.org/docs/guide/rest_apps/setup_config.html)
> ~~quote ~~
> ~~To enable the developer REST API service in Apache Geode, set the 
> start-dev-rest-api Geode property to true when starting a data node using 
> either gfsh or the ServerLauncher API. Setting this property to true on a 
> data node will start up an embedded Jetty server and deploy the REST 
> developer API WAR file.~~
> ~~It should highlight that its necessary to have 2 more properties 
> bind-address and http-service-port defined to make it work.~~
> We would be happy to provide further details on this matter if needed.



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

Re: GeodeRedisAdapter improvments/feedback

[Galen M O'Sullivan]

If we put them in separate regions, we'll have the overhead of looking up
in two regions added to each and every operation, and the overhead of
creating all these regions.

If we really wanted to we could have some threshold at which we spill
collections over into their own regions, and have something like the best
of both worlds. It's more complex, though, and I don't know how many people
actually use truly huge collections.

On Tue, Feb 14, 2017 at 4:21 PM, Hitesh Khamesra <
hitesh...@yahoo.com.invalid> wrote:

> Jason/Dan: Sorry to hear about that. But both of you have asked the right
> question.
> it depends on your use-case(item 2,3,4,5) . For example "hashes" can be
> use to define key-value pair or java bean. In this case  probably it is
> better to keep that hash at region-entry level.  But if you want to know
> top 10 tweets which are trending then probably you want use
> partition-region for "sorted-set".
>
>
>   From: Jason Huynh 
>  To: dev@geode.apache.org; "u...@geode.apache.org" ;
> Hitesh Khamesra 
>  Sent: Tuesday, February 14, 2017 3:15 PM
>  Subject: Re: GeodeRedisAdapter improvments/feedback
>
> Hi Hitesh,
>
> Not sure about everyone else, but I had a hard time reading this,  however
> I think I figured out what you were describing... the only part I still am
> unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean
> you want feedback and voting on whether both behaviors are desired?  As in
> old implementation and new implementation?
>
> 2,3,4)  The new implementation would mean all the data for a specific data
> structure is contained in a single bucket.  So the individual data
> structures are not quite scalable.  How would you allow scaling of a single
> data structure?
>
> On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:
>
> > In what format do you want the feedback Hitesh?  For now I’ll just
> comment:
> >
> > 1. Redis Type String
> > No comments except that a future Geode value-add would be to extend the
> > Jedis client so that the K/V’s are not compressed. In this way OQL and CQ
> > will work.  The tradeoff of this is that the data cannot be read by a
> > native redis client but for Geode users it’s great. Call the new client
> > Geodis.
> >
> > 2. List/ Hash/ Set/ SortedSet
> > Creating a separate region for each creates a constraint that the keys
> are
> > limited to the characters for region names, which are A-z/0-9/ - and _.
> > Everything else is out. Redis users might start asking questions why
> their
> > list named ++^^/## throws an error. Your suggestion to make it a key
> rather
> > than a region solves this. Furthermore, creating a new region every time
> a
> > new Redis collection is created is going to be slow. I’m not sure why a
> > region was created but I’m sure it made sense to the developer at the
> time.
> >
> > 7. Default Config
> > Can’t we configure a gfsh option to default to the region types we want?
> > Customer A will want PARTITION but Customer B will want
> > PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider
> a
> > geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_
> PERSISTENT
> > that makes _all_ Redis regions of that type?
> >
> >
> >
> > On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra   > hitesh...@yahoo.com>> wrote:
> >
> > Current GeodeRedisAdapter implementation is based on
> > https://cwiki.apache.org/confluence/display/GEODE/
> Geode+Redis+Adapter+Proposal
> > .
> > We are looking for some feedback on Redis commands and their mapping to
> > geode region.
> >
> > 1. Redis Type String
> >  a. Usage Set k1 v1
> >  b. Current implementation creates "STRING_REGION" geode-partition-region
> > upfront
> >  c. This k1/v1 are geode-region key/value
> >  d. Any feedback?
> >
> > 2. List Type
> >  a. usage "rpush mylist A"
> >  b. Current implementation maps each list to geode-partition-region(i.e.
> > mylist is geode-partition-region); with the ability to get item from
> > head/tail
> >  c. Feedback/vote
> >  -- List type operation at region-entry level;
> >  -- region-key = "mylist"
> >  -- region-value = Arraylist (will support all redis list ops)
> >  d. Feedback/vote: both behavior is desirable
> >
> >
> > 3. Hashes
> >  a. this represents field-value or java bean object
> >  b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
> >  c. Current implementation maps each hashes to
> > geode-partition-region(i.e. user1000 is geode-partition-region)
> >  d. Feedback/vote
> >-- Should we map hashes to region-entry
> >-- region-key = user1000
> >-- region-value = map
> >-- This will provide java bean sort to behaviour with 10s of
> > field-value
> >-- Personally I would prefer this..
> >  e. Feedback/vote: both behaviour is desirable
> >
> > 4. Sets
> >  a. This represents unique keys in set
> >  b. usage "sadd myset 1 2 3"
> >  c. Current implementation maps each sadd to geode-partition-region(i.e.
> > myset is geode-partition-region)
> >  d. Feedback

Re: [DISCUSS] JIRA guidelines

[Galen M O'Sullivan]

+1 to the article and removing the draft label

On Tue, Feb 14, 2017 at 4:05 PM, Akihiro Kitada  wrote:

> I agree!
>
>
> --
> Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
> Support.Pivotal.io   |  Mon-Fri  9:00am to
> 5:30pm JST  |  1-877-477-2269
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 
>
>
> 2017-02-15 8:47 GMT+09:00 Dan Smith :
>
> > We have this draft of JIRA guidelines sitting on the wiki. I updated it
> > slightly. Can we agree on these guidelines and remove the draft label? Is
> > there more that needs to be here?
> >
> > https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=57311462
> >
> > -Dan
> >
>

[jira] [Created] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2485:
---

 Summary: CacheTransactionManager suspend/resume can leak memory 
for 30 minutes
 Key: GEODE-2485
 URL: https://issues.apache.org/jira/browse/GEODE-2485
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Darrel Schneider


Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
allocated for 30 minutes. If you are doing a high rate of suspend/resume calls 
then this could cause you to run out of memory in that 30 minute window.

As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small as 
1 (which would cause the memory to be freed up after 1 minute instead of 30 
minutes).

One fix for this is to periodically call cache.getCCPTimer().timerPurge() after 
a certain number of resume calls have been done (for example 1000). Currently 
resume is calling cancel on the TimerTask but that leaves the task in the 
SystemTimer queue until it expires. Calling timerPurge it addition to cancel 
will fix this bug. Calling timerPurge for every cancel may cause the resume 
method to take too long and keep in mind the getCCPTimer is used by other 
things so the size of the SystemTimer queue that is being purged will not only 
be the number of suspended txs.



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

[jira] [Commented] (GEODE-2231) Create new partitioning example

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2231:


Commit 17fd0ab82e768afd88cb21a8c289c57da91c615c in geode-examples's branch 
refs/heads/feature/GEODE-2231 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode-examples.git;h=17fd0ab ]

GEODE-2231 Intermediate commit

- Producer expects an argument identifying which region to
populate
- Partial rewrite of the README.md file to present the
example in two parts


> Create new partitioning example
> ---
>
> Key: GEODE-2231
> URL: https://issues.apache.org/jira/browse/GEODE-2231
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> Add a new example to the geode-examples that demonstrates partitioning.
> The example will use the same structure as the replicated example, starting 2 
> servers that host a partitioned region (with no redundant copies).  Run the 
> producer to populate the region.  Run the consumer to see the contents of the 
> region. Then, stop one of the servers and run the consumer again to notice 
> that only roughly half (with 2 servers and hopefully a reasonable hash) of 
> the entries are present.



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

Re: GeodeRedisAdapter improvments/feedback

[Hitesh Khamesra]

Jason/Dan: Sorry to hear about that. But both of you have asked the right 
question.
it depends on your use-case(item 2,3,4,5) . For example "hashes" can be use to 
define key-value pair or java bean. In this case  probably it is better to keep 
that hash at region-entry level.  But if you want to know top 10 tweets which 
are trending then probably you want use partition-region for "sorted-set". 


  From: Jason Huynh 
 To: dev@geode.apache.org; "u...@geode.apache.org" ; 
Hitesh Khamesra  
 Sent: Tuesday, February 14, 2017 3:15 PM
 Subject: Re: GeodeRedisAdapter improvments/feedback
   
Hi Hitesh,

Not sure about everyone else, but I had a hard time reading this,  however
I think I figured out what you were describing... the only part I still am
unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean
you want feedback and voting on whether both behaviors are desired?  As in
old implementation and new implementation?

2,3,4)  The new implementation would mean all the data for a specific data
structure is contained in a single bucket.  So the individual data
structures are not quite scalable.  How would you allow scaling of a single
data structure?

On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:

> In what format do you want the feedback Hitesh?  For now I’ll just comment:
>
> 1. Redis Type String
> No comments except that a future Geode value-add would be to extend the
> Jedis client so that the K/V’s are not compressed. In this way OQL and CQ
> will work.  The tradeoff of this is that the data cannot be read by a
> native redis client but for Geode users it’s great. Call the new client
> Geodis.
>
> 2. List/ Hash/ Set/ SortedSet
> Creating a separate region for each creates a constraint that the keys are
> limited to the characters for region names, which are A-z/0-9/ - and _.
> Everything else is out. Redis users might start asking questions why their
> list named ++^^/## throws an error. Your suggestion to make it a key rather
> than a region solves this. Furthermore, creating a new region every time a
> new Redis collection is created is going to be slow. I’m not sure why a
> region was created but I’m sure it made sense to the developer at the time.
>
> 7. Default Config
> Can’t we configure a gfsh option to default to the region types we want?
> Customer A will want PARTITION but Customer B will want
> PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a
> geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT
> that makes _all_ Redis regions of that type?
>
>
>
> On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra  hitesh...@yahoo.com>> wrote:
>
> Current GeodeRedisAdapter implementation is based on
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal
> .
> We are looking for some feedback on Redis commands and their mapping to
> geode region.
>
> 1. Redis Type String
>  a. Usage Set k1 v1
>  b. Current implementation creates "STRING_REGION" geode-partition-region
> upfront
>  c. This k1/v1 are geode-region key/value
>  d. Any feedback?
>
> 2. List Type
>  a. usage "rpush mylist A"
>  b. Current implementation maps each list to geode-partition-region(i.e.
> mylist is geode-partition-region); with the ability to get item from
> head/tail
>  c. Feedback/vote
>      -- List type operation at region-entry level;
>      -- region-key = "mylist"
>      -- region-value = Arraylist (will support all redis list ops)
>  d. Feedback/vote: both behavior is desirable
>
>
> 3. Hashes
>  a. this represents field-value or java bean object
>  b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
>  c. Current implementation maps each hashes to
> geode-partition-region(i.e. user1000 is geode-partition-region)
>  d. Feedback/vote
>    -- Should we map hashes to region-entry
>    -- region-key = user1000
>    -- region-value = map
>    -- This will provide java bean sort to behaviour with 10s of
> field-value
>    -- Personally I would prefer this..
>  e. Feedback/vote: both behaviour is desirable
>
> 4. Sets
>  a. This represents unique keys in set
>  b. usage "sadd myset 1 2 3"
>  c. Current implementation maps each sadd to geode-partition-region(i.e.
> myset is geode-partition-region)
>  d. Feedback/vote
>    -- Should we map set to region-entry
>    -- region-key = myset
>    -- region-value = Hashset
>  e. Feedback/vote: both behaviour is desirable
>
> 5. SortedSets
>  a. This represents unique keys in set with score (usecase Query top-10)
>  b. usage "zadd hackers 1940 "Alan Kay""
>  c. Current implementation maps each zadd to geode-partition-region(i.e.
> hackers is geode-partition-region)
>  d. Feedback/vote
>    -- Should we map set to region-entry
>    -- region-key = hackers
>    -- region-value = Sorted Hashset
>  e. Feedback/vote: both behaviour is desirable
>
> 6. HyperLogLogs
>  a. A HyperLogLog is a probabilistic data structure used in order to
> count unique things (technically this is referred to estima

Re: GeodeRedisAdapter improvments/feedback

[William Markito Oliveira]

Definitely not by asking in the middle of on-going  discussion threads. 

Instructions: http://bfy.tw/A5ub :)

Sent from my iPhone

> On Feb 14, 2017, at 6:38 PM, Michael Vos  wrote:
> 
> How do I unsubscribe from this email list?
> 
> Thank you, 
> 
> Michael Vos
> Strategic Partnerships
> 310-804-7223 | m...@pivotal.io
> 
> 
> 
> 
> 
>> On Feb 14, 2017, at 3:37 PM, Dan Smith  wrote:
>> 
>> I also had a hard time reading this. It sounds like the tl;dr is that your 
>> are proposing storing each redis collection in a single region entry, rather 
>> than a a partition region? I guess the question is whether users will have a 
>> few very large collections that need to be partitioned, or lots and lots of 
>> really tiny collections. I'm not quite sure what the more common use case is.
>> 
>> -Dan
>> 
>>> On Tue, Feb 14, 2017 at 3:22 PM, Swapnil Bawaskar  
>>> wrote:
>>> The Redis adapter was designed so that we can scale all the Redis data 
>>> structures horizontally. If you bring the data structures to region entry 
>>> level, there is no reason for anyone to use our implementation over Redis.
>>> 
 On Tue, Feb 14, 2017 at 3:15 PM Jason Huynh  wrote:
 Hi Hitesh,
 
 Not sure about everyone else, but I had a hard time reading this,  however 
 I think I figured out what you were describing... the only part I still am 
 unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean 
 you want feedback and voting on whether both behaviors are desired?  As in 
 old implementation and new implementation?
 
 2,3,4)  The new implementation would mean all the data for a specific data 
 structure is contained in a single bucket.  So the individual data 
 structures are not quite scalable.  How would you allow scaling of a 
 single data structure?
 
 On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:
 In what format do you want the feedback Hitesh?  For now I’ll just comment:
 
 1. Redis Type String
 No comments except that a future Geode value-add would be to extend the 
 Jedis client so that the K/V’s are not compressed. In this way OQL and CQ 
 will work.  The tradeoff of this is that the data cannot be read by a 
 native redis client but for Geode users it’s great. Call the new client 
 Geodis.
 
 2. List/ Hash/ Set/ SortedSet
 Creating a separate region for each creates a constraint that the keys are 
 limited to the characters for region names, which are A-z/0-9/ - and _.  
 Everything else is out. Redis users might start asking questions why their 
 list named ++^^/## throws an error. Your suggestion to make it a key 
 rather than a region solves this. Furthermore, creating a new region every 
 time a new Redis collection is created is going to be slow. I’m not sure 
 why a region was created but I’m sure it made sense to the developer at 
 the time.
 
 7. Default Config
 Can’t we configure a gfsh option to default to the region types we want?  
 Customer A will want PARTITION but Customer B will want 
 PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a 
 geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT 
 that makes _all_ Redis regions of that type?
 
 
 
 On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra 
 mailto:hitesh...@yahoo.com>> wrote:
 
 Current GeodeRedisAdapter implementation is based on 
 https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal.
 We are looking for some feedback on Redis commands and their mapping to 
 geode region.
 
 1. Redis Type String
   a. Usage Set k1 v1
   b. Current implementation creates "STRING_REGION" geode-partition-region 
 upfront
   c. This k1/v1 are geode-region key/value
   d. Any feedback?
 
 2. List Type
   a. usage "rpush mylist A"
   b. Current implementation maps each list to geode-partition-region(i.e. 
 mylist is geode-partition-region); with the ability to get item from 
 head/tail
   c. Feedback/vote
   -- List type operation at region-entry level;
   -- region-key = "mylist"
   -- region-value = Arraylist (will support all redis list ops)
   d. Feedback/vote: both behavior is desirable
 
 
 3. Hashes
   a. this represents field-value or java bean object
   b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
   c. Current implementation maps each hashes to 
 geode-partition-region(i.e. user1000 is geode-partition-region)
   d. Feedback/vote
 -- Should we map hashes to region-entry
 -- region-key = user1000
 -- region-value = map
 -- This will provide java bean sort to behaviour with 10s of 
 field-value
 -- Personally I would prefer this..
   e. Feedback/vote: both behaviour is desirable
 
 4. Sets

Re: [DISCUSS] JIRA guidelines

[Akihiro Kitada]

I agree!


-- 
Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736
Support.Pivotal.io   |  Mon-Fri  9:00am to
5:30pm JST  |  1-877-477-2269
[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]



2017-02-15 8:47 GMT+09:00 Dan Smith :

> We have this draft of JIRA guidelines sitting on the wiki. I updated it
> slightly. Can we agree on these guidelines and remove the draft label? Is
> there more that needs to be here?
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311462
>
> -Dan
>

Re: [DISCUSS] JIRA guidelines

[Kenneth Howe]

+1 on the guidelines - can always be discussed and updated further as needed
+1 remove draft

> On Feb 14, 2017, at 3:47 PM, Dan Smith  wrote:
> 
> We have this draft of JIRA guidelines sitting on the wiki. I updated it
> slightly. Can we agree on these guidelines and remove the draft label? Is
> there more that needs to be here?
> 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311462
> 
> -Dan

Re: [DISCUSS] JIRA guidelines

[Jared Stewart]

+1 to removing the draft label

> On Feb 14, 2017, at 3:47 PM, Dan Smith  wrote:
> 
> We have this draft of JIRA guidelines sitting on the wiki. I updated it
> slightly. Can we agree on these guidelines and remove the draft label? Is
> there more that needs to be here?
> 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311462
> 
> -Dan

[DISCUSS] JIRA guidelines

[Dan Smith]

We have this draft of JIRA guidelines sitting on the wiki. I updated it
slightly. Can we agree on these guidelines and remove the draft label? Is
there more that needs to be here?

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311462

-Dan

Re: GeodeRedisAdapter improvments/feedback

[Michael Vos]

How do I unsubscribe from this email list?

Thank you, 

Michael Vos
Strategic Partnerships
310-804-7223 | m...@pivotal.io





> On Feb 14, 2017, at 3:37 PM, Dan Smith  wrote:
> 
> I also had a hard time reading this. It sounds like the tl;dr is that your 
> are proposing storing each redis collection in a single region entry, rather 
> than a a partition region? I guess the question is whether users will have a 
> few very large collections that need to be partitioned, or lots and lots of 
> really tiny collections. I'm not quite sure what the more common use case is.
> 
> -Dan
> 
> On Tue, Feb 14, 2017 at 3:22 PM, Swapnil Bawaskar  > wrote:
> The Redis adapter was designed so that we can scale all the Redis data 
> structures horizontally. If you bring the data structures to region entry 
> level, there is no reason for anyone to use our implementation over Redis.
> 
> On Tue, Feb 14, 2017 at 3:15 PM Jason Huynh  > wrote:
> Hi Hitesh,
> 
> Not sure about everyone else, but I had a hard time reading this,  however I 
> think I figured out what you were describing... the only part I still am 
> unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean you 
> want feedback and voting on whether both behaviors are desired?  As in old 
> implementation and new implementation?
> 
> 2,3,4)  The new implementation would mean all the data for a specific data 
> structure is contained in a single bucket.  So the individual data structures 
> are not quite scalable.  How would you allow scaling of a single data 
> structure?
> 
> On Tue, Feb 14, 2017 at 3:05 PM Real Wes  > wrote:
> In what format do you want the feedback Hitesh?  For now I’ll just comment:
> 
> 1. Redis Type String
> No comments except that a future Geode value-add would be to extend the Jedis 
> client so that the K/V’s are not compressed. In this way OQL and CQ will 
> work.  The tradeoff of this is that the data cannot be read by a native redis 
> client but for Geode users it’s great. Call the new client Geodis.
> 
> 2. List/ Hash/ Set/ SortedSet
> Creating a separate region for each creates a constraint that the keys are 
> limited to the characters for region names, which are A-z/0-9/ - and _.  
> Everything else is out. Redis users might start asking questions why their 
> list named ++^^/## throws an error. Your suggestion to make it a key rather 
> than a region solves this. Furthermore, creating a new region every time a 
> new Redis collection is created is going to be slow. I’m not sure why a 
> region was created but I’m sure it made sense to the developer at the time.
> 
> 7. Default Config
> Can’t we configure a gfsh option to default to the region types we want?  
> Customer A will want PARTITION but Customer B will want 
> PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a 
> geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT 
> that makes _all_ Redis regions of that type?
> 
> 
> 
> On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra   >> wrote:
> 
> Current GeodeRedisAdapter implementation is based on 
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal
>  
> .
> We are looking for some feedback on Redis commands and their mapping to geode 
> region.
> 
> 1. Redis Type String
>   a. Usage Set k1 v1
>   b. Current implementation creates "STRING_REGION" geode-partition-region 
> upfront
>   c. This k1/v1 are geode-region key/value
>   d. Any feedback?
> 
> 2. List Type
>   a. usage "rpush mylist A"
>   b. Current implementation maps each list to geode-partition-region(i.e. 
> mylist is geode-partition-region); with the ability to get item from head/tail
>   c. Feedback/vote
>   -- List type operation at region-entry level;
>   -- region-key = "mylist"
>   -- region-value = Arraylist (will support all redis list ops)
>   d. Feedback/vote: both behavior is desirable
> 
> 
> 3. Hashes
>   a. this represents field-value or java bean object
>   b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
>   c. Current implementation maps each hashes to geode-partition-region(i.e. 
> user1000 is geode-partition-region)
>   d. Feedback/vote
> -- Should we map hashes to region-entry
> -- region-key = user1000
> -- region-value = map
> -- This will provide java bean sort to behaviour with 10s of field-value
> -- Personally I would prefer this..
>   e. Feedback/vote: both behaviour is desirable
> 
> 4. Sets
>   a. This represents unique keys in set
>   b. usage "sadd myset 1 2 3"
>   c. Current implementation maps each sadd to geode-partition-region(i.e. 
> myset is geode-partition-region)
>   d. Feedback/vote
> -- Should we map set to region-entry
> -- region-ke

Re: GeodeRedisAdapter improvments/feedback

[Dan Smith]

I also had a hard time reading this. It sounds like the tl;dr is that your
are proposing storing each redis collection in a single region entry,
rather than a a partition region? I guess the question is whether users
will have a few very large collections that need to be partitioned, or lots
and lots of really tiny collections. I'm not quite sure what the more
common use case is.

-Dan

On Tue, Feb 14, 2017 at 3:22 PM, Swapnil Bawaskar 
wrote:

> The Redis adapter was designed so that we can scale all the Redis data
> structures horizontally. If you bring the data structures to region entry
> level, there is no reason for anyone to use our implementation over Redis.
>
> On Tue, Feb 14, 2017 at 3:15 PM Jason Huynh  wrote:
>
>> Hi Hitesh,
>>
>> Not sure about everyone else, but I had a hard time reading this,
>>  however I think I figured out what you were describing... the only part I
>> still am unsure about is  Feedback/vote: both behaviour is desirable.  Do
>> you mean you want feedback and voting on whether both behaviors are
>> desired?  As in old implementation and new implementation?
>>
>> 2,3,4)  The new implementation would mean all the data for a specific
>> data structure is contained in a single bucket.  So the individual data
>> structures are not quite scalable.  How would you allow scaling of a single
>> data structure?
>>
>> On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:
>>
>> In what format do you want the feedback Hitesh?  For now I’ll just
>> comment:
>>
>> 1. Redis Type String
>> No comments except that a future Geode value-add would be to extend the
>> Jedis client so that the K/V’s are not compressed. In this way OQL and CQ
>> will work.  The tradeoff of this is that the data cannot be read by a
>> native redis client but for Geode users it’s great. Call the new client
>> Geodis.
>>
>> 2. List/ Hash/ Set/ SortedSet
>> Creating a separate region for each creates a constraint that the keys
>> are limited to the characters for region names, which are A-z/0-9/ - and
>> _.  Everything else is out. Redis users might start asking questions why
>> their list named ++^^/## throws an error. Your suggestion to make it a key
>> rather than a region solves this. Furthermore, creating a new region every
>> time a new Redis collection is created is going to be slow. I’m not sure
>> why a region was created but I’m sure it made sense to the developer at the
>> time.
>>
>> 7. Default Config
>> Can’t we configure a gfsh option to default to the region types we want?
>> Customer A will want PARTITION but Customer B will want 
>> PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.
>> I wonder if we can consider a geode> create region —redisType=PARTITION_
>> REDUNDANT_EXPIRATION_PERSISTENT that makes _all_ Redis regions of that
>> type?
>>
>>
>>
>> On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra > hitesh...@yahoo.com>> wrote:
>>
>> Current GeodeRedisAdapter implementation is based on
>> https://cwiki.apache.org/confluence/display/GEODE/
>> Geode+Redis+Adapter+Proposal.
>> We are looking for some feedback on Redis commands and their mapping to
>> geode region.
>>
>> 1. Redis Type String
>>   a. Usage Set k1 v1
>>   b. Current implementation creates "STRING_REGION"
>> geode-partition-region upfront
>>   c. This k1/v1 are geode-region key/value
>>   d. Any feedback?
>>
>> 2. List Type
>>   a. usage "rpush mylist A"
>>   b. Current implementation maps each list to geode-partition-region(i.e.
>> mylist is geode-partition-region); with the ability to get item from
>> head/tail
>>   c. Feedback/vote
>>   -- List type operation at region-entry level;
>>   -- region-key = "mylist"
>>   -- region-value = Arraylist (will support all redis list ops)
>>   d. Feedback/vote: both behavior is desirable
>>
>>
>> 3. Hashes
>>   a. this represents field-value or java bean object
>>   b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
>>   c. Current implementation maps each hashes to
>> geode-partition-region(i.e. user1000 is geode-partition-region)
>>   d. Feedback/vote
>> -- Should we map hashes to region-entry
>> -- region-key = user1000
>> -- region-value = map
>> -- This will provide java bean sort to behaviour with 10s of
>> field-value
>> -- Personally I would prefer this..
>>   e. Feedback/vote: both behaviour is desirable
>>
>> 4. Sets
>>   a. This represents unique keys in set
>>   b. usage "sadd myset 1 2 3"
>>   c. Current implementation maps each sadd to geode-partition-region(i.e.
>> myset is geode-partition-region)
>>   d. Feedback/vote
>> -- Should we map set to region-entry
>> -- region-key = myset
>> -- region-value = Hashset
>>   e. Feedback/vote: both behaviour is desirable
>>
>> 5. SortedSets
>>   a. This represents unique keys in set with score (usecase Query top-10)
>>   b. usage "zadd hackers 1940 "Alan Kay""
>>   c. Current implementation maps each zadd to geode-partition-region(i.e.
>> hackers is geode-partition-region)
>>   d. Feedback/vote
>>   

Re: GeodeRedisAdapter improvments/feedback

[Swapnil Bawaskar]

The Redis adapter was designed so that we can scale all the Redis data
structures horizontally. If you bring the data structures to region entry
level, there is no reason for anyone to use our implementation over Redis.

On Tue, Feb 14, 2017 at 3:15 PM Jason Huynh  wrote:

> Hi Hitesh,
>
> Not sure about everyone else, but I had a hard time reading this,  however
> I think I figured out what you were describing... the only part I still am
> unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean
> you want feedback and voting on whether both behaviors are desired?  As in
> old implementation and new implementation?
>
> 2,3,4)  The new implementation would mean all the data for a specific data
> structure is contained in a single bucket.  So the individual data
> structures are not quite scalable.  How would you allow scaling of a single
> data structure?
>
> On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:
>
> In what format do you want the feedback Hitesh?  For now I’ll just comment:
>
> 1. Redis Type String
> No comments except that a future Geode value-add would be to extend the
> Jedis client so that the K/V’s are not compressed. In this way OQL and CQ
> will work.  The tradeoff of this is that the data cannot be read by a
> native redis client but for Geode users it’s great. Call the new client
> Geodis.
>
> 2. List/ Hash/ Set/ SortedSet
> Creating a separate region for each creates a constraint that the keys are
> limited to the characters for region names, which are A-z/0-9/ - and _.
> Everything else is out. Redis users might start asking questions why their
> list named ++^^/## throws an error. Your suggestion to make it a key rather
> than a region solves this. Furthermore, creating a new region every time a
> new Redis collection is created is going to be slow. I’m not sure why a
> region was created but I’m sure it made sense to the developer at the time.
>
> 7. Default Config
> Can’t we configure a gfsh option to default to the region types we want?
> Customer A will want PARTITION but Customer B will want
> PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a
> geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT
> that makes _all_ Redis regions of that type?
>
>
>
> On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra  hitesh...@yahoo.com>> wrote:
>
> Current GeodeRedisAdapter implementation is based on
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal
> .
> We are looking for some feedback on Redis commands and their mapping to
> geode region.
>
> 1. Redis Type String
>   a. Usage Set k1 v1
>   b. Current implementation creates "STRING_REGION" geode-partition-region
> upfront
>   c. This k1/v1 are geode-region key/value
>   d. Any feedback?
>
> 2. List Type
>   a. usage "rpush mylist A"
>   b. Current implementation maps each list to geode-partition-region(i.e.
> mylist is geode-partition-region); with the ability to get item from
> head/tail
>   c. Feedback/vote
>   -- List type operation at region-entry level;
>   -- region-key = "mylist"
>   -- region-value = Arraylist (will support all redis list ops)
>   d. Feedback/vote: both behavior is desirable
>
>
> 3. Hashes
>   a. this represents field-value or java bean object
>   b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
>   c. Current implementation maps each hashes to
> geode-partition-region(i.e. user1000 is geode-partition-region)
>   d. Feedback/vote
> -- Should we map hashes to region-entry
> -- region-key = user1000
> -- region-value = map
> -- This will provide java bean sort to behaviour with 10s of
> field-value
> -- Personally I would prefer this..
>   e. Feedback/vote: both behaviour is desirable
>
> 4. Sets
>   a. This represents unique keys in set
>   b. usage "sadd myset 1 2 3"
>   c. Current implementation maps each sadd to geode-partition-region(i.e.
> myset is geode-partition-region)
>   d. Feedback/vote
> -- Should we map set to region-entry
> -- region-key = myset
> -- region-value = Hashset
>   e. Feedback/vote: both behaviour is desirable
>
> 5. SortedSets
>   a. This represents unique keys in set with score (usecase Query top-10)
>   b. usage "zadd hackers 1940 "Alan Kay""
>   c. Current implementation maps each zadd to geode-partition-region(i.e.
> hackers is geode-partition-region)
>   d. Feedback/vote
> -- Should we map set to region-entry
> -- region-key = hackers
> -- region-value = Sorted Hashset
>   e. Feedback/vote: both behaviour is desirable
>
> 6. HyperLogLogs
>   a. A HyperLogLog is a probabilistic data structure used in order to
> count unique things (technically this is referred to estimating the
> cardinality of a set).
>   b. usage "pfadd hll a b c d"
>   c. Current implementation creates "HLL_REGION" geode-partition-region
> upfront
>   d. hll becomes region-key and value is HLL object
>   e. any feedback?
>
> 7. Default config for geode-reg

Re: GeodeRedisAdapter improvments/feedback

[Jason Huynh]

Hi Hitesh,

Not sure about everyone else, but I had a hard time reading this,  however
I think I figured out what you were describing... the only part I still am
unsure about is  Feedback/vote: both behaviour is desirable.  Do you mean
you want feedback and voting on whether both behaviors are desired?  As in
old implementation and new implementation?

2,3,4)  The new implementation would mean all the data for a specific data
structure is contained in a single bucket.  So the individual data
structures are not quite scalable.  How would you allow scaling of a single
data structure?

On Tue, Feb 14, 2017 at 3:05 PM Real Wes  wrote:

> In what format do you want the feedback Hitesh?  For now I’ll just comment:
>
> 1. Redis Type String
> No comments except that a future Geode value-add would be to extend the
> Jedis client so that the K/V’s are not compressed. In this way OQL and CQ
> will work.  The tradeoff of this is that the data cannot be read by a
> native redis client but for Geode users it’s great. Call the new client
> Geodis.
>
> 2. List/ Hash/ Set/ SortedSet
> Creating a separate region for each creates a constraint that the keys are
> limited to the characters for region names, which are A-z/0-9/ - and _.
> Everything else is out. Redis users might start asking questions why their
> list named ++^^/## throws an error. Your suggestion to make it a key rather
> than a region solves this. Furthermore, creating a new region every time a
> new Redis collection is created is going to be slow. I’m not sure why a
> region was created but I’m sure it made sense to the developer at the time.
>
> 7. Default Config
> Can’t we configure a gfsh option to default to the region types we want?
> Customer A will want PARTITION but Customer B will want
> PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a
> geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT
> that makes _all_ Redis regions of that type?
>
>
>
> On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra  hitesh...@yahoo.com>> wrote:
>
> Current GeodeRedisAdapter implementation is based on
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal
> .
> We are looking for some feedback on Redis commands and their mapping to
> geode region.
>
> 1. Redis Type String
>   a. Usage Set k1 v1
>   b. Current implementation creates "STRING_REGION" geode-partition-region
> upfront
>   c. This k1/v1 are geode-region key/value
>   d. Any feedback?
>
> 2. List Type
>   a. usage "rpush mylist A"
>   b. Current implementation maps each list to geode-partition-region(i.e.
> mylist is geode-partition-region); with the ability to get item from
> head/tail
>   c. Feedback/vote
>   -- List type operation at region-entry level;
>   -- region-key = "mylist"
>   -- region-value = Arraylist (will support all redis list ops)
>   d. Feedback/vote: both behavior is desirable
>
>
> 3. Hashes
>   a. this represents field-value or java bean object
>   b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
>   c. Current implementation maps each hashes to
> geode-partition-region(i.e. user1000 is geode-partition-region)
>   d. Feedback/vote
> -- Should we map hashes to region-entry
> -- region-key = user1000
> -- region-value = map
> -- This will provide java bean sort to behaviour with 10s of
> field-value
> -- Personally I would prefer this..
>   e. Feedback/vote: both behaviour is desirable
>
> 4. Sets
>   a. This represents unique keys in set
>   b. usage "sadd myset 1 2 3"
>   c. Current implementation maps each sadd to geode-partition-region(i.e.
> myset is geode-partition-region)
>   d. Feedback/vote
> -- Should we map set to region-entry
> -- region-key = myset
> -- region-value = Hashset
>   e. Feedback/vote: both behaviour is desirable
>
> 5. SortedSets
>   a. This represents unique keys in set with score (usecase Query top-10)
>   b. usage "zadd hackers 1940 "Alan Kay""
>   c. Current implementation maps each zadd to geode-partition-region(i.e.
> hackers is geode-partition-region)
>   d. Feedback/vote
> -- Should we map set to region-entry
> -- region-key = hackers
> -- region-value = Sorted Hashset
>   e. Feedback/vote: both behaviour is desirable
>
> 6. HyperLogLogs
>   a. A HyperLogLog is a probabilistic data structure used in order to
> count unique things (technically this is referred to estimating the
> cardinality of a set).
>   b. usage "pfadd hll a b c d"
>   c. Current implementation creates "HLL_REGION" geode-partition-region
> upfront
>   d. hll becomes region-key and value is HLL object
>   e. any feedback?
>
> 7. Default config for geode-region (vote)
>a. partition region
>b. 1 redundant copy
>c. Persistence
>d. Eviction
>e. Expiration
>f. ?
>
> 8. It seems; redis knows type(list, hashes, string ,set ..) of each key.
> Thus for each operation we need to make sure type of key. In current
> implementation we have 

Re: GeodeRedisAdapter improvments/feedback

[Real Wes]

In what format do you want the feedback Hitesh?  For now I’ll just comment:

1. Redis Type String
No comments except that a future Geode value-add would be to extend the Jedis 
client so that the K/V’s are not compressed. In this way OQL and CQ will work.  
The tradeoff of this is that the data cannot be read by a native redis client 
but for Geode users it’s great. Call the new client Geodis.

2. List/ Hash/ Set/ SortedSet
Creating a separate region for each creates a constraint that the keys are 
limited to the characters for region names, which are A-z/0-9/ - and _.  
Everything else is out. Redis users might start asking questions why their list 
named ++^^/## throws an error. Your suggestion to make it a key rather than a 
region solves this. Furthermore, creating a new region every time a new Redis 
collection is created is going to be slow. I’m not sure why a region was 
created but I’m sure it made sense to the developer at the time.

7. Default Config
Can’t we configure a gfsh option to default to the region types we want?  
Customer A will want PARTITION but Customer B will want 
PARTITION_REDUNDANT_EXPIRATION_PERSISTENT.  I wonder if we can consider a 
geode> create region —redisType=PARTITION_REDUNDANT_EXPIRATION_PERSISTENT that 
makes _all_ Redis regions of that type?



On Feb 14, 2017, at 5:36 PM, Hitesh Khamesra 
mailto:hitesh...@yahoo.com>> wrote:

Current GeodeRedisAdapter implementation is based on 
https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal.
We are looking for some feedback on Redis commands and their mapping to geode 
region.

1. Redis Type String
  a. Usage Set k1 v1
  b. Current implementation creates "STRING_REGION" geode-partition-region 
upfront
  c. This k1/v1 are geode-region key/value
  d. Any feedback?

2. List Type
  a. usage "rpush mylist A"
  b. Current implementation maps each list to geode-partition-region(i.e. 
mylist is geode-partition-region); with the ability to get item from head/tail
  c. Feedback/vote
  -- List type operation at region-entry level;
  -- region-key = "mylist"
  -- region-value = Arraylist (will support all redis list ops)
  d. Feedback/vote: both behavior is desirable


3. Hashes
  a. this represents field-value or java bean object
  b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
  c. Current implementation maps each hashes to geode-partition-region(i.e. 
user1000 is geode-partition-region)
  d. Feedback/vote
-- Should we map hashes to region-entry
-- region-key = user1000
-- region-value = map
-- This will provide java bean sort to behaviour with 10s of field-value
-- Personally I would prefer this..
  e. Feedback/vote: both behaviour is desirable

4. Sets
  a. This represents unique keys in set
  b. usage "sadd myset 1 2 3"
  c. Current implementation maps each sadd to geode-partition-region(i.e. myset 
is geode-partition-region)
  d. Feedback/vote
-- Should we map set to region-entry
-- region-key = myset
-- region-value = Hashset
  e. Feedback/vote: both behaviour is desirable

5. SortedSets
  a. This represents unique keys in set with score (usecase Query top-10)
  b. usage "zadd hackers 1940 "Alan Kay""
  c. Current implementation maps each zadd to geode-partition-region(i.e. 
hackers is geode-partition-region)
  d. Feedback/vote
-- Should we map set to region-entry
-- region-key = hackers
-- region-value = Sorted Hashset
  e. Feedback/vote: both behaviour is desirable

6. HyperLogLogs
  a. A HyperLogLog is a probabilistic data structure used in order to count 
unique things (technically this is referred to estimating the cardinality of a 
set).
  b. usage "pfadd hll a b c d"
  c. Current implementation creates "HLL_REGION" geode-partition-region upfront
  d. hll becomes region-key and value is HLL object
  e. any feedback?

7. Default config for geode-region (vote)
   a. partition region
   b. 1 redundant copy
   c. Persistence
   d. Eviction
   e. Expiration
   f. ?

8. It seems; redis knows type(list, hashes, string ,set ..) of each key. Thus 
for each operation we need to make sure type of key. In current implementation 
we have different region for each redis type. Thus we have another 
region(metaTypeRegion) which keeps type for each key. This makes any operation 
in geode slow as it needs to verify that type. For instance, creating new key 
need to make sure its already there or not. Whether we should allow type change 
or not.
  a. Feedback/vote
 -- type change of key
 -- Can we allow two key with same name but two differnt type (as it will 
endup in two different geode-region)
String type "key1" in string region
HLL type "key1" in HLL region
  b. any other feedback

9. Transactions:
  a. we will not support transaction in redisAdapter as geode transaction are 
limited to single node.
  b. feedback?

10. Redis COMMAND (https://redis.io/commands/command)
  a. should we implement this "COMMAND" ?

11. 

Re: Propose a new implementation for collections in Geode transaction (GEODE-2392)

[Hitesh Khamesra]

+1 for supporting repeatable read semantics consistently. throw 
Unsupportedexception if some apis are not supported inside tx. 
-Hitesh.  From: Anthony Baker 
 To: dev@geode.apache.org 
 Sent: Monday, February 13, 2017 8:08 AM
 Subject: Re: Propose a new implementation for collections in Geode transaction 
(GEODE-2392)
   
Questions:

1) Do you know why we don’t set detectReadConflicts [1] true by default?  I 
would guess that most users would not expect dirty reads in the context of a 
repeatable read isolation level.
2) In the case of non-local reads on a Partitioned Region, shouldn’t we throw a 
TransactionDataNotColocatedException?
3) Some cache operations throw an UnsupportedOperationInTransactionException.  
Is there a reason we don’t for containsValue()?


Anthony

[1] 
https://geode.apache.org/docs/guide/developing/transactions/transaction_semantics.html

> On Feb 10, 2017, at 12:23 PM, Anilkumar Gingade  wrote:
> 
> As Eric mentioned, this will address the current inconsistencies in the
> product and will provide consistent behavior with replicated and
> partitioned region.
> 
> Also, if we look into typical database transaction applications, the
> transaction queries doesn't touch/read all the records in the table, mostly
> or always they are targeted queries (with where clause) with small result
> set. In Geode case, without support for any filtering option with
> collection api's, it may have to bring in all the region entries into the
> Tx state, which application may not be looking for...The better solution to
> support this is by making Geode queries transactional; which can provide
> repeatable read semantic on sub-set data.
> 
> I agree, its hard for application to distinguish what apis are part of Tx
> and what is not...Option to address this could be, proper documentation or
> not allowing collection apis inside the Tx. In needed, application has to
> suspend the Tx, to call them.
> 
> -Anil.
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Feb 10, 2017 at 10:57 AM, Eric Shu  wrote:
> 
>> Hi Dan,
>> 
>> Currently query results do not reflect transaction state at all. The new
>> proposal won't change that.
>> 
>> On Fri, Feb 10, 2017 at 10:47 AM, Eric Shu  wrote:
>> 
>>> Please note even in our current transaction implementation, repeatable
>>> read is not supported on collection operation in transaction with
>>> Partitioned Region. Currently, only the local entry set (resides in the
>>> local node) of a PR is copied into the txState, while data on the remote
>>> nodes are not. Another call of the collection operation of the same
>>> transaction could have different results for the data on the remote
>> nodes.
>>> 
>>> In addition, containValue() call currently does not support repeatable
>>> read either. It does not copy all data into txState (replicated or
>>> partitioned regions.)
>>> 
>>> Currently we only support limited repeatable read for collection
>>> operations in transaction (at least for PR).
>>> 
>>> On Fri, Feb 10, 2017 at 8:36 AM, Anthony Baker 
>> wrote:
>>> 
 I tend to agree with Mike.  Removing collection reads from the txn state
 changes the programming model and makes it harder to write a Geode
 application.  We’re leaking internal details into the public behavior.
 
 Is there another way to provide this optimization to the user?  Perhaps
 something like:
 
    CacheTransactionManager txMgr = cache.getCacheTransactionManager();
    txMgr.begin(READ_COMMITTED);  // just thinking out loud here
 
 Or, we could set a hard cap on the size of txState.  Would that satisfy
 the original goal to ensure that users apply Geode txns correctly?
 
 Anthony
 
> On Feb 10, 2017, at 12:15 AM, Michael Stolz 
>> wrote:
> 
> -1
> 
> I would recommend against breaking repeatable read semantics for
 specific
> cases. If we're going to do something about the memory pressure,
>> great,
 but
> not at the cost of functionality guarantees.
> 
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
> 
> On Feb 9, 2017 10:29 PM, "Eric Shu"  wrote:
> 
> All,
> 
> In current Geode transaction implementation, there will be memory
 pressure
> if collection is used in a transaction. (GEODE-2392
> https://issues.apache.org/jira/browse/GEODE-2392).
> 
> Geode transactions provide repeatable read semantics. In order to
 support
> this repeatable read isolation, all read operations copy the current
 value
> in txState.
> 
> The proposed new implementation is to have collection operation in a
> transaction not copying all values into its txState. Instead, it will
>> go
> over to region directly but reflecting the new state of the entries
 changed
> by the previous operations of this transaction.
> 
> Please note that the proposed implementation will not support
>> repeatable
> 

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #472 was successful.
---
Scheduled
1681 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

GeodeRedisAdapter improvments/feedback

[Hitesh Khamesra]

Current GeodeRedisAdapter implementation is based on 
https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+Adapter+Proposal.
We are looking for some feedback on Redis commands and their mapping to geode 
region.

1. Redis Type String
  a. Usage Set k1 v1
  b. Current implementation creates "STRING_REGION" geode-partition-region 
upfront
  c. This k1/v1 are geode-region key/value
  d. Any feedback?
 
2. List Type
  a. usage "rpush mylist A"
  b. Current implementation maps each list to geode-partition-region(i.e. 
mylist is geode-partition-region); with the ability to get item from head/tail
  c. Feedback/vote
  -- List type operation at region-entry level;
  -- region-key = "mylist"
  -- region-value = Arraylist (will support all redis list ops)
  d. Feedback/vote: both behavior is desirable
  

3. Hashes
  a. this represents field-value or java bean object
  b. usage "hmset user1000 username antirez birthyear 1977 verified 1"
  c. Current implementation maps each hashes to geode-partition-region(i.e. 
user1000 is geode-partition-region)
  d. Feedback/vote
    -- Should we map hashes to region-entry
    -- region-key = user1000
    -- region-value = map
    -- This will provide java bean sort to behaviour with 10s of field-value
    -- Personally I would prefer this..
  e. Feedback/vote: both behaviour is desirable

4. Sets
  a. This represents unique keys in set
  b. usage "sadd myset 1 2 3" 
  c. Current implementation maps each sadd to geode-partition-region(i.e. myset 
is geode-partition-region)
  d. Feedback/vote
    -- Should we map set to region-entry
    -- region-key = myset
    -- region-value = Hashset
  e. Feedback/vote: both behaviour is desirable

5. SortedSets
  a. This represents unique keys in set with score (usecase Query top-10)
  b. usage "zadd hackers 1940 "Alan Kay"" 
  c. Current implementation maps each zadd to geode-partition-region(i.e. 
hackers is geode-partition-region)
  d. Feedback/vote
    -- Should we map set to region-entry
    -- region-key = hackers
    -- region-value = Sorted Hashset
  e. Feedback/vote: both behaviour is desirable

6. HyperLogLogs
  a. A HyperLogLog is a probabilistic data structure used in order to count 
unique things (technically this is referred to estimating the cardinality of a 
set).
  b. usage "pfadd hll a b c d"
  c. Current implementation creates "HLL_REGION" geode-partition-region upfront
  d. hll becomes region-key and value is HLL object
  e. any feedback?
  
7. Default config for geode-region (vote) 
   a. partition region
   b. 1 redundant copy
   c. Persistence
   d. Eviction
   e. Expiration
   f. ?
   
8. It seems; redis knows type(list, hashes, string ,set ..) of each key. Thus 
for each operation we need to make sure type of key. In current implementation 
we have different region for each redis type. Thus we have another 
region(metaTypeRegion) which keeps type for each key. This makes any operation 
in geode slow as it needs to verify that type. For instance, creating new key 
need to make sure its already there or not. Whether we should allow type change 
or not.
  a. Feedback/vote 
 -- type change of key
 -- Can we allow two key with same name but two differnt type (as it will 
endup in two different geode-region)
    String type "key1" in string region
    HLL type "key1" in HLL region
  b. any other feedback
  
9. Transactions:
  a. we will not support transaction in redisAdapter as geode transaction are 
limited to single node.
  b. feedback?
  
10. Redis COMMAND (https://redis.io/commands/command)
  a. should we implement this "COMMAND" ?
  
11. Any other redis command we should consider?
 

Thanks.Hitesh

[jira] [Created] (GEODE-2484) Remove ACE from native client dependencies

[David Kimura (JIRA)]

David Kimura created GEODE-2484:
---

 Summary: Remove ACE from native client dependencies
 Key: GEODE-2484
 URL: https://issues.apache.org/jira/browse/GEODE-2484
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: David Kimura


Remove ACE from native client dependencies.

Replace ACE usage with C++11 and/or Boost 1.63+



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

[jira] [Assigned] (GEODE-2477) CI Failure suspect string from returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-2477:
--

Assignee: Jason Huynh

> CI Failure  suspect string from 
> returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite
> 
>
> Key: GEODE-2477
> URL: https://issues.apache.org/jira/browse/GEODE-2477
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
>Assignee: Jason Huynh
>
> Revision dbea592cc96f64c9fbc7abf8bbf597a69c5881cd
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during 
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1450
> [error 2017/02/12 06:02:16.915 PST  GatewaySender_AsyncEventQueue_index#_region_1> tid=0x7a8] Unable to save to 
> lucene index
> org.apache.geode.cache.CacheClosedException: The cache has been closed
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1621)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:498)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation.distribute(AbstractUpdateOperation.java:70)
>   at 
> org.apache.geode.internal.cache.BucketRegion.basicPutPart2(BucketRegion.java:633)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
>   at 
> org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:485)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5194)
>   at 
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1605)
>   at 
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1592)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:277)
>   at 
> org.apache.geode.cache.lucene.internal.filesystem.FileSystem.putChunk(FileSystem.java:183)
>   at 
> org.apache.geode.cache.lucene.internal.filesystem.FileOutputStream.flushBuffer(FileOutputStream.java:90)
>   at 
> org.apache.geode.cache.lucene.internal.filesystem.FileOutputStream.close(FileOutputStream.java:78)
>   at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
>   at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
>   at 
> org.apache.lucene.store.OutputStreamIndexOutput.close(OutputStreamIndexOutput.java:70)
>   at 
> org.apache.lucene.codecs.compressing.CompressingStoredFieldsIndexWriter.close(CompressingStoredFieldsIndexWriter.java:210)
>   at org.apache.lucene.util.IOUtils.close(IOUtils.java:89)
>   at org.apache.lucene.util.IOUtils.close(IOUtils.java:76)
>   at 
> org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.close(CompressingStoredFieldsWriter.java:138)
>   at 
> org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:117)
>   at 
> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:423)
>   at 
> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:502)
>   at 
> org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:614)
>   at 
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2815)
>   at 
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
>   at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
>   at 
> org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImpl.commit(IndexRepositoryImpl.java:144)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneEventListener.processEvents(LuceneEventListener.java:88)
>   at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:154)
>   at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:80)
>   at 
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:593)
>   at 
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1036)
> {noformat}



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

[jira] [Created] (GEODE-2483) Allow developer to set security permissions within functions

[Diane Hardman (JIRA)]

Diane Hardman created GEODE-2483:


 Summary: Allow developer to set security permissions within 
functions
 Key: GEODE-2483
 URL: https://issues.apache.org/jira/browse/GEODE-2483
 Project: Geode
  Issue Type: Improvement
  Components: functions, security
Reporter: Diane Hardman


Currently users need DATA:WRITE permission to execute a function on the 
servers. As an application/function developer, I would like to specify in my 
function what permissions are required to execute it. 
Additionally, when I deploy my function to a cluster with security configured, 
if I have not specified user permissions, the deploy should fail.



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

Re: Gradle build for idea

[Udo Kohlmeyer]

Ok... just to clarify... I have imported the project into Idea using the 
build in gradle support.


But when I run the idea command on command line, that is when I see the 
failure. I was wondering if we should be concerned about this...


--Udo


On 2/14/17 13:33, Jinmei Liao wrote:

I do not need to run gradle command in order to use IDEA. I just imported
those modules, and IDEA will sort things out on its own.

On Tue, Feb 14, 2017 at 1:20 PM, Udo Kohlmeyer  wrote:


Hi there,

When I run `gradle idea` the following exception is thrown.

* What went wrong:
Execution failed for task ':geode-core:ideaModule'.

Cannot change dependencies of configuration ':geode-core:antlr' after it

has been included in dependency resolution.

Is this something that we can resolve? Any idea what could be causing this
failure?

--Udo

Re: Gradle build for idea

[Jinmei Liao]

I do not need to run gradle command in order to use IDEA. I just imported
those modules, and IDEA will sort things out on its own.

On Tue, Feb 14, 2017 at 1:20 PM, Udo Kohlmeyer  wrote:

> Hi there,
>
> When I run `gradle idea` the following exception is thrown.
>
> * What went wrong:
> Execution failed for task ':geode-core:ideaModule'.
> > Cannot change dependencies of configuration ':geode-core:antlr' after it
> has been included in dependency resolution.
>
> Is this something that we can resolve? Any idea what could be causing this
> failure?
>
> --Udo
>
>


-- 
Cheers

Jinmei

Review Request 56682: GEODE-2444: move Redis out of geode-core.

[Galen O'Sullivan]

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

Review request for geode, Bruce Schuchardt, Hitesh Khamesra, Udo Kohlmeyer, and 
Dan Smith.


Repository: geode


Description
---

I'm taking over this ticket from Udo's: https://reviews.apache.org/r/56564/

* Move geode-redis to its own package.
* Make a `GeodeRedisService` interface that will get loaded by 
`GemFireCacheImpl`.
* Move functionality to `GeodeRedisServiceImpl`, keep the old 
`GeodeRedisServer` as a shell for backwards compatibility.
* Improve tests and make some fixes.


Diffs
-

  geode-core/build.gradle 8eba6d4e8 
  
geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java
 63f650510 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java
 c2a395de0 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java
 fa6d13f7c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
6e374ecb7 
  
geode-core/src/main/java/org/apache/geode/internal/hll/CardinalityMergeException.java
 59ab0950e 
  geode-core/src/main/java/org/apache/geode/internal/hll/HyperLogLog.java 
4bdf81c77 
  geode-core/src/main/java/org/apache/geode/internal/hll/HyperLogLogPlus.java 
fc4b6e554 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/FixedPartitionAttributesInfo.java
 eb0435a37 
  geode-core/src/main/java/org/apache/geode/redis/GeodeRedisServer.java 
4c97c98bf 
  geode-core/src/main/java/org/apache/geode/redis/GeodeRedisService.java 
PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/redis/internal/ByteArrayWrapper.java 
4a0ef5989 
  
geode-core/src/main/java/org/apache/geode/redis/internal/ByteToCommandDecoder.java
 124bf7512 
  geode-core/src/main/java/org/apache/geode/redis/internal/Coder.java  
  geode-core/src/main/java/org/apache/geode/redis/internal/Command.java  
  geode-core/src/main/java/org/apache/geode/redis/internal/DoubleWrapper.java 
60cd130da 
  
geode-core/src/main/java/org/apache/geode/redis/internal/ExecutionHandlerContext.java
 e2b49bedc 
  geode-core/src/main/java/org/apache/geode/redis/internal/Executor.java  
  geode-core/src/main/java/org/apache/geode/redis/internal/Extendable.java  
  
geode-core/src/main/java/org/apache/geode/redis/internal/RedisCommandParserException.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/RedisCommandType.java  
  geode-core/src/main/java/org/apache/geode/redis/internal/RedisConstants.java 
3c39c01c5 
  geode-core/src/main/java/org/apache/geode/redis/internal/RedisDataType.java 
63a15dff9 
  
geode-core/src/main/java/org/apache/geode/redis/internal/RedisDataTypeMismatchException.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/RegionCreationException.java
  
  geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java 
5994d7d8c 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/AbstractExecutor.java
 c9d47ab9b 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/AbstractScanExecutor.java
 0eb6dcad3 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/AuthExecutor.java
 9d318a450 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/DBSizeExecutor.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/DelExecutor.java
 e0db6518c 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/EchoExecutor.java
 407e65354 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/ExistsExecutor.java
 96611dc06 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/ExpirationExecutor.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/ExpireAtExecutor.java
 0962a7daa 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/ExpireExecutor.java
 d986826e7 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/FlushAllExecutor.java
 f8551665a 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/KeysExecutor.java
 9398d87e3 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/ListQuery.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/PExpireAtExecutor.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/PExpireExecutor.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/PTTLExecutor.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/PersistExecutor.java
 db4d19a88 
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/PingExecutor.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/QuitExecutor.java
  
  
geode-core/src/main/java/org/apache/geode/redis/internal/executor/ScanExecutor.java
 5e62

Re: Merge conflict from release/1.1.0 branch to develop

[Bruce Schuchardt]

There are changes on develop to DirectChannel that aren't in the 1.1.0 
branch.  I don't see why git isn't figuring that out.


The backward-compatibility classes were modified in the 1.1.0 branch to 
try to track down the problem with locating the classpaths file in 
geode-old-versions.  We could revert those on the 1.1.0 branch if you 
like since they aren't needed anymore.


For both of these sets of changes you could use "-s ours" when merging 
1.1.0 to develop.


Le 2/14/2017 à 12:16 PM, Hitesh Khamesra a écrit :

I was merging release/1.1.0 branch to develop to see if something we need to 
pull from there. Generally we don't expect anything from it but it is showing 
some conflicts. Can you(Bruce, Jenmei, Jared) please look following files.

-bash-4.2$ git merge --no-ff release/1.1.0Auto-merging gradle.properties
Auto-merging 
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscBCDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscBCDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgrade2DUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgrade2DUnitTest.java
Auto-merging 
geode-core/src/main/java/org/apache/geode/internal/tcp/TCPConduit.java
Auto-merging 
geode-core/src/main/java/org/apache/geode/distributed/internal/direct/DirectChannel.java
CONFLICT (content): Merge conflict in 
geode-core/src/main/java/org/apache/geode/distributed/internal/direct/DirectChannel.java
Automatic merge failed; fix conflicts and then commit the result.
-bash-4.2$

Gradle build for idea

[Udo Kohlmeyer]

Hi there,

When I run `gradle idea` the following exception is thrown.

* What went wrong:
Execution failed for task ':geode-core:ideaModule'.
> Cannot change dependencies of configuration ':geode-core:antlr' after 
it has been included in dependency resolution.


Is this something that we can resolve? Any idea what could be causing 
this failure?


--Udo

[jira] [Commented] (GEODE-2462) Unify quick starts and examples

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2462:


Commit 975f48fa6a98d9b66a9e48627d03da72228f86bc in geode-native's branch 
refs/heads/develop from [~PivotalSarge]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=975f48f ]

GEODE-2462: Remove examples file used by unit tests.

This closes #10.


> Unify quick starts and examples
> ---
>
> Key: GEODE-2462
> URL: https://issues.apache.org/jira/browse/GEODE-2462
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> Currently, there exists both src/quickstart and examples under the native 
> root. It is unclear what the difference is or what value-add the examples 
> directories brings. The exemplary code under src/quickstart and examples 
> ought to be unified, without duplicates, of course. Given that src/quickstart 
> has more code, it should be the single location of exemplary code for the 
> native libraries.



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

[GitHub] geode-native pull request #10: Fix build on Windows.

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2470) Remove Dependency on sed tool

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Remove Dependency on sed tool
> -
>
> Key: GEODE-2470
> URL: https://issues.apache.org/jira/browse/GEODE-2470
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Michael Martell
>
> The integration tests currently rely on sed to replace strings inside config 
> xml files. This task replaces that dependency with standard C++ code.



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

[GitHub] geode-native pull request #6: GEODE-2470: Replace sed dependency with standa...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2470) Remove Dependency on sed tool

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2470:


Commit 21c050f942706c7ab61df55802c4a6476d383700 in geode-native's branch 
refs/heads/develop from [~mmartell]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=21c050f ]

GEODE-2470: Replace sed dependency with standard C++.

- sed is used in CacheHelper to do string replacement of port number
variables in the input xml configuration files.

This closes #6.


> Remove Dependency on sed tool
> -
>
> Key: GEODE-2470
> URL: https://issues.apache.org/jira/browse/GEODE-2470
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Michael Martell
>
> The integration tests currently rely on sed to replace strings inside config 
> xml files. This task replaces that dependency with standard C++ code.



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

[jira] [Commented] (GEODE-2479) correct doc reference to a com.gemstone package

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2479:


Commit 5b67166cb9d75c1936245c97ffe0e6031e60467b in geode's branch 
refs/heads/feature/GEODE-2402 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5b67166 ]

GEODE-2479 Remove docs reference to gemstone.com package


> correct doc reference to a com.gemstone package
> ---
>
> Key: GEODE-2479
> URL: https://issues.apache.org/jira/browse/GEODE-2479
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> File geode-docs/developing/data_serialization/auto_serialization.html still 
> has a spurious reference to a com.gemstone package.  It should be corrected 
> to identify org.apache.geode instead.
> At the same time, remove links to the 2 subsections with headers
> - Customizing Serialization with Class Pattern Strings
> - Extending the ReflectionBasedAutoSerializer
> These are in the navigation bar, so the links server no purpose.



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

[jira] [Commented] (GEODE-2474) netstat command fails to correctly identify OS and --with-lsof fails on Mac

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2474:


Commit de819a34e422f8f213c3426b6a2303a9d77da450 in geode's branch 
refs/heads/feature/GEODE-2402 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=de819a3 ]

GEODE-2474: mark NetstatDUnitTest as flaky


> netstat command fails to correctly identify OS and --with-lsof fails on Mac
> ---
>
> Key: GEODE-2474
> URL: https://issues.apache.org/jira/browse/GEODE-2474
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: MiscellaneousCommands, NetstatCommand, gfsh, netstat
>
> The netstat gfsh command uses NetstatFunction which has its own faulty logic 
> for identifying the operating system. This logic identifies Mac as Windows 
> and fails to process --with-lsof.
> NetstatFunction should instead use org.apache.geode.internal.lang.SystemUtils 
> which correctly identifies the operating system.



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

[jira] [Commented] (GEODE-2402) CI Failure: LuceneQueriesPeerFixedPRDUnitTest.returnCorrectResultsWhenRebalanceHappensOnIndexUpdate

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2402:


Commit 372ddeea950a22e0da762464e02b6a2031339683 in geode's branch 
refs/heads/feature/GEODE-2402 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=372ddee ]

GEODE-2402: Write to the lucene region buckets using a callback argument

We were writing directly to the bucket regions of the file region and
chunk region in the lucene code. With this change, we will instead write
to the top level PR and pass a callback argument indicating the target
bucket. The file and chunk regions now have a partition listener to
route the put to the correct bucket.

The reason for all of this is that in some cases, the core code can can
send a message that only includes the PR id and the key. We need want
the core to be able to resolve the correct bucket from just those
things. When we were putting directly into the PR, if the core code
tried to compute the bucket id for a key it was getting the wrong
bucket id, or in the case of a fixed PR, throwing an exception.


> CI Failure: 
> LuceneQueriesPeerFixedPRDUnitTest.returnCorrectResultsWhenRebalanceHappensOnIndexUpdate
> ---
>
> Key: GEODE-2402
> URL: https://issues.apache.org/jira/browse/GEODE-2402
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
>
> This is with 26325b5ef502b6599e9294be41ad96cbf882ab7f
> {noformat}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.cache.lucene.LuceneQueriesPRBase.putEntriesAndValidateQueryResults(LuceneQueriesPRBase.java:148)
>   at 
> org.apache.geode.cache.lucene.LuceneQueriesPRBase.returnCorrectResultsWhenRebalanceHappensOnIndexUpdate(LuceneQueriesPRBase.java:59)
>   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:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   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:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:

[jira] [Commented] (GEODE-2460) Update dependency versions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2460:


Commit 652e9a59a6babe81b47c34a950459466f630db12 in geode's branch 
refs/heads/feature/GEODE-2402 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=652e9a5 ]

GEODE-2460: update dependency versions

Update the following dependency versions defined in
gradle/dependency-versions.properties.

Update major versions (compile test only):

* org.apache.bcel:bcel:6.0

Update minor versions (distributed in release):

* commons-beanutils:1.9.3
* commons-fileupload:1.3.2
* commons-io:2.5
* commons-lang:2.6
* commons-logging:1.2
* commons-modeler:2.0.1
* fastutil:7.0.13
* guava:21.0
* jansi:1.14
* javax.mail-api:1.4.7
* jline:2.14.3
* jopt-simple:5.0.3
* log4j-api:2.7
* log4j-core:2.7
* log4j-jcl:2.7
* log4j-jul:2.7
* log4j-slf4j-impl:2.7
* netty-all:4.1.7.Final
* shiro-core:1.3.2
* slf4j-api:1.7.22

Update minor versions (compile test and main):

* assertj-core:3.6.2
* cglib:cglib:3.2.4
* commons-configuration:1.10
* derby:10.13.1.1
* google-gson:2.8.0
* httpclient:4.5.2
* httpcore:4.4.6
* hsqldb:2.3.4
* javassist:3.21.0-GA
* jedis:2.9.0
* JUnitParams:1.0.6
* mockrunner:1.1.2
* mortbay-jetty-servlet-api:2.5.20110712
* phantomjsdriver:1.3.0
* powermock-core:1.6.6
* powermock-module-junit4:1.6.6
* powermock-api-mockito:1.6.6
* selenium-api:3.0.1
* selenium-remote-driver:3.0.1
* selenium-support:3.0.1
* spymemcached:2.12.2
* system-rules:1.16.1
* tomcat-catalina:7.0.73 (tomcat7)
* tomcat-coyote:7.0.73 (tomcat7)
* tomcat-juli:7.0.73 (tomcat7)
* tomcat-catalina:8.5.9 (tomcat8)
* tomcat-coyote:8.5.9 (tomcat8)
* tomcat-juli:8.5.9 (tomcat8)


> Update dependency versions
> --
>
> Key: GEODE-2460
> URL: https://issues.apache.org/jira/browse/GEODE-2460
> Project: Geode
>  Issue Type: Wish
>  Components: build, docs
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Here's the first bunch of dependency version updates that passes precheckin 
> without modifying source code:
> Update the following dependency versions defined in
> gradle/dependency-versions.properties.
> Update major versions (test-only):
> * org.apache.bcel:bcel:6.0
> Update minor versions (test and main):
> * commons-beanutils:1.9.3 
> * commons-fileupload:1.3.2 
> * commons-io:2.5 
> * commons-lang:2.6
> * commons-logging:1.2
> * commons-modeler:2.0.1
> * fastutil:7.0.13
> * guava:21.0
> * jansi:1.14
> * javax.mail-api:1.4.7
> * jline:2.14.3
> * jopt-simple:5.0.3
> * log4j-api:2.7
> * log4j-core:2.7
> * log4j-jcl:2.7
> * log4j-jul:2.7
> * log4j-slf4j-impl:2.7
> * netty-all:4.1.7.Final
> * shiro-core:1.3.2
> * slf4j-api:1.7.22
> Update minor versions (test-only):
> * assertj-core:3.6.2
> * cglib:cglib:3.2.4
> * commons-configuration:1.10
> * derby:10.13.1.1
> * google-gson:2.8.0
> * httpclient:4.5.2
> * httpcore:4.4.6
> * hsqldb:2.3.4
> * javassist:3.21.0-GA
> * jedis:2.9.0
> * JUnitParams:1.0.6
> * mockrunner:1.1.2
> * mortbay-jetty-servlet-api:2.5.20110712
> * phantomjsdriver:1.3.0
> * powermock-core:1.6.6
> * powermock-module-junit4:1.6.6
> * powermock-api-mockito:1.6.6
> * selenium-api:3.0.1
> * selenium-remote-driver:3.0.1
> * selenium-support:3.0.1
> * spymemcached:2.12.2
> * system-rules:1.16.1
> * tomcat-catalina:7.0.73 (tomcat7)
> * tomcat-coyote:7.0.73 (tomcat7)
> * tomcat-juli:7.0.73 (tomcat7)
> * tomcat-catalina:8.5.9 (tomcat8)
> * tomcat-coyote:8.5.9 (tomcat8)
> * tomcat-juli:8.5.9 (tomcat8)



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

[jira] [Commented] (GEODE-2475) Upgrade lucene version to 6.4.1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2475:


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

GEODE-2475: Upgrade Lucene version to 6.4.1


> Upgrade lucene version to 6.4.1 
> 
>
> Key: GEODE-2475
> URL: https://issues.apache.org/jira/browse/GEODE-2475
> Project: Geode
>  Issue Type: Task
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> We should probably keep geode up to date with the latest Lucene jars



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

[jira] [Commented] (GEODE-2398) Sporadic Oplog corruption due to channel.write failure

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2398:


Commit 9b0f16570aad4abc82b71d0d16167a9774449d41 in geode's branch 
refs/heads/feature/GEODE-2402 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9b0f165 ]

GEODE-2398: Retry oplog channel.write on silent failures

Implemented limited retries in two forms of Oplog.flush() when channel.write() 
is called.
If write() returns bytes witten less than the change in the ByteBuffer 
positions, then reset
buffer positions and re-try writing for a liomited number of times. Throws
IOException if the write doesn't succeeded after a few retries (max
number of retries is defined by a static).

Added new unit tests.


> Sporadic Oplog corruption due to channel.write failure
> --
>
> Key: GEODE-2398
> URL: https://issues.apache.org/jira/browse/GEODE-2398
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
> Fix For: 1.2.0
>
>
> There have been some occurrences of Oplog corruption during testing that have 
> been traced to failures in writing oplog entries to the .crf file. When it 
> fails, Oplog.flush attempts to write a ByteBuffer to the file channel. The 
> call to channel.write(bb) method returns 0 bytes written, but the source 
> ByteBuffer position is moved to the ByteBuffer limit.



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

[jira] [Commented] (GEODE-1716) Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest of the tests to fail.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1716:


Commit f19ccfd07d3a6e81203f94c6630645ea729d243f in geode's branch 
refs/heads/feature/GEODE-2402 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f19ccfd ]

GEODE-1716: refactor JMXMBeanDunitTest

* refactor MBeanServerConnectRule for easier usage.
* refactor LocatorServerStartupRule to be able to start up locator/server in VM 
out of sequence


> Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest 
> of the tests to fail.
> ---
>
> Key: GEODE-1716
> URL: https://issues.apache.org/jira/browse/GEODE-1716
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Udo Kohlmeyer
>Priority: Minor
>
> In JMXMBeanDUnitTest the testJMXOverNonSSL test is causing the whole test 
> class to fail. It seems the RMI stuff does not clean up nicely after itself.



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

[jira] [Commented] (GEODE-2398) Sporadic Oplog corruption due to channel.write failure

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2398:


Commit fb14e9aab263654ed0176dcc3c9738be1b208a82 in geode's branch 
refs/heads/feature/GEODE-2402 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fb14e9a ]

GEODE-2398: Updates from review

https://reviews.apache.org/r/56506/


> Sporadic Oplog corruption due to channel.write failure
> --
>
> Key: GEODE-2398
> URL: https://issues.apache.org/jira/browse/GEODE-2398
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
> Fix For: 1.2.0
>
>
> There have been some occurrences of Oplog corruption during testing that have 
> been traced to failures in writing oplog entries to the .crf file. When it 
> fails, Oplog.flush attempts to write a ByteBuffer to the file channel. The 
> call to channel.write(bb) method returns 0 bytes written, but the source 
> ByteBuffer position is moved to the ByteBuffer limit.



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

Re: Merge conflict from release/1.1.0 branch to develop

[Jared Stewart]

Hi Hitesh,

It looks to me like the merge conflicts in ClusterConfig tests are due to this 
commit being included in develop, but not in release/1.1.0:  [d188118 Jinmei 
Liao  on 2/8/17 at 4:04 PM]

-Jared

> On Feb 14, 2017, at 12:16 PM, Hitesh Khamesra  
> wrote:
> 
> I was merging release/1.1.0 branch to develop to see if something we need to 
> pull from there. Generally we don't expect anything from it but it is showing 
> some conflicts. Can you(Bruce, Jenmei, Jared) please look following files.
> 
> -bash-4.2$ git merge --no-ff release/1.1.0Auto-merging gradle.properties
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscBCDUnitTest.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscBCDUnitTest.java
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
> Auto-merging 
> geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgrade2DUnitTest.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgrade2DUnitTest.java
> Auto-merging 
> geode-core/src/main/java/org/apache/geode/internal/tcp/TCPConduit.java
> Auto-merging 
> geode-core/src/main/java/org/apache/geode/distributed/internal/direct/DirectChannel.java
> CONFLICT (content): Merge conflict in 
> geode-core/src/main/java/org/apache/geode/distributed/internal/direct/DirectChannel.java
> Automatic merge failed; fix conflicts and then commit the result.
> -bash-4.2$
> 
> 
> 

Merge conflict from release/1.1.0 branch to develop

[Hitesh Khamesra]

I was merging release/1.1.0 branch to develop to see if something we need to 
pull from there. Generally we don't expect anything from it but it is showing 
some conflicts. Can you(Bruce, Jenmei, Jared) please look following files.

-bash-4.2$ git merge --no-ff release/1.1.0Auto-merging gradle.properties
Auto-merging 
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/VersionManager.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscBCDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscBCDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
Auto-merging 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgrade2DUnitTest.java
CONFLICT (content): Merge conflict in 
geode-core/src/test/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgrade2DUnitTest.java
Auto-merging 
geode-core/src/main/java/org/apache/geode/internal/tcp/TCPConduit.java
Auto-merging 
geode-core/src/main/java/org/apache/geode/distributed/internal/direct/DirectChannel.java
CONFLICT (content): Merge conflict in 
geode-core/src/main/java/org/apache/geode/distributed/internal/direct/DirectChannel.java
Automatic merge failed; fix conflicts and then commit the result.
-bash-4.2$

[GitHub] geode-native pull request #10: Fix build on Windows.

[PivotalSarge]

GitHub user PivotalSarge opened a pull request:

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

Fix build on Windows.

There was a lingering reference to one of the example files, 
ComplexNumber.cs, in the CLI tests. Restoring that file to a different location 
was insufficient because the CMake files also had references to it. Further 
research showed that the test was omitted anyway so I just removed all the 
offenders.

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

$ git pull https://github.com/PivotalSarge/geode-native feature/GEODE-2462

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

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


commit f1b432ee915341096295e39d1fcc8ba35449c281
Author: Sarge 
Date:   2017-02-14T18:43:52Z

GEODE-2462: Restore example file used by the unit tests.

commit a9b68fd7b05815e794d8ada31c1d2587985eef33
Author: Sarge 
Date:   2017-02-14T20:09:30Z

GEODE-2462: Remove examples file used by unit tests.




---
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-1964) Add docs for native client to native client repo

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1964:


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

Merge branch 'feature/GEODE-1964' into develop

This adds the documentation for geode-native from the geode repo.  All
history was brought over intact to preserve changes.


> Add docs for native client to native client repo
> 
>
> Key: GEODE-1964
> URL: https://issues.apache.org/jira/browse/GEODE-1964
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> After the native client code has been merged to develop, the documentation 
> should follow. This subtask allows us to 'park' the existing docs on a 
> feature branch until they're needed.



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

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit c8d10ec6440a3030a5da8c3022fb16fa2809150d in geode's branch 
refs/heads/master from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c8d10ec ]

GEODE-2433  Backwards compatibility tests are not actually running

Show current working directory if unable to run backward compatibility
tests.  For some reason we aren't finding the classpaths file when running
under Jenkins.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



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

[jira] [Commented] (GEODE-2432) Don't create and upload empty maven artifacts for geode-benchmarks, geode-old-versions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2432:


Commit 05b6965cf323aaba493da59631678540dbf9fe35 in geode's branch 
refs/heads/master from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=05b6965 ]

GEODE-2432: Disable maven artifacts for geode-benchmarks


> Don't create and upload empty maven artifacts for geode-benchmarks, 
> geode-old-versions
> --
>
> Key: GEODE-2432
> URL: https://issues.apache.org/jira/browse/GEODE-2432
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.1.0
>
>
> The 1.1.0.RC1 maven site shows that we're creating and uploading empty maven 
> artifacts for these sub projects.
> geode-benchmarks - this project contains only jmh tests
> geode-old-versions - this project seems to be completely empty?
> We should probably disable uploading maven archives for these projects.



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

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2430:


Commit f637dc6a5145e6e331189efab8dd2e854889c67c in geode's branch 
refs/heads/master from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f637dc6 ]

GEODE-2430: Refactor ZipUtils

(cherry picked from commit 50aebcc)


> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



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

[jira] [Commented] (GEODE-2434) geodeOldVersionClasspaths.txt is generated every time build is parsed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2434:


Commit 889d17041a26536dcc99b9f2bd0207c9c2695340 in geode's branch 
refs/heads/master from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=889d170 ]

GEODE-2434: Generate old version classpaths in doLast

The geode-old-versions/build.gradle was generating the classpath
properties file during the build configuration phase, rather than the
execution phase.

Also converting the file to an actual properties file so that it will
handle special characters properly.


> geodeOldVersionClasspaths.txt is generated every time build is parsed
> -
>
> Key: GEODE-2434
> URL: https://issues.apache.org/jira/browse/GEODE-2434
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.1.0, 1.2.0
>
>
> geode-old-versions/build.gradle regenerates geodeOldVersionClasspaths.txt 
> during the configuration phase of the task createGeodeClasspathsFile. This is 
> a performance issue with the build because every time someone types ./gradlew 
> it will regenerate this file while configuring the build.



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

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2430:


Commit 2286fd064a52173eab8fdcfadfb89a01e81ef728 in geode's branch 
refs/heads/master from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2286fd0 ]

GEODE-2430: Fix failing tests

* this closes #395

(cherry picked from commit 147eb7c)


> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



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

[jira] [Commented] (GEODE-2430) Remove binary files from test resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2430:


Commit 831fa44f0618787f5c5a895c0da4c5ca9f7d4bdc in geode's branch 
refs/heads/master from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=831fa44 ]

GEODE-2430: Remove jar and zip files from test resources

This closes #393

(cherry picked from commit e769796)


> Remove binary files from test resources
> ---
>
> Key: GEODE-2430
> URL: https://issues.apache.org/jira/browse/GEODE-2430
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> We have some tests which rely on the following binary files:
> {code}
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config_security.zip
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group1.jar
> + 
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/group2.jar
> {code}
> We need to convert our tests to generate these files dynamically instead so 
> that we don't have binary files checked into our repository.



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

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit 5554dd24a3932900b28956cac357f0e4bbe9d6e0 in geode's branch 
refs/heads/master from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5554dd2 ]

GEODE-2433  Backwards compatibility tests are not actually running

The geode-old-versions/build.gradle file was not included in the original
commit for backward-compatibility testing.  It's needed to establish
the old-version source sets and generate the classpaths file used by
VersionManager.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



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

[jira] [Commented] (GEODE-2433) Backwards compatibility tests are not actually running

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2433:


Commit 5e6f67346c75a92084bbb1e46f7f0c016353eb97 in geode's branch 
refs/heads/master from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5e6f673 ]

GEODE-2433 Backwards compatibility tests are not actually running

Tests will now fail of there are no older versions of Geode to test
against.


> Backwards compatibility tests are not actually running
> --
>
> Key: GEODE-2433
> URL: https://issues.apache.org/jira/browse/GEODE-2433
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> We have several backwards compatibility tests checked in -
> RollingUpgradeDUnitTest
> RollingUpgrade2DUnitTest
> ClientServerMiscBCDUnitTest
> These tests are all parametered by the list of old versions to run against.
> However, it looks like the code to get the list of old versions incorrectly 
> just logs a message and continues on if it can't find a file called 
> geodeOldVersionClasspaths.txt. That file does not exist and is not being 
> generated as far is I can tell. The entire project - geode-old-versions, is 
> completely empty.
> The net effect is these tests don't actually run, because the list of 
> parameters is an empty list.



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

[jira] [Commented] (GEODE-2471) AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2471:


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

GEODE-2471: fix the race condition in test code.


> AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching
> --
>
> Key: GEODE-2471
> URL: https://issues.apache.org/jira/browse/GEODE-2471
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: CI
>
> {noformat}
> found in concourse distributedTest #383
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventListenerDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching(AsyncEventListenerDUnitTest.java:1675)
>   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:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   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:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.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:109)
>   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

[jira] [Resolved] (GEODE-2471) AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching

[xiaojian zhou (JIRA)]

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

xiaojian zhou resolved GEODE-2471.
--
Resolution: Fixed

> AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching
> --
>
> Key: GEODE-2471
> URL: https://issues.apache.org/jira/browse/GEODE-2471
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: CI
>
> {noformat}
> found in concourse distributedTest #383
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventListenerDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching(AsyncEventListenerDUnitTest.java:1675)
>   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:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   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:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.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:109)
>   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:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.i

[jira] [Commented] (GEODE-2467) Support Newer Versions of Visual Studio

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2467:


Commit 37a0e008b718156f5b01215add30471b9513cccd in geode-native's branch 
refs/heads/develop from [~mmartell]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=37a0e00 ]

GEODE-2467: Switch Xerces CMakeLists.txt to highest supported Visual Studio 
version.

- Also move MSVC_VERSION check above if (WIN32) check
- This change allows building Xerces with Visual Studio 2015 (called
14.0 internally).

This closes #7.


> Support Newer Versions of Visual Studio
> ---
>
> Key: GEODE-2467
> URL: https://issues.apache.org/jira/browse/GEODE-2467
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> This task is to support building the native client with newer versions of 
> Visual Studio including VS 2015 and VS 2017.
> Reasons include:
> 1) with 2017 release date of March 7 just announced, this makes a 2013 basd 
> build really old
> 2) stronger C++11/14/17 support
> 3) dotNetty requires newer tool chains, and nice to use a single tool
> 4) much better built-in git support
> 5) there are no source changes required, only tweak is to xerces 
> CMakeLists.txt



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

[GitHub] geode-native pull request #7: Feature/geode 2467

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2474) netstat command fails to correctly identify OS and --with-lsof fails on Mac

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2474:


Commit de819a34e422f8f213c3426b6a2303a9d77da450 in geode's branch 
refs/heads/feature/GEODE-2267 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=de819a3 ]

GEODE-2474: mark NetstatDUnitTest as flaky


> netstat command fails to correctly identify OS and --with-lsof fails on Mac
> ---
>
> Key: GEODE-2474
> URL: https://issues.apache.org/jira/browse/GEODE-2474
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: MiscellaneousCommands, NetstatCommand, gfsh, netstat
>
> The netstat gfsh command uses NetstatFunction which has its own faulty logic 
> for identifying the operating system. This logic identifies Mac as Windows 
> and fails to process --with-lsof.
> NetstatFunction should instead use org.apache.geode.internal.lang.SystemUtils 
> which correctly identifies the operating system.



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

[jira] [Commented] (GEODE-2267) Add gfsh command to export stat files

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2267:


Commit 815bee611e6df87b58ca5b9700e510655761fc91 in geode's branch 
refs/heads/feature/GEODE-2267 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=815bee6 ]

Merge branch 'develop' into GEODE-2267

# Conflicts:
#   
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
#   
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java


> Add gfsh command to export stat files
> -
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



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

[jira] [Commented] (GEODE-2398) Sporadic Oplog corruption due to channel.write failure

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2398:


Commit 9b0f16570aad4abc82b71d0d16167a9774449d41 in geode's branch 
refs/heads/feature/GEODE-2267 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9b0f165 ]

GEODE-2398: Retry oplog channel.write on silent failures

Implemented limited retries in two forms of Oplog.flush() when channel.write() 
is called.
If write() returns bytes witten less than the change in the ByteBuffer 
positions, then reset
buffer positions and re-try writing for a liomited number of times. Throws
IOException if the write doesn't succeeded after a few retries (max
number of retries is defined by a static).

Added new unit tests.


> Sporadic Oplog corruption due to channel.write failure
> --
>
> Key: GEODE-2398
> URL: https://issues.apache.org/jira/browse/GEODE-2398
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
> Fix For: 1.2.0
>
>
> There have been some occurrences of Oplog corruption during testing that have 
> been traced to failures in writing oplog entries to the .crf file. When it 
> fails, Oplog.flush attempts to write a ByteBuffer to the file channel. The 
> call to channel.write(bb) method returns 0 bytes written, but the source 
> ByteBuffer position is moved to the ByteBuffer limit.



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

[jira] [Commented] (GEODE-1716) Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest of the tests to fail.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1716:


Commit f19ccfd07d3a6e81203f94c6630645ea729d243f in geode's branch 
refs/heads/feature/GEODE-2267 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f19ccfd ]

GEODE-1716: refactor JMXMBeanDunitTest

* refactor MBeanServerConnectRule for easier usage.
* refactor LocatorServerStartupRule to be able to start up locator/server in VM 
out of sequence


> Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest 
> of the tests to fail.
> ---
>
> Key: GEODE-1716
> URL: https://issues.apache.org/jira/browse/GEODE-1716
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Udo Kohlmeyer
>Priority: Minor
>
> In JMXMBeanDUnitTest the testJMXOverNonSSL test is causing the whole test 
> class to fail. It seems the RMI stuff does not clean up nicely after itself.



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

[jira] [Commented] (GEODE-2398) Sporadic Oplog corruption due to channel.write failure

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2398:


Commit fb14e9aab263654ed0176dcc3c9738be1b208a82 in geode's branch 
refs/heads/feature/GEODE-2267 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fb14e9a ]

GEODE-2398: Updates from review

https://reviews.apache.org/r/56506/


> Sporadic Oplog corruption due to channel.write failure
> --
>
> Key: GEODE-2398
> URL: https://issues.apache.org/jira/browse/GEODE-2398
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
> Fix For: 1.2.0
>
>
> There have been some occurrences of Oplog corruption during testing that have 
> been traced to failures in writing oplog entries to the .crf file. When it 
> fails, Oplog.flush attempts to write a ByteBuffer to the file channel. The 
> call to channel.write(bb) method returns 0 bytes written, but the source 
> ByteBuffer position is moved to the ByteBuffer limit.



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

[jira] [Commented] (GEODE-2475) Upgrade lucene version to 6.4.1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2475:


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

GEODE-2475: Upgrade Lucene version to 6.4.1


> Upgrade lucene version to 6.4.1 
> 
>
> Key: GEODE-2475
> URL: https://issues.apache.org/jira/browse/GEODE-2475
> Project: Geode
>  Issue Type: Task
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> We should probably keep geode up to date with the latest Lucene jars



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

[jira] [Commented] (GEODE-2479) correct doc reference to a com.gemstone package

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2479:


Commit 5b67166cb9d75c1936245c97ffe0e6031e60467b in geode's branch 
refs/heads/feature/GEODE-2267 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5b67166 ]

GEODE-2479 Remove docs reference to gemstone.com package


> correct doc reference to a com.gemstone package
> ---
>
> Key: GEODE-2479
> URL: https://issues.apache.org/jira/browse/GEODE-2479
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> File geode-docs/developing/data_serialization/auto_serialization.html still 
> has a spurious reference to a com.gemstone package.  It should be corrected 
> to identify org.apache.geode instead.
> At the same time, remove links to the 2 subsections with headers
> - Customizing Serialization with Class Pattern Strings
> - Extending the ReflectionBasedAutoSerializer
> These are in the navigation bar, so the links server no purpose.



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

Re: Review Request 56668: GEODE-2474: mark NetstatDUnitTest as flaky

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Feb. 14, 2017, 5:01 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56668/
> ---
> 
> (Updated Feb. 14, 2017, 5:01 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2474: mark NetstatDUnitTest as flaky
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
>  3ee0c46675a250db4db2b8558c5cee3cf1e5eea8 
> 
> Diff: https://reviews.apache.org/r/56668/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[RESULT][VOTE] RC2: Apache Geode 1.1.0 release

[Hitesh Khamesra]

The vote passes with 6 +1 and 2 +0 votes:

Jinmei Liao  +1
Udo Kohlmeyer    +1
William Markito  +1
Dan Smith    +1
Xiaojian Zhou    +1 
Anthony Baker    +1

Kenneth Howe +0
Karen Miller +0

Mail thread: 
http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201702.mbox/%3C1656177403.1540917.1486673726802%40mail.yahoo.com%3E

Thanks.Dan & Hitesh

Re: Review Request 56637: refactor ServerStarterRule and LocatorStarterRule so that they can be created without a Properties first.

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On Feb. 14, 2017, 7 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56637/
> ---
> 
> (Updated Feb. 14, 2017, 7 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> refactor ServerStarterRule and LocatorStarterRule so that they can be created 
> without a Properties first.
> 
> * this would ease the usage of thsee rules, so that it can always be used as 
> a rule and users don't have to worry about stopping the locator/server 
> manually.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  f93498fcbcea0ec8d8f0b91a0367e9b6fb7d4ae1 
> 
> Diff: https://reviews.apache.org/r/56637/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> This code change will also fix the currently failing integration tests. See 
> the change in MemberMBeanSecurityJUnitTest.java
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 56637: refactor ServerStarterRule and LocatorStarterRule so that they can be created without a Properties first.

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On Feb. 14, 2017, 7 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56637/
> ---
> 
> (Updated Feb. 14, 2017, 7 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> refactor ServerStarterRule and LocatorStarterRule so that they can be created 
> without a Properties first.
> 
> * this would ease the usage of thsee rules, so that it can always be used as 
> a rule and users don't have to worry about stopping the locator/server 
> manually.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  f93498fcbcea0ec8d8f0b91a0367e9b6fb7d4ae1 
> 
> Diff: https://reviews.apache.org/r/56637/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> This code change will also fix the currently failing integration tests. See 
> the change in MemberMBeanSecurityJUnitTest.java
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 56637: refactor ServerStarterRule and LocatorStarterRule so that they can be created without a Properties first.

[Jinmei Liao]

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

(Updated Feb. 14, 2017, 7 p.m.)


Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk Lund.


Repository: geode


Description
---

refactor ServerStarterRule and LocatorStarterRule so that they can be created 
without a Properties first.

* this would ease the usage of thsee rules, so that it can always be used as a 
rule and users don't have to worry about stopping the locator/server manually.


Diffs (updated)
-

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

Diff: https://reviews.apache.org/r/56637/diff/


Testing
---

precheckin successful

This code change will also fix the currently failing integration tests. See the 
change in MemberMBeanSecurityJUnitTest.java


Thanks,

Jinmei Liao

Re: Review Request 56635: GEODE-2481: extract default properties generation to its own class

[Jared Stewart]

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




geode-core/src/test/java/org/apache/geode/distributed/internal/DefaultPropertiesGeneratorIntegrationTest.java
 (line 20)


The test does not compile for me as this import (`import static 
org.apache.geode.internal.lang.SystemUtils.getClassPath;`) does not resolve.  
It looks like `import static org.apache.bcel.util.ClassPath.getClassPath;` is 
the the right one.


- Jared Stewart


On Feb. 14, 2017, 2:33 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56635/
> ---
> 
> (Updated Feb. 14, 2017, 2:33 a.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and Ken 
> Howe.
> 
> 
> Bugs: GEODE-2481
> https://issues.apache.org/jira/browse/GEODE-2481
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2481: extract default properties generation to its own class
> 
> While refactoring GemFireVersion for GEODE-2474, I noticed that 
> GemFireVersionIntegrationJUnitTest has nothing to do with GemFireVersion.
> 
> Extract generation of default properties to DefaultPropertiesGenerator.
> 
> Rename GemFireVersionIntegrationJUnitTest to 
> DefaultPropertiesGeneratorIntegrationTest. Add tests to increase code 
> coverage.
> 
> Note: I have several changes on feature/GEODE-2474 branch which I'll separate 
> into multiple reviews. I'll do a final precheckin on the entire branch and 
> then merge the changes in after everything passes review and precheckin.
> 
> DistributionConfig and DefaultPropertiesGenerator should eventually move to a 
> configuration package, but I don't really want to combine anything that big 
> with this change.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle f34688043dd3e6bf8e8bdf0cb223d533b692e301 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DefaultPropertiesGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java
>  fa6d13f7cec40ae18f78da28b3b912e01be363aa 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DefaultPropertiesGeneratorIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/GemFireVersionIntegrationJUnitTest.java
>  cae331325f17b470e6dd786d0f9a52bba7cb42a6 
> 
> Diff: https://reviews.apache.org/r/56635/diff/
> 
> 
> Testing
> ---
> 
> DefaultPropertiesGeneratorIntegrationTest
> GemFireVersionJUnitTest
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 56637: refactor ServerStarterRule and LocatorStarterRule so that they can be created without a Properties first.

[Kenneth Howe]

Agree that the normal use if properties is null would be to call one of the 
other startServer methods. My concern was that there’s nothing that enforces 
that.

Adding a null check is good.

Ken

> On Feb 14, 2017, at 10:48 AM, Jinmei Liao  wrote:
> 
> 
> 
>> On Feb. 14, 2017, 6:37 p.m., Ken Howe wrote:
>>> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java,
>>>  lines 94-99
>>> 
>>> 
>>>Looks like a null properties argument will cause an NPE
> 
> Usually when user call this method, he should have a non-null property 
> object, otherwise, he would call the other vairiation of the startServer 
> without the property argument. But I can put a null check here.
> 
> 
> - Jinmei
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56637/#review165541
> ---
> 
> 
> On Feb. 14, 2017, 4:19 p.m., Jinmei Liao wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/56637/
>> ---
>> 
>> (Updated Feb. 14, 2017, 4:19 p.m.)
>> 
>> 
>> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
>> Lund.
>> 
>> 
>> Repository: geode
>> 
>> 
>> Description
>> ---
>> 
>> refactor ServerStarterRule and LocatorStarterRule so that they can be 
>> created without a Properties first.
>> 
>> * this would ease the usage of thsee rules, so that it can always be used as 
>> a rule and users don't have to worry about stopping the locator/server 
>> manually.
>> 
>> 
>> Diffs
>> -
>> 
>>  
>> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>>  2fd6771e24a0a1c2b0450348845dbd9ee36e4d38 
>>  
>> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>>  07e82c319dac25a3d0997d5ea9419127db171487 
>>  
>> geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
>>  33b32e9f720319b9ddbf70d5ab21c688897e1210 
>>  
>> geode-core/src/test/java/org/apache/geode/security/AbstractSecureServerDUnitTest.java
>>  d202b768f14d6ada6c94700df417b733a49c8d8b 
>>  
>> geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
>>  23ffa9a9e5eb403742d31db042b3d0b59f095400 
>>  
>> geode-core/src/test/java/org/apache/geode/security/SecurityClusterConfigDUnitTest.java
>>  fcda2a322e31f5bcd00f922adb9fe7332e2073ef 
>>  
>> geode-core/src/test/java/org/apache/geode/security/SecurityWithoutClusterConfigDUnitTest.java
>>  3add1abe0c14b7948716bce44c0ad7b4dbebd2ea 
>>  
>> geode-core/src/test/java/org/apache/geode/security/StartServerAuthorizationTest.java
>>  8a797022b05c5e3d24599639b5a44830cf669f25 
>>  
>> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>>  0ac459c96cb6e588e016de67fa5b827e62fdcfa0 
>>  
>> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>>  00a0f1e580d17417004e4462ff42c3364522550c 
>>  
>> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>>  f93498fcbcea0ec8d8f0b91a0367e9b6fb7d4ae1 
>>  geode-cq/src/test/java/org/apache/geode/security/CQClientAuthDunitTest.java 
>> 1aa275d0cda7b7dcf9de9fe2837d48491bebfcfa 
>> 
>> Diff: https://reviews.apache.org/r/56637/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> precheckin successful
>> 
>> This code change will also fix the currently failing integration tests. See 
>> the change in MemberMBeanSecurityJUnitTest.java
>> 
>> 
>> Thanks,
>> 
>> Jinmei Liao
>> 
>> 
> 

[jira] [Commented] (GEODE-2474) netstat command fails to correctly identify OS and --with-lsof fails on Mac

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2474:


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

GEODE-2474: mark NetstatDUnitTest as flaky


> netstat command fails to correctly identify OS and --with-lsof fails on Mac
> ---
>
> Key: GEODE-2474
> URL: https://issues.apache.org/jira/browse/GEODE-2474
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: MiscellaneousCommands, NetstatCommand, gfsh, netstat
>
> The netstat gfsh command uses NetstatFunction which has its own faulty logic 
> for identifying the operating system. This logic identifies Mac as Windows 
> and fails to process --with-lsof.
> NetstatFunction should instead use org.apache.geode.internal.lang.SystemUtils 
> which correctly identifies the operating system.



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

Re: Review Request 56637: refactor ServerStarterRule and LocatorStarterRule so that they can be created without a Properties first.

[Jinmei Liao]

> On Feb. 14, 2017, 6:37 p.m., Ken Howe wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java,
> >  lines 94-99
> > 
> >
> > Looks like a null properties argument will cause an NPE

Usually when user call this method, he should have a non-null property object, 
otherwise, he would call the other vairiation of the startServer without the 
property argument. But I can put a null check here.


- Jinmei


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


On Feb. 14, 2017, 4:19 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56637/
> ---
> 
> (Updated Feb. 14, 2017, 4:19 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> refactor ServerStarterRule and LocatorStarterRule so that they can be created 
> without a Properties first.
> 
> * this would ease the usage of thsee rules, so that it can always be used as 
> a rule and users don't have to worry about stopping the locator/server 
> manually.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  2fd6771e24a0a1c2b0450348845dbd9ee36e4d38 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  07e82c319dac25a3d0997d5ea9419127db171487 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
>  33b32e9f720319b9ddbf70d5ab21c688897e1210 
>   
> geode-core/src/test/java/org/apache/geode/security/AbstractSecureServerDUnitTest.java
>  d202b768f14d6ada6c94700df417b733a49c8d8b 
>   
> geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
>  23ffa9a9e5eb403742d31db042b3d0b59f095400 
>   
> geode-core/src/test/java/org/apache/geode/security/SecurityClusterConfigDUnitTest.java
>  fcda2a322e31f5bcd00f922adb9fe7332e2073ef 
>   
> geode-core/src/test/java/org/apache/geode/security/SecurityWithoutClusterConfigDUnitTest.java
>  3add1abe0c14b7948716bce44c0ad7b4dbebd2ea 
>   
> geode-core/src/test/java/org/apache/geode/security/StartServerAuthorizationTest.java
>  8a797022b05c5e3d24599639b5a44830cf669f25 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  0ac459c96cb6e588e016de67fa5b827e62fdcfa0 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  00a0f1e580d17417004e4462ff42c3364522550c 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  f93498fcbcea0ec8d8f0b91a0367e9b6fb7d4ae1 
>   geode-cq/src/test/java/org/apache/geode/security/CQClientAuthDunitTest.java 
> 1aa275d0cda7b7dcf9de9fe2837d48491bebfcfa 
> 
> Diff: https://reviews.apache.org/r/56637/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> This code change will also fix the currently failing integration tests. See 
> the change in MemberMBeanSecurityJUnitTest.java
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 56668: GEODE-2474: mark NetstatDUnitTest as flaky

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On Feb. 14, 2017, 5:01 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56668/
> ---
> 
> (Updated Feb. 14, 2017, 5:01 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2474: mark NetstatDUnitTest as flaky
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
>  3ee0c46675a250db4db2b8558c5cee3cf1e5eea8 
> 
> Diff: https://reviews.apache.org/r/56668/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 56637: refactor ServerStarterRule and LocatorStarterRule so that they can be created without a Properties first.

[Ken Howe]

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




geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 (lines 89 - 94)


Looks like a null properties argument will cause an NPE


- Ken Howe


On Feb. 14, 2017, 4:19 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56637/
> ---
> 
> (Updated Feb. 14, 2017, 4:19 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> refactor ServerStarterRule and LocatorStarterRule so that they can be created 
> without a Properties first.
> 
> * this would ease the usage of thsee rules, so that it can always be used as 
> a rule and users don't have to worry about stopping the locator/server 
> manually.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  2fd6771e24a0a1c2b0450348845dbd9ee36e4d38 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  07e82c319dac25a3d0997d5ea9419127db171487 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
>  33b32e9f720319b9ddbf70d5ab21c688897e1210 
>   
> geode-core/src/test/java/org/apache/geode/security/AbstractSecureServerDUnitTest.java
>  d202b768f14d6ada6c94700df417b733a49c8d8b 
>   
> geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
>  23ffa9a9e5eb403742d31db042b3d0b59f095400 
>   
> geode-core/src/test/java/org/apache/geode/security/SecurityClusterConfigDUnitTest.java
>  fcda2a322e31f5bcd00f922adb9fe7332e2073ef 
>   
> geode-core/src/test/java/org/apache/geode/security/SecurityWithoutClusterConfigDUnitTest.java
>  3add1abe0c14b7948716bce44c0ad7b4dbebd2ea 
>   
> geode-core/src/test/java/org/apache/geode/security/StartServerAuthorizationTest.java
>  8a797022b05c5e3d24599639b5a44830cf669f25 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  0ac459c96cb6e588e016de67fa5b827e62fdcfa0 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  00a0f1e580d17417004e4462ff42c3364522550c 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  f93498fcbcea0ec8d8f0b91a0367e9b6fb7d4ae1 
>   geode-cq/src/test/java/org/apache/geode/security/CQClientAuthDunitTest.java 
> 1aa275d0cda7b7dcf9de9fe2837d48491bebfcfa 
> 
> Diff: https://reviews.apache.org/r/56637/diff/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> This code change will also fix the currently failing integration tests. See 
> the change in MemberMBeanSecurityJUnitTest.java
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Updated] (GEODE-2479) correct doc reference to a com.gemstone package

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller updated GEODE-2479:
---
Fix Version/s: 1.2.0

> correct doc reference to a com.gemstone package
> ---
>
> Key: GEODE-2479
> URL: https://issues.apache.org/jira/browse/GEODE-2479
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> File geode-docs/developing/data_serialization/auto_serialization.html still 
> has a spurious reference to a com.gemstone package.  It should be corrected 
> to identify org.apache.geode instead.
> At the same time, remove links to the 2 subsections with headers
> - Customizing Serialization with Class Pattern Strings
> - Extending the ReflectionBasedAutoSerializer
> These are in the navigation bar, so the links server no purpose.



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

[jira] [Resolved] (GEODE-2479) correct doc reference to a com.gemstone package

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-2479.

Resolution: Fixed
  Assignee: Karen Smoler Miller

> correct doc reference to a com.gemstone package
> ---
>
> Key: GEODE-2479
> URL: https://issues.apache.org/jira/browse/GEODE-2479
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> File geode-docs/developing/data_serialization/auto_serialization.html still 
> has a spurious reference to a com.gemstone package.  It should be corrected 
> to identify org.apache.geode instead.
> At the same time, remove links to the 2 subsections with headers
> - Customizing Serialization with Class Pattern Strings
> - Extending the ReflectionBasedAutoSerializer
> These are in the navigation bar, so the links server no purpose.



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

[jira] [Commented] (GEODE-2470) Remove Dependency on sed tool

[ASF GitHub Bot (JIRA)]

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

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

Github user mmartell commented on the issue:

https://github.com/apache/geode-native/pull/6
  
As per your suggestions, switched to using assign with 
istreambuf_iterators. 


> Remove Dependency on sed tool
> -
>
> Key: GEODE-2470
> URL: https://issues.apache.org/jira/browse/GEODE-2470
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Michael Martell
>
> The integration tests currently rely on sed to replace strings inside config 
> xml files. This task replaces that dependency with standard C++ code.



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

[GitHub] geode-native issue #6: GEODE-2470: Replace sed dependency with standard C++.

[mmartell]

Github user mmartell commented on the issue:

https://github.com/apache/geode-native/pull/6
  
As per your suggestions, switched to using assign with 
istreambuf_iterators. 


---
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-2469) Redis adapter Hash key support

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra commented on GEODE-2469:


Seems like we need to consider ":' here

Redis keys

Redis keys are binary safe, this means that you can use any binary sequence as 
a key, from a string like "foo" to the content of a JPEG file. The empty string 
is also a valid key.

A few other rules about keys:

Very long keys are not a good idea. For instance a key of 1024 bytes is a 
bad idea not only memory-wise, but also because the lookup of the key in the 
dataset may require several costly key-comparisons. Even when the task at hand 
is to match the existence of a large value, hashing it (for example with SHA1) 
is a better idea, especially from the perspective of memory and bandwidth.
Very short keys are often not a good idea. There is little point in writing 
"u1000flw" as a key if you can instead write "user:1000:followers". The latter 
is more readable and the added space is minor compared to the space used by the 
key object itself and the value object. While short keys will obviously consume 
a bit less memory, your job is to find the right balance.
Try to stick with a schema. For instance "object-type:id" is a good idea, 
as in "user:1000". Dots or dashes are often used for multi-word fields, as in 
"comment:1234:reply.to" or "comment:1234:reply-to".
The maximum allowed key size is 512 MB.


> Redis adapter Hash key support
> --
>
> Key: GEODE-2469
> URL: https://issues.apache.org/jira/browse/GEODE-2469
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Gregory Green
>
> The Redis adapter does not appear to handle hash keys correctly.
> The following Example: Redis CLI works.
> localhost:11211>  HSET companies name "John Smith"
> Using a  HSET :id  .. produces an error
> Example:
> localhost:11211>  HSET companies:1000 name "John Smith"
> [Server error]
> [fine 2017/02/10 16:04:33.289 EST server1  
> tid=0x6a] Region names may only be alphanumeric and may contain hyphens or 
> underscores: companies: 1000
> java.lang.IllegalArgumentException: Region names may only be alphanumeric and 
> may contain hyphens or underscores: companies: 1000
> at 
> org.apache.geode.internal.cache.LocalRegion.validateRegionName(LocalRegion.java:7618)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3201)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3181)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3169)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
> at 
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.createRegion(RegionCreateFunction.java:355)
> at 
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.execute(RegionCreateFunction.java:90)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution$2.run(AbstractExecution.java:303)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
> at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
> at java.lang.Thread.run(Thread.java:745)
> //Example Spring Data Redis Object sample
> @Data
> @EqualsAndHashCode()
> @RedisHash(value="companies")
> @NoArgsConstructor
> public class Company
> {
>   private @Id String id;
>
> //Repository
> public interface CompanyRepository extends CrudRepository 
> {
>  
> }
> //When saving using a repository
> repository.save(this.myCompany);
> [Same Server error]
> java.lang.IllegalArgumentException: Region names may only be alphanumeric and 
> may contain hyphens or underscores: 
> companies:f05405c2-86f2-4aaf-bd0c-6fecd483bf28
> at 
> org.apache.geode.internal.cache.LocalRegion.validateRegionName(LocalRegion.java:7618)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3201)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3181)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3169)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
> at 
> org.apache.geode.m

[jira] [Commented] (GEODE-2479) correct doc reference to a com.gemstone package

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2479:


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

GEODE-2479 Remove docs reference to gemstone.com package


> correct doc reference to a com.gemstone package
> ---
>
> Key: GEODE-2479
> URL: https://issues.apache.org/jira/browse/GEODE-2479
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>
> File geode-docs/developing/data_serialization/auto_serialization.html still 
> has a spurious reference to a com.gemstone package.  It should be corrected 
> to identify org.apache.geode instead.
> At the same time, remove links to the 2 subsections with headers
> - Customizing Serialization with Class Pattern Strings
> - Extending the ReflectionBasedAutoSerializer
> These are in the navigation bar, so the links server no purpose.



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

Re: C++ client change history

[Jacob Barrett]

I mean NOW in its own repo at https://github.com/apache/geode-native.


On Tue, Feb 14, 2017 at 9:01 AM Jacob Barrett  wrote:

> Also, keep in mind that Geode Native is not in its own repo at
> https://github.com/apache/geode-native.
>
> -Jake
>
> On Tue, Feb 14, 2017 at 9:00 AM Jacob Barrett  wrote:
>
> No. The NC probably won't make a Geode release until later. There are
> still many things that have to be changed to comply with ASF release rules.
>
> -Jake
>
> On Tue, Feb 14, 2017 at 8:05 AM Gal Palmery 
> wrote:
>
> Hi,
> Is this latest sw grant planned to be a part of the new release that is
> now in discussion ?
>
> Thanks,
> Gal
>
> -Original Message-
> From: Ernest Burghardt [mailto:eburgha...@pivotal.io]
> Sent: Tuesday, February 14, 2017 17:18
> To: dev@geode.apache.org
> Subject: Re: C++ client change history
>
> I don't believe so, best bet is to just treat this latest sw grant as
> where the community will start from on geode-native.
>
>
>
> On Tue, Feb 14, 2017 at 7:05 AM, Avital Amity 
> wrote:
>
> > Thanks Ernie,
> >
> > Is there a place I can find the defect list/feature list between the
> > first dump and the latest one?
> >
> > Thanks
> > Avital
> >
> > -Original Message-
> > From: Ernest Burghardt [mailto:eburgha...@pivotal.io]
> > Sent: Tuesday, February 14, 2017 5:02 PM
> > To: dev@geode.apache.org
> > Subject: Re: C++ client change history
> >
> > Avital,
> > "first dump" == first grant of native client code, we advise you to
> > ignoring the initial grant and begin from the current offering.
> >
> > Best,
> > Ernie
> >
> > On Mon, Feb 13, 2017 at 11:16 PM, Jacob Barrett 
> > wrote:
> >
> > > It's sent by all gemfire servers up to but not including 9.0. The
> > > client was never using the value it was reading. It doesn't bother
> > reading it now.
> > > It works with servers that do send the value and those that don't.
> > >
> > > You should really ignore the first dump and not try to consider
> > > resolving diffs between the two.
> > >
> > > -Jake
> > >
> > > On Mon, Feb 13, 2017 at 10:51 PM Avital Amity
> > > 
> > > wrote:
> > >
> > > > Hi Jacob,
> > > >
> > > > Does the deprecated long in GEODE server 1.0 still exist in GF
> server?
> > > > In what version was it removed from the server
> > > >
> > > > Thanks
> > > > Avital
> > > >
> > > > -Original Message-
> > > > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > > > Sent: Monday, February 13, 2017 8:33 PM
> > > > To: dev@geode.apache.org
> > > > Subject: Re: C++ client change history
> > > >
> > > > The change happened in a commercial release between grants. The
> > > > ping case had a deprecated long read that was not compatible with
> > > > the server Geode 1.0. After removing the read the code path was
> > > > merged with the default as there was no diff.
> > > >
> > > > On Mon, Feb 13, 2017 at 10:06 AM Michael William Dodge <
> > > mdo...@pivotal.io>
> > > > wrote:
> > > >
> > > > > I'm not sure exactly what happened as my git fu isn't that great
> > > > > but could it be as part of commit
> > > > > 4fa64db926f51d4b12d6e4040c703cc69a9832fe? In that commit I see a
> > > > > block under case TcrMessage::PING: being removed so that
> > > > > execution falls through to default: but I'm unsure that I've
> > > > > pieced the output from git diff together properly so that may
> > > > > not be a change that happened in
> > > > TcrMessage::handleByteArrayResponse.
> > > > >
> > > > > Sarge
> > > > >
> > > > > > On 12 Feb, 2017, at 09:25, Avital Amity
> > > > > > 
> > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm trying to track the history of TcrMessage.cpp but I can
> > > > > > find it only
> > > > > in the new client release where it moved under cppcache/src
> > > > > > In particular I'm searching for the change where in function
> > > > > TcrMessage::handleByteArrayResponse
> > > > > > Where the case of PING message was merged with the case of the
> > > > > > default
> > > > > message
> > > > > >
> > > > > > Thanks
> > > > > > Avital
> > > > > > This message and the information contained herein is
> > > > > > proprietary and
> > > > > confidential and subject to the Amdocs policy statement,
> > > > > >
> > > > > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > > > >
> > > > >
> > > > This message and the information contained herein is proprietary
> > > > and confidential and subject to the Amdocs policy statement,
> > > >
> > > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > > >
> > >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
>

Re: Review Request 56632: This is caused by race condition that bucket is moved, but 'moved' is not set to true yet

[Jason Huynh]

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


Ship it!




Ship It!

- Jason Huynh


On Feb. 14, 2017, 2:10 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56632/
> ---
> 
> (Updated Feb. 14, 2017, 2:10 a.m.)
> 
> 
> Review request for geode and Jason Huynh.
> 
> 
> Bugs: GEODE-2471
> https://issues.apache.org/jira/browse/GEODE-2471
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> I can reproduce the bug by put a sleep between moveBucket() and move=true.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/wan/asyncqueue/AsyncEventListenerDUnitTest.java
>  e2e062b 
> 
> Diff: https://reviews.apache.org/r/56632/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: C++ client change history

[Jacob Barrett]

Also, keep in mind that Geode Native is not in its own repo at
https://github.com/apache/geode-native.

-Jake

On Tue, Feb 14, 2017 at 9:00 AM Jacob Barrett  wrote:

> No. The NC probably won't make a Geode release until later. There are
> still many things that have to be changed to comply with ASF release rules.
>
> -Jake
>
> On Tue, Feb 14, 2017 at 8:05 AM Gal Palmery 
> wrote:
>
> Hi,
> Is this latest sw grant planned to be a part of the new release that is
> now in discussion ?
>
> Thanks,
> Gal
>
> -Original Message-
> From: Ernest Burghardt [mailto:eburgha...@pivotal.io]
> Sent: Tuesday, February 14, 2017 17:18
> To: dev@geode.apache.org
> Subject: Re: C++ client change history
>
> I don't believe so, best bet is to just treat this latest sw grant as
> where the community will start from on geode-native.
>
>
>
> On Tue, Feb 14, 2017 at 7:05 AM, Avital Amity 
> wrote:
>
> > Thanks Ernie,
> >
> > Is there a place I can find the defect list/feature list between the
> > first dump and the latest one?
> >
> > Thanks
> > Avital
> >
> > -Original Message-
> > From: Ernest Burghardt [mailto:eburgha...@pivotal.io]
> > Sent: Tuesday, February 14, 2017 5:02 PM
> > To: dev@geode.apache.org
> > Subject: Re: C++ client change history
> >
> > Avital,
> > "first dump" == first grant of native client code, we advise you to
> > ignoring the initial grant and begin from the current offering.
> >
> > Best,
> > Ernie
> >
> > On Mon, Feb 13, 2017 at 11:16 PM, Jacob Barrett 
> > wrote:
> >
> > > It's sent by all gemfire servers up to but not including 9.0. The
> > > client was never using the value it was reading. It doesn't bother
> > reading it now.
> > > It works with servers that do send the value and those that don't.
> > >
> > > You should really ignore the first dump and not try to consider
> > > resolving diffs between the two.
> > >
> > > -Jake
> > >
> > > On Mon, Feb 13, 2017 at 10:51 PM Avital Amity
> > > 
> > > wrote:
> > >
> > > > Hi Jacob,
> > > >
> > > > Does the deprecated long in GEODE server 1.0 still exist in GF
> server?
> > > > In what version was it removed from the server
> > > >
> > > > Thanks
> > > > Avital
> > > >
> > > > -Original Message-
> > > > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > > > Sent: Monday, February 13, 2017 8:33 PM
> > > > To: dev@geode.apache.org
> > > > Subject: Re: C++ client change history
> > > >
> > > > The change happened in a commercial release between grants. The
> > > > ping case had a deprecated long read that was not compatible with
> > > > the server Geode 1.0. After removing the read the code path was
> > > > merged with the default as there was no diff.
> > > >
> > > > On Mon, Feb 13, 2017 at 10:06 AM Michael William Dodge <
> > > mdo...@pivotal.io>
> > > > wrote:
> > > >
> > > > > I'm not sure exactly what happened as my git fu isn't that great
> > > > > but could it be as part of commit
> > > > > 4fa64db926f51d4b12d6e4040c703cc69a9832fe? In that commit I see a
> > > > > block under case TcrMessage::PING: being removed so that
> > > > > execution falls through to default: but I'm unsure that I've
> > > > > pieced the output from git diff together properly so that may
> > > > > not be a change that happened in
> > > > TcrMessage::handleByteArrayResponse.
> > > > >
> > > > > Sarge
> > > > >
> > > > > > On 12 Feb, 2017, at 09:25, Avital Amity
> > > > > > 
> > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm trying to track the history of TcrMessage.cpp but I can
> > > > > > find it only
> > > > > in the new client release where it moved under cppcache/src
> > > > > > In particular I'm searching for the change where in function
> > > > > TcrMessage::handleByteArrayResponse
> > > > > > Where the case of PING message was merged with the case of the
> > > > > > default
> > > > > message
> > > > > >
> > > > > > Thanks
> > > > > > Avital
> > > > > > This message and the information contained herein is
> > > > > > proprietary and
> > > > > confidential and subject to the Amdocs policy statement,
> > > > > >
> > > > > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > > > >
> > > > >
> > > > This message and the information contained herein is proprietary
> > > > and confidential and subject to the Amdocs policy statement,
> > > >
> > > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > > >
> > >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>
>

[jira] [Commented] (GEODE-2427) JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests

[Jinmei Liao (JIRA)]

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

Jinmei Liao commented on GEODE-2427:


fixed

> JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
> --
>
> Key: GEODE-2427
> URL: https://issues.apache.org/jira/browse/GEODE-2427
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> JMXMBeanDUnitTest.testJMXOverLegacySSL is currently marked as a FlakyTest. If 
> you run this test with the other tests in JMXMBeanDUnitTest it fails 100% of 
> the time. By marking it as FlakyTest, it runs separately in its own JVMs 
> during the FlakyTest task. This seems to be caused by the other tests setting 
> some statics that don't get cleaned up before running testJMXOverLegacySSL. 
> So there's some sort of product configuration pollution going on here.
> JMXMBeanDUnitTest is cleaning up all System properties between tests, so the 
> problem is not caused by a System property remaining set. It seems like it 
> might have something to do with SSL configuration in JDK classes being static.
> The FlakyTest task forks the testing JVMs for every test case so 
> testJMXOverLegacySSL ends up with fresh JVMs under FlakyTest and it passes 
> 100% that way.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host 
> 10.118.33.232 with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
>   at 
> org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:139)
>   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 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
>   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: 
> javax.naming.CommunicationE

[jira] [Assigned] (GEODE-2427) JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2427:
--

Assignee: Jinmei Liao

> JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
> --
>
> Key: GEODE-2427
> URL: https://issues.apache.org/jira/browse/GEODE-2427
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> JMXMBeanDUnitTest.testJMXOverLegacySSL is currently marked as a FlakyTest. If 
> you run this test with the other tests in JMXMBeanDUnitTest it fails 100% of 
> the time. By marking it as FlakyTest, it runs separately in its own JVMs 
> during the FlakyTest task. This seems to be caused by the other tests setting 
> some statics that don't get cleaned up before running testJMXOverLegacySSL. 
> So there's some sort of product configuration pollution going on here.
> JMXMBeanDUnitTest is cleaning up all System properties between tests, so the 
> problem is not caused by a System property remaining set. It seems like it 
> might have something to do with SSL configuration in JDK classes being static.
> The FlakyTest task forks the testing JVMs for every test case so 
> testJMXOverLegacySSL ends up with fresh JVMs under FlakyTest and it passes 
> 100% that way.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host 
> 10.118.33.232 with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
>   at 
> org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:139)
>   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 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
>   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: 
> javax.naming.CommunicationException [Root exception is 
> 

[jira] [Resolved] (GEODE-2427) JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2427.

   Resolution: Fixed
Fix Version/s: 1.2.0

> JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests
> --
>
> Key: GEODE-2427
> URL: https://issues.apache.org/jira/browse/GEODE-2427
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
> Fix For: 1.2.0
>
>
> JMXMBeanDUnitTest.testJMXOverLegacySSL is currently marked as a FlakyTest. If 
> you run this test with the other tests in JMXMBeanDUnitTest it fails 100% of 
> the time. By marking it as FlakyTest, it runs separately in its own JVMs 
> during the FlakyTest task. This seems to be caused by the other tests setting 
> some statics that don't get cleaned up before running testJMXOverLegacySSL. 
> So there's some sort of product configuration pollution going on here.
> JMXMBeanDUnitTest is cleaning up all System properties between tests, so the 
> problem is not caused by a System property remaining set. It seems like it 
> might have something to do with SSL configuration in JDK classes being static.
> The FlakyTest task forks the testing JVMs for every test case so 
> testJMXOverLegacySSL ends up with fresh JVMs under FlakyTest and it passes 
> 100% that way.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host 
> 10.118.33.232 with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
>   at 
> org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:139)
>   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 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
>   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: 
> javax.naming.CommunicationException [Ro

Review Request 56668: GEODE-2474: mark NetstatDUnitTest as flaky

[Jinmei Liao]

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

Review request for geode.


Repository: geode


Description
---

GEODE-2474: mark NetstatDUnitTest as flaky


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
 3ee0c46675a250db4db2b8558c5cee3cf1e5eea8 

Diff: https://reviews.apache.org/r/56668/diff/


Testing
---


Thanks,

Jinmei Liao

Re: C++ client change history

[Jacob Barrett]

No. The NC probably won't make a Geode release until later. There are still
many things that have to be changed to comply with ASF release rules.

-Jake

On Tue, Feb 14, 2017 at 8:05 AM Gal Palmery  wrote:

> Hi,
> Is this latest sw grant planned to be a part of the new release that is
> now in discussion ?
>
> Thanks,
> Gal
>
> -Original Message-
> From: Ernest Burghardt [mailto:eburgha...@pivotal.io]
> Sent: Tuesday, February 14, 2017 17:18
> To: dev@geode.apache.org
> Subject: Re: C++ client change history
>
> I don't believe so, best bet is to just treat this latest sw grant as
> where the community will start from on geode-native.
>
>
>
> On Tue, Feb 14, 2017 at 7:05 AM, Avital Amity 
> wrote:
>
> > Thanks Ernie,
> >
> > Is there a place I can find the defect list/feature list between the
> > first dump and the latest one?
> >
> > Thanks
> > Avital
> >
> > -Original Message-
> > From: Ernest Burghardt [mailto:eburgha...@pivotal.io]
> > Sent: Tuesday, February 14, 2017 5:02 PM
> > To: dev@geode.apache.org
> > Subject: Re: C++ client change history
> >
> > Avital,
> > "first dump" == first grant of native client code, we advise you to
> > ignoring the initial grant and begin from the current offering.
> >
> > Best,
> > Ernie
> >
> > On Mon, Feb 13, 2017 at 11:16 PM, Jacob Barrett 
> > wrote:
> >
> > > It's sent by all gemfire servers up to but not including 9.0. The
> > > client was never using the value it was reading. It doesn't bother
> > reading it now.
> > > It works with servers that do send the value and those that don't.
> > >
> > > You should really ignore the first dump and not try to consider
> > > resolving diffs between the two.
> > >
> > > -Jake
> > >
> > > On Mon, Feb 13, 2017 at 10:51 PM Avital Amity
> > > 
> > > wrote:
> > >
> > > > Hi Jacob,
> > > >
> > > > Does the deprecated long in GEODE server 1.0 still exist in GF
> server?
> > > > In what version was it removed from the server
> > > >
> > > > Thanks
> > > > Avital
> > > >
> > > > -Original Message-
> > > > From: Jacob Barrett [mailto:jbarr...@pivotal.io]
> > > > Sent: Monday, February 13, 2017 8:33 PM
> > > > To: dev@geode.apache.org
> > > > Subject: Re: C++ client change history
> > > >
> > > > The change happened in a commercial release between grants. The
> > > > ping case had a deprecated long read that was not compatible with
> > > > the server Geode 1.0. After removing the read the code path was
> > > > merged with the default as there was no diff.
> > > >
> > > > On Mon, Feb 13, 2017 at 10:06 AM Michael William Dodge <
> > > mdo...@pivotal.io>
> > > > wrote:
> > > >
> > > > > I'm not sure exactly what happened as my git fu isn't that great
> > > > > but could it be as part of commit
> > > > > 4fa64db926f51d4b12d6e4040c703cc69a9832fe? In that commit I see a
> > > > > block under case TcrMessage::PING: being removed so that
> > > > > execution falls through to default: but I'm unsure that I've
> > > > > pieced the output from git diff together properly so that may
> > > > > not be a change that happened in
> > > > TcrMessage::handleByteArrayResponse.
> > > > >
> > > > > Sarge
> > > > >
> > > > > > On 12 Feb, 2017, at 09:25, Avital Amity
> > > > > > 
> > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm trying to track the history of TcrMessage.cpp but I can
> > > > > > find it only
> > > > > in the new client release where it moved under cppcache/src
> > > > > > In particular I'm searching for the change where in function
> > > > > TcrMessage::handleByteArrayResponse
> > > > > > Where the case of PING message was merged with the case of the
> > > > > > default
> > > > > message
> > > > > >
> > > > > > Thanks
> > > > > > Avital
> > > > > > This message and the information contained herein is
> > > > > > proprietary and
> > > > > confidential and subject to the Amdocs policy statement,
> > > > > >
> > > > > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > > > >
> > > > >
> > > > This message and the information contained herein is proprietary
> > > > and confidential and subject to the Amdocs policy statement,
> > > >
> > > > you may review at http://www.amdocs.com/email_disclaimer.asp
> > > >
> > >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Review Request 56635: GEODE-2481: extract default properties generation to its own class

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On Feb. 14, 2017, 2:33 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56635/
> ---
> 
> (Updated Feb. 14, 2017, 2:33 a.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and Ken 
> Howe.
> 
> 
> Bugs: GEODE-2481
> https://issues.apache.org/jira/browse/GEODE-2481
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2481: extract default properties generation to its own class
> 
> While refactoring GemFireVersion for GEODE-2474, I noticed that 
> GemFireVersionIntegrationJUnitTest has nothing to do with GemFireVersion.
> 
> Extract generation of default properties to DefaultPropertiesGenerator.
> 
> Rename GemFireVersionIntegrationJUnitTest to 
> DefaultPropertiesGeneratorIntegrationTest. Add tests to increase code 
> coverage.
> 
> Note: I have several changes on feature/GEODE-2474 branch which I'll separate 
> into multiple reviews. I'll do a final precheckin on the entire branch and 
> then merge the changes in after everything passes review and precheckin.
> 
> DistributionConfig and DefaultPropertiesGenerator should eventually move to a 
> configuration package, but I don't really want to combine anything that big 
> with this change.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle f34688043dd3e6bf8e8bdf0cb223d533b692e301 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DefaultPropertiesGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java
>  fa6d13f7cec40ae18f78da28b3b912e01be363aa 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DefaultPropertiesGeneratorIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/GemFireVersionIntegrationJUnitTest.java
>  cae331325f17b470e6dd786d0f9a52bba7cb42a6 
> 
> Diff: https://reviews.apache.org/r/56635/diff/
> 
> 
> Testing
> ---
> 
> DefaultPropertiesGeneratorIntegrationTest
> GemFireVersionJUnitTest
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 56633: GEODE-2474: refactor code to use SystemUtils to read OS system props

[Jinmei Liao]

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




geode-core/src/test/java/org/apache/geode/internal/lang/SystemUtilsJUnitTest.java
 (line 114)


Are these tests really necessary? The expected and actual are using the 
same code to get the results.


Everything else looks great.

- Jinmei Liao


On Feb. 14, 2017, 2:31 a.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56633/
> ---
> 
> (Updated Feb. 14, 2017, 2:31 a.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and Ken 
> Howe.
> 
> 
> Bugs: GEODE-2474
> https://issues.apache.org/jira/browse/GEODE-2474
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2474: refactor code to use SystemUtils to read OS system props
> 
> Centralize OS system property reading in SystemUtils.
> 
> Refactor NetstatFunction and GemFireVersion to use SystemUtils.
> 
> This fixes use of --with-lsof on Mac (manually tested). I'll add new tests to 
> NetstatDUnitTest and a new integration test for netstat command in a 
> follow-up commit & review.
> 
> I have several changes on feature/GEODE-2474 branch which I'll separate into 
> multiple reviews. I'll do a final precheckin on the entire branch and then 
> merge the changes in after everything passes review and precheckin.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/GemFireVersion.java 
> 26d4fb3c5705bffdcdbbc6c261dbe9ffd297642e 
>   geode-core/src/main/java/org/apache/geode/internal/lang/SystemUtils.java 
> 66c158c93fecac4feb2da56f617f5efc7bba56e1 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/NetstatFunction.java
>  5fa30f47187972a209a781eae9024957dc80fb72 
>   
> geode-core/src/test/java/org/apache/geode/internal/lang/SystemUtilsJUnitTest.java
>  48f176eabc18d3ffa56daaa7da12634a9554f39d 
> 
> Diff: https://reviews.apache.org/r/56633/diff/
> 
> 
> Testing
> ---
> 
> SystemUtilsJUnitTest
> NetstatDUnitTest
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 56637: refactor ServerStarterRule and LocatorStarterRule so that they can be created without a Properties first.

[Jinmei Liao]

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

(Updated Feb. 14, 2017, 4:19 p.m.)


Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk Lund.


Repository: geode


Description
---

refactor ServerStarterRule and LocatorStarterRule so that they can be created 
without a Properties first.

* this would ease the usage of thsee rules, so that it can always be used as a 
rule and users don't have to worry about stopping the locator/server manually.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
 2fd6771e24a0a1c2b0450348845dbd9ee36e4d38 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
 07e82c319dac25a3d0997d5ea9419127db171487 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
 33b32e9f720319b9ddbf70d5ab21c688897e1210 
  
geode-core/src/test/java/org/apache/geode/security/AbstractSecureServerDUnitTest.java
 d202b768f14d6ada6c94700df417b733a49c8d8b 
  
geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
 23ffa9a9e5eb403742d31db042b3d0b59f095400 
  
geode-core/src/test/java/org/apache/geode/security/SecurityClusterConfigDUnitTest.java
 fcda2a322e31f5bcd00f922adb9fe7332e2073ef 
  
geode-core/src/test/java/org/apache/geode/security/SecurityWithoutClusterConfigDUnitTest.java
 3add1abe0c14b7948716bce44c0ad7b4dbebd2ea 
  
geode-core/src/test/java/org/apache/geode/security/StartServerAuthorizationTest.java
 8a797022b05c5e3d24599639b5a44830cf669f25 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 0ac459c96cb6e588e016de67fa5b827e62fdcfa0 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
 00a0f1e580d17417004e4462ff42c3364522550c 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 f93498fcbcea0ec8d8f0b91a0367e9b6fb7d4ae1 
  geode-cq/src/test/java/org/apache/geode/security/CQClientAuthDunitTest.java 
1aa275d0cda7b7dcf9de9fe2837d48491bebfcfa 

Diff: https://reviews.apache.org/r/56637/diff/


Testing (updated)
---

precheckin successful

This code change will also fix the currently failing integration tests. See the 
change in MemberMBeanSecurityJUnitTest.java


Thanks,

Jinmei Liao

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

[Jinmei Liao]

We have a fix for the integration test failure, and fix for the distributed
tests are in review too. Thanks!

On Tue, Feb 14, 2017 at 8:12 AM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> Changes:
>
> [klund] GEODE-2460: update dependency versions
>
> [jiliao] GEODE-1716: refactor JMXMBeanDunitTest
>
> [huynhja] GEODE-2475: Upgrade Lucene version to 6.4.1
>
> [khowe] GEODE-2398: Retry oplog channel.write on silent failures
>
> [khowe] GEODE-2398: Updates from review
>
> --
> [...truncated 874 lines...]
> :geode-json:spotlessCheck
> :geode-json:test UP-TO-DATE
> :geode-json:check
> :geode-json:build
> :geode-json:distributedTest UP-TO-DATE
> :geode-json:flakyTest UP-TO-DATE
> :geode-json:integrationTest UP-TO-DATE
> :geode-junit:javadoc
> :geode-junit:javadocJar
> :geode-junit:sourcesJar
> :geode-junit:signArchives SKIPPED
> :geode-junit:assemble
> :geode-junit:compileTestJava
> :geode-junit:processTestResources UP-TO-DATE
> :geode-junit:testClasses
> :geode-junit:checkMissedTests
> :geode-junit:spotlessJavaCheck
> :geode-junit:spotlessCheck
> :geode-junit:test
> :geode-junit:check
> :geode-junit:build
> :geode-junit:distributedTest
> :geode-junit:flakyTest
> :geode-junit:integrationTest
> :geode-lucene:assemble
> :geode-lucene:compileTestJava
> Download https://repo1.maven.org/maven2/org/apache/lucene/
> lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.pom
> Download https://repo1.maven.org/maven2/org/apache/lucene/
> lucene-codecs/6.4.1/lucene-codecs-6.4.1.pom
> Download https://repo1.maven.org/maven2/com/carrotsearch/
> randomizedtesting/randomizedtesting-runner/2.4.
> 0/randomizedtesting-runner-2.4.0.pom
> Download https://repo1.maven.org/maven2/com/carrotsearch/
> randomizedtesting/randomizedtesting-parent/2.4.
> 0/randomizedtesting-parent-2.4.0.pom
> Download https://repo1.maven.org/maven2/org/apache/lucene/
> lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.jar
> Download https://repo1.maven.org/maven2/org/apache/lucene/
> lucene-codecs/6.4.1/lucene-codecs-6.4.1.jar
> Download https://repo1.maven.org/maven2/com/carrotsearch/
> randomizedtesting/randomizedtesting-runner/2.4.
> 0/randomizedtesting-runner-2.4.0.jar
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> :geode-lucene:processTestResources
> :geode-lucene:testClasses
> :geode-lucene:checkMissedTests
> :geode-lucene:spotlessJavaCheck
> :geode-lucene:spotlessCheck
> :geode-lucene:test
> :geode-lucene:check
> :geode-lucene:build
> :geode-lucene:distributedTest
> :geode-lucene:flakyTest
> :geode-lucene:integrationTest
> :geode-old-client-support:assemble
> :geode-old-client-support:compileTestJava
> :geode-old-client-support:processTestResources UP-TO-DATE
> :geode-old-client-support:testClasses
> :geode-old-client-support:checkMissedTests
> :geode-old-client-support:spotlessJavaCheck
> :geode-old-client-support:spotlessCheck
> :geode-old-client-support:test
> :geode-old-client-support:check
> :geode-old-client-support:build
> :geode-old-client-support:distributedTest
> :geode-old-client-support:flakyTest
> :geode-old-client-support:integrationTest
> :geode-old-versions:javadoc UP-TO-DATE
> :geode-old-versions:javadocJar
> :geode-old-versions:sourcesJar
> :geode-old-versions:signArchives SKIPPED
> :geode-old-versions:assemble
> :geode-old-versions:compileTestJava UP-TO-DATE
> :geode-old-versions:processTestResources UP-TO-DATE
> :geode-old-versions:testClasses UP-TO-DATE
> :geode-old-versions:checkMissedTests UP-TO-DATE
> :geode-old-versions:spotlessJavaCheck
> :geode-old-versions:spotlessCheck
> :geode-old-versions:test UP-TO-DATE
> :geode-old-versions:check
> :geode-old-versions:build
> :geode-old-versions:distributedTest UP-TO-DATE
> :geode-old-versions:flakyTest UP-TO-DATE
> :geode-old-versions:integrationTest UP-TO-DATE
> :geode-pulse:assemble
> :geode-pulse:compileTestJava
> Download https://repo1.maven.org/maven2/com/codeborne/
> phantomjsdriver/1.3.0/phantomjsdriver-1.3.0.pom
> Download https://repo1.maven.org/maven2/org/seleniumhq/
> selenium/selenium-api/3.0.1/selenium-api-3.0.1.pom
> Download https://repo1.maven.org/maven2/org/seleniumhq/
> selenium/selenium-remote-driver/3.0.1/selenium-remote-driver-3.0.1.pom
> Download https://repo1.maven.org/maven2/org/seleniumhq/
> selenium/selenium-support/3.0.1/selenium-support-3.0.1.pom
> Download https://repo1.maven.org/maven2/org/apache/
> httpcomponents/httpmime/4.5.2/httpmime-4.5.2.pom
> Download https://repo1.maven.org/maven2/cglib/cglib-nodep/3.2.
> 4/cglib-nodep-3.2.4.pom
> Download https://repo1.maven.org/maven2/com/codeborne/
> phantomjsdriver/1.3.0/phantomjsdriver-1.3.0.jar
> Download https://repo1.maven.org/maven2/org/seleniumhq/
> selenium/selenium-api/3.0.1/selenium-api-3.0.

Re: [VOTE] RC2: Apache Geode release - v1.1.0

[Jinmei Liao]

+1
basic gfsh with security turned on.

On Tue, Feb 14, 2017 at 7:54 AM, Udo Kohlmeyer 
wrote:

> +1
>
> CRUD
> Simple OQL
> Basic GFSH (start/stop servers, describe regions...)
>
>
> On 2/14/17 05:06, William Markito Oliveira wrote:
>
>> +1 (binding)
>>
>> Checked build from src
>> Basic gfsh cmds, crud
>> Verified Signatures and hashes.
>>
>> Definitely should fix the incubating references in a subsequent release.
>>   v1.1.1 ?
>>
>> Thanks.
>>
>> On Mon, Feb 13, 2017 at 1:17 PM Dan Smith 
>> wrote:
>>
>> +1 (binding)
>>>
>>> IMO I think we don't have to hold up this release for the incubating
>>> references in BUILDING, docker, etc. as long as we can make the docs on
>>> the
>>> website correct. Is someone working on cleaning up the incubating
>>> references on develop?
>>>
>>> Verified:
>>>   - signatures of artifacts
>>>   - download and basic CRUD test of geode-core from the maven site
>>>   - source build works
>>>   - basic gfsh CRUD test
>>>
>>>
>>> -Dan
>>>
>>> On Sun, Feb 12, 2017 at 10:50 AM, Anthony Baker 
>>> wrote:
>>>
>>> +1 (binding)

 Verified:
 - LICENSE + NOTICE
 - rat report
 - hashes and signatures
 - builds from src / tag
 - sample applications run correctly

 Anthony

 On Feb 9, 2017, at 12:55 PM, Hitesh Khamesra
>
 
>>>
 wrote:

> All,
>
> This is the second release candidate of the first release for Apache
>
 Geode, version 1.1.0.

> Thanks to all the community members.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>
 projectId=12318420&version=12338352

>
> *** Please download, test and vote by Tuesday, February 14, 0800 hrs US
>
 Pacific.

> Note that we are voting upon the source (tag):
> rel/v1.1.0.RC2
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
>
 refs/tags/rel/v1.1.0.RC2

> Commit ID: 2286fd064a52173eab8fdcfadfb89a01e81ef728
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC2/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/
>
 orgapachegeode-1016/

> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/release/1.1.0/KEYS
>
> pub   4096R/AC6AB8ED 2017-01-18
>Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A
>
 B8ED

> Thanks,
> Hitesh
>


>


-- 
Cheers

Jinmei