Re: Missing Gitbox activation email

[Jacob Barrett]

I think the key is exactly what Dan pointed out about accepting the Apache org 
invite on GitHub. If you hadn’t done that previously you must do it now. You 
must have any and all GitHub IDs you plan to use as committer registered with 
Apache. You should also have any and all email addresses you plan to use as 
committer registered as well.

-Jake


> On Sep 6, 2017, at 8:07 PM, Ernest Burghardt  wrote:
> 
> When geode-native moved I don't think we received an activation email...
> just had to follow the instructions Jake sent out: (obviously drop the
> "-native")
> 
> For committers the origin is now github.com/apache/geode-native. Before you
> can get write access to the new repo you need to "link" your accounts via
> https://gitbox.apache.org/setup/. You should also change the URL of your
> origin from Apache to GitHub. You will also notice we have full control
> over pull requests, including assignments and labeling. Good times ahead.
> 
>> On Wed, Sep 6, 2017 at 5:53 PM, Xiaojian Zhou  wrote:
>> 
>> I did not get any email. But it seems all set for me.
>> 
>> ​
>> 
>>> On Wed, Sep 6, 2017 at 4:33 PM, Nabarun Nag  wrote:
>>> 
>>> *I think the email takes some time to arrive."An organisational invite
>>> will
>>> be sent to you via email shortly thereafter (within 30 minutes)."*
>>> 
 On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:
 
 If you are stuck on 3rd step (MFA Status) make you have added your
>>> github
 username on id.apache.org *and* that you have accepted the invitation
>>> to
 join the apache group on github.
 
 You should see an apache feather listed underneath your organizations on
 github.
 
 -Dan
 
 On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett 
>>> wrote:
 
> I’d hit up Infra tomorrow if it isn’t working by then.
> 
>> On Sep 6, 2017, at 4:06 PM, Jared Stewart 
>>> wrote:
>> 
>> I’m stuck on the same step.  I tried clearing out my GitHub
>>> username at
> id.apache.org  and then re-adding it in the
>>> hopes
> of re-triggering the email, but it still hasn’t arrived.
>> 
>> - Jared
>>> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
>>> 
>>> Hey there,
>>> 
>>> I've gone through all the steps to activate my github user with
 gitbox.
>>> 
>>> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
> currently waiting for the email that I'm supposed to receive, BUT it
>>> has
> never arrived. I have checked my Spam folder and it was not in there
 either.
>>> 
>>> Does anyone know how to have to email sent *again*?
>>> 
>>> --Udo
>> 
> 
 
>>> 
>> 
>> 

Re: Missing Gitbox activation email

[Ernest Burghardt]

When geode-native moved I don't think we received an activation email...
just had to follow the instructions Jake sent out: (obviously drop the
"-native")

For committers the origin is now github.com/apache/geode-native. Before you
can get write access to the new repo you need to "link" your accounts via
https://gitbox.apache.org/setup/. You should also change the URL of your
origin from Apache to GitHub. You will also notice we have full control
over pull requests, including assignments and labeling. Good times ahead.

On Wed, Sep 6, 2017 at 5:53 PM, Xiaojian Zhou  wrote:

> I did not get any email. But it seems all set for me.
>
> ​
>
> On Wed, Sep 6, 2017 at 4:33 PM, Nabarun Nag  wrote:
>
>> *I think the email takes some time to arrive."An organisational invite
>> will
>> be sent to you via email shortly thereafter (within 30 minutes)."*
>>
>> On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:
>>
>> > If you are stuck on 3rd step (MFA Status) make you have added your
>> github
>> > username on id.apache.org *and* that you have accepted the invitation
>> to
>> > join the apache group on github.
>> >
>> > You should see an apache feather listed underneath your organizations on
>> > github.
>> >
>> > -Dan
>> >
>> > On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett 
>> wrote:
>> >
>> > > I’d hit up Infra tomorrow if it isn’t working by then.
>> > >
>> > > > On Sep 6, 2017, at 4:06 PM, Jared Stewart 
>> wrote:
>> > > >
>> > > > I’m stuck on the same step.  I tried clearing out my GitHub
>> username at
>> > > id.apache.org  and then re-adding it in the
>> hopes
>> > > of re-triggering the email, but it still hasn’t arrived.
>> > > >
>> > > > - Jared
>> > > >> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
>> > > >>
>> > > >> Hey there,
>> > > >>
>> > > >> I've gone through all the steps to activate my github user with
>> > gitbox.
>> > > >>
>> > > >> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
>> > > currently waiting for the email that I'm supposed to receive, BUT it
>> has
>> > > never arrived. I have checked my Spam folder and it was not in there
>> > either.
>> > > >>
>> > > >> Does anyone know how to have to email sent *again*?
>> > > >>
>> > > >> --Udo
>> > > >
>> > >
>> >
>>
>
>

Re: Stored procedures on Apache Geode.

[John Blum]

Hi Marios-

Comments below...

On Sun, Aug 27, 2017 at 11:32 AM, marios390 <
marios.sofocle...@creditsafe.com> wrote:

> Hi John,
>
> I am confused a little bit about the different ways of setting up geode
> cluster and deploying it in CF.
> In short:
>
>   *   If we choose gemfire we can easily provision it on CF via a tile,
> whereas if we go with Geode we have to setup cluster externally (i.e aws)
> correct ?
>

Correct


>   *   I really like using annotations to configure embedded components
> (i.e locator, servers etc) and am wondering weather or not I can use those
> to deploy app  directly on CF without setting up a cluster externally.
>

Not exactly, not when using the PCF, PCC tile (as you called out above).

If you were to create your own DS (peer cache cluster) on PCF from a
collection of your own *Spring Boot* applications deployed to PCF, then
sure, maybe, but that is not a topology we are recommending.  We are
strictly encouraging users to take advantage of the managed services
offered in PCF using the client/server topology since they will be
optimized accordingly.

Therefore, PCF only supports deployment of *Spring (Boot),* GemFire "cache
client" (i.e. ClientCache) applications (that use PCF services like
PCC/SSC, which are backed by Pivotal GemFire).  There is not an option to
run Apache Geode server-side in PCF and you won't be able to leverage SDG's
new Annotation configuration model to configure the PCF, PCC
(GemFire-based) "servers".  Configuration of the PCF/GemFire-based tile
will all be handled using either the PCF cli (+ BOSH) and/or with PCF's UI.

Typically, a user should only really need to worry about provisioning the
service, and the cluster such as the number of servers required by the
application on start, scaling the service to handle load, the amount
memory, etc.

Beyond that, my vision is that the application will inform the service of
all the configuration artifacts it needs via the application's
configuration meta-data (as in Spring configuration meta-data in all it
various forms; no "special" descriptors required either, *yuck*!).

A certain faction would have you use *Gfsh* to configure Regions, etc, as
indicated in the documentation.  I think this is complete non-sense.

A user really should not be aware that GemFire is involved at all when
using PCC/SSC, especially for simple UC (e.g. "*look-aside caching*", which
was the initial intent of the PCC service, though that is now evolving).

Having said that, what does this mean?

Well, like the server-side configuration, there are a set of Annotations
for use on the client as well.

You are probably already aware of the @ClientCacheApplication annotation
(which is to the client as the @PeerCacheApplication annotation is to the
server).  There won't be any embeddable service annotations for the client
(e.g. @EnableLocator, @EnableManager, @EnableRedisServer,
@EnableMemcachedServer, etc), but there are new and powerful annotations
coming for the client (some are already available).

For instance...

1. @EnableEntityDefinedRegions - which creates Regions (locally) for @Region
annotated application domain classes used in the SD[G] Repository
abstraction/extension.  For example...

*@Region("Customers")*
class Customer { ... }

interface CustomersRepository extends CrudRepository { ... }

2. @EnableCachingDefinedRegions - which creates Regions (locally) for
all *Spring
Cache Abstraction* annotated application service components in a *Spring*
(Boot) application.  This applies to all of *Spring's* *Cache Abstraction*
annotations (@Cacheable, @CacheEvict, @CachePut, @Caching, @CacheConfig)
along with JSR-107 - *JCache* annotations.  For example...

@Service
class CustomerService {

*@Cacheable("Customers")*
Customer findByAccount(Account account) {
...
 }
}


3. @EnableIndexing - applies Index (OQL or Lucene, now) using annotated
fields on application domain objects.  For example...

@Region("Customers")
class Customer {

*@Indexed* // OQL Index
String lastName;

*@LuceneIndexed*
String notes;

}

Of course, all of this would not be as useful it if did not get "pushed" to
the server, so there is...

4 @EnableClusterConfiguration - which uses the *Spring* *(Data
GemFire/Geode)* annotations and configuration meta-data to configure the
servers now. Not only that, it will push the configuration in such a manner
that the GemFire/Geode *Cluster Configuration* service is used to
"remember" the config sent by the *Spring* application so that if the PCC
service on PCF is restarted for any reason (a.k.a. cluster is bounced), the
cluster will pick up the configuration the clients sent it, originally.
Clients are also careful not to stomp any existing configuration or data
that may already be present.  In other words, when a client is updated or
pushed, it only augments the configuration (currently, it never "nukes and
paves").  New clients, with additional configuration not yet 

Failed: apache/geode#3785 (dummy-branch - 1b8ef66)

[Travis CI]

Build Update for apache/geode
-

Build: #3785
Status: Failed

Duration: 22 minutes and 45 seconds
Commit: 1b8ef66 (dummy-branch)
Author: Jianxia Chen
Message: test asf github

View the changeset: https://github.com/apache/geode/commit/1b8ef66d2a34

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/272709772?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

On Wed, Sep 6, 2017 at 4:37 PM Mark Hanson  wrote:

>  C# a very new
> language has added the same -1 behavior, so obviously it does not cause
> major problems.


Can you cite references here?


The major problem comes when dealing with units. When we change the time
based methods to take units to remove ambiguity -1 is no longer a trivial
solution. The simplest explanation for that is -1s != -1ms, so you can't
simply check for -1 sentinel values. You could say that all values less
than 0s are infinite but why make things like this in modern times. We have
better ways to express meaningful values.

-Jake

Re: [Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

[Mark Hanson]

For me there is only one real challenge, not an objection as I like builder
and fluent models as well, but there is an added challenge of debugging. it
can effectively combine 5 lines into one, which means it is *slightly* more
annoying to debug, and the fact that return values go away, but for a
builder object, that shouldn't be an issue.

I think moving the C++ API there in the short term is a point for
discussion, but I like the direction.

On Wed, Sep 6, 2017 at 1:56 PM, Ernest Burghardt 
wrote:

> I really like the Fluent pattern as it is done in C# and Java...
>
> I'm not sure the juice is worth the squeeze in an existing c++ library.
>
> I do agree we should normalize our factory/builder patterns.
>
> On Wed, Sep 6, 2017 at 12:28 PM, Jacob Barrett 
> wrote:
>
> > Mark,
> >
> > I believe the real issue is that we use multiple patterns and should be
> > converging on one pattern. We have examples of both Factory and Builder
> > models and both with and without Fluent pattern.
> >
> > If the Java API is tending towards Builder model with Fluent pattern
> then I
> > am for that as long as this common practice in the C++ world. In my
> > searching I don't see any strong tendency towards any one model or
> pattern
> > in the C++ world. The only real trick to the Fluent pattern in C++ is
> what
> > is the type of the return value? Is it &, *, or some smart pointer? I
> would
> > expect it be a ref. My only issue with this is that if the original
> factory
> > variable is a pointer then the operator changes, for example:
> > prtToCachFactory->setSomething("arrow").setSomethingElse("dot");
> >
> > It also needs to be VERY clear in the docs is the builder could ever
> return
> > something other than a reference to the original instance of the
> builder. I
> > have seen models where it is possible so you have to do things like to
> > guard against the return changing:
> > auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> > if (somethingMore) {
> >   cacheFactory = cacheFactory.setSomethingMore();
> > }
> > auto cache = cacheFactory.create();
> >
> > If you have to do that then it because less desirable to have the fluent
> > pattern because it is prone to error and less readable. We should
> guarantee
> > something like this will work:
> > auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> > if (somethingMore) {
> >   cacheFactory.setSomethingMore();
> > }
> > auto cache = cacheFactory.create();
> >
> > -Jake
> >
> >
> >
> >
> > On Wed, Sep 6, 2017 at 10:38 AM Darrel Schneider 
> > wrote:
> >
> > > In the geode java apis you would create a CacheFactory (or
> > > ClientCacheFactory), configure it fluently, and then call create at the
> > > end. So even though we call them factories in the geode java apis, they
> > use
> > > the Builder pattern and also support the fluent model in that you could
> > do
> > > this:
> > >   ClientCache cache = new  ClientCacheFactory().set("propName",
> > > "propValue").addPoolLocator("addr", 10678).create();
> > >
> > >  Also in java the DistributedSystem is hidden under the Cache. So you
> add
> > > config to your CacheFactory and when you create it, it will also
> connect
> > > the DistributedSystem. It used to be that in java you had to connect
> the
> > > DistributedSystem first and then the Cache. Since the DistributedSystem
> > is
> > > never used apart for a Cache I think this simplification was helpful to
> > > users.
> > >
> > > On Wed, Sep 6, 2017 at 10:13 AM, Mark Hanson 
> wrote:
> > >
> > > > Problem:
> > > >
> > > > To fluent and builder model or not to fluent and builder model In
> > the
> > > > native client
> > > >
> > > > we use the factory model of generating objects, we are wondering if a
> > > move
> > > > to the fluent model
> > > >
> > > > and the builder pattern would be better.
> > > >
> > > >
> > > > Background:
> > > >
> > > > In designing the various types of allocators for our objects, we have
> > > > considered
> > > >
> > > > whether or not use the builder and fluent patterns instead of the
> > Factory
> > > > pattern.
> > > >
> > > > The current code base is written following the factory pattern, but
> it
> > > > seems that
> > > >
> > > > the Builder pattern is becoming more popular. Further, people are
> also
> > > > using the
> > > >
> > > > fluent model as well.
> > > >
> > > > Discussion:
> > > >
> > > > The argument for the Builder pattern is that it allows greater
> > > > specification before the actual
> > > >
> > > > creation of the object. For example, Factory often focuses on the
> > > > attributes
> > > >
> > > > after the creation of the object. The Builder pattern allows one to
> set
> > > the
> > > >
> > > > attributes before the creation of the object, allowing a more
> specific
> > > > object
> > > >
> > > > to be generated. Currently code is written to the Factory pattern.
> > > >
> > > > Consider 

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

To be sure, if we find particular API bad/unclear/misnamed, a change is
always easy to justify.

On Wed, Sep 6, 2017 at 4:37 PM, Mark Hanson  wrote:

> To play devil's advocate,
>
> I have dealt with -1 for years in network development among other places.
> In just about every case, it has not been a problem. The only cases I can
> think of where it has gotten weird in recent memory are badly designed API
> such as the retry attempts because the API should have really been called
> attempts... Why is this a big enough problem to invest in? C# a very new
> language has added the same -1 behavior, so obviously it does not cause
> major problems. While I support separate API for clarity, what justifies
> the expense(time and testing)?? One might not call this a technical debt
> issue, considering all the other users of this approach.
>
> Again just playing devil's advocate here.
>
> Thanks,
> Mark
>
>
>
> On Wed, Sep 6, 2017 at 3:26 PM, Anthony Baker  wrote:
>
>> Perfect!
>>
>> > On Sep 6, 2017, at 3:13 PM, Jacob Barrett  wrote:
>> >
>> > And this is where the details are more useful than the abstract. I
>> think if
>> > we focus more on specific API methods and answer the questions for each
>> or
>> > those we will spend less time going back and forth on the use of
>> sentinel
>> > values.
>> >
>> > X.doSomethingUntil(10s); <- do something, give up after at least 10s
>> > X.doSomething(); <- do something, never give up
>> >
>> > Very clear and no sentinel values.
>> >
>> > Y.doSomethingWithLimit(10); <- do it 10 times
>> > Y.doSomething(); <- do it forever
>> >
>> > Very clear and no sentinel values.
>> >
>> > -Jake
>> >
>> >
>> > On Wed, Sep 6, 2017 at 2:50 PM Anthony Baker  wrote:
>> >
>> >>
>> >>> On Sep 6, 2017, at 2:29 PM, Jacob Barrett 
>> wrote:
>> >>>
>> >>> Ok, I did not find that previous message at all clarifying but I did
>> find
>> >>> this one clarifying.
>> >>
>> >> I think the objective is to provide a clear and understandable API.
>> >>
>> >> IMO, a ReallyBigNumber is not easily readable.  Is the user’s intent to
>> >> wait XXX time or forever?  Why not provide a constant value / enum to
>> >> signal intent?
>> >>
>> >> There are so many usages of “0 as infinity” throughout the internets
>> that
>> >> I personally don’t find it all that confusing.
>> >>
>> >> Anthony
>> >>
>> >>
>>
>>
>

Re: Missing Gitbox activation email

[Xiaojian Zhou]

I did not get any email. But it seems all set for me.

​

On Wed, Sep 6, 2017 at 4:33 PM, Nabarun Nag  wrote:

> *I think the email takes some time to arrive."An organisational invite will
> be sent to you via email shortly thereafter (within 30 minutes)."*
>
> On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:
>
> > If you are stuck on 3rd step (MFA Status) make you have added your github
> > username on id.apache.org *and* that you have accepted the invitation to
> > join the apache group on github.
> >
> > You should see an apache feather listed underneath your organizations on
> > github.
> >
> > -Dan
> >
> > On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett 
> wrote:
> >
> > > I’d hit up Infra tomorrow if it isn’t working by then.
> > >
> > > > On Sep 6, 2017, at 4:06 PM, Jared Stewart 
> wrote:
> > > >
> > > > I’m stuck on the same step.  I tried clearing out my GitHub username
> at
> > > id.apache.org  and then re-adding it in the
> hopes
> > > of re-triggering the email, but it still hasn’t arrived.
> > > >
> > > > - Jared
> > > >> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
> > > >>
> > > >> Hey there,
> > > >>
> > > >> I've gone through all the steps to activate my github user with
> > gitbox.
> > > >>
> > > >> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
> > > currently waiting for the email that I'm supposed to receive, BUT it
> has
> > > never arrived. I have checked my Spam folder and it was not in there
> > either.
> > > >>
> > > >> Does anyone know how to have to email sent *again*?
> > > >>
> > > >> --Udo
> > > >
> > >
> >
>

Re: Missing Gitbox activation email

[Nabarun Nag]

*I think the email takes some time to arrive."An organisational invite will
be sent to you via email shortly thereafter (within 30 minutes)."*

On Wed, Sep 6, 2017 at 4:21 PM Dan Smith  wrote:

> If you are stuck on 3rd step (MFA Status) make you have added your github
> username on id.apache.org *and* that you have accepted the invitation to
> join the apache group on github.
>
> You should see an apache feather listed underneath your organizations on
> github.
>
> -Dan
>
> On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett  wrote:
>
> > I’d hit up Infra tomorrow if it isn’t working by then.
> >
> > > On Sep 6, 2017, at 4:06 PM, Jared Stewart  wrote:
> > >
> > > I’m stuck on the same step.  I tried clearing out my GitHub username at
> > id.apache.org  and then re-adding it in the hopes
> > of re-triggering the email, but it still hasn’t arrived.
> > >
> > > - Jared
> > >> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
> > >>
> > >> Hey there,
> > >>
> > >> I've gone through all the steps to activate my github user with
> gitbox.
> > >>
> > >> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
> > currently waiting for the email that I'm supposed to receive, BUT it has
> > never arrived. I have checked my Spam folder and it was not in there
> either.
> > >>
> > >> Does anyone know how to have to email sent *again*?
> > >>
> > >> --Udo
> > >
> >
>

Re: Missing Gitbox activation email

[Dan Smith]

If you are stuck on 3rd step (MFA Status) make you have added your github
username on id.apache.org *and* that you have accepted the invitation to
join the apache group on github.

You should see an apache feather listed underneath your organizations on
github.

-Dan

On Wed, Sep 6, 2017 at 4:08 PM, Jacob Barrett  wrote:

> I’d hit up Infra tomorrow if it isn’t working by then.
>
> > On Sep 6, 2017, at 4:06 PM, Jared Stewart  wrote:
> >
> > I’m stuck on the same step.  I tried clearing out my GitHub username at
> id.apache.org  and then re-adding it in the hopes
> of re-triggering the email, but it still hasn’t arrived.
> >
> > - Jared
> >> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
> >>
> >> Hey there,
> >>
> >> I've gone through all the steps to activate my github user with gitbox.
> >>
> >> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm
> currently waiting for the email that I'm supposed to receive, BUT it has
> never arrived. I have checked my Spam folder and it was not in there either.
> >>
> >> Does anyone know how to have to email sent *again*?
> >>
> >> --Udo
> >
>

Re: Missing Gitbox activation email

[Jacob Barrett]

I’d hit up Infra tomorrow if it isn’t working by then.

> On Sep 6, 2017, at 4:06 PM, Jared Stewart  wrote:
> 
> I’m stuck on the same step.  I tried clearing out my GitHub username at 
> id.apache.org  and then re-adding it in the hopes of 
> re-triggering the email, but it still hasn’t arrived.
> 
> - Jared
>> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
>> 
>> Hey there,
>> 
>> I've gone through all the steps to activate my github user with gitbox.
>> 
>> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm currently 
>> waiting for the email that I'm supposed to receive, BUT it has never 
>> arrived. I have checked my Spam folder and it was not in there either.
>> 
>> Does anyone know how to have to email sent *again*?
>> 
>> --Udo
> 

[CANCEL][VOTE] Apache Geode release - v1.2.1 RC1

[Anthony Baker]

Cancelling the vote on this release candidate due to concerns about breaking 
backwards compatibility in a patch release.

Anthony

> On Aug 25, 2017, at 3:20 PM, Anthony Baker  wrote:
> 
> This is the first release candidate for Apache Geode, version 1.2.1.
> Thanks to all the community members for their contributions to this
> release!
> 
> *** Please download, test and vote by Wednesday, August 25, 0800 hrs
> US Pacific. ***
> 
> It fixes the following issues:
>  
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12341124
> 
> Note that we are voting upon the source tags:  rel/v1.2.1.RC1
>  
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=commit;h=1bb1cae34814bdca298e476f8b88d19e4bc0dd51
>  
> https://git-wip-us.apache.org/repos/asf?p=geode-examples.git;a=commit;h=5d034de588a43cdefb8fbb3a6259579785768340
> 
> Commit ID:
>  1bb1cae34814bdca298e476f8b88d19e4bc0dd51 (geode)
>  5d034de588a43cdefb8fbb3a6259579785768340 (geode-examples)
> 
> Source and binary files:
>  https://dist.apache.org/repos/dist/dev/geode/1.2.1.RC1
> 
> Maven staging repo:
>  https://repository.apache.org/content/repositories/orgapachegeode-1021
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
>  
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=blob_plain;f=KEYS;hb=HEAD
> 
> pub  4096R/C72CFB64 2015-10-01
>  Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
> 
> Anthony

Re: Missing Gitbox activation email

[Jared Stewart]

I’m stuck on the same step.  I tried clearing out my GitHub username at 
id.apache.org  and then re-adding it in the hopes of 
re-triggering the email, but it still hasn’t arrived.

- Jared
> On Sep 6, 2017, at 4:04 PM, Udo Kohlmeyer  wrote:
> 
> Hey there,
> 
> I've gone through all the steps to activate my github user with gitbox.
> 
> Looking at gitbox.apache.org, I was completed step 2 of 3. I'm currently 
> waiting for the email that I'm supposed to receive, BUT it has never arrived. 
> I have checked my Spam folder and it was not in there either.
> 
> Does anyone know how to have to email sent *again*?
> 
> --Udo

Missing Gitbox activation email

[Udo Kohlmeyer]

Hey there,

I've gone through all the steps to activate my github user with gitbox.

Looking at gitbox.apache.org, I was completed step 2 of 3. I'm currently 
waiting for the email that I'm supposed to receive, BUT it has never 
arrived. I have checked my Spam folder and it was not in there either.


Does anyone know how to have to email sent *again*?

--Udo

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #670 was successful.
---
Scheduled
2029 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Anthony Baker]

Perfect!

> On Sep 6, 2017, at 3:13 PM, Jacob Barrett  wrote:
> 
> And this is where the details are more useful than the abstract. I think if
> we focus more on specific API methods and answer the questions for each or
> those we will spend less time going back and forth on the use of sentinel
> values.
> 
> X.doSomethingUntil(10s); <- do something, give up after at least 10s
> X.doSomething(); <- do something, never give up
> 
> Very clear and no sentinel values.
> 
> Y.doSomethingWithLimit(10); <- do it 10 times
> Y.doSomething(); <- do it forever
> 
> Very clear and no sentinel values.
> 
> -Jake
> 
> 
> On Wed, Sep 6, 2017 at 2:50 PM Anthony Baker  wrote:
> 
>> 
>>> On Sep 6, 2017, at 2:29 PM, Jacob Barrett  wrote:
>>> 
>>> Ok, I did not find that previous message at all clarifying but I did find
>>> this one clarifying.
>> 
>> I think the objective is to provide a clear and understandable API.
>> 
>> IMO, a ReallyBigNumber is not easily readable.  Is the user’s intent to
>> wait XXX time or forever?  Why not provide a constant value / enum to
>> signal intent?
>> 
>> There are so many usages of “0 as infinity” throughout the internets that
>> I personally don’t find it all that confusing.
>> 
>> Anthony
>> 
>> 

Re: [Discuss] What type should C++ object creation functions return?

[David Kimura]

Sure.  If we made these changes RegionFactory::create would change to:

Region RegionFactory::create(const char*);

Since Region has a deleted copy constructor, we would have to implement a
move constructor and a move assignment operator.

Region(const Region&& other);
Region& operator=(const Region&& other);

Thus I think a call like following should not invoke copy constructor even
if compiler doesn't support copy-elision:

auto region = RegionFactory().create(...);

Thanks,
David

On Wed, Sep 6, 2017 at 2:31 PM, Jacob Barrett  wrote:

> Great, can you provide some examples of what some of the APIs would look
> like if we made these changes?
>
> On Wed, Sep 6, 2017 at 2:29 PM David Kimura  wrote:
>
> > Good point.  In those cases, the copy constructor should have been
> deleted
> > to prevent the copy build up.  For objects when copy constructor is
> deleted
> > *and* compiler doesn't perform RVO, I think we'd likely need to add a
> move
> > constructor.
> >
> > Thanks,
> > David
> >
> > On Wed, Sep 6, 2017 at 2:01 PM, Jacob Barrett 
> wrote:
> >
> > > Bare object sounds nice to me. The caller has the option at that point
> to
> > > copy to heap into smart pointer or keep on stack.
> > >
> > > Mixed with the fluent/builder conversation in another thread this would
> > > simplify to:
> > >
> > > auto cache = CacheFactory().setSomething().create();
> > >
> > > Which I think looks pretty darn readable.
> > >
> > > If they want to stash that cache in the heap and pass it around to
> other
> > > callers then:
> > >
> > > auto cache = std::shared_ptr(CacheFactory().setSomething().
> > > create());
> > >
> > > Which isn't as nice to read but gets the job done.
> > >
> > > I think with many of these calls they are not frequent calls to if any
> of
> > > them resulted in copies it wouldn't be the end of the world. What we
> need
> > > to make sure doesn't happen though is that a copy builds up more of the
> > > underlying resources. I would not want a copy of Cache to returned by
> > > CacheFactory to result in another set of connections to the servers.
> > >
> > > Have you looked closely at what copy would do in the case of each of
> the
> > > objects we are looking at on the public API? Assuming no optimization
> > and a
> > > copy is performed then are there resources be re-allocated that we
> don't
> > > want re-alloacted. If that is the case then we need to consider
> > > alternatives like ref, ptr or pimpl.
> > >
> > > -Jake
> > >
> > >
> > > On Wed, Sep 6, 2017 at 12:53 PM Ernest Burghardt <
> eburgha...@pivotal.io>
> > > wrote:
> > >
> > > > std::unique_ptr looks like a good option.
> > > >
> > > > then again if the typical usage is like so:
> > > >
> > > > cachePtr = CacheFactory::createCacheFactory(pp)->create();
> > > >
> > > > it seems simple enough to just return the bare object
> > > >
> > > > EB
> > > >
> > > > On Wed, Sep 6, 2017 at 1:27 PM, David Kimura 
> > wrote:
> > > >
> > > > > What type should C++ object creation functions return (e.g.
> pointer,
> > > > smart
> > > > > pointer, reference, etc.)?  Several of our C++ API's return shared
> > > > > pointers.  For example in the following function signature [1]:
> > > > >
> > > > > std::shared_ptr CacheFactory::
> > > createCacheFactory(...);
> > > > >
> > > > > Here the only case I can see for shared pointer is to indicate
> > > ownership
> > > > of
> > > > > CacheFactory.  Ideally this should probably be std::unique_ptr
> > because
> > > > > callee shouldn't share ownership.  However, I don't see the point
> of
> > > > using
> > > > > a pointer at all..  I suggest we return the bare object, like the
> > > > following
> > > > > signature:
> > > > >
> > > > > CacheFactory CacheFactory::createCacheFactory(...);
> > > > >
> > > > > In C++03, this would have been a performance hit because we'd end
> up
> > > with
> > > > > an added call to the copy constructor.  In C++11, std::unique_ptr
> > gives
> > > > > std::move for free and thus avoids copy-constructor call. However,
> > most
> > > > > modern C++11 compilers already perform copy-elision here.  In fact,
> > > C++17
> > > > > standard dictates that compilers must perform RVO here.  Therefore
> it
> > > > > doesn't seem to me that std::shared_ptr or std::unique_ptr buys us
> > much
> > > > in
> > > > > this situation.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Thanks,
> > > > > David
> > > > >
> > > > >
> > > > > [1] https://github.com/apache/geode-native/blob/develop/
> > > > > cppcache/include/geode/CacheFactory.hpp#L54
> > > > >
> > > >
> > >
> >
>

Build failed in Jenkins: Geode-nightly-flaky #114

[Apache Jenkins Server]

See 

--
Started by upstream project "Geode-nightly" build number 946
originally caused by:
 Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H14 (couchdbtest ubuntu xenial) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/geode.git # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/geode.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/geode.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:817)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1084)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1115)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:560)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:485)
at hudson.model.Run.execute(Run.java:1735)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:405)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/geode.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: repository 'https://git-wip-us.apache.org/repos/asf/geode.git/' 
not found

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1924)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1643)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:71)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:352)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at ..remote call to H14(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:830)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor866.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy106.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:815)
... 11 more
ERROR: Error fetching remote repo 'origin'
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/geode.git # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/geode.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/geode.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:817)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1084)
  

Build failed in Jenkins: Geode-nightly #946

[Apache Jenkins Server]

See 


Changes:

[gosullivan] GEODE-3385: Change GetAllRequest to return list of errors.

[bschuchardt] GEODE-3514: Clean up locator and protobuf related code

--
[...truncated 413.11 KB...]
---
* What went wrong:
Execution failed for task ':geode-assembly:integrationTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

4: Task failed with an exception.
---
* What went wrong:
Execution failed for task ':geode-core:distributedTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

5: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':extensions/geode-modules-assembly:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

6: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-common:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

7: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-core:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

8: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-cq:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

9: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-json:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

10: Task failed with an exception.
---

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Anthony Baker]

> On Sep 6, 2017, at 2:29 PM, Jacob Barrett  wrote:
> 
> Ok, I did not find that previous message at all clarifying but I did find
> this one clarifying.

I think the objective is to provide a clear and understandable API.  

IMO, a ReallyBigNumber is not easily readable.  Is the user’s intent to wait 
XXX time or forever?  Why not provide a constant value / enum to signal intent?

There are so many usages of “0 as infinity” throughout the internets that I 
personally don’t find it all that confusing.

Anthony

Re: [Discuss] What type should C++ object creation functions return?

[Jacob Barrett]

Great, can you provide some examples of what some of the APIs would look
like if we made these changes?

On Wed, Sep 6, 2017 at 2:29 PM David Kimura  wrote:

> Good point.  In those cases, the copy constructor should have been deleted
> to prevent the copy build up.  For objects when copy constructor is deleted
> *and* compiler doesn't perform RVO, I think we'd likely need to add a move
> constructor.
>
> Thanks,
> David
>
> On Wed, Sep 6, 2017 at 2:01 PM, Jacob Barrett  wrote:
>
> > Bare object sounds nice to me. The caller has the option at that point to
> > copy to heap into smart pointer or keep on stack.
> >
> > Mixed with the fluent/builder conversation in another thread this would
> > simplify to:
> >
> > auto cache = CacheFactory().setSomething().create();
> >
> > Which I think looks pretty darn readable.
> >
> > If they want to stash that cache in the heap and pass it around to other
> > callers then:
> >
> > auto cache = std::shared_ptr(CacheFactory().setSomething().
> > create());
> >
> > Which isn't as nice to read but gets the job done.
> >
> > I think with many of these calls they are not frequent calls to if any of
> > them resulted in copies it wouldn't be the end of the world. What we need
> > to make sure doesn't happen though is that a copy builds up more of the
> > underlying resources. I would not want a copy of Cache to returned by
> > CacheFactory to result in another set of connections to the servers.
> >
> > Have you looked closely at what copy would do in the case of each of the
> > objects we are looking at on the public API? Assuming no optimization
> and a
> > copy is performed then are there resources be re-allocated that we don't
> > want re-alloacted. If that is the case then we need to consider
> > alternatives like ref, ptr or pimpl.
> >
> > -Jake
> >
> >
> > On Wed, Sep 6, 2017 at 12:53 PM Ernest Burghardt 
> > wrote:
> >
> > > std::unique_ptr looks like a good option.
> > >
> > > then again if the typical usage is like so:
> > >
> > > cachePtr = CacheFactory::createCacheFactory(pp)->create();
> > >
> > > it seems simple enough to just return the bare object
> > >
> > > EB
> > >
> > > On Wed, Sep 6, 2017 at 1:27 PM, David Kimura 
> wrote:
> > >
> > > > What type should C++ object creation functions return (e.g. pointer,
> > > smart
> > > > pointer, reference, etc.)?  Several of our C++ API's return shared
> > > > pointers.  For example in the following function signature [1]:
> > > >
> > > > std::shared_ptr CacheFactory::
> > createCacheFactory(...);
> > > >
> > > > Here the only case I can see for shared pointer is to indicate
> > ownership
> > > of
> > > > CacheFactory.  Ideally this should probably be std::unique_ptr
> because
> > > > callee shouldn't share ownership.  However, I don't see the point of
> > > using
> > > > a pointer at all..  I suggest we return the bare object, like the
> > > following
> > > > signature:
> > > >
> > > > CacheFactory CacheFactory::createCacheFactory(...);
> > > >
> > > > In C++03, this would have been a performance hit because we'd end up
> > with
> > > > an added call to the copy constructor.  In C++11, std::unique_ptr
> gives
> > > > std::move for free and thus avoids copy-constructor call. However,
> most
> > > > modern C++11 compilers already perform copy-elision here.  In fact,
> > C++17
> > > > standard dictates that compilers must perform RVO here.  Therefore it
> > > > doesn't seem to me that std::shared_ptr or std::unique_ptr buys us
> much
> > > in
> > > > this situation.
> > > >
> > > > Thoughts?
> > > >
> > > > Thanks,
> > > > David
> > > >
> > > >
> > > > [1] https://github.com/apache/geode-native/blob/develop/
> > > > cppcache/include/geode/CacheFactory.hpp#L54
> > > >
> > >
> >
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

Ok, I did not find that previous message at all clarifying but I did find
this one clarifying.

Yes, I believe the consensus is sentinel values like -1 and 0 should be
eliminated. The value should carry a consistent meaning based on the unit
of the value. If you think about it then there is really no special case of
0 (zero) when considered in the specified unit. It's zero iterations, zero
seconds, or zero whatever. Negative numbers tend to be meaningless and
should not be allowed. Infinity is also meaningless as there is nearly
never a time when infinity is meant literally.

0 for example, a sleep for 0s would sleep for at least zero seconds,
effectively not sleeping. A wait for 0s would be wait for at least 0
seconds before giving up, effectively give up immediately if the operation
can't be completed without additional waiting or blocking. An iteration of
0 times would iterate over some operation zero times, effectively not at
all.

N for example, a sleep for Ns would sleep for at least N seconds. A wait
for Ns would wait for at least N seconds for the operation to complete
without additional waiting or blocking. An iteration of N times would
iterate over some operation N times.

Forever/All/Infinity, a sleep for seconds::max seconds would sleep for at
least seconds::max seconds (at least 292 years), effectively forever. A
wait for seconds::max seconds would wait for at least seconds::max seconds
for the operation to complete without additional waiting or blocking,
effectively forever. An iteration of
std::numeric_limits::max() times is by definition the max any
container could store for read or writing of the results of the operation,
effectively infinity. Or if just want to execute infinitely then
considering 292 years was our duration infinite then
std::numeric_limits::max() works out to 2 operations per
nanosecond, and since current CPU instructions are still measured in the
microseconds we are safe for a while, not to mention that you will likely
reboot in 292 years.

-Jake


On Wed, Sep 6, 2017 at 2:00 PM Mark Hanson  wrote:

> Hi,
>
> To clarify, the original email was to discuss the concept of overloading a
> number to mean infinity.
> The example cited was one where we were using -1 to mean all. While the
> example case was decided (remove the function), the basic question was not
> answered. I attempted in the previous email to summarize the general
> impression I was getting from people, which was that -1 to indicate
> infinity was undesirable.
>
> This is a ubiquitous construct, used in socket api for example, so I think
> it is good to have a clear answers, but there have not been any. Hence the
> clarification.
>
> Thanks,
> Mark
>
>
>
> > On Sep 6, 2017, at 11:11 AM, Jacob Barrett  wrote:
> >
> > I really am not following what you are trying to say.
> >
> > I think too many side conversations have muddied this original thread.
> The
> > question was about tries, lets keep focused on retries and not transition
> > the conversation to timeouts.
> >
> > As it relates to retries the consensus was get rid of it because it is
> more
> > appropriately handled by the current timeout APIs.
> >
> > If we need a thread about timeouts and their values then let's start a
> new
> > thread.
> >
> > -Jake
> >
> > On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson > wrote:
> >
> >> So the basic challenge here is for specific API, do we want to focus on
> >> providing a
> >> wait forever approach or just use the standard MAX_UNSIGNED and
> duration.
> >> I
> >> think that variable delay is something someone would implement in their
> own
> >> API
> >> and would not be done in the public API where consistency is valuable. I
> >> could be
> >> wrong in that belief.
> >>
> >> Further, it is sounding like a move away from overloading is the desired
> >> direction.
> >> Do we have any points against it??
> >>
> >> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz 
> wrote:
> >>
> >>> We would certainly rather have the time-out set correctly, but one of
> the
> >>> things I've noticed is, sometimes there is just one query or one
> function
> >>> that takes a really long time, and because we keep retrying it with the
> >>> same timeout, it keeps timing out each retry. It would probably be much
> >>> smarter to use some sort of increasing timeout on the retries until we
> >> give
> >>> up.
> >>>
> >>> --
> >>> Mike Stolz
> >>> Principal Engineer, GemFire Product Manager
> >>> Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> >>>
> >>> On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson  > wrote:
> >>>
>  I actually don’t really have a strong opinion one way or the other. I
> >> get
>  both approaches. If we want to tailor the code to use a timeout
> instead
> >>> of
>  retry attempts I guess that is fine. It seems kind of like we are
>  perpetuating the 

Re: [Discuss] What type should C++ object creation functions return?

[David Kimura]

Good point.  In those cases, the copy constructor should have been deleted
to prevent the copy build up.  For objects when copy constructor is deleted
*and* compiler doesn't perform RVO, I think we'd likely need to add a move
constructor.

Thanks,
David

On Wed, Sep 6, 2017 at 2:01 PM, Jacob Barrett  wrote:

> Bare object sounds nice to me. The caller has the option at that point to
> copy to heap into smart pointer or keep on stack.
>
> Mixed with the fluent/builder conversation in another thread this would
> simplify to:
>
> auto cache = CacheFactory().setSomething().create();
>
> Which I think looks pretty darn readable.
>
> If they want to stash that cache in the heap and pass it around to other
> callers then:
>
> auto cache = std::shared_ptr(CacheFactory().setSomething().
> create());
>
> Which isn't as nice to read but gets the job done.
>
> I think with many of these calls they are not frequent calls to if any of
> them resulted in copies it wouldn't be the end of the world. What we need
> to make sure doesn't happen though is that a copy builds up more of the
> underlying resources. I would not want a copy of Cache to returned by
> CacheFactory to result in another set of connections to the servers.
>
> Have you looked closely at what copy would do in the case of each of the
> objects we are looking at on the public API? Assuming no optimization and a
> copy is performed then are there resources be re-allocated that we don't
> want re-alloacted. If that is the case then we need to consider
> alternatives like ref, ptr or pimpl.
>
> -Jake
>
>
> On Wed, Sep 6, 2017 at 12:53 PM Ernest Burghardt 
> wrote:
>
> > std::unique_ptr looks like a good option.
> >
> > then again if the typical usage is like so:
> >
> > cachePtr = CacheFactory::createCacheFactory(pp)->create();
> >
> > it seems simple enough to just return the bare object
> >
> > EB
> >
> > On Wed, Sep 6, 2017 at 1:27 PM, David Kimura  wrote:
> >
> > > What type should C++ object creation functions return (e.g. pointer,
> > smart
> > > pointer, reference, etc.)?  Several of our C++ API's return shared
> > > pointers.  For example in the following function signature [1]:
> > >
> > > std::shared_ptr CacheFactory::
> createCacheFactory(...);
> > >
> > > Here the only case I can see for shared pointer is to indicate
> ownership
> > of
> > > CacheFactory.  Ideally this should probably be std::unique_ptr because
> > > callee shouldn't share ownership.  However, I don't see the point of
> > using
> > > a pointer at all..  I suggest we return the bare object, like the
> > following
> > > signature:
> > >
> > > CacheFactory CacheFactory::createCacheFactory(...);
> > >
> > > In C++03, this would have been a performance hit because we'd end up
> with
> > > an added call to the copy constructor.  In C++11, std::unique_ptr gives
> > > std::move for free and thus avoids copy-constructor call. However, most
> > > modern C++11 compilers already perform copy-elision here.  In fact,
> C++17
> > > standard dictates that compilers must perform RVO here.  Therefore it
> > > doesn't seem to me that std::shared_ptr or std::unique_ptr buys us much
> > in
> > > this situation.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > David
> > >
> > >
> > > [1] https://github.com/apache/geode-native/blob/develop/
> > > cppcache/include/geode/CacheFactory.hpp#L54
> > >
> >
>

Re: [Discuss] What type should C++ object creation functions return?

[Jacob Barrett]

Bare object sounds nice to me. The caller has the option at that point to
copy to heap into smart pointer or keep on stack.

Mixed with the fluent/builder conversation in another thread this would
simplify to:

auto cache = CacheFactory().setSomething().create();

Which I think looks pretty darn readable.

If they want to stash that cache in the heap and pass it around to other
callers then:

auto cache = std::shared_ptr(CacheFactory().setSomething().create());

Which isn't as nice to read but gets the job done.

I think with many of these calls they are not frequent calls to if any of
them resulted in copies it wouldn't be the end of the world. What we need
to make sure doesn't happen though is that a copy builds up more of the
underlying resources. I would not want a copy of Cache to returned by
CacheFactory to result in another set of connections to the servers.

Have you looked closely at what copy would do in the case of each of the
objects we are looking at on the public API? Assuming no optimization and a
copy is performed then are there resources be re-allocated that we don't
want re-alloacted. If that is the case then we need to consider
alternatives like ref, ptr or pimpl.

-Jake


On Wed, Sep 6, 2017 at 12:53 PM Ernest Burghardt 
wrote:

> std::unique_ptr looks like a good option.
>
> then again if the typical usage is like so:
>
> cachePtr = CacheFactory::createCacheFactory(pp)->create();
>
> it seems simple enough to just return the bare object
>
> EB
>
> On Wed, Sep 6, 2017 at 1:27 PM, David Kimura  wrote:
>
> > What type should C++ object creation functions return (e.g. pointer,
> smart
> > pointer, reference, etc.)?  Several of our C++ API's return shared
> > pointers.  For example in the following function signature [1]:
> >
> > std::shared_ptr CacheFactory::createCacheFactory(...);
> >
> > Here the only case I can see for shared pointer is to indicate ownership
> of
> > CacheFactory.  Ideally this should probably be std::unique_ptr because
> > callee shouldn't share ownership.  However, I don't see the point of
> using
> > a pointer at all..  I suggest we return the bare object, like the
> following
> > signature:
> >
> > CacheFactory CacheFactory::createCacheFactory(...);
> >
> > In C++03, this would have been a performance hit because we'd end up with
> > an added call to the copy constructor.  In C++11, std::unique_ptr gives
> > std::move for free and thus avoids copy-constructor call. However, most
> > modern C++11 compilers already perform copy-elision here.  In fact, C++17
> > standard dictates that compilers must perform RVO here.  Therefore it
> > doesn't seem to me that std::shared_ptr or std::unique_ptr buys us much
> in
> > this situation.
> >
> > Thoughts?
> >
> > Thanks,
> > David
> >
> >
> > [1] https://github.com/apache/geode-native/blob/develop/
> > cppcache/include/geode/CacheFactory.hpp#L54
> >
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

Hi,

To clarify, the original email was to discuss the concept of overloading a 
number to mean infinity. 
The example cited was one where we were using -1 to mean all. While the example 
case was decided (remove the function), the basic question was not answered. I 
attempted in the previous email to summarize the general impression I was 
getting from people, which was that -1 to indicate infinity was undesirable.

This is a ubiquitous construct, used in socket api for example, so I think it 
is good to have a clear answers, but there have not been any. Hence the 
clarification.

Thanks,
Mark



> On Sep 6, 2017, at 11:11 AM, Jacob Barrett  wrote:
> 
> I really am not following what you are trying to say.
> 
> I think too many side conversations have muddied this original thread. The
> question was about tries, lets keep focused on retries and not transition
> the conversation to timeouts.
> 
> As it relates to retries the consensus was get rid of it because it is more
> appropriately handled by the current timeout APIs.
> 
> If we need a thread about timeouts and their values then let's start a new
> thread.
> 
> -Jake
> 
> On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson  > wrote:
> 
>> So the basic challenge here is for specific API, do we want to focus on
>> providing a
>> wait forever approach or just use the standard MAX_UNSIGNED and duration.
>> I
>> think that variable delay is something someone would implement in their own
>> API
>> and would not be done in the public API where consistency is valuable. I
>> could be
>> wrong in that belief.
>> 
>> Further, it is sounding like a move away from overloading is the desired
>> direction.
>> Do we have any points against it??
>> 
>> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz  wrote:
>> 
>>> We would certainly rather have the time-out set correctly, but one of the
>>> things I've noticed is, sometimes there is just one query or one function
>>> that takes a really long time, and because we keep retrying it with the
>>> same timeout, it keeps timing out each retry. It would probably be much
>>> smarter to use some sort of increasing timeout on the retries until we
>> give
>>> up.
>>> 
>>> --
>>> Mike Stolz
>>> Principal Engineer, GemFire Product Manager
>>> Mobile: +1-631-835-4771 <(631)%20835-4771>
>>> 
>>> On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson >> > wrote:
>>> 
 I actually don’t really have a strong opinion one way or the other. I
>> get
 both approaches. If we want to tailor the code to use a timeout instead
>>> of
 retry attempts I guess that is fine. It seems kind of like we are
 perpetuating the same API problem, that the LCD approach alleviates,
>> but
>>> ok.
 
 It is more complicated to code because now you need to push everything
 through poll or select. Such as the connect. Not that that is a bad
>>> thing,
 because it is not. It is just more complicated.
 
 Thanks,
 Mark
 
 http://developerweb.net/viewtopic.php?id=3196 
  <
>> http://developerweb.net/ 
 viewtopic.php?id=3196>
> On Aug 31, 2017, at 3:47 PM, Jacob Barrett  >
>>> wrote:
> 
> None of the time spent performing the request is deterministic that’s
 why there are timeouts. I don’t follow your rational for claiming it
 complicated to code.
> 
>> On Aug 31, 2017, at 3:27 PM, Mark Hanson > >
>> wrote:
>> 
>> The only problem with that is the time to connect to another server
>> is
 non-deterministic. So,  the code one would have to write to enable this
 would involve a select and a bit of not fun code, but in general could
>> be
 not very useful as an API.
>> 
>> I would say the lowest common denominator approach or the server
>> based
 approach is better.
>> 
>> Just two cents.
>> 
>> Thanks,
>> Mark
>>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett >> >
 wrote:
>>> 
>>> I believe what Bruce was saying is that the behavior should be
>>> covered
 by
>>> timeouts not iteration attempts. If the client is able to
>>> successfully
 send
>>> the command to a server but a failure occurs waiting for a reply we
 would
>>> not retry. If the client is unable to send the request to a sever
 because
>>> the connection closes then we would try the next server, and the
>>> next,
 up
>>> to the timeout value.
>>> 
 On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson >
 wrote:
 
 I can also see why the user doing the retries themselves has
>> value.
 As a

Re: [Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

[Ernest Burghardt]

I really like the Fluent pattern as it is done in C# and Java...

I'm not sure the juice is worth the squeeze in an existing c++ library.

I do agree we should normalize our factory/builder patterns.

On Wed, Sep 6, 2017 at 12:28 PM, Jacob Barrett  wrote:

> Mark,
>
> I believe the real issue is that we use multiple patterns and should be
> converging on one pattern. We have examples of both Factory and Builder
> models and both with and without Fluent pattern.
>
> If the Java API is tending towards Builder model with Fluent pattern then I
> am for that as long as this common practice in the C++ world. In my
> searching I don't see any strong tendency towards any one model or pattern
> in the C++ world. The only real trick to the Fluent pattern in C++ is what
> is the type of the return value? Is it &, *, or some smart pointer? I would
> expect it be a ref. My only issue with this is that if the original factory
> variable is a pointer then the operator changes, for example:
> prtToCachFactory->setSomething("arrow").setSomethingElse("dot");
>
> It also needs to be VERY clear in the docs is the builder could ever return
> something other than a reference to the original instance of the builder. I
> have seen models where it is possible so you have to do things like to
> guard against the return changing:
> auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> if (somethingMore) {
>   cacheFactory = cacheFactory.setSomethingMore();
> }
> auto cache = cacheFactory.create();
>
> If you have to do that then it because less desirable to have the fluent
> pattern because it is prone to error and less readable. We should guarantee
> something like this will work:
> auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> if (somethingMore) {
>   cacheFactory.setSomethingMore();
> }
> auto cache = cacheFactory.create();
>
> -Jake
>
>
>
>
> On Wed, Sep 6, 2017 at 10:38 AM Darrel Schneider 
> wrote:
>
> > In the geode java apis you would create a CacheFactory (or
> > ClientCacheFactory), configure it fluently, and then call create at the
> > end. So even though we call them factories in the geode java apis, they
> use
> > the Builder pattern and also support the fluent model in that you could
> do
> > this:
> >   ClientCache cache = new  ClientCacheFactory().set("propName",
> > "propValue").addPoolLocator("addr", 10678).create();
> >
> >  Also in java the DistributedSystem is hidden under the Cache. So you add
> > config to your CacheFactory and when you create it, it will also connect
> > the DistributedSystem. It used to be that in java you had to connect the
> > DistributedSystem first and then the Cache. Since the DistributedSystem
> is
> > never used apart for a Cache I think this simplification was helpful to
> > users.
> >
> > On Wed, Sep 6, 2017 at 10:13 AM, Mark Hanson  wrote:
> >
> > > Problem:
> > >
> > > To fluent and builder model or not to fluent and builder model In
> the
> > > native client
> > >
> > > we use the factory model of generating objects, we are wondering if a
> > move
> > > to the fluent model
> > >
> > > and the builder pattern would be better.
> > >
> > >
> > > Background:
> > >
> > > In designing the various types of allocators for our objects, we have
> > > considered
> > >
> > > whether or not use the builder and fluent patterns instead of the
> Factory
> > > pattern.
> > >
> > > The current code base is written following the factory pattern, but it
> > > seems that
> > >
> > > the Builder pattern is becoming more popular. Further, people are also
> > > using the
> > >
> > > fluent model as well.
> > >
> > > Discussion:
> > >
> > > The argument for the Builder pattern is that it allows greater
> > > specification before the actual
> > >
> > > creation of the object. For example, Factory often focuses on the
> > > attributes
> > >
> > > after the creation of the object. The Builder pattern allows one to set
> > the
> > >
> > > attributes before the creation of the object, allowing a more specific
> > > object
> > >
> > > to be generated. Currently code is written to the Factory pattern.
> > >
> > > Consider the following case of connecting to a cache.
> > >
> > > Our current pattern (Factory)
> > >
> > > CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();
> > >
> > > CachePtr cache = cacheFactory->create();
> > >
> > > cache->getDistributedSystem().Credentials(“emma”, “pizza”);
> > >
> > > cache->getDistributedSystem().connect();
> > >
> > > API Used:
> > >
> > > bool DistributedSystem::Credentials(String, String)
> > >
> > > void DistributedSystem::connect()
> > >
> > > Cache CacheFactory::create()
> > >
> > > Builder pattern
> > >
> > > CacheFactory cf = new CacheFactory();
> > >
> > > cf.Locator(“192.168.0.5”, 10334);
> > >
> > > cf.Credentials(“emma”, “pizza”);
> > >
> > > Cache cache = cf.Connect();
> > >
> > > API Used:
> > >
> > > bool Locator(String, String)
> > 

Review Request 62132: GEODE-3277: Fix error path constructors of Launcher inner State classess

[Ken Howe]

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

Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

Updated tests for changes in the error constructors for ServerState and
LocatorState.

Minor spelling corrections.

This reintroduces changes that were reverted due to merge conflicts with
the previous state of the develop branch


Diffs
-

  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
83c1ab533e3dea323a8a99f7002b9464a54dfc25 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
ae64691605130c9b212a3a33bb65ae37b28af02b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StartLocatorCommand.java
 72ccfbbc83b18e8bc32759dbeabaf2f9ef4c2f45 
  
geode-core/src/test/java/org/apache/geode/distributed/LauncherIntegrationTestCase.java
 409a96dbe416a6f96c2389356b9d823d1adb793f 
  
geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherLocalIntegrationTest.java
 9fce94e89a369094a2383eb9103f2f43a8ff3013 
  
geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherRemoteIntegrationTest.java
 cc42a53772f3064b800ca1ac1ae894be6c715399 
  
geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherLocalIntegrationTest.java
 29ddaaf6692565a9afb8c528790b35798d118a31 
  
geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherRemoteIntegrationTest.java
 733a1082ae9993fbdb646712380af7dcc1cca560 
  geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java 
2bcd994d4d14888adfdf68abef5acbc068b6fea8 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 a9ce889006800523505dace6e0b4696c9911d205 


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


Testing
---

Precheckin is green


Thanks,

Ken Howe

Re: [Discuss] What type should C++ object creation functions return?

[Ernest Burghardt]

std::unique_ptr looks like a good option.

then again if the typical usage is like so:

cachePtr = CacheFactory::createCacheFactory(pp)->create();

it seems simple enough to just return the bare object

EB

On Wed, Sep 6, 2017 at 1:27 PM, David Kimura  wrote:

> What type should C++ object creation functions return (e.g. pointer, smart
> pointer, reference, etc.)?  Several of our C++ API's return shared
> pointers.  For example in the following function signature [1]:
>
> std::shared_ptr CacheFactory::createCacheFactory(...);
>
> Here the only case I can see for shared pointer is to indicate ownership of
> CacheFactory.  Ideally this should probably be std::unique_ptr because
> callee shouldn't share ownership.  However, I don't see the point of using
> a pointer at all..  I suggest we return the bare object, like the following
> signature:
>
> CacheFactory CacheFactory::createCacheFactory(...);
>
> In C++03, this would have been a performance hit because we'd end up with
> an added call to the copy constructor.  In C++11, std::unique_ptr gives
> std::move for free and thus avoids copy-constructor call. However, most
> modern C++11 compilers already perform copy-elision here.  In fact, C++17
> standard dictates that compilers must perform RVO here.  Therefore it
> doesn't seem to me that std::shared_ptr or std::unique_ptr buys us much in
> this situation.
>
> Thoughts?
>
> Thanks,
> David
>
>
> [1] https://github.com/apache/geode-native/blob/develop/
> cppcache/include/geode/CacheFactory.hpp#L54
>

Re: [Discuss] What type should C++ object creation functions return?

[Michael William Dodge]

I like just returning the object as that removes the possibility of a null 
pointer.

Sarge

> On 6 Sep, 2017, at 12:27, David Kimura  wrote:
> 
> What type should C++ object creation functions return (e.g. pointer, smart
> pointer, reference, etc.)?  Several of our C++ API's return shared
> pointers.  For example in the following function signature [1]:
> 
>std::shared_ptr CacheFactory::createCacheFactory(...);
> 
> Here the only case I can see for shared pointer is to indicate ownership of
> CacheFactory.  Ideally this should probably be std::unique_ptr because
> callee shouldn't share ownership.  However, I don't see the point of using
> a pointer at all..  I suggest we return the bare object, like the following
> signature:
> 
>CacheFactory CacheFactory::createCacheFactory(...);
> 
> In C++03, this would have been a performance hit because we'd end up with
> an added call to the copy constructor.  In C++11, std::unique_ptr gives
> std::move for free and thus avoids copy-constructor call. However, most
> modern C++11 compilers already perform copy-elision here.  In fact, C++17
> standard dictates that compilers must perform RVO here.  Therefore it
> doesn't seem to me that std::shared_ptr or std::unique_ptr buys us much in
> this situation.
> 
> Thoughts?
> 
> Thanks,
> David
> 
> 
> [1] https://github.com/apache/geode-native/blob/develop/
> cppcache/include/geode/CacheFactory.hpp#L54

Re: Review Request 62088: GEODE-3249 Validate internal client/server messages

[Brian Baynes]

Ah, I see. Makes sense.

On Sep 6, 2017 12:23 PM, "Bruce Schuchardt"  wrote:

I think we will want to remove this property in the next major release and
have the behavior it enables be how the servers always act.

On 9/6/17 10:23 AM, Brian Baynes wrote:

In this case, won't we be changing the default of this property with the
next major release?  So perhaps the choice is to follow the default=false
convention now, or with the next major release..?


On Wed, Sep 6, 2017 at 8:47 AM, Bruce Schuchardt 
wrote:

>
>
> > On Sept. 5, 2017, 5:09 p.m., Galen O'Sullivan wrote:
> > > I prefer config option names to be as unambiguous as possible. I think
> `allow` would be clearer than `disallow` because it avoids
> double-negatives. Can we use
> > > `allow-internal-messages-without-credentials` and have it default to
> `true`?
>
> In general Java properties ought to default to _false_ if they aren't
> set.  We've had other properties default to _true_ in the past and they
> were awkward.
>
>
> - Bruce
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62088/#review184608
> ---
>
>
> On Sept. 5, 2017, 10:57 a.m., Bruce Schuchardt wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/62088/
> > ---
> >
> > (Updated Sept. 5, 2017, 10:57 a.m.)
> >
> >
> > Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh
> Khamesra, and Udo Kohlmeyer.
> >
> >
> > Bugs: GEODE-3249
> > https://issues.apache.org/jira/browse/GEODE-3249
> >
> >
> > Repository: geode
> >
> >
> > Description
> > ---
> >
> > This change leaves the security hole in place but allows you to plug it
> by setting the system property
> >
> > geode.disallow-internal-messages-without-credentials=true
> >
> > Clients must be upgraded to the release containing this change if you
> set this system property to true and client/server authentication is
> enabled.  Otherwise client messages to register PDX types or Instantiators
> will be rejected by the servers.
> >
> >
> > Diffs
> > -
> >
> >   geode-core/src/main/java/org/apache/geode/internal/cache/ti
> er/sockets/ServerConnection.java b243d8ebb8f7fb698a4637c7a787ee2d7216f1f7
> >
> >
> > Diff: https://reviews.apache.org/r/62088/diff/1/
> >
> >
> > Testing
> > ---
> >
> >
> > Thanks,
> >
> > Bruce Schuchardt
> >
> >
>
>

Re: Review Request 62088: GEODE-3249 Validate internal client/server messages

[Bruce Schuchardt]

I think we will want to remove this property in the next major release 
and have the behavior it enables be how the servers always act.



On 9/6/17 10:23 AM, Brian Baynes wrote:
In this case, won't we be changing the default of this property with 
the next major release?  So perhaps the choice is to follow the 
default=false convention now, or with the next major release..?



On Wed, Sep 6, 2017 at 8:47 AM, Bruce Schuchardt 
> wrote:




> On Sept. 5, 2017, 5:09 p.m., Galen O'Sullivan wrote:
> > I prefer config option names to be as unambiguous as possible.
I think `allow` would be clearer than `disallow` because it avoids
double-negatives. Can we use
> > `allow-internal-messages-without-credentials` and have it
default to `true`?

In general Java properties ought to default to _false_ if they
aren't set.  We've had other properties default to _true_ in the
past and they were awkward.


- Bruce


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

---


On Sept. 5, 2017, 10:57 a.m., Bruce Schuchardt wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62088/

> ---
>
> (Updated Sept. 5, 2017, 10:57 a.m.)
>
>
> Review request for geode, Alexander Murmann, Galen O'Sullivan,
Hitesh Khamesra, and Udo Kohlmeyer.
>
>
> Bugs: GEODE-3249
> https://issues.apache.org/jira/browse/GEODE-3249

>
>
> Repository: geode
>
>
> Description
> ---
>
> This change leaves the security hole in place but allows you to
plug it by setting the system property
>
> geode.disallow-internal-messages-without-credentials=true
>
> Clients must be upgraded to the release containing this change
if you set this system property to true and client/server
authentication is enabled.  Otherwise client messages to register
PDX types or Instantiators will be rejected by the servers.
>
>
> Diffs
> -
>
> 
 
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
b243d8ebb8f7fb698a4637c7a787ee2d7216f1f7
>
>
> Diff: https://reviews.apache.org/r/62088/diff/1/

>
>
> Testing
> ---
>
>
> Thanks,
>
> Bruce Schuchardt
>
>

Re: Review Request 61895: GEDOE-3516: TXManagerImpl.tryResume call may add itself again into the waiting thread queue

[Nick Reich]

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


Ship it!




Ship It!

- Nick Reich


On Sept. 6, 2017, 6:42 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61895/
> ---
> 
> (Updated Sept. 6, 2017, 6:42 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Lynn Gallinat, 
> and Nick Reich.
> 
> 
> Bugs: GEODE-3516
> https://issues.apache.org/jira/browse/GEODE-3516
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove the thread from waiting thread queue after successfully resumed the 
> transaction
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/TXManagerImpl.java 
> a0a4d7c 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/TXManagerImplJUnitTest.java
>  a2c1e70 
> 
> 
> Diff: https://reviews.apache.org/r/61895/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Review Request 61895: GEDOE-3516: TXManagerImpl.tryResume call may add itself again into the waiting thread queue

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On Sept. 6, 2017, 11:42 a.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61895/
> ---
> 
> (Updated Sept. 6, 2017, 11:42 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Lynn Gallinat, 
> and Nick Reich.
> 
> 
> Bugs: GEODE-3516
> https://issues.apache.org/jira/browse/GEODE-3516
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove the thread from waiting thread queue after successfully resumed the 
> transaction
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/TXManagerImpl.java 
> a0a4d7c 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/TXManagerImplJUnitTest.java
>  a2c1e70 
> 
> 
> Diff: https://reviews.apache.org/r/61895/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Review Request 61895: GEDOE-3516: TXManagerImpl.tryResume call may add itself again into the waiting thread queue

[Eric Shu]

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

(Updated Sept. 6, 2017, 6:42 p.m.)


Review request for geode, anilkumar gingade, Darrel Schneider, Lynn Gallinat, 
and Nick Reich.


Changes
---

Fix review comments -- port the changes from Darrel.


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


Repository: geode


Description
---

Remove the thread from waiting thread queue after successfully resumed the 
transaction


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/internal/cache/TXManagerImpl.java 
a0a4d7c 
  
geode-core/src/test/java/org/apache/geode/internal/cache/TXManagerImplJUnitTest.java
 a2c1e70 


Diff: https://reviews.apache.org/r/61895/diff/3/

Changes: https://reviews.apache.org/r/61895/diff/2-3/


Testing
---

precheckin.


Thanks,

Eric Shu

Re: [Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

[Jacob Barrett]

Mark,

I believe the real issue is that we use multiple patterns and should be
converging on one pattern. We have examples of both Factory and Builder
models and both with and without Fluent pattern.

If the Java API is tending towards Builder model with Fluent pattern then I
am for that as long as this common practice in the C++ world. In my
searching I don't see any strong tendency towards any one model or pattern
in the C++ world. The only real trick to the Fluent pattern in C++ is what
is the type of the return value? Is it &, *, or some smart pointer? I would
expect it be a ref. My only issue with this is that if the original factory
variable is a pointer then the operator changes, for example:
prtToCachFactory->setSomething("arrow").setSomethingElse("dot");

It also needs to be VERY clear in the docs is the builder could ever return
something other than a reference to the original instance of the builder. I
have seen models where it is possible so you have to do things like to
guard against the return changing:
auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
if (somethingMore) {
  cacheFactory = cacheFactory.setSomethingMore();
}
auto cache = cacheFactory.create();

If you have to do that then it because less desirable to have the fluent
pattern because it is prone to error and less readable. We should guarantee
something like this will work:
auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
if (somethingMore) {
  cacheFactory.setSomethingMore();
}
auto cache = cacheFactory.create();

-Jake




On Wed, Sep 6, 2017 at 10:38 AM Darrel Schneider 
wrote:

> In the geode java apis you would create a CacheFactory (or
> ClientCacheFactory), configure it fluently, and then call create at the
> end. So even though we call them factories in the geode java apis, they use
> the Builder pattern and also support the fluent model in that you could do
> this:
>   ClientCache cache = new  ClientCacheFactory().set("propName",
> "propValue").addPoolLocator("addr", 10678).create();
>
>  Also in java the DistributedSystem is hidden under the Cache. So you add
> config to your CacheFactory and when you create it, it will also connect
> the DistributedSystem. It used to be that in java you had to connect the
> DistributedSystem first and then the Cache. Since the DistributedSystem is
> never used apart for a Cache I think this simplification was helpful to
> users.
>
> On Wed, Sep 6, 2017 at 10:13 AM, Mark Hanson  wrote:
>
> > Problem:
> >
> > To fluent and builder model or not to fluent and builder model In the
> > native client
> >
> > we use the factory model of generating objects, we are wondering if a
> move
> > to the fluent model
> >
> > and the builder pattern would be better.
> >
> >
> > Background:
> >
> > In designing the various types of allocators for our objects, we have
> > considered
> >
> > whether or not use the builder and fluent patterns instead of the Factory
> > pattern.
> >
> > The current code base is written following the factory pattern, but it
> > seems that
> >
> > the Builder pattern is becoming more popular. Further, people are also
> > using the
> >
> > fluent model as well.
> >
> > Discussion:
> >
> > The argument for the Builder pattern is that it allows greater
> > specification before the actual
> >
> > creation of the object. For example, Factory often focuses on the
> > attributes
> >
> > after the creation of the object. The Builder pattern allows one to set
> the
> >
> > attributes before the creation of the object, allowing a more specific
> > object
> >
> > to be generated. Currently code is written to the Factory pattern.
> >
> > Consider the following case of connecting to a cache.
> >
> > Our current pattern (Factory)
> >
> > CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();
> >
> > CachePtr cache = cacheFactory->create();
> >
> > cache->getDistributedSystem().Credentials(“emma”, “pizza”);
> >
> > cache->getDistributedSystem().connect();
> >
> > API Used:
> >
> > bool DistributedSystem::Credentials(String, String)
> >
> > void DistributedSystem::connect()
> >
> > Cache CacheFactory::create()
> >
> > Builder pattern
> >
> > CacheFactory cf = new CacheFactory();
> >
> > cf.Locator(“192.168.0.5”, 10334);
> >
> > cf.Credentials(“emma”, “pizza”);
> >
> > Cache cache = cf.Connect();
> >
> > API Used:
> >
> > bool Locator(String, String)
> >
> > bool Credentials(String, String)
> >
> > Cache Connection()
> >
> >
> > Next up we think the real direction lies in further incorporating the
> > fluent model
> >
> >
> >
> > Fluent model
> >
> > Cache cache = new CacheFactory()->Locator(“192.168.0.5",
> > 10334).Credentials(“emma”, “pizza”).Connect();
> >
> > API Used:
> >
> > CacheFactory Locator(String, String)
> >
> > CacheFactory Credentials(String, String)
> >
> > Cache Connection()
> >
> > Do people see value in heading this direction? Sufficient value to
> rewrite
> > the API for 

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

I really am not following what you are trying to say.

I think too many side conversations have muddied this original thread. The
question was about tries, lets keep focused on retries and not transition
the conversation to timeouts.

As it relates to retries the consensus was get rid of it because it is more
appropriately handled by the current timeout APIs.

If we need a thread about timeouts and their values then let's start a new
thread.

-Jake

On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson  wrote:

> So the basic challenge here is for specific API, do we want to focus on
> providing a
> wait forever approach or just use the standard MAX_UNSIGNED and duration.
> I
> think that variable delay is something someone would implement in their own
> API
> and would not be done in the public API where consistency is valuable. I
> could be
> wrong in that belief.
>
> Further, it is sounding like a move away from overloading is the desired
> direction.
> Do we have any points against it??
>
> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz  wrote:
>
> > We would certainly rather have the time-out set correctly, but one of the
> > things I've noticed is, sometimes there is just one query or one function
> > that takes a really long time, and because we keep retrying it with the
> > same timeout, it keeps timing out each retry. It would probably be much
> > smarter to use some sort of increasing timeout on the retries until we
> give
> > up.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >
> > On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson  wrote:
> >
> > > I actually don’t really have a strong opinion one way or the other. I
> get
> > > both approaches. If we want to tailor the code to use a timeout instead
> > of
> > > retry attempts I guess that is fine. It seems kind of like we are
> > > perpetuating the same API problem, that the LCD approach alleviates,
> but
> > ok.
> > >
> > > It is more complicated to code because now you need to push everything
> > > through poll or select. Such as the connect. Not that that is a bad
> > thing,
> > > because it is not. It is just more complicated.
> > >
> > > Thanks,
> > > Mark
> > >
> > > http://developerweb.net/viewtopic.php?id=3196 <
> http://developerweb.net/
> > > viewtopic.php?id=3196>
> > > > On Aug 31, 2017, at 3:47 PM, Jacob Barrett 
> > wrote:
> > > >
> > > > None of the time spent performing the request is deterministic that’s
> > > why there are timeouts. I don’t follow your rational for claiming it
> > > complicated to code.
> > > >
> > > >> On Aug 31, 2017, at 3:27 PM, Mark Hanson 
> wrote:
> > > >>
> > > >> The only problem with that is the time to connect to another server
> is
> > > non-deterministic. So,  the code one would have to write to enable this
> > > would involve a select and a bit of not fun code, but in general could
> be
> > > not very useful as an API.
> > > >>
> > > >> I would say the lowest common denominator approach or the server
> based
> > > approach is better.
> > > >>
> > > >> Just two cents.
> > > >>
> > > >> Thanks,
> > > >> Mark
> > > >>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett 
> > > wrote:
> > > >>>
> > > >>> I believe what Bruce was saying is that the behavior should be
> > covered
> > > by
> > > >>> timeouts not iteration attempts. If the client is able to
> > successfully
> > > send
> > > >>> the command to a server but a failure occurs waiting for a reply we
> > > would
> > > >>> not retry. If the client is unable to send the request to a sever
> > > because
> > > >>> the connection closes then we would try the next server, and the
> > next,
> > > up
> > > >>> to the timeout value.
> > > >>>
> > >  On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson 
> > > wrote:
> > > 
> > >  I can also see why the user doing the retries themselves has
> value.
> > > As a
> > >  lowest common denominator approach, pulling the API is sound.
> > > 
> > > > On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson  >
> > > wrote:
> > > >
> > > > I think the setRetryAttempts really harks back to the case that
> > > Bruce was
> > > > alluding to in which the server goes down. Which is the one valid
> > > case
> > >  for
> > > > this kind of API in theory. Are we say that in that case we don't
> > > retry?
> > > > Seems like we are making the API a little less nice for people.
> > > > As a developer using an API, I want to do as little as possible
> and
> > > get
> > > > the most robust solution possible. This seems to go the wrong
> > > direction
> > >  of
> > > > that kind of intent in a way. I want the client to automatically
> > try
> > >  every
> > > > server. I don't ever want to configure the value. I could limit
> > with
> > > this
> > > > API and force 

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Michael Stolz]

Just don't break existing users.
Timeouts are tricky, and we have lots of users who have tuned them very
carefully over the years.

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

On Wed, Sep 6, 2017 at 1:18 PM, Mark Hanson  wrote:

> So the basic challenge here is for specific API, do we want to focus on
> providing a
> wait forever approach or just use the standard MAX_UNSIGNED and duration.
> I
> think that variable delay is something someone would implement in their own
> API
> and would not be done in the public API where consistency is valuable. I
> could be
> wrong in that belief.
>
> Further, it is sounding like a move away from overloading is the desired
> direction.
> Do we have any points against it??
>
> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz  wrote:
>
> > We would certainly rather have the time-out set correctly, but one of the
> > things I've noticed is, sometimes there is just one query or one function
> > that takes a really long time, and because we keep retrying it with the
> > same timeout, it keeps timing out each retry. It would probably be much
> > smarter to use some sort of increasing timeout on the retries until we
> give
> > up.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771
> >
> > On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson  wrote:
> >
> > > I actually don’t really have a strong opinion one way or the other. I
> get
> > > both approaches. If we want to tailor the code to use a timeout instead
> > of
> > > retry attempts I guess that is fine. It seems kind of like we are
> > > perpetuating the same API problem, that the LCD approach alleviates,
> but
> > ok.
> > >
> > > It is more complicated to code because now you need to push everything
> > > through poll or select. Such as the connect. Not that that is a bad
> > thing,
> > > because it is not. It is just more complicated.
> > >
> > > Thanks,
> > > Mark
> > >
> > > http://developerweb.net/viewtopic.php?id=3196 <
> http://developerweb.net/
> > > viewtopic.php?id=3196>
> > > > On Aug 31, 2017, at 3:47 PM, Jacob Barrett 
> > wrote:
> > > >
> > > > None of the time spent performing the request is deterministic that’s
> > > why there are timeouts. I don’t follow your rational for claiming it
> > > complicated to code.
> > > >
> > > >> On Aug 31, 2017, at 3:27 PM, Mark Hanson 
> wrote:
> > > >>
> > > >> The only problem with that is the time to connect to another server
> is
> > > non-deterministic. So,  the code one would have to write to enable this
> > > would involve a select and a bit of not fun code, but in general could
> be
> > > not very useful as an API.
> > > >>
> > > >> I would say the lowest common denominator approach or the server
> based
> > > approach is better.
> > > >>
> > > >> Just two cents.
> > > >>
> > > >> Thanks,
> > > >> Mark
> > > >>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett 
> > > wrote:
> > > >>>
> > > >>> I believe what Bruce was saying is that the behavior should be
> > covered
> > > by
> > > >>> timeouts not iteration attempts. If the client is able to
> > successfully
> > > send
> > > >>> the command to a server but a failure occurs waiting for a reply we
> > > would
> > > >>> not retry. If the client is unable to send the request to a sever
> > > because
> > > >>> the connection closes then we would try the next server, and the
> > next,
> > > up
> > > >>> to the timeout value.
> > > >>>
> > >  On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson 
> > > wrote:
> > > 
> > >  I can also see why the user doing the retries themselves has
> value.
> > > As a
> > >  lowest common denominator approach, pulling the API is sound.
> > > 
> > > > On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson  >
> > > wrote:
> > > >
> > > > I think the setRetryAttempts really harks back to the case that
> > > Bruce was
> > > > alluding to in which the server goes down. Which is the one valid
> > > case
> > >  for
> > > > this kind of API in theory. Are we say that in that case we don't
> > > retry?
> > > > Seems like we are making the API a little less nice for people.
> > > > As a developer using an API, I want to do as little as possible
> and
> > > get
> > > > the most robust solution possible. This seems to go the wrong
> > > direction
> > >  of
> > > > that kind of intent in a way. I want the client to automatically
> > try
> > >  every
> > > > server. I don't ever want to configure the value. I could limit
> > with
> > > this
> > > > API and force it to never retry or I could cause it to retry more
> > > times
> > > > than I care for it to.  If we are going to get rid of this API in
> > > > particular, I would favor having it automatically try some number
> > of
> > > > servers or all, 

Re: [Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

[Darrel Schneider]

In the geode java apis you would create a CacheFactory (or
ClientCacheFactory), configure it fluently, and then call create at the
end. So even though we call them factories in the geode java apis, they use
the Builder pattern and also support the fluent model in that you could do
this:
  ClientCache cache = new  ClientCacheFactory().set("propName",
"propValue").addPoolLocator("addr", 10678).create();

 Also in java the DistributedSystem is hidden under the Cache. So you add
config to your CacheFactory and when you create it, it will also connect
the DistributedSystem. It used to be that in java you had to connect the
DistributedSystem first and then the Cache. Since the DistributedSystem is
never used apart for a Cache I think this simplification was helpful to
users.

On Wed, Sep 6, 2017 at 10:13 AM, Mark Hanson  wrote:

> Problem:
>
> To fluent and builder model or not to fluent and builder model In the
> native client
>
> we use the factory model of generating objects, we are wondering if a move
> to the fluent model
>
> and the builder pattern would be better.
>
>
> Background:
>
> In designing the various types of allocators for our objects, we have
> considered
>
> whether or not use the builder and fluent patterns instead of the Factory
> pattern.
>
> The current code base is written following the factory pattern, but it
> seems that
>
> the Builder pattern is becoming more popular. Further, people are also
> using the
>
> fluent model as well.
>
> Discussion:
>
> The argument for the Builder pattern is that it allows greater
> specification before the actual
>
> creation of the object. For example, Factory often focuses on the
> attributes
>
> after the creation of the object. The Builder pattern allows one to set the
>
> attributes before the creation of the object, allowing a more specific
> object
>
> to be generated. Currently code is written to the Factory pattern.
>
> Consider the following case of connecting to a cache.
>
> Our current pattern (Factory)
>
> CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();
>
> CachePtr cache = cacheFactory->create();
>
> cache->getDistributedSystem().Credentials(“emma”, “pizza”);
>
> cache->getDistributedSystem().connect();
>
> API Used:
>
> bool DistributedSystem::Credentials(String, String)
>
> void DistributedSystem::connect()
>
> Cache CacheFactory::create()
>
> Builder pattern
>
> CacheFactory cf = new CacheFactory();
>
> cf.Locator(“192.168.0.5”, 10334);
>
> cf.Credentials(“emma”, “pizza”);
>
> Cache cache = cf.Connect();
>
> API Used:
>
> bool Locator(String, String)
>
> bool Credentials(String, String)
>
> Cache Connection()
>
>
> Next up we think the real direction lies in further incorporating the
> fluent model
>
>
>
> Fluent model
>
> Cache cache = new CacheFactory()->Locator(“192.168.0.5",
> 10334).Credentials(“emma”, “pizza”).Connect();
>
> API Used:
>
> CacheFactory Locator(String, String)
>
> CacheFactory Credentials(String, String)
>
> Cache Connection()
>
> Do people see value in heading this direction? Sufficient value to rewrite
> the API for Geode Native for example?
>
>
>
> Conclusion
>
> We need input to decide the future direction. What do people think???
>

Re: Review Request 62088: GEODE-3249 Validate internal client/server messages

[Brian Baynes]

In this case, won't we be changing the default of this property with the
next major release?  So perhaps the choice is to follow the default=false
convention now, or with the next major release..?


On Wed, Sep 6, 2017 at 8:47 AM, Bruce Schuchardt 
wrote:

>
>
> > On Sept. 5, 2017, 5:09 p.m., Galen O'Sullivan wrote:
> > > I prefer config option names to be as unambiguous as possible. I think
> `allow` would be clearer than `disallow` because it avoids
> double-negatives. Can we use
> > > `allow-internal-messages-without-credentials` and have it default to
> `true`?
>
> In general Java properties ought to default to _false_ if they aren't
> set.  We've had other properties default to _true_ in the past and they
> were awkward.
>
>
> - Bruce
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62088/#review184608
> ---
>
>
> On Sept. 5, 2017, 10:57 a.m., Bruce Schuchardt wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/62088/
> > ---
> >
> > (Updated Sept. 5, 2017, 10:57 a.m.)
> >
> >
> > Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh
> Khamesra, and Udo Kohlmeyer.
> >
> >
> > Bugs: GEODE-3249
> > https://issues.apache.org/jira/browse/GEODE-3249
> >
> >
> > Repository: geode
> >
> >
> > Description
> > ---
> >
> > This change leaves the security hole in place but allows you to plug it
> by setting the system property
> >
> > geode.disallow-internal-messages-without-credentials=true
> >
> > Clients must be upgraded to the release containing this change if you
> set this system property to true and client/server authentication is
> enabled.  Otherwise client messages to register PDX types or Instantiators
> will be rejected by the servers.
> >
> >
> > Diffs
> > -
> >
> >   geode-core/src/main/java/org/apache/geode/internal/cache/
> tier/sockets/ServerConnection.java b243d8ebb8f7fb698a4637c7a787ee
> 2d7216f1f7
> >
> >
> > Diff: https://reviews.apache.org/r/62088/diff/1/
> >
> >
> > Testing
> > ---
> >
> >
> > Thanks,
> >
> > Bruce Schuchardt
> >
> >
>
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

So the basic challenge here is for specific API, do we want to focus on
providing a
wait forever approach or just use the standard MAX_UNSIGNED and duration.
I
think that variable delay is something someone would implement in their own
API
and would not be done in the public API where consistency is valuable. I
could be
wrong in that belief.

Further, it is sounding like a move away from overloading is the desired
direction.
Do we have any points against it??

On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz  wrote:

> We would certainly rather have the time-out set correctly, but one of the
> things I've noticed is, sometimes there is just one query or one function
> that takes a really long time, and because we keep retrying it with the
> same timeout, it keeps timing out each retry. It would probably be much
> smarter to use some sort of increasing timeout on the retries until we give
> up.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson  wrote:
>
> > I actually don’t really have a strong opinion one way or the other. I get
> > both approaches. If we want to tailor the code to use a timeout instead
> of
> > retry attempts I guess that is fine. It seems kind of like we are
> > perpetuating the same API problem, that the LCD approach alleviates, but
> ok.
> >
> > It is more complicated to code because now you need to push everything
> > through poll or select. Such as the connect. Not that that is a bad
> thing,
> > because it is not. It is just more complicated.
> >
> > Thanks,
> > Mark
> >
> > http://developerweb.net/viewtopic.php?id=3196  > viewtopic.php?id=3196>
> > > On Aug 31, 2017, at 3:47 PM, Jacob Barrett 
> wrote:
> > >
> > > None of the time spent performing the request is deterministic that’s
> > why there are timeouts. I don’t follow your rational for claiming it
> > complicated to code.
> > >
> > >> On Aug 31, 2017, at 3:27 PM, Mark Hanson  wrote:
> > >>
> > >> The only problem with that is the time to connect to another server is
> > non-deterministic. So,  the code one would have to write to enable this
> > would involve a select and a bit of not fun code, but in general could be
> > not very useful as an API.
> > >>
> > >> I would say the lowest common denominator approach or the server based
> > approach is better.
> > >>
> > >> Just two cents.
> > >>
> > >> Thanks,
> > >> Mark
> > >>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett 
> > wrote:
> > >>>
> > >>> I believe what Bruce was saying is that the behavior should be
> covered
> > by
> > >>> timeouts not iteration attempts. If the client is able to
> successfully
> > send
> > >>> the command to a server but a failure occurs waiting for a reply we
> > would
> > >>> not retry. If the client is unable to send the request to a sever
> > because
> > >>> the connection closes then we would try the next server, and the
> next,
> > up
> > >>> to the timeout value.
> > >>>
> >  On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson 
> > wrote:
> > 
> >  I can also see why the user doing the retries themselves has value.
> > As a
> >  lowest common denominator approach, pulling the API is sound.
> > 
> > > On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson 
> > wrote:
> > >
> > > I think the setRetryAttempts really harks back to the case that
> > Bruce was
> > > alluding to in which the server goes down. Which is the one valid
> > case
> >  for
> > > this kind of API in theory. Are we say that in that case we don't
> > retry?
> > > Seems like we are making the API a little less nice for people.
> > > As a developer using an API, I want to do as little as possible and
> > get
> > > the most robust solution possible. This seems to go the wrong
> > direction
> >  of
> > > that kind of intent in a way. I want the client to automatically
> try
> >  every
> > > server. I don't ever want to configure the value. I could limit
> with
> > this
> > > API and force it to never retry or I could cause it to retry more
> > times
> > > than I care for it to.  If we are going to get rid of this API in
> > > particular, I would favor having it automatically try some number
> of
> > > servers or all, but not retrying at all would not be my choice.
> > >
> > > On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <
> jbarr...@pivotal.io>
> > > wrote:
> > >
> > >>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson 
> > wrote:
> > >>>
> > >>> I would have to go looking, but the key concept is that this is a
> >  bigger
> > >>> problem.
> > >>>
> > >>> interval such as the time between retries
> > >>> wait as in how long to wait for a response...
> > >>>
> > >>
> > >> All time 

[Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

[Mark Hanson]

Problem:

To fluent and builder model or not to fluent and builder model In the
native client

we use the factory model of generating objects, we are wondering if a move
to the fluent model

and the builder pattern would be better.


Background:

In designing the various types of allocators for our objects, we have
considered

whether or not use the builder and fluent patterns instead of the Factory
pattern.

The current code base is written following the factory pattern, but it
seems that

the Builder pattern is becoming more popular. Further, people are also
using the

fluent model as well.

Discussion:

The argument for the Builder pattern is that it allows greater
specification before the actual

creation of the object. For example, Factory often focuses on the
attributes

after the creation of the object. The Builder pattern allows one to set the

attributes before the creation of the object, allowing a more specific
object

to be generated. Currently code is written to the Factory pattern.

Consider the following case of connecting to a cache.

Our current pattern (Factory)

CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();

CachePtr cache = cacheFactory->create();

cache->getDistributedSystem().Credentials(“emma”, “pizza”);

cache->getDistributedSystem().connect();

API Used:

bool DistributedSystem::Credentials(String, String)

void DistributedSystem::connect()

Cache CacheFactory::create()

Builder pattern

CacheFactory cf = new CacheFactory();

cf.Locator(“192.168.0.5”, 10334);

cf.Credentials(“emma”, “pizza”);

Cache cache = cf.Connect();

API Used:

bool Locator(String, String)

bool Credentials(String, String)

Cache Connection()


Next up we think the real direction lies in further incorporating the
fluent model



Fluent model

Cache cache = new CacheFactory()->Locator(“192.168.0.5",
10334).Credentials(“emma”, “pizza”).Connect();

API Used:

CacheFactory Locator(String, String)

CacheFactory Credentials(String, String)

Cache Connection()

Do people see value in heading this direction? Sufficient value to rewrite
the API for Geode Native for example?



Conclusion

We need input to decide the future direction. What do people think???

Re: Need suggestion for exception expected but was

[Anthony Baker]

Please provide steps to reproduce this issue, or logs that can help us better 
diagnose the problem.

> On Sep 6, 2017, at 9:48 AM, dinesh 1004  wrote:
> 
> I am using geode 1.2
> 
> Thanks
> Dinesh
> 
> On 6 Sep 2017 20:51, "Anthony Baker"  wrote:
> 
>> What version of Geode is this?  Did you change the log4j version?
>> 
>> Anthony
>> 
>>> On Sep 6, 2017, at 7:47 AM, Dinesh Akhand  wrote:
>>> 
>>> java.lang.Exception: Unexpected exception, expected> exceptions.IMDGRuntimeException> but was
>>>  at org.apache.geode.internal.logging.LogService$
>> PropertyChangeListenerImpl.propertyChange(LogService.java:279)
>>>  at org.apache.logging.log4j.core.LoggerContext.
>> firePropertyChangeEvent(LoggerContext.java:519)
>>>  at org.apache.logging.log4j.core.LoggerContext.
>> setConfiguration(LoggerContext.java:500)
>>>  at org.apache.logging.log4j.core.
>> LoggerContext.reconfigure(LoggerContext.java:562)
>>>  at org.apache.logging.log4j.core.
>> LoggerContext.reconfigure(LoggerContext.java:578)
>>>  at org.apache.geode.internal.logging.LogService.init(
>> LogService.java:84)
>>>  at org.apache.geode.internal.logging.LogService.(
>> LogService.java:72)
>>>  at org.apache.geode.distributed.internal.
>> InternalDistributedSystem.(InternalDistributedSystem.java:129)
>>> 
>>> 
>>> Can any one suggest me about this exception.
>>> 
>>> While creating logger inInternalDistributedSystem
>>> private static final boolean ALLOW_MEMORY_LOCK_WHEN_OVERCOMMITTED =
>>> Boolean.getBoolean(DistributionConfig.GEMFIRE_PREFIX +
>> "Cache.ALLOW_MEMORY_OVERCOMMIT");
>>> private static final Logger logger = LogService.getLogger();
>>> 
>>> public static final String DISABLE_MANAGEMENT_PROPERTY =
>>> DistributionConfig.GEMFIRE_PREFIX + "disableManagement";
>>> 
>>> /**
>>> Thanks,
>>> Dinesh Akhand
>>> This message and the information contained herein is proprietary and
>> confidential and subject to the Amdocs policy statement,
>>> 
>>> you may review at https://www.amdocs.com/about/email-disclaimer <
>> https://www.amdocs.com/about/email-disclaimer>
>> 
>> 

Re: fix geode-old-versions downloads with a clean build?

[Dan Smith]

I submitted a PR to try to cache the old version somewhere else but people
didn't like the approach I took so I closed it. If someone wants to take
this up that would be great, I'm don't really have time to mess with it
right now.

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

-Dan

On Wed, Sep 6, 2017 at 9:47 AM, Mark Hanson  wrote:

> There was discussion about taking that out I am very hopeful that it
> happens.
>
> Thanks,
> Mark
>
> On Wed, Sep 6, 2017 at 9:25 AM, Galen O'Sullivan 
> wrote:
>
> > Hi all,
> >
> > I like to run a `./gradlew clean build` when I'm pulling, reviewing, or
> > about to push a new build. It seems that this causes the cached geode zip
> > files to have to be redownloaded, which means that the build takes 10
> > minutes instead of 2. If I'm touching a couple of branches a day, this
> can
> > result in significant wasted time. Is there a way to run a clean build
> > without resetting these tests?
> >
> > Thanks,
> > Galen
> >
>

RE: [DISCUSS] Bug while parsing the JSON "key which having short data type" in locate command "https://github.com/apache/geode/pull/752"

[dinesh 1004]

Need suggestions on same pull request

Thanks,
Dinesh

On 1 Sep 2017 09:46, "Dinesh Akhand"  wrote:

> Hi Team,
>
> Please reply over below mail chain.
>
> Need you focus on the issue.
>
> Thanks,
> Dinesh Akhand
>
> -Original Message-
> From: Dinesh Akhand
> Sent: Thursday, August 31, 2017 7:04 PM
> To: dev@geode.apache.org
> Subject: [DISCUSS] Bug while parsing the JSON "key which having short data
> type" in locate command "https://github.com/apache/geode/pull/752;
>
> Hi,
>
>
>
> I have created the pull request for the same .
>
> https://github.com/apache/geode/pull/752
>
>
>
> Jira ticket GEODE-3544.
>
>
>
> Case 1)
>
>
>
> Short data type is getting converted into integer &  geode is looking for
> set method  with integer
>
> And it throws the exception.
>
>
>
> So I am converting the value with parameterType  using
> ConvertUtils.convert which solve the problem for all primitive/wrapper type
>
> Example 2)
>
>  If key data type in short i =5
>
>   It will look for method  seti(integer )
>
> Case 2) If key having the base class it check only key class set method .
>
>
>
> So I change getDeclaredMethods to getMethods()
>
>
>
>
>
> Thanks,
>
> Dinesh Akhand
>
>
>
> -Original Message-
> From: Dinesh Akhand
> Sent: Monday, August 28, 2017 5:46 PM
> To: dev@geode.apache.org
> Subject: Bug while parsing the JSON "key which having short data type" in
> locate command
>
>
>
> Hi Team,
>
>
>
> I have found one bug in geode 1.2 .
>
>
>
> If in the key we having the short data type
>
>
>
> Example:
>
>
>
> public class EmpData  implements Serializable{ private short empid;
>
>
>
> public short getEmpid() {
>
>return empid;
>
> }
>
>
>
> public void setEmpid(short empid) {
>
>this.empid = empid;
>
> }
>
>
>
>
>
> EmpData d1 = new EmpData();
>
> D1. setEmpid((short)1);
>
>
>
> Region.put(d1,"value1");
>
>
>
> Now try locate command on this .
>
>
>
>
>
> Problem in code: file JSONTokener.java. it always return short to int value
>
>
>
> try {
>
> long longValue = Long.parseLong(number, base);
>
> if(longValue <= Short.MAX_VALUE && longValue >= Short.MIN_VALUE)
>
> {
>
>  return (short) longValue;
>
> }
>
> else if (longValue <= Integer.MAX_VALUE && longValue >=
> Integer.MIN_VALUE) {
>
>   return (int) longValue;
>
> } else {
>
>   return longValue;
>
> }
>
>
>
> Later it cause the problem of java.lang.IllegalArgumentException:
> argument type mismatch.
>
> locate entry --key=--key=('empid ':1) --region=CUSTOMER_1
>
>
>
> alternate way :  changes the  DataCommandFunctionJUnitTest.java changes
> the testLocateKeyIsObject method
>
>
>
> due to same problem, we are facing problem with all commands where we
> usage the key.
>
>
>
> Thanks,
>
> Dinesh Akhand
>
>
>
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
>
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>
>

Re: Need suggestion for exception expected but was

[dinesh 1004]

I am using geode 1.2

Thanks
Dinesh

On 6 Sep 2017 20:51, "Anthony Baker"  wrote:

> What version of Geode is this?  Did you change the log4j version?
>
> Anthony
>
> > On Sep 6, 2017, at 7:47 AM, Dinesh Akhand  wrote:
> >
> > java.lang.Exception: Unexpected exception, expected exceptions.IMDGRuntimeException> but was
> >   at org.apache.geode.internal.logging.LogService$
> PropertyChangeListenerImpl.propertyChange(LogService.java:279)
> >   at org.apache.logging.log4j.core.LoggerContext.
> firePropertyChangeEvent(LoggerContext.java:519)
> >   at org.apache.logging.log4j.core.LoggerContext.
> setConfiguration(LoggerContext.java:500)
> >   at org.apache.logging.log4j.core.
> LoggerContext.reconfigure(LoggerContext.java:562)
> >   at org.apache.logging.log4j.core.
> LoggerContext.reconfigure(LoggerContext.java:578)
> >   at org.apache.geode.internal.logging.LogService.init(
> LogService.java:84)
> >   at org.apache.geode.internal.logging.LogService.(
> LogService.java:72)
> >   at org.apache.geode.distributed.internal.
> InternalDistributedSystem.(InternalDistributedSystem.java:129)
> >
> >
> > Can any one suggest me about this exception.
> >
> > While creating logger inInternalDistributedSystem
> >  private static final boolean ALLOW_MEMORY_LOCK_WHEN_OVERCOMMITTED =
> >  Boolean.getBoolean(DistributionConfig.GEMFIRE_PREFIX +
> "Cache.ALLOW_MEMORY_OVERCOMMIT");
> >  private static final Logger logger = LogService.getLogger();
> >
> >  public static final String DISABLE_MANAGEMENT_PROPERTY =
> >  DistributionConfig.GEMFIRE_PREFIX + "disableManagement";
> >
> >  /**
> > Thanks,
> > Dinesh Akhand
> > This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> >
> > you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>
>

Re: fix geode-old-versions downloads with a clean build?

[Mark Hanson]

There was discussion about taking that out I am very hopeful that it
happens.

Thanks,
Mark

On Wed, Sep 6, 2017 at 9:25 AM, Galen O'Sullivan 
wrote:

> Hi all,
>
> I like to run a `./gradlew clean build` when I'm pulling, reviewing, or
> about to push a new build. It seems that this causes the cached geode zip
> files to have to be redownloaded, which means that the build takes 10
> minutes instead of 2. If I'm touching a couple of branches a day, this can
> result in significant wasted time. Is there a way to run a clean build
> without resetting these tests?
>
> Thanks,
> Galen
>

Re: Review Request 62088: GEODE-3249 Validate internal client/server messages

[Bruce Schuchardt]

> On Sept. 5, 2017, 5:09 p.m., Galen O'Sullivan wrote:
> > I prefer config option names to be as unambiguous as possible. I think 
> > `allow` would be clearer than `disallow` because it avoids 
> > double-negatives. Can we use
> > `allow-internal-messages-without-credentials` and have it default to `true`?

In general Java properties ought to default to _false_ if they aren't set.  
We've had other properties default to _true_ in the past and they were awkward.


- Bruce


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


On Sept. 5, 2017, 10:57 a.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62088/
> ---
> 
> (Updated Sept. 5, 2017, 10:57 a.m.)
> 
> 
> Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh 
> Khamesra, and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-3249
> https://issues.apache.org/jira/browse/GEODE-3249
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This change leaves the security hole in place but allows you to plug it by 
> setting the system property
> 
> geode.disallow-internal-messages-without-credentials=true
> 
> Clients must be upgraded to the release containing this change if you set 
> this system property to true and client/server authentication is enabled.  
> Otherwise client messages to register PDX types or Instantiators will be 
> rejected by the servers.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
>  b243d8ebb8f7fb698a4637c7a787ee2d7216f1f7 
> 
> 
> Diff: https://reviews.apache.org/r/62088/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Need suggestion for exception expected but was

[Anthony Baker]

What version of Geode is this?  Did you change the log4j version?

Anthony

> On Sep 6, 2017, at 7:47 AM, Dinesh Akhand  wrote:
> 
> java.lang.Exception: Unexpected exception, 
> expected but 
> was
>   at 
> org.apache.geode.internal.logging.LogService$PropertyChangeListenerImpl.propertyChange(LogService.java:279)
>   at 
> org.apache.logging.log4j.core.LoggerContext.firePropertyChangeEvent(LoggerContext.java:519)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:500)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:562)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:578)
>   at 
> org.apache.geode.internal.logging.LogService.init(LogService.java:84)
>   at 
> org.apache.geode.internal.logging.LogService.(LogService.java:72)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.(InternalDistributedSystem.java:129)
> 
> 
> Can any one suggest me about this exception.
> 
> While creating logger inInternalDistributedSystem
>  private static final boolean ALLOW_MEMORY_LOCK_WHEN_OVERCOMMITTED =
>  Boolean.getBoolean(DistributionConfig.GEMFIRE_PREFIX + 
> "Cache.ALLOW_MEMORY_OVERCOMMIT");
>  private static final Logger logger = LogService.getLogger();
> 
>  public static final String DISABLE_MANAGEMENT_PROPERTY =
>  DistributionConfig.GEMFIRE_PREFIX + "disableManagement";
> 
>  /**
> Thanks,
> Dinesh Akhand
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> 
> you may review at https://www.amdocs.com/about/email-disclaimer 
> 

Need suggestion for exception expected but was

[Dinesh Akhand]

java.lang.Exception: Unexpected exception, 
expected but 
was
   at 
org.apache.geode.internal.logging.LogService$PropertyChangeListenerImpl.propertyChange(LogService.java:279)
   at 
org.apache.logging.log4j.core.LoggerContext.firePropertyChangeEvent(LoggerContext.java:519)
   at 
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:500)
   at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:562)
   at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:578)
   at 
org.apache.geode.internal.logging.LogService.init(LogService.java:84)
   at 
org.apache.geode.internal.logging.LogService.(LogService.java:72)
   at 
org.apache.geode.distributed.internal.InternalDistributedSystem.(InternalDistributedSystem.java:129)


Can any one suggest me about this exception.

While creating logger inInternalDistributedSystem
  private static final boolean ALLOW_MEMORY_LOCK_WHEN_OVERCOMMITTED =
  Boolean.getBoolean(DistributionConfig.GEMFIRE_PREFIX + 
"Cache.ALLOW_MEMORY_OVERCOMMIT");
  private static final Logger logger = LogService.getLogger();

  public static final String DISABLE_MANAGEMENT_PROPERTY =
  DistributionConfig.GEMFIRE_PREFIX + "disableManagement";

  /**
Thanks,
Dinesh Akhand
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Re: DISCUSS : Monitor the neighbour JVM using neihbour's member-timeout (GEODE-3411)

[Anthony Baker]

Are you intending to use server groups to divide the cluster into different 
logical groupings?  Unless the groups host entirely separate data sets I could 
see an asymmetric response pattern depending if the primary was hosted on a 
member with a short / long timeout.

Anthony

> On Sep 6, 2017, at 7:27 AM, Aravind Musigumpula 
>  wrote:
> 
> Hi Udo,
> 
> For your question: "If you feel that the member timeout is too short for some 
> members, why don't you increase the current member timeout?"
> 
> Yes, for some members I feel that member-timeout is short. I want to increase 
> the timeout for some members. But that timeout is not being used to monitor 
> themselves but instead the increased member timeout may be used to monitor 
> some other member.
> 
> If I want some member to be alive for a little more time even if it is not 
> responding, Now I need to increase the timeout of all the members.
> 
> Do you mean to increase the current member timeout for all the members.
> 
> 
> Thanks,
> Aravind Musigumpula 
> 
> 
> -Original Message-
> From: Udo Kohlmeyer [mailto:ukohlme...@pivotal.io] 
> Sent: Friday, September 01, 2017 10:05 PM
> To: dev@geode.apache.org
> Subject: Re: DISCUSS : Monitor the neighbour JVM using neihbour's 
> member-timeout (GEODE-3411)
> 
> Hi there Aravind,
> 
> I have a singular problem with this approach.
> 
> If a some members are designated to do more work, and don't have time to 
> respond to the cluster that they are alive using the current member timeout, 
> then they are not available to accept data. Which means they are not 
> effective members of the cluster and we cannot count on them to host data or 
> replicates.
> 
> This setting is there to safe guard the cluster against non-responsive 
> members that cause the whole cluster to be unhealthy if left unchecked for 
> too long. This can lead to potential data loss
> 
> If you feel that the member timeout is too short for some members, why don't 
> you increase the current member timeout?
> 
> My opinion is a -1 for changing the current behavior.
> 
> --Udo
> 
> On 9/1/17 03:46, Aravind Musigumpula wrote:
>> Hi Brian,
>> 
>> This will help if the user has some member doing a heavy duty when compared 
>> to others, in this case we need to give such member some extra time to that 
>> member.
>> 
>> Thanks,
>> Aravind Musigumpula
>> 
>> 
>> -Original Message-
>> From: Brian Baynes [mailto:bbay...@pivotal.io]
>> Sent: Friday, September 01, 2017 4:39 AM
>> To: dev@geode.apache.org
>> Subject: Re: DISCUSS : Monitor the neighbour JVM using neihbour's 
>> member-timeout (GEODE-3411)
>> 
>> Hi, Aravind.
>> 
>> Can you help me understand why this might be a useful feature for Geode?  I 
>> see that your needs require it, but why would users in general want to allow 
>> longer timeouts for some members?  This is a significant change with 
>> backward-compatibility implications, so would be good for the community to 
>> understand the potential benefit.
>> 
>> Thanks!
>> Brian
>> 
>> On Mon, Aug 28, 2017 at 12:20 AM, Aravind Musigumpula < 
>> aravind.musigump...@amdocs.com> wrote:
>> 
>>> Hi Team,
>>> 
>>> We have a requirement to configure  different member timeout for 
>>> different members as we need some members to survive in the view for 
>>> longer time than the other the members before being kicked out of the 
>>> view in case they aren't responding.
>>> 
>>> 
>>> 1.   Now with the current monitoring system it is not possible to
>>> determine when the member will be kicked out of the view if we 
>>> configure different member-timeout's for some required members.
>>> 
>>> 2.   Because if a member is not responding to any heartbeat requests,
>>> the member who is monitoring the non-responding member will initiate 
>>> check member request.
>>> 
>>> 3.   In this check member request monitoring member pings the
>>> non-responding member and waits for member-timeout of monitoring 
>>> member for a response.
>>> 
>>> 4.   If still there is no response, it will initiate a final suspect
>>> request to coordinator where the coordinator does the final check 
>>> waiting for coordinators member-timeout.
>>> 
>>> 5.   If coordinator did not get any response, it will remove the
>>> non-responding member from the view and publishes it.
>>> 
>>> 6.   So, Here the time period for removing a member depends on its
>>> monitoring member's and coordinator's timeout. But the monitoring 
>>> member depends on the view but it may change from time to time.
>>> 
>>> So, now when a monitoring-member doing the check on a member, if we 
>>> wait for the non-responding member's timeout instead of the 
>>> monitoring member-timeout, then the time when the non-responding 
>>> member will be removed from the view depends on its own 
>>> member-timeout and the coordinators member-timeout.
>>> Hence we can configure different member-timeout for the required members.
>>> 
>>> I 

RE: DISCUSS : Monitor the neighbour JVM using neihbour's member-timeout (GEODE-3411)

[Aravind Musigumpula]

Hi Udo,

For your question: "If you feel that the member timeout is too short for some 
members, why don't you increase the current member timeout?"

Yes, for some members I feel that member-timeout is short. I want to increase 
the timeout for some members. But that timeout is not being used to monitor 
themselves but instead the increased member timeout may be used to monitor some 
other member.

If I want some member to be alive for a little more time even if it is not 
responding, Now I need to increase the timeout of all the members.

Do you mean to increase the current member timeout for all the members.


Thanks,
Aravind Musigumpula 


-Original Message-
From: Udo Kohlmeyer [mailto:ukohlme...@pivotal.io] 
Sent: Friday, September 01, 2017 10:05 PM
To: dev@geode.apache.org
Subject: Re: DISCUSS : Monitor the neighbour JVM using neihbour's 
member-timeout (GEODE-3411)

Hi there Aravind,

I have a singular problem with this approach.

If a some members are designated to do more work, and don't have time to 
respond to the cluster that they are alive using the current member timeout, 
then they are not available to accept data. Which means they are not effective 
members of the cluster and we cannot count on them to host data or replicates.

This setting is there to safe guard the cluster against non-responsive members 
that cause the whole cluster to be unhealthy if left unchecked for too long. 
This can lead to potential data loss

If you feel that the member timeout is too short for some members, why don't 
you increase the current member timeout?

My opinion is a -1 for changing the current behavior.

--Udo

On 9/1/17 03:46, Aravind Musigumpula wrote:
> Hi Brian,
>
> This will help if the user has some member doing a heavy duty when compared 
> to others, in this case we need to give such member some extra time to that 
> member.
>
> Thanks,
> Aravind Musigumpula
>
>
> -Original Message-
> From: Brian Baynes [mailto:bbay...@pivotal.io]
> Sent: Friday, September 01, 2017 4:39 AM
> To: dev@geode.apache.org
> Subject: Re: DISCUSS : Monitor the neighbour JVM using neihbour's 
> member-timeout (GEODE-3411)
>
> Hi, Aravind.
>
> Can you help me understand why this might be a useful feature for Geode?  I 
> see that your needs require it, but why would users in general want to allow 
> longer timeouts for some members?  This is a significant change with 
> backward-compatibility implications, so would be good for the community to 
> understand the potential benefit.
>
> Thanks!
> Brian
>
> On Mon, Aug 28, 2017 at 12:20 AM, Aravind Musigumpula < 
> aravind.musigump...@amdocs.com> wrote:
>
>> Hi Team,
>>
>> We have a requirement to configure  different member timeout for 
>> different members as we need some members to survive in the view for 
>> longer time than the other the members before being kicked out of the 
>> view in case they aren't responding.
>>
>>
>> 1.   Now with the current monitoring system it is not possible to
>> determine when the member will be kicked out of the view if we 
>> configure different member-timeout's for some required members.
>>
>> 2.   Because if a member is not responding to any heartbeat requests,
>> the member who is monitoring the non-responding member will initiate 
>> check member request.
>>
>> 3.   In this check member request monitoring member pings the
>> non-responding member and waits for member-timeout of monitoring 
>> member for a response.
>>
>> 4.   If still there is no response, it will initiate a final suspect
>> request to coordinator where the coordinator does the final check 
>> waiting for coordinators member-timeout.
>>
>> 5.   If coordinator did not get any response, it will remove the
>> non-responding member from the view and publishes it.
>>
>> 6.   So, Here the time period for removing a member depends on its
>> monitoring member's and coordinator's timeout. But the monitoring 
>> member depends on the view but it may change from time to time.
>>
>> So, now when a monitoring-member doing the check on a member, if we 
>> wait for the non-responding member's timeout instead of the 
>> monitoring member-timeout, then the time when the non-responding 
>> member will be removed from the view depends on its own 
>> member-timeout and the coordinators member-timeout.
>> Hence we can configure different member-timeout for the required members.
>>
>> I created a pull request based on the above scenario:
>> https://github.com/apache/geode/pull/717
>>
>> Is the above approach correct? Do we have any concerns around this area?
>> Please give your insights on this issue.
>>
>> Thanks,
>> Aravind Musigumpula
>>
>> This message and the information contained herein is proprietary and 
>> confidential and subject to the Amdocs policy statement,
>>
>> you may review at https://www.amdocs.com/about/email-disclaimer < 
>> https://www.amdocs.com/about/email-disclaimer>
>>
> This message and the information contained herein