Build failed in Jenkins: Geode-nightly #972

[Apache Jenkins Server]

See 

--
[...truncated 1.33 MB...]
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:330)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:205)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:179)
at 
org.apache.geode.internal.cache.wan.WANTestBase.createFirstLocatorWithDSId(WANTestBase.java:283)
at 
org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest.lambda$testReplicatedSerialPropagationWithFilter$a2e85a4$1(ConcurrentWANPropagation_2_DUnitTest.java:341)

org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest
 > testSerialPropagationWithFilter FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest$$Lambda$533/679028541.call
 in VM 0 running on Host 62ed47c2ccba with 8 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
at org.apache.geode.test.dunit.VM.invoke(VM.java:331)
at 
org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest.testSerialPropagationWithFilter(ConcurrentWANPropagation_2_DUnitTest.java:304)

Caused by:
java.lang.OutOfMemoryError: Failed creating 314572800 bytes of off-heap 
memory during cache creation.
at 
org.apache.geode.internal.offheap.AddressableMemoryManager.allocate(AddressableMemoryManager.java:64)
at 
org.apache.geode.internal.offheap.SlabImpl.(SlabImpl.java:35)
at 
org.apache.geode.internal.offheap.SlabImpl.(SlabImpl.java:27)
at 
org.apache.geode.internal.offheap.MemoryAllocatorImpl$1.create(MemoryAllocatorImpl.java:93)
at 
org.apache.geode.internal.offheap.MemoryAllocatorImpl.create(MemoryAllocatorImpl.java:122)
at 
org.apache.geode.internal.offheap.MemoryAllocatorImpl.create(MemoryAllocatorImpl.java:89)
at 
org.apache.geode.internal.offheap.OffHeapStorage.basicCreateOffHeapStorage(OffHeapStorage.java:219)
at 
org.apache.geode.internal.offheap.OffHeapStorage.createOffHeapStorage(OffHeapStorage.java:207)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:700)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:350)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:336)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:330)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:205)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:179)
at 
org.apache.geode.internal.cache.wan.WANTestBase.createFirstLocatorWithDSId(WANTestBase.java:283)
at 
org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest.lambda$testSerialPropagationWithFilter$a2e85a4$1(ConcurrentWANPropagation_2_DUnitTest.java:304)

org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest
 > testNormalRegionSerialPropagation FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest$$Lambda$534/1765263205.call
 in VM 0 running on Host 62ed47c2ccba with 8 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
at org.apache.geode.test.dunit.VM.invoke(VM.java:331)
at 
org.apache.geode.internal.cache.wan.concurrent.ConcurrentWANPropagation_2_DUnitTest.testNormalRegionSerialPropagation(ConcurrentWANPropagation_2_DUnitTest.java:371)

Caused by:
java.lang.OutOfMemoryError: Failed creating 314572800 bytes of off-heap 
memory during cache creation.
at 
org.apache.geode.internal.offheap.AddressableMemoryManager.allocate(AddressableMemoryManager.java:64)
at 
org.apache.geode.internal.offheap.SlabImpl.(SlabImpl.java:35)
at 
org.apache.geode.internal.offheap.SlabImpl.(SlabImpl.java:27)
at 
org.apache.geode.internal.offheap.MemoryAllocatorImpl$1.create(MemoryAllocatorImpl.java:93)
at 
org.apache.geode.internal.offheap.MemoryAllocatorImpl.create(MemoryAllocatorImpl.java:122)
at 
org.apache.geode.internal.offheap.MemoryAllocatorImpl.create(MemoryAllocatorImpl.java:89)
at 
org.apache.geode.intern

Re: [DISCUSS] Removal of "Submit an Issue" from Geode webpage

[Alexander Murmann]

+1 for moving them to the mailing list

On Fri, Sep 29, 2017 at 8:41 PM, Mark Bretl  wrote:

> +1 for removal
>
> —Mark
>
> On Fri, Sep 29, 2017 at 1:17 PM Gregory Chase  wrote:
>
> > Yes please, especially since I'm not the one posting these :)
> >
> > On Fri, Sep 29, 2017 at 11:35 AM, Dave Barnes 
> wrote:
> >
> > > +1 to removing the button.
> > > +1 to Dan's suggestion of nudging users toward the mailing list.  I
> see a
> > > place we could add a few words on the Community page, where the Users
> > > mailing list is the first entry; add to the blurb "or raise an issue".
> > (The
> > > Mailing Lists menu choice takes you here, as well.)
> > >
> > >
> > > On Fri, Sep 29, 2017 at 11:15 AM, Dan Smith  wrote:
> > >
> > > > +1 - I think it would be better to just encourage users to send
> > > > issues/questions to the users list initially.
> > > >
> > > > -Dan
> > > >
> > > > On Fri, Sep 29, 2017 at 11:08 AM, Michael William Dodge
> > > >  wrote:
> > > > > +1 to improving the signal-to-noise ratio
> > > > >
> > > > >> On 29 Sep, 2017, at 11:07, Jason Huynh  wrote:
> > > > >>
> > > > >> GEODE-3280
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Greg Chase
> >
> > Product team, Pivotal Cloud Foundry Services
> > https://pivotal.io/platform/services 
> >
> > Pivotal Software
> > http://www.pivotal.io/
> >
> > 650-215-0477
> > @GregChase
> >
>

Re: [DISCUSS] Using out parameters and its effects on function overload resolution

[Jacob Barrett]

We are already in contention with our style guide on many items. I suggest
we use it as a guideline only and establish our own rules. The more
research into the Google C++ guide is really driven by legacy C/C++ issues
at Google.

Regarding the in/out issue I am for multiple return types so that we
migrate to a more functional programming style. An interesting article I
read last week on this issue sheds some good light on why,
https://www.fluentcpp.com/2016/11/22/make-your-functions-functional/.

As a bonus, once we go C++17 (in 2020ish I am sure) we can use auto
structured return values.
auto [a, b] = foo.getAAndB();

-Jake


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

> I forgot to mention, and it's probably worth noting, that passing non-const
> ref knowingly defies our style-guide.
>
> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
>
> Thanks,
> David
>
> On Wed, Sep 27, 2017 at 12:32 PM, Ernest Burghardt 
> wrote:
>
> > Currently we have a mix of the counter argument...
> >
> > we use return values and you have to call the explicitly named methods:
> > double* readDoubleArray(const char* fieldName, int32_t& length)
> > int64_t* readLongArray(const char* fieldName, int32_t& length)
> >
> > I'm good with non-const refs in-out to the specific method calls OR
> > overload readArray and different return values...
> >
> > EB
> >
> > On Wed, Sep 27, 2017 at 1:27 PM, Michael William Dodge <
> mdo...@pivotal.io>
> > wrote:
> >
> > > I like the idea of using non-const references for in-out parameters
> only
> > > and using tuples for the cases where there are multiple out parameters.
> > > Yes, the return type does not participate in overload resolution but I
> > > don't think there would be many cases where that would be an issue.
> (But
> > I
> > > haven't done any research so that's just a WAG.)
> > >
> > > Sarge
> > >
> > > > On 27 Sep, 2017, at 12:22, David Kimura  wrote:
> > > >
> > > > Is there a use case in our C++ client code to ever use out
> parameters?
> > > >
> > > > Currently code uses out parameters to return multiple values from a
> > > > function.  [1]
> > > >
> > > > virtual int64_t* PdxReader::readLongArray(const char* fieldName,
> > int32_t&
> > > > length) = 0;
> > > >
> > > >
> > > > In this case, we could return a tuple instead.  I think the advantage
> > of
> > > > this is it doesn't force a separation between the variable
> declaration
> > > and
> > > > assignment, which may lead to spaghetti code.  I think avoiding out
> > > > parameters also leads to more well defined behavior.  What would one
> > > expect
> > > > if they called getCqListeners with an already partially populated
> > vector?
> > > > [2]
> > > >
> > > > virtual void CqAttributes::getCqListeners(std::vector > v)
> > > = 0;
> > > >
> > > >
> > > > As a counter argument, could function overload resolution be a valid
> > use
> > > > case of out parameters?  In PdxReader::readType methods, Type seems
> > > > redundant.  As a user, why should I have to call
> > > readLongArray(int64_t[]&)
> > > > rather than just call read(int64_t[]&)?  In this case, if we didn't
> use
> > > out
> > > > parameter our signature clashes with other read methods.
> > > >
> > > > Thoughts?
> > > >
> > > > Thanks,
> > > > David
> > > >
> > > > [1]
> > > > https://github.com/apache/geode-native/blob/
> > > 44635ffa95926c9cffecc1dcaac02fb3012d1eef/cppcache/include/
> > > geode/PdxReader.hpp#L288
> > > > [2]
> > > > https://github.com/apache/geode-native/blob/
> > > 44635ffa95926c9cffecc1dcaac02fb3012d1eef/cppcache/include/
> > > geode/CqAttributes.hpp#L60
> > >
> > >
> >
>

Re: [DISCUSS] Removal of "Submit an Issue" from Geode webpage

[Dave Barnes]

I volunteer to handle this, beginning with a JIRA ticket.
I'm not sure we need to add any text anywhere. On the Geode home page
there's a button for "ask a question on the Mailing LIsts", though it is
located below the fold.

On Mon, Oct 2, 2017 at 8:59 AM, Alexander Murmann 
wrote:

> +1 for moving them to the mailing list
>
> On Fri, Sep 29, 2017 at 8:41 PM, Mark Bretl  wrote:
>
> > +1 for removal
> >
> > —Mark
> >
> > On Fri, Sep 29, 2017 at 1:17 PM Gregory Chase  wrote:
> >
> > > Yes please, especially since I'm not the one posting these :)
> > >
> > > On Fri, Sep 29, 2017 at 11:35 AM, Dave Barnes 
> > wrote:
> > >
> > > > +1 to removing the button.
> > > > +1 to Dan's suggestion of nudging users toward the mailing list.  I
> > see a
> > > > place we could add a few words on the Community page, where the Users
> > > > mailing list is the first entry; add to the blurb "or raise an
> issue".
> > > (The
> > > > Mailing Lists menu choice takes you here, as well.)
> > > >
> > > >
> > > > On Fri, Sep 29, 2017 at 11:15 AM, Dan Smith 
> wrote:
> > > >
> > > > > +1 - I think it would be better to just encourage users to send
> > > > > issues/questions to the users list initially.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Fri, Sep 29, 2017 at 11:08 AM, Michael William Dodge
> > > > >  wrote:
> > > > > > +1 to improving the signal-to-noise ratio
> > > > > >
> > > > > >> On 29 Sep, 2017, at 11:07, Jason Huynh 
> wrote:
> > > > > >>
> > > > > >> GEODE-3280
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Greg Chase
> > >
> > > Product team, Pivotal Cloud Foundry Services
> > > https://pivotal.io/platform/services 
> > >
> > > Pivotal Software
> > > http://www.pivotal.io/
> > >
> > > 650-215-0477
> > > @GregChase
> > >
> >
>

Re: 1.3.0 release

[Brian Baynes]

I've removed the 1.3.0 tag from these items:

GEODE-3563  SSL socket
handling problems in TCPConduit run
GEODE-3705  New client
protocol: Implement handshake
GEODE-3637 
configureClientSSLSocket call can block Acceptor thread




On Sun, Oct 1, 2017 at 9:31 AM, Swapnil Bawaskar 
wrote:

> Hi All,
> We actually have gone up from 11 to 15 issues tagged for release with 1.3.
> Based on recent activity (or lack there of) and features not related to
> Security, I think we should not wait for the following issues for 1.3: (I
> will remove 1.3 labels for these if there are no concerns in 72 hours)
> GEODE-3563  SSL socket
> handling problems in TCPConduit run
> GEODE-3521  Allow region
> set op to bootstrap JTA
> GEODE-3622  The first
> HeapLRU evictions on large region can consume high amounts of CPU
> GEODE-3705  New client
> protocol: Implement handshake
> GEODE-3682  Trace
> displaying incorrect indexes being used
> GEODE-3637 
> configureClientSSLSocket
> call can block Acceptor thread
>
> Which brings us down to the following 8:
> GEODE-2817  Have the
> function author determine what permissions the function execution requires
> GEODE-2919  Provide
> finer
> grained security
> GEODE-3190  CI failure:
> org.apache.geode.internal.cache.Bug48182JUnitTest.
> test48182WithRegionDestroy
> GEODE-3495  Review and
> update dependencies for 1.3.0
> GEODE-3621  Revert
> breaking changes in SecurityManager
> GEODE-3628  fix required
> permission for lucene query
> GEODE-3685  MBean
> wrappers are not always applied correctly
> GEODE-3723  Reconsider
> using Optional as the parameter for getRequiredPermissions
>
>
> On Fri, Sep 15, 2017 at 1:11 PM Swapnil Bawaskar 
> wrote:
>
> > I took preliminary look and tagged some issues for 1.3.0.
> > Looks like we have 11 issues remaining:
> >
> > https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=92&projectKey=GEODE&view=planning&selectedIssue=
> GEODE-2788&versions=visible&selectedVersion=12340669
> >
> > Please take a look at these issues to see which are not critical to fix
> in
> > 1.3 and also look at issues assigned to you/reported by you to see if
> they
> > must be tagged for 1.3.
> >
> > Thanks!
> >
> >
> >
> > On Fri, Sep 15, 2017 at 10:36 AM Anthony Baker 
> wrote:
> >
> >> Excellent!  Can you review the open issues currently tagged for 1.3.0 (I
> >> think it’s probably not accurate) and gather consensus on any remaining
> >> changes needed?
> >>
> >> Anthony
> >>
> >> > On Sep 12, 2017, at 2:40 PM, Swapnil Bawaskar 
> >> wrote:
> >> >
> >> > Sound good.
> >> >
> >> > I would like to volunteer to be the release manager.
> >> >
> >> > Thanks!
> >> >
> >> >
> >> > On Tue, Sep 12, 2017 at 2:24 PM Anthony Baker 
> >> wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> I think we should begin discussing scope and timeline for the 1.3.0
> >> >> release.  I know we’re still finalizing 1.2.1, but we released 1.2.0
> >> almost
> >> >> two months ago and we’ve fixed almost 200 issues in that time.  IMO,
> we
> >> >> should complete 1.2.1 and then immediately turn around 1.3.0.
> >> >>
> >> >> Thoughts?  Any volunteers for release manager?
> >> >>
> >> >> Anthony
> >> >>
> >> >>
> >>
> >>
>

Re: [DISCUSS] Removal of "Submit an Issue" from Geode webpage

[Dave Barnes]

Created GEODE-3726 (https://issues.apache.org/jira/browse/GEODE-3726)

On Mon, Oct 2, 2017 at 9:07 AM, Dave Barnes  wrote:

> I volunteer to handle this, beginning with a JIRA ticket.
> I'm not sure we need to add any text anywhere. On the Geode home page
> there's a button for "ask a question on the Mailing LIsts", though it is
> located below the fold.
>
> On Mon, Oct 2, 2017 at 8:59 AM, Alexander Murmann 
> wrote:
>
>> +1 for moving them to the mailing list
>>
>> On Fri, Sep 29, 2017 at 8:41 PM, Mark Bretl  wrote:
>>
>> > +1 for removal
>> >
>> > —Mark
>> >
>> > On Fri, Sep 29, 2017 at 1:17 PM Gregory Chase 
>> wrote:
>> >
>> > > Yes please, especially since I'm not the one posting these :)
>> > >
>> > > On Fri, Sep 29, 2017 at 11:35 AM, Dave Barnes 
>> > wrote:
>> > >
>> > > > +1 to removing the button.
>> > > > +1 to Dan's suggestion of nudging users toward the mailing list.  I
>> > see a
>> > > > place we could add a few words on the Community page, where the
>> Users
>> > > > mailing list is the first entry; add to the blurb "or raise an
>> issue".
>> > > (The
>> > > > Mailing Lists menu choice takes you here, as well.)
>> > > >
>> > > >
>> > > > On Fri, Sep 29, 2017 at 11:15 AM, Dan Smith 
>> wrote:
>> > > >
>> > > > > +1 - I think it would be better to just encourage users to send
>> > > > > issues/questions to the users list initially.
>> > > > >
>> > > > > -Dan
>> > > > >
>> > > > > On Fri, Sep 29, 2017 at 11:08 AM, Michael William Dodge
>> > > > >  wrote:
>> > > > > > +1 to improving the signal-to-noise ratio
>> > > > > >
>> > > > > >> On 29 Sep, 2017, at 11:07, Jason Huynh 
>> wrote:
>> > > > > >>
>> > > > > >> GEODE-3280
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Greg Chase
>> > >
>> > > Product team, Pivotal Cloud Foundry Services
>> > > https://pivotal.io/platform/services 
>> > >
>> > > Pivotal Software
>> > > http://www.pivotal.io/
>> > >
>> > > 650-215-0477
>> > > @GregChase
>> > >
>> >
>>
>
>

Re: New client/server protocol - seeking feedback

[Michael Stolz]

We should check that it is actually safe to add fields.
If it isn't we're likely to have a lot of versioning to do.

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

On Mon, Sep 25, 2017 at 5:25 PM, Galen O'Sullivan 
wrote:

> Replies inline.
>
> On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer 
> wrote:
>
> > Replies inline
> > On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith  wrote:
> >
> > > This actually brings up another point I was going to ask about. I don't
> > see
> > > any version information in the protocol. How will we handle adding new
> > > features to this protocol? Do the clients and servers negotiate which
> > > version of the protocol to use somehow?
> > >
> > > I think there should be a plan in place for making changes to the
> > protocol
> > > and supporting old clients. Given that, we shouldn't add fields that
> > aren't
> > > actually used into the existing version of the protocol. When we
> > introduce
> > > new features into the protocol, that's the point at which we should add
> > the
> > > fields to support that feature.
> > >
> >
> > [UK] - Protobuf allows for the amending of messages. As soon as the
> > protocol changes significantly the "magic" number will have to be
> > incremented, indicating a new (non-backward compatible) version of the
> > protocol. This of course has bigger problems, where Java does not allow
> for
> > multiple versions of the same class to be loaded, so a server could run
> > only 1 version of Protobuf messages at a time.
> >
>
> We have to be careful about how we extend protobuf messages, though. I'm
> not sure exactly what's safe to do, but it should at least be safe to add
> fields (assuming they don't change existing behavior -- we'll have to think
> about this) and ignore old fields (which is how you would remove a
> now-unused field). It's fairly simple to add new operations without any
> interesting breakages - they'll fail with older servers and not be sent
> with older clients. I think adding new operations is a pretty good way to
> add features that don't require a real rework of the protocol. For those
> that do, we can version the initial byte.
>

Re: [DISCUSS] Using out parameters and its effects on function overload resolution

[Jacob Barrett]

Basic docs on the C++11 tuple use for multiple return types:
http://en.cppreference.com/w/cpp/utility/tuple

In C++11 we would have:

std::tuple foo::getAAndB() {...}

And call it with:

int a;
std::string b;
std::tie(a, b) = foo.getAAndB();

While this isn't super pretty I would argue it is more readable than.

std::string b;
auto a = foo.getAAndB(b);

I believe this is unclear when reading that b is an out variable rather
than passing empty string value to the function.

And certainly easier to understand than:
int a;
std::string b;
foo.getAAndB(a, b);

Again, is a and be inadvertently uninitialized?

Alternatively the tuple can be called like:

auto r = foo.getAAndB();
auto a = std::get<0>(r);
auto b = std::get<1>(r);




Another interesting blog on the issue:
https://dzone.com/articles/returning-multiple-values-from-functions-in-c

-Jake


On Mon, Oct 2, 2017 at 9:07 AM Jacob Barrett  wrote:

> We are already in contention with our style guide on many items. I suggest
> we use it as a guideline only and establish our own rules. The more
> research into the Google C++ guide is really driven by legacy C/C++ issues
> at Google.
>
> Regarding the in/out issue I am for multiple return types so that we
> migrate to a more functional programming style. An interesting article I
> read last week on this issue sheds some good light on why,
> https://www.fluentcpp.com/2016/11/22/make-your-functions-functional/.
>
> As a bonus, once we go C++17 (in 2020ish I am sure) we can use auto
> structured return values.
> auto [a, b] = foo.getAAndB();
>
> -Jake
>
>
> On Wed, Sep 27, 2017 at 1:14 PM David Kimura  wrote:
>
>> I forgot to mention, and it's probably worth noting, that passing
>> non-const
>> ref knowingly defies our style-guide.
>>
>> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
>>
>> Thanks,
>> David
>>
>> On Wed, Sep 27, 2017 at 12:32 PM, Ernest Burghardt > >
>> wrote:
>>
>> > Currently we have a mix of the counter argument...
>> >
>> > we use return values and you have to call the explicitly named methods:
>> > double* readDoubleArray(const char* fieldName, int32_t& length)
>> > int64_t* readLongArray(const char* fieldName, int32_t& length)
>> >
>> > I'm good with non-const refs in-out to the specific method calls OR
>> > overload readArray and different return values...
>> >
>> > EB
>> >
>> > On Wed, Sep 27, 2017 at 1:27 PM, Michael William Dodge <
>> mdo...@pivotal.io>
>> > wrote:
>> >
>> > > I like the idea of using non-const references for in-out parameters
>> only
>> > > and using tuples for the cases where there are multiple out
>> parameters.
>> > > Yes, the return type does not participate in overload resolution but I
>> > > don't think there would be many cases where that would be an issue.
>> (But
>> > I
>> > > haven't done any research so that's just a WAG.)
>> > >
>> > > Sarge
>> > >
>> > > > On 27 Sep, 2017, at 12:22, David Kimura  wrote:
>> > > >
>> > > > Is there a use case in our C++ client code to ever use out
>> parameters?
>> > > >
>> > > > Currently code uses out parameters to return multiple values from a
>> > > > function.  [1]
>> > > >
>> > > > virtual int64_t* PdxReader::readLongArray(const char* fieldName,
>> > int32_t&
>> > > > length) = 0;
>> > > >
>> > > >
>> > > > In this case, we could return a tuple instead.  I think the
>> advantage
>> > of
>> > > > this is it doesn't force a separation between the variable
>> declaration
>> > > and
>> > > > assignment, which may lead to spaghetti code.  I think avoiding out
>> > > > parameters also leads to more well defined behavior.  What would one
>> > > expect
>> > > > if they called getCqListeners with an already partially populated
>> > vector?
>> > > > [2]
>> > > >
>> > > > virtual void CqAttributes::getCqListeners(std::vector> > v)
>> > > = 0;
>> > > >
>> > > >
>> > > > As a counter argument, could function overload resolution be a valid
>> > use
>> > > > case of out parameters?  In PdxReader::readType methods, Type seems
>> > > > redundant.  As a user, why should I have to call
>> > > readLongArray(int64_t[]&)
>> > > > rather than just call read(int64_t[]&)?  In this case, if we didn't
>> use
>> > > out
>> > > > parameter our signature clashes with other read methods.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > Thanks,
>> > > > David
>> > > >
>> > > > [1]
>> > > > https://github.com/apache/geode-native/blob/
>> > > 44635ffa95926c9cffecc1dcaac02fb3012d1eef/cppcache/include/
>> > > geode/PdxReader.hpp#L288
>> > > > [2]
>> > > > https://github.com/apache/geode-native/blob/
>> > > 44635ffa95926c9cffecc1dcaac02fb3012d1eef/cppcache/include/
>> > > geode/CqAttributes.hpp#L60
>> > >
>> > >
>> >
>>
>

Re: New client/server protocol - seeking feedback

[Jacob Barrett]

A change to a message should just be a new message, no need to version it.
Clients and severs could negotiate the messages they support or attempt the
message they support and fallback to an alternative if the server rejects
it. Consider Put and PutEx (ignore the names):
Put ( Key, Value )
PutEx (Key, Value, SomethingElse )
The client could try PutEx but if rejected by older server and
SomethingElse is not important to its operation it could try Put instead.
Alternatively the server could be queried or a list of supported message
IDs in which it could return only PutEx and the older client could make a
decision easier as to whether or not it can talk to the server.

Although one could argue these are district operation that should be
defined as independent messages anyway. Think clean OO design in your
message design. The message should have significantly change behavior
because of a single parameter otherwise it is really a new thing and should
be defined as a new message.

The short answer is that version numbers make for a nightmare of
compatibility especially when interleaving releases and maintenance
releases. Look at our current protocol and the gaps we leave in the ordinal
numbering to avoid this issue. Let's not make that same mistake.



As for interleaving requests and responses, this should be layered in the
protocol. The top layer should only deal with serial request/response. Let
a lower layer encapsulate the upper level in a multiplexed manor. The naive
layer could just open additional sockets to achieve interleaving, while an
advanced approach would create sub channels on the socket and forward to
the appropriate upper later session. All very easily achieved with Netty.
When the client connects it could negotiate if the server supports the
channel method, just like we negotiate SSL or authentication. The other
benefit to this approach is you don't have an unused field in your protocol
for clients that don't want to implement something so complex.


-Jake





On Mon, Oct 2, 2017 at 10:22 AM Michael Stolz  wrote:

> We should check that it is actually safe to add fields.
> If it isn't we're likely to have a lot of versioning to do.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Mon, Sep 25, 2017 at 5:25 PM, Galen O'Sullivan 
> wrote:
>
> > Replies inline.
> >
> > On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer 
> > wrote:
> >
> > > Replies inline
> > > On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith  wrote:
> > >
> > > > This actually brings up another point I was going to ask about. I
> don't
> > > see
> > > > any version information in the protocol. How will we handle adding
> new
> > > > features to this protocol? Do the clients and servers negotiate which
> > > > version of the protocol to use somehow?
> > > >
> > > > I think there should be a plan in place for making changes to the
> > > protocol
> > > > and supporting old clients. Given that, we shouldn't add fields that
> > > aren't
> > > > actually used into the existing version of the protocol. When we
> > > introduce
> > > > new features into the protocol, that's the point at which we should
> add
> > > the
> > > > fields to support that feature.
> > > >
> > >
> > > [UK] - Protobuf allows for the amending of messages. As soon as the
> > > protocol changes significantly the "magic" number will have to be
> > > incremented, indicating a new (non-backward compatible) version of the
> > > protocol. This of course has bigger problems, where Java does not allow
> > for
> > > multiple versions of the same class to be loaded, so a server could run
> > > only 1 version of Protobuf messages at a time.
> > >
> >
> > We have to be careful about how we extend protobuf messages, though. I'm
> > not sure exactly what's safe to do, but it should at least be safe to add
> > fields (assuming they don't change existing behavior -- we'll have to
> think
> > about this) and ignore old fields (which is how you would remove a
> > now-unused field). It's fairly simple to add new operations without any
> > interesting breakages - they'll fail with older servers and not be sent
> > with older clients. I think adding new operations is a pretty good way to
> > add features that don't require a real rework of the protocol. For those
> > that do, we can version the initial byte.
> >
>

Passed: jinmeiliao/geode#23 (3621 - c66ec97)

[Travis CI]

Build Update for jinmeiliao/geode
-

Build: #23
Status: Passed

Duration: 15 minutes and 2 seconds
Commit: c66ec97 (3621)
Author: Jinmei Liao
Message: GEODE-3621: revert the change to maintain backward compatibility

View the changeset: 
https://github.com/jinmeiliao/geode/compare/2284ea6978e5^...c66ec970bccb

View the full build log and details: 
https://travis-ci.org/jinmeiliao/geode/builds/282343147?utm_source=email&utm_medium=notification

--

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

Re: New client/server protocol - seeking feedback

[Hitesh Khamesra]

 +1
On Monday, October 2, 2017, 11:14:55 AM PDT, Jacob Barrett 
 wrote:  
 
 A change to a message should just be a new message, no need to version it.
Clients and severs could negotiate the messages they support or attempt the
message they support and fallback to an alternative if the server rejects
it. Consider Put and PutEx (ignore the names):
Put ( Key, Value )
PutEx (Key, Value, SomethingElse )
The client could try PutEx but if rejected by older server and
SomethingElse is not important to its operation it could try Put instead.
Alternatively the server could be queried or a list of supported message
IDs in which it could return only PutEx and the older client could make a
decision easier as to whether or not it can talk to the server.

Although one could argue these are district operation that should be
defined as independent messages anyway. Think clean OO design in your
message design. The message should have significantly change behavior
because of a single parameter otherwise it is really a new thing and should
be defined as a new message.

The short answer is that version numbers make for a nightmare of
compatibility especially when interleaving releases and maintenance
releases. Look at our current protocol and the gaps we leave in the ordinal
numbering to avoid this issue. Let's not make that same mistake.



As for interleaving requests and responses, this should be layered in the
protocol. The top layer should only deal with serial request/response. Let
a lower layer encapsulate the upper level in a multiplexed manor. The naive
layer could just open additional sockets to achieve interleaving, while an
advanced approach would create sub channels on the socket and forward to
the appropriate upper later session. All very easily achieved with Netty.
When the client connects it could negotiate if the server supports the
channel method, just like we negotiate SSL or authentication. The other
benefit to this approach is you don't have an unused field in your protocol
for clients that don't want to implement something so complex.


-Jake





On Mon, Oct 2, 2017 at 10:22 AM Michael Stolz  wrote:

> We should check that it is actually safe to add fields.
> If it isn't we're likely to have a lot of versioning to do.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Mon, Sep 25, 2017 at 5:25 PM, Galen O'Sullivan 
> wrote:
>
> > Replies inline.
> >
> > On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer 
> > wrote:
> >
> > > Replies inline
> > > On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith  wrote:
> > >
> > > > This actually brings up another point I was going to ask about. I
> don't
> > > see
> > > > any version information in the protocol. How will we handle adding
> new
> > > > features to this protocol? Do the clients and servers negotiate which
> > > > version of the protocol to use somehow?
> > > >
> > > > I think there should be a plan in place for making changes to the
> > > protocol
> > > > and supporting old clients. Given that, we shouldn't add fields that
> > > aren't
> > > > actually used into the existing version of the protocol. When we
> > > introduce
> > > > new features into the protocol, that's the point at which we should
> add
> > > the
> > > > fields to support that feature.
> > > >
> > >
> > > [UK] - Protobuf allows for the amending of messages. As soon as the
> > > protocol changes significantly the "magic" number will have to be
> > > incremented, indicating a new (non-backward compatible) version of the
> > > protocol. This of course has bigger problems, where Java does not allow
> > for
> > > multiple versions of the same class to be loaded, so a server could run
> > > only 1 version of Protobuf messages at a time.
> > >
> >
> > We have to be careful about how we extend protobuf messages, though. I'm
> > not sure exactly what's safe to do, but it should at least be safe to add
> > fields (assuming they don't change existing behavior -- we'll have to
> think
> > about this) and ignore old fields (which is how you would remove a
> > now-unused field). It's fairly simple to add new operations without any
> > interesting breakages - they'll fail with older servers and not be sent
> > with older clients. I think adding new operations is a pretty good way to
> > add features that don't require a real rework of the protocol. For those
> > that do, we can version the initial byte.
> >
>
  

New client protocol configuration

[Galen O'Sullivan]

Currently, we have a setting for the new client protocol that controls
whether authentication is required or not. We expect to expand this in the
future, and also that there may be more configuration options for the
protocol. We would like to namespace the settings for this protocol but
don't really have a good name for the protocol.

We're expecting to do configuration via gemfire.properties -- I hear that's
the right place to put these things. It looks like the setting would take a
form like `geode.new-client-protocol.authentication-mode`. "New" client
protocol is not a good name because it will be outdated before long. It's
not the only client protocol, so "client-protocol" would be misleading. Any
other ideas?

Thanks,
Galen

Re: New client protocol configuration

[Dan Smith]

Security configuration for this new protocol should should be done in
a way that is consistent with existing SSL related properties. See
https://geode.apache.org/docs/guide/12/managing/security/implementing_ssl.html.

In this case, maybe this new protocol should be use the same
configuration as the old protocol - ssl-enabled-components=server. I
can't really see why someone would want security for one protocol and
not the other.

-Dan

On Mon, Oct 2, 2017 at 11:56 AM, Galen O'Sullivan  wrote:
> Currently, we have a setting for the new client protocol that controls
> whether authentication is required or not. We expect to expand this in the
> future, and also that there may be more configuration options for the
> protocol. We would like to namespace the settings for this protocol but
> don't really have a good name for the protocol.
>
> We're expecting to do configuration via gemfire.properties -- I hear that's
> the right place to put these things. It looks like the setting would take a
> form like `geode.new-client-protocol.authentication-mode`. "New" client
> protocol is not a good name because it will be outdated before long. It's
> not the only client protocol, so "client-protocol" would be misleading. Any
> other ideas?
>
> Thanks,
> Galen

Re: New client protocol configuration

[Anthony Baker]

Is there a need for property yet?

The authentication-enabled question could be answered from the existing 
security properties.  That ensures consistency and means a user would only need 
to set a single switch.

If we only support a single authentication mode, we can defer adding 
configration until we need it.

Anthony

> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan  wrote:
> 
> Currently, we have a setting for the new client protocol that controls
> whether authentication is required or not. We expect to expand this in the
> future, and also that there may be more configuration options for the
> protocol. We would like to namespace the settings for this protocol but
> don't really have a good name for the protocol.
> 
> We're expecting to do configuration via gemfire.properties -- I hear that's
> the right place to put these things. It looks like the setting would take a
> form like `geode.new-client-protocol.authentication-mode`. "New" client
> protocol is not a good name because it will be outdated before long. It's
> not the only client protocol, so "client-protocol" would be misleading. Any
> other ideas?
> 
> Thanks,
> Galen

Re: New client protocol configuration

[Dan Smith]

One thing to think about - if the new protocol doesn't support two-way
authentication maybe we should throw an exception if the user sets
ssl-require-authentication=true? We definitely don't want to lie to
the user and pretend that we are providing some level of security
which we are not.

I'm assuming the new protocol will also need to read the ssl-ciphers,
ssl-protocols, ssl-keystore and ssl-truststore settings.

-Dan

On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker  wrote:
> Is there a need for property yet?
>
> The authentication-enabled question could be answered from the existing 
> security properties.  That ensures consistency and means a user would only 
> need to set a single switch.
>
> If we only support a single authentication mode, we can defer adding 
> configration until we need it.
>
> Anthony
>
>> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan  wrote:
>>
>> Currently, we have a setting for the new client protocol that controls
>> whether authentication is required or not. We expect to expand this in the
>> future, and also that there may be more configuration options for the
>> protocol. We would like to namespace the settings for this protocol but
>> don't really have a good name for the protocol.
>>
>> We're expecting to do configuration via gemfire.properties -- I hear that's
>> the right place to put these things. It looks like the setting would take a
>> form like `geode.new-client-protocol.authentication-mode`. "New" client
>> protocol is not a good name because it will be outdated before long. It's
>> not the only client protocol, so "client-protocol" would be misleading. Any
>> other ideas?
>>
>> Thanks,
>> Galen
>

Re: [DISCUSS] Using out parameters and its effects on function overload resolution

[David Kimura]

I agree. I think returning tuple flows better and seems to be the way the
language is progressing.

Also, I think it's probably even more efficient than using out variable.
Using out variable we'd pay the cost of the default constructor and then
the cost populating any state which is essentially equivalent to a copy
constructor.  While returning tuples we can let the compiler perform RVO
and the standard library perform small object optimization.

The other question though is, could function overload resolution be a valid
use case for out variables (particularly in PdxReader, for example)?

Thanks,
David

On Mon, Oct 2, 2017 at 10:56 AM, Jacob Barrett  wrote:

> Basic docs on the C++11 tuple use for multiple return types:
> http://en.cppreference.com/w/cpp/utility/tuple
>
> In C++11 we would have:
>
> std::tuple foo::getAAndB() {...}
>
> And call it with:
>
> int a;
> std::string b;
> std::tie(a, b) = foo.getAAndB();
>
> While this isn't super pretty I would argue it is more readable than.
>
> std::string b;
> auto a = foo.getAAndB(b);
>
> I believe this is unclear when reading that b is an out variable rather
> than passing empty string value to the function.
>
> And certainly easier to understand than:
> int a;
> std::string b;
> foo.getAAndB(a, b);
>
> Again, is a and be inadvertently uninitialized?
>
> Alternatively the tuple can be called like:
>
> auto r = foo.getAAndB();
> auto a = std::get<0>(r);
> auto b = std::get<1>(r);
>
>
>
>
> Another interesting blog on the issue:
> https://dzone.com/articles/returning-multiple-values-from-functions-in-c
>
> -Jake
>
>
> On Mon, Oct 2, 2017 at 9:07 AM Jacob Barrett  wrote:
>
> > We are already in contention with our style guide on many items. I
> suggest
> > we use it as a guideline only and establish our own rules. The more
> > research into the Google C++ guide is really driven by legacy C/C++
> issues
> > at Google.
> >
> > Regarding the in/out issue I am for multiple return types so that we
> > migrate to a more functional programming style. An interesting article I
> > read last week on this issue sheds some good light on why,
> > https://www.fluentcpp.com/2016/11/22/make-your-functions-functional/.
> >
> > As a bonus, once we go C++17 (in 2020ish I am sure) we can use auto
> > structured return values.
> > auto [a, b] = foo.getAAndB();
> >
> > -Jake
> >
> >
> > On Wed, Sep 27, 2017 at 1:14 PM David Kimura  wrote:
> >
> >> I forgot to mention, and it's probably worth noting, that passing
> >> non-const
> >> ref knowingly defies our style-guide.
> >>
> >> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
> >>
> >> Thanks,
> >> David
> >>
> >> On Wed, Sep 27, 2017 at 12:32 PM, Ernest Burghardt <
> eburgha...@pivotal.io
> >> >
> >> wrote:
> >>
> >> > Currently we have a mix of the counter argument...
> >> >
> >> > we use return values and you have to call the explicitly named
> methods:
> >> > double* readDoubleArray(const char* fieldName, int32_t& length)
> >> > int64_t* readLongArray(const char* fieldName, int32_t& length)
> >> >
> >> > I'm good with non-const refs in-out to the specific method calls OR
> >> > overload readArray and different return values...
> >> >
> >> > EB
> >> >
> >> > On Wed, Sep 27, 2017 at 1:27 PM, Michael William Dodge <
> >> mdo...@pivotal.io>
> >> > wrote:
> >> >
> >> > > I like the idea of using non-const references for in-out parameters
> >> only
> >> > > and using tuples for the cases where there are multiple out
> >> parameters.
> >> > > Yes, the return type does not participate in overload resolution
> but I
> >> > > don't think there would be many cases where that would be an issue.
> >> (But
> >> > I
> >> > > haven't done any research so that's just a WAG.)
> >> > >
> >> > > Sarge
> >> > >
> >> > > > On 27 Sep, 2017, at 12:22, David Kimura 
> wrote:
> >> > > >
> >> > > > Is there a use case in our C++ client code to ever use out
> >> parameters?
> >> > > >
> >> > > > Currently code uses out parameters to return multiple values from
> a
> >> > > > function.  [1]
> >> > > >
> >> > > > virtual int64_t* PdxReader::readLongArray(const char* fieldName,
> >> > int32_t&
> >> > > > length) = 0;
> >> > > >
> >> > > >
> >> > > > In this case, we could return a tuple instead.  I think the
> >> advantage
> >> > of
> >> > > > this is it doesn't force a separation between the variable
> >> declaration
> >> > > and
> >> > > > assignment, which may lead to spaghetti code.  I think avoiding
> out
> >> > > > parameters also leads to more well defined behavior.  What would
> one
> >> > > expect
> >> > > > if they called getCqListeners with an already partially populated
> >> > vector?
> >> > > > [2]
> >> > > >
> >> > > > virtual void CqAttributes::getCqListeners(
> std::vector >> > v)
> >> > > = 0;
> >> > > >
> >> > > >
> >> > > > As a counter argument, could function overload resolution be a
> valid
> >> > use
> >> > > > case of out parameters?  In PdxReader::readType methods, Type
> seems
> >> > > > redundant.  As a use

Re: New client protocol configuration

[Jacob Barrett]

Seriously? Stop with properties already. There are so many better ways to
do configuration. We already have strong APIs for setting up the server as
well as XML which nearly correlates with the API. In fact the XML and API
should be merged together better. Think spring!

For configuration of the new protocol it could just be another "connector"
for clients on the existing "server" element. All configuration related to
it as child elements/attributes of that element. XML has enforceable schema
and type safety and can be parsed directly in to domain objects with JAXB.
You can't get type safety from properties or provide a schema for
properties.

Something like this:

http://.../client-tng-1.0";  version="10.0">
  

  foo

  


-Jake

On Mon, Oct 2, 2017 at 11:56 AM Galen O'Sullivan 
wrote:

> Currently, we have a setting for the new client protocol that controls
> whether authentication is required or not. We expect to expand this in the
> future, and also that there may be more configuration options for the
> protocol. We would like to namespace the settings for this protocol but
> don't really have a good name for the protocol.
>
> We're expecting to do configuration via gemfire.properties -- I hear that's
> the right place to put these things. It looks like the setting would take a
> form like `geode.new-client-protocol.authentication-mode`. "New" client
> protocol is not a good name because it will be outdated before long. It's
> not the only client protocol, so "client-protocol" would be misleading. Any
> other ideas?
>
> Thanks,
> Galen
>

Re: New client/server protocol - seeking feedback

[Michael William Dodge]

From my days using Win32 APIs, I think fixing Foo() with FooEx() is an 
anti-pattern. But that's not to say that "version 37 fixes the parameters to 
Foo() and in no other way changes anything" is any better. I see the version as 
useful for determining the structure of the protocol, not the specifics of a 
message per se.

One of the disadvantages of using versions is that it can lead to spaghetti 
code such as cascading if statements to handle different versions of any given 
message. I worry that having the client and server negotiate which messages 
they are going to use would also be a significant addition of complexity.

Sarge

> On 2 Oct, 2017, at 11:14, Jacob Barrett  wrote:
> 
> A change to a message should just be a new message, no need to version it.
> Clients and severs could negotiate the messages they support or attempt the
> message they support and fallback to an alternative if the server rejects
> it. Consider Put and PutEx (ignore the names):
> Put ( Key, Value )
> PutEx (Key, Value, SomethingElse )
> The client could try PutEx but if rejected by older server and
> SomethingElse is not important to its operation it could try Put instead.
> Alternatively the server could be queried or a list of supported message
> IDs in which it could return only PutEx and the older client could make a
> decision easier as to whether or not it can talk to the server.
> 
> Although one could argue these are district operation that should be
> defined as independent messages anyway. Think clean OO design in your
> message design. The message should have significantly change behavior
> because of a single parameter otherwise it is really a new thing and should
> be defined as a new message.
> 
> The short answer is that version numbers make for a nightmare of
> compatibility especially when interleaving releases and maintenance
> releases. Look at our current protocol and the gaps we leave in the ordinal
> numbering to avoid this issue. Let's not make that same mistake.
> 
> 
> 
> As for interleaving requests and responses, this should be layered in the
> protocol. The top layer should only deal with serial request/response. Let
> a lower layer encapsulate the upper level in a multiplexed manor. The naive
> layer could just open additional sockets to achieve interleaving, while an
> advanced approach would create sub channels on the socket and forward to
> the appropriate upper later session. All very easily achieved with Netty.
> When the client connects it could negotiate if the server supports the
> channel method, just like we negotiate SSL or authentication. The other
> benefit to this approach is you don't have an unused field in your protocol
> for clients that don't want to implement something so complex.
> 
> 
> -Jake
> 
> 
> 
> 
> 
> On Mon, Oct 2, 2017 at 10:22 AM Michael Stolz  wrote:
> 
>> We should check that it is actually safe to add fields.
>> If it isn't we're likely to have a lot of versioning to do.
>> 
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Lead
>> Mobile: +1-631-835-4771 <(631)%20835-4771>
>> 
>> On Mon, Sep 25, 2017 at 5:25 PM, Galen O'Sullivan 
>> wrote:
>> 
>>> Replies inline.
>>> 
>>> On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer 
>>> wrote:
>>> 
 Replies inline
 On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith  wrote:
 
> This actually brings up another point I was going to ask about. I
>> don't
 see
> any version information in the protocol. How will we handle adding
>> new
> features to this protocol? Do the clients and servers negotiate which
> version of the protocol to use somehow?
> 
> I think there should be a plan in place for making changes to the
 protocol
> and supporting old clients. Given that, we shouldn't add fields that
 aren't
> actually used into the existing version of the protocol. When we
 introduce
> new features into the protocol, that's the point at which we should
>> add
 the
> fields to support that feature.
> 
 
 [UK] - Protobuf allows for the amending of messages. As soon as the
 protocol changes significantly the "magic" number will have to be
 incremented, indicating a new (non-backward compatible) version of the
 protocol. This of course has bigger problems, where Java does not allow
>>> for
 multiple versions of the same class to be loaded, so a server could run
 only 1 version of Protobuf messages at a time.
 
>>> 
>>> We have to be careful about how we extend protobuf messages, though. I'm
>>> not sure exactly what's safe to do, but it should at least be safe to add
>>> fields (assuming they don't change existing behavior -- we'll have to
>> think
>>> about this) and ignore old fields (which is how you would remove a
>>> now-unused field). It's fairly simple to add new operations without any
>>> interesting breakages - they'll fail with older servers and not be sent
>>> with older clients. I think adding new operations is a p

Re: [DISCUSS] Using out parameters and its effects on function overload resolution

[Jacob Barrett]

On Mon, Oct 2, 2017 at 12:19 PM David Kimura  wrote:

> The other question though is, could function overload resolution be a valid
> use case for out variables (particularly in PdxReader, for example)?


I am against exceptions to rules unless the exception is more readable. In
this case I don't think the exception to our rule, of using return values
only and no out params, gains anything for single return types that differ.

auto i = input.readInt();
auto b = input.readByte();

Is more expressive and readable than:

int i;
input.read(i);
char b;
input.readByte(b);

Templates could solve the problem, but I am not sure it is more expressive
or easier to read:

auto i = input.read();
auto b = input.read();


It also runs into issues of ballooning specializations for each of the C++
types. See: http://coliru.stacked-crooked.com/a/33ca43ee0ed59a7f


I think in this case since the serializer is dealing with our "GemFire
Types" which just happen to be Java types then we should be descriptive in
those terms therefor readInt, readLong, readShort, etc. wins in my book.

-Jake

Re: New client protocol configuration

[John Blum]

I don't mean to derail the topic at hand, but...

On the same vain as Properties, can we also stop talking about XML?  I much
prefer Properties over XML any day, especially given YAML.  However, that
does not imply Properties should be added at will.  Properties also
increase the "surface area" of the public API as well.

Also, the API and XML are not on even plane; not even close.

IMO, the API should be the primary means to configure a feature; all other
configuration options are secondary and optional (as needed).

Therefore, given an API-first approach, the other configuration formats and
options become more apparent (providing the API was designed with the right
abstractions in the first place).

$.0.02,
-j



On Mon, Oct 2, 2017 at 12:18 PM, Dan Smith  wrote:

> One thing to think about - if the new protocol doesn't support two-way
> authentication maybe we should throw an exception if the user sets
> ssl-require-authentication=true? We definitely don't want to lie to
> the user and pretend that we are providing some level of security
> which we are not.
>
> I'm assuming the new protocol will also need to read the ssl-ciphers,
> ssl-protocols, ssl-keystore and ssl-truststore settings.
>
> -Dan
>
> On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker  wrote:
> > Is there a need for property yet?
> >
> > The authentication-enabled question could be answered from the existing
> security properties.  That ensures consistency and means a user would only
> need to set a single switch.
> >
> > If we only support a single authentication mode, we can defer adding
> configration until we need it.
> >
> > Anthony
> >
> >> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan 
> wrote:
> >>
> >> Currently, we have a setting for the new client protocol that controls
> >> whether authentication is required or not. We expect to expand this in
> the
> >> future, and also that there may be more configuration options for the
> >> protocol. We would like to namespace the settings for this protocol but
> >> don't really have a good name for the protocol.
> >>
> >> We're expecting to do configuration via gemfire.properties -- I hear
> that's
> >> the right place to put these things. It looks like the setting would
> take a
> >> form like `geode.new-client-protocol.authentication-mode`. "New" client
> >> protocol is not a good name because it will be outdated before long.
> It's
> >> not the only client protocol, so "client-protocol" would be misleading.
> Any
> >> other ideas?
> >>
> >> Thanks,
> >> Galen
> >
>



-- 
-John
john.blum10101 (skype)

Passed: apache/geode#4072 (GEODE-3715-javadocs - e228a48)

[Travis CI]

Build Update for apache/geode
-

Build: #4072
Status: Passed

Duration: 19 minutes and 25 seconds
Commit: e228a48 (GEODE-3715-javadocs)
Author: Kirk Lund
Message: GEODE-3715: improve javadocs of DistributedTest rules

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

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/282389032?utm_source=email&utm_medium=notification

--

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

Re: New client protocol configuration

[Jacob Barrett]

Yes to API first, config file second! Config file should reflect the API
and domain objects.


But... How can you even begin go argue properties over XML? Configuration
should be well structured and expressive. Properties is neither.

Properties can't handle collections of things without some serious ugliness.
server.connectors.0.name = "my connector"
server.connectors.0.port = "1234"
server.connectors.0.someConfig = "true"
server.connectors.1.name = "my connector"
server.connectors.1.port = "1234"
server.connectors.1.someConfig = "true"

This isn't at all well structured or even that readable.

Doesn't have built in support for duplicate protection:
somthing.name = "my name"

something.name = "OOPS"

No type safety:
my.timeout = "yes please"

If I am configuring with XML and a schema my editor will warn me about such
mistakes before I hit the runtime. None of the other mentioned formats can
do that.

In the list of configuration file formats properties falls nowhere on that
list.
XML takes the cake because of the type safety from schema support.
YAML lacks type safety and schema but can at least express collections.
JSON ugly syntax, lacks type safety and schema, but supports collections.

Sure XML has its shortcomings but I would love to hear why properties is
better in your opinion.

2

-Jake



On Mon, Oct 2, 2017 at 12:57 PM John Blum  wrote:

> I don't mean to derail the topic at hand, but...
>
> On the same vain as Properties, can we also stop talking about XML?  I much
> prefer Properties over XML any day, especially given YAML.  However, that
> does not imply Properties should be added at will.  Properties also
> increase the "surface area" of the public API as well.
>
> Also, the API and XML are not on even plane; not even close.
>
> IMO, the API should be the primary means to configure a feature; all other
> configuration options are secondary and optional (as needed).
>
> Therefore, given an API-first approach, the other configuration formats and
> options become more apparent (providing the API was designed with the right
> abstractions in the first place).
>
> $.0.02,
> -j
>
>
>
> On Mon, Oct 2, 2017 at 12:18 PM, Dan Smith  wrote:
>
> > One thing to think about - if the new protocol doesn't support two-way
> > authentication maybe we should throw an exception if the user sets
> > ssl-require-authentication=true? We definitely don't want to lie to
> > the user and pretend that we are providing some level of security
> > which we are not.
> >
> > I'm assuming the new protocol will also need to read the ssl-ciphers,
> > ssl-protocols, ssl-keystore and ssl-truststore settings.
> >
> > -Dan
> >
> > On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker 
> wrote:
> > > Is there a need for property yet?
> > >
> > > The authentication-enabled question could be answered from the existing
> > security properties.  That ensures consistency and means a user would
> only
> > need to set a single switch.
> > >
> > > If we only support a single authentication mode, we can defer adding
> > configration until we need it.
> > >
> > > Anthony
> > >
> > >> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan 
> > wrote:
> > >>
> > >> Currently, we have a setting for the new client protocol that controls
> > >> whether authentication is required or not. We expect to expand this in
> > the
> > >> future, and also that there may be more configuration options for the
> > >> protocol. We would like to namespace the settings for this protocol
> but
> > >> don't really have a good name for the protocol.
> > >>
> > >> We're expecting to do configuration via gemfire.properties -- I hear
> > that's
> > >> the right place to put these things. It looks like the setting would
> > take a
> > >> form like `geode.new-client-protocol.authentication-mode`. "New"
> client
> > >> protocol is not a good name because it will be outdated before long.
> > It's
> > >> not the only client protocol, so "client-protocol" would be
> misleading.
> > Any
> > >> other ideas?
> > >>
> > >> Thanks,
> > >> Galen
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

Re: New client/server protocol - seeking feedback

[Udo Kohlmeyer]

+1 to what Jake said. Our approach is exactly what your preference is. The
adding of messages would new operations and variations on the operation.
PUT will be different to PUT_WITH_CALLBACK. Even in the backend the
processing of the messages will be handled by a different
operationsHandlers.

With the addition of the HANDSHAKE message GEODE-3705
 we hope to be able to
negotiate supported versions and functionality up-front, before processing
any operational messages.

In addition to that, major version changes will only be introduced with
non-backwards compatible changes to the message structure. How to multiplex
the different major version messages is still up for design and
implementation though.

--Udo

On Mon, Oct 2, 2017 at 12:37 PM, Michael William Dodge 
wrote:

> From my days using Win32 APIs, I think fixing Foo() with FooEx() is an
> anti-pattern. But that's not to say that "version 37 fixes the parameters
> to Foo() and in no other way changes anything" is any better. I see the
> version as useful for determining the structure of the protocol, not the
> specifics of a message per se.
>
> One of the disadvantages of using versions is that it can lead to
> spaghetti code such as cascading if statements to handle different versions
> of any given message. I worry that having the client and server negotiate
> which messages they are going to use would also be a significant addition
> of complexity.
>
> Sarge
>
> > On 2 Oct, 2017, at 11:14, Jacob Barrett  wrote:
> >
> > A change to a message should just be a new message, no need to version
> it.
> > Clients and severs could negotiate the messages they support or attempt
> the
> > message they support and fallback to an alternative if the server rejects
> > it. Consider Put and PutEx (ignore the names):
> > Put ( Key, Value )
> > PutEx (Key, Value, SomethingElse )
> > The client could try PutEx but if rejected by older server and
> > SomethingElse is not important to its operation it could try Put instead.
> > Alternatively the server could be queried or a list of supported message
> > IDs in which it could return only PutEx and the older client could make a
> > decision easier as to whether or not it can talk to the server.
> >
> > Although one could argue these are district operation that should be
> > defined as independent messages anyway. Think clean OO design in your
> > message design. The message should have significantly change behavior
> > because of a single parameter otherwise it is really a new thing and
> should
> > be defined as a new message.
> >
> > The short answer is that version numbers make for a nightmare of
> > compatibility especially when interleaving releases and maintenance
> > releases. Look at our current protocol and the gaps we leave in the
> ordinal
> > numbering to avoid this issue. Let's not make that same mistake.
> >
> >
> >
> > As for interleaving requests and responses, this should be layered in the
> > protocol. The top layer should only deal with serial request/response.
> Let
> > a lower layer encapsulate the upper level in a multiplexed manor. The
> naive
> > layer could just open additional sockets to achieve interleaving, while
> an
> > advanced approach would create sub channels on the socket and forward to
> > the appropriate upper later session. All very easily achieved with Netty.
> > When the client connects it could negotiate if the server supports the
> > channel method, just like we negotiate SSL or authentication. The other
> > benefit to this approach is you don't have an unused field in your
> protocol
> > for clients that don't want to implement something so complex.
> >
> >
> > -Jake
> >
> >
> >
> >
> >
> > On Mon, Oct 2, 2017 at 10:22 AM Michael Stolz  wrote:
> >
> >> We should check that it is actually safe to add fields.
> >> If it isn't we're likely to have a lot of versioning to do.
> >>
> >> --
> >> Mike Stolz
> >> Principal Engineer, GemFire Product Lead
> >> Mobile: +1-631-835-4771 <(631)%20835-4771>
> >>
> >> On Mon, Sep 25, 2017 at 5:25 PM, Galen O'Sullivan <
> gosulli...@pivotal.io>
> >> wrote:
> >>
> >>> Replies inline.
> >>>
> >>> On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer  >
> >>> wrote:
> >>>
>  Replies inline
>  On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith 
> wrote:
> 
> > This actually brings up another point I was going to ask about. I
> >> don't
>  see
> > any version information in the protocol. How will we handle adding
> >> new
> > features to this protocol? Do the clients and servers negotiate which
> > version of the protocol to use somehow?
> >
> > I think there should be a plan in place for making changes to the
>  protocol
> > and supporting old clients. Given that, we shouldn't add fields that
>  aren't
> > actually used into the existing version of the protocol. When we
>  introduce
> > new features into the protocol, that's the point at which we shou

Re: New client protocol configuration

[Dan Smith]

I realized I've been assuming you were asking about turning on ssl
authentication. Maybe you are talking about authenticating with the
security manager. Either way, what Anthony said still applies - the
new protocol should just use the existing properties (security-manager
in that case).

-Dan

On Mon, Oct 2, 2017 at 12:57 PM, John Blum  wrote:
> I don't mean to derail the topic at hand, but...
>
> On the same vain as Properties, can we also stop talking about XML?  I much
> prefer Properties over XML any day, especially given YAML.  However, that
> does not imply Properties should be added at will.  Properties also
> increase the "surface area" of the public API as well.
>
> Also, the API and XML are not on even plane; not even close.
>
> IMO, the API should be the primary means to configure a feature; all other
> configuration options are secondary and optional (as needed).
>
> Therefore, given an API-first approach, the other configuration formats and
> options become more apparent (providing the API was designed with the right
> abstractions in the first place).
>
> $.0.02,
> -j
>
>
>
> On Mon, Oct 2, 2017 at 12:18 PM, Dan Smith  wrote:
>
>> One thing to think about - if the new protocol doesn't support two-way
>> authentication maybe we should throw an exception if the user sets
>> ssl-require-authentication=true? We definitely don't want to lie to
>> the user and pretend that we are providing some level of security
>> which we are not.
>>
>> I'm assuming the new protocol will also need to read the ssl-ciphers,
>> ssl-protocols, ssl-keystore and ssl-truststore settings.
>>
>> -Dan
>>
>> On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker  wrote:
>> > Is there a need for property yet?
>> >
>> > The authentication-enabled question could be answered from the existing
>> security properties.  That ensures consistency and means a user would only
>> need to set a single switch.
>> >
>> > If we only support a single authentication mode, we can defer adding
>> configration until we need it.
>> >
>> > Anthony
>> >
>> >> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan 
>> wrote:
>> >>
>> >> Currently, we have a setting for the new client protocol that controls
>> >> whether authentication is required or not. We expect to expand this in
>> the
>> >> future, and also that there may be more configuration options for the
>> >> protocol. We would like to namespace the settings for this protocol but
>> >> don't really have a good name for the protocol.
>> >>
>> >> We're expecting to do configuration via gemfire.properties -- I hear
>> that's
>> >> the right place to put these things. It looks like the setting would
>> take a
>> >> form like `geode.new-client-protocol.authentication-mode`. "New" client
>> >> protocol is not a good name because it will be outdated before long.
>> It's
>> >> not the only client protocol, so "client-protocol" would be misleading.
>> Any
>> >> other ideas?
>> >>
>> >> Thanks,
>> >> Galen
>> >
>>
>
>
>
> --
> -John
> john.blum10101 (skype)

Re: New client protocol configuration

[Swapnil Bawaskar]

As a geode admin setting up the cluster with security, I don't want to
worry about what version of protocol the client is going to use.
+1 for the new protocol to just use existing properties.

On Mon, Oct 2, 2017 at 1:24 PM Dan Smith  wrote:

> I realized I've been assuming you were asking about turning on ssl
> authentication. Maybe you are talking about authenticating with the
> security manager. Either way, what Anthony said still applies - the
> new protocol should just use the existing properties (security-manager
> in that case).
>
> -Dan
>
> On Mon, Oct 2, 2017 at 12:57 PM, John Blum  wrote:
> > I don't mean to derail the topic at hand, but...
> >
> > On the same vain as Properties, can we also stop talking about XML?  I
> much
> > prefer Properties over XML any day, especially given YAML.  However, that
> > does not imply Properties should be added at will.  Properties also
> > increase the "surface area" of the public API as well.
> >
> > Also, the API and XML are not on even plane; not even close.
> >
> > IMO, the API should be the primary means to configure a feature; all
> other
> > configuration options are secondary and optional (as needed).
> >
> > Therefore, given an API-first approach, the other configuration formats
> and
> > options become more apparent (providing the API was designed with the
> right
> > abstractions in the first place).
> >
> > $.0.02,
> > -j
> >
> >
> >
> > On Mon, Oct 2, 2017 at 12:18 PM, Dan Smith  wrote:
> >
> >> One thing to think about - if the new protocol doesn't support two-way
> >> authentication maybe we should throw an exception if the user sets
> >> ssl-require-authentication=true? We definitely don't want to lie to
> >> the user and pretend that we are providing some level of security
> >> which we are not.
> >>
> >> I'm assuming the new protocol will also need to read the ssl-ciphers,
> >> ssl-protocols, ssl-keystore and ssl-truststore settings.
> >>
> >> -Dan
> >>
> >> On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker 
> wrote:
> >> > Is there a need for property yet?
> >> >
> >> > The authentication-enabled question could be answered from the
> existing
> >> security properties.  That ensures consistency and means a user would
> only
> >> need to set a single switch.
> >> >
> >> > If we only support a single authentication mode, we can defer adding
> >> configration until we need it.
> >> >
> >> > Anthony
> >> >
> >> >> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan  >
> >> wrote:
> >> >>
> >> >> Currently, we have a setting for the new client protocol that
> controls
> >> >> whether authentication is required or not. We expect to expand this
> in
> >> the
> >> >> future, and also that there may be more configuration options for the
> >> >> protocol. We would like to namespace the settings for this protocol
> but
> >> >> don't really have a good name for the protocol.
> >> >>
> >> >> We're expecting to do configuration via gemfire.properties -- I hear
> >> that's
> >> >> the right place to put these things. It looks like the setting would
> >> take a
> >> >> form like `geode.new-client-protocol.authentication-mode`. "New"
> client
> >> >> protocol is not a good name because it will be outdated before long.
> >> It's
> >> >> not the only client protocol, so "client-protocol" would be
> misleading.
> >> Any
> >> >> other ideas?
> >> >>
> >> >> Thanks,
> >> >> Galen
> >> >
> >>
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
>

Re: New client protocol configuration

[John Blum]

*Properties* are simple (think *Spring Boot; *there is no better example);

YAML provides structure (with IDE support);

*Type-Safety* is the responsibility of the framework/API (think the
configuration format really should not matter, but data-binding/conversion
is always a concern regardless of the configuration format, like
validation, which should not be expressed/enforced with in the XSD, and
simply cannot be enforced when property placeholders are supported (a very
useful and powerful configuration option) in XML since the type would
necessarily be constrained to xsd:string in that case).

Again, I emphasis that adding Properties should be done with care as it
increases the "surface area" and complexity of any public API (yes,
configuration Properties are part of the public API).  Properties are also
only suitable for simple configuration attributes (like a port).

When complex configuration is needed, there is not better option than
providing adequate API support with right abstractions, hence 1 of the
reasons *Spring* is moving away from XML (which can get overly verbose) to
Java config.

-j



On Mon, Oct 2, 2017 at 1:36 PM, Swapnil Bawaskar 
wrote:

> As a geode admin setting up the cluster with security, I don't want to
> worry about what version of protocol the client is going to use.
> +1 for the new protocol to just use existing properties.
>
> On Mon, Oct 2, 2017 at 1:24 PM Dan Smith  wrote:
>
> > I realized I've been assuming you were asking about turning on ssl
> > authentication. Maybe you are talking about authenticating with the
> > security manager. Either way, what Anthony said still applies - the
> > new protocol should just use the existing properties (security-manager
> > in that case).
> >
> > -Dan
> >
> > On Mon, Oct 2, 2017 at 12:57 PM, John Blum  wrote:
> > > I don't mean to derail the topic at hand, but...
> > >
> > > On the same vain as Properties, can we also stop talking about XML?  I
> > much
> > > prefer Properties over XML any day, especially given YAML.  However,
> that
> > > does not imply Properties should be added at will.  Properties also
> > > increase the "surface area" of the public API as well.
> > >
> > > Also, the API and XML are not on even plane; not even close.
> > >
> > > IMO, the API should be the primary means to configure a feature; all
> > other
> > > configuration options are secondary and optional (as needed).
> > >
> > > Therefore, given an API-first approach, the other configuration formats
> > and
> > > options become more apparent (providing the API was designed with the
> > right
> > > abstractions in the first place).
> > >
> > > $.0.02,
> > > -j
> > >
> > >
> > >
> > > On Mon, Oct 2, 2017 at 12:18 PM, Dan Smith  wrote:
> > >
> > >> One thing to think about - if the new protocol doesn't support two-way
> > >> authentication maybe we should throw an exception if the user sets
> > >> ssl-require-authentication=true? We definitely don't want to lie to
> > >> the user and pretend that we are providing some level of security
> > >> which we are not.
> > >>
> > >> I'm assuming the new protocol will also need to read the ssl-ciphers,
> > >> ssl-protocols, ssl-keystore and ssl-truststore settings.
> > >>
> > >> -Dan
> > >>
> > >> On Mon, Oct 2, 2017 at 12:08 PM, Anthony Baker 
> > wrote:
> > >> > Is there a need for property yet?
> > >> >
> > >> > The authentication-enabled question could be answered from the
> > existing
> > >> security properties.  That ensures consistency and means a user would
> > only
> > >> need to set a single switch.
> > >> >
> > >> > If we only support a single authentication mode, we can defer adding
> > >> configration until we need it.
> > >> >
> > >> > Anthony
> > >> >
> > >> >> On Oct 2, 2017, at 11:56 AM, Galen O'Sullivan <
> gosulli...@apache.org
> > >
> > >> wrote:
> > >> >>
> > >> >> Currently, we have a setting for the new client protocol that
> > controls
> > >> >> whether authentication is required or not. We expect to expand this
> > in
> > >> the
> > >> >> future, and also that there may be more configuration options for
> the
> > >> >> protocol. We would like to namespace the settings for this protocol
> > but
> > >> >> don't really have a good name for the protocol.
> > >> >>
> > >> >> We're expecting to do configuration via gemfire.properties -- I
> hear
> > >> that's
> > >> >> the right place to put these things. It looks like the setting
> would
> > >> take a
> > >> >> form like `geode.new-client-protocol.authentication-mode`. "New"
> > client
> > >> >> protocol is not a good name because it will be outdated before
> long.
> > >> It's
> > >> >> not the only client protocol, so "client-protocol" would be
> > misleading.
> > >> Any
> > >> >> other ideas?
> > >> >>
> > >> >> Thanks,
> > >> >> Galen
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> >
>



-- 
-John
john.blum10101 (skype)

Re: New client/server protocol - seeking feedback

[Jacob Barrett]

On Mon, Oct 2, 2017 at 12:37 PM Michael William Dodge 
wrote:

> From my days using Win32 APIs, I think fixing Foo() with FooEx() is an
> anti-pattern. But that's not to say that "version 37 fixes the parameters
> to Foo() and in no other way changes anything" is any better. I see the
> version as useful for determining the structure of the protocol, not the
> specifics of a message per se.
>

I was hoping someone would catch the Win32 reference there and exactly why
I said ignore the names. The point is that two messages that different in
content are in fact two distinct messages with very very very minor
exceptions.

One of the disadvantages of using versions is that it can lead to spaghetti
> code such as cascading if statements to handle different versions of any
> given message. I worry that having the client and server negotiate which
> messages they are going to use would also be a significant addition of
> complexity.
>

Look at our current code... If version 65, do this, if 72, do this, if 80
do that... It is a mess.

-Jake

Geode configuration (was: New client protocol configuration)

[Dan Smith]

Let's move this discussion about the best way to configure geode off of
this thread about the client protocol.

I do agree with John that we should move away from xml. Right now if I add
a new configuration option I have to:

 - add it to the java API
 - Add it to the xsd
 - write code to do xml parsing and generation
 - write code for a gfsh command
 - write code to update cluster configuration

This turns what should be a 5 minute task into 5 days. How can we get to
the point where we just define a new configuration option in one place?

-Dan


*Properties* are simple (think *Spring Boot; *there is no better example);
>
> YAML provides structure (with IDE support);
>
> *Type-Safety* is the responsibility of the framework/API (think the
> configuration format really should not matter, but data-binding/conversion
> is always a concern regardless of the configuration format, like
> validation, which should not be expressed/enforced with in the XSD, and
> simply cannot be enforced when property placeholders are supported (a very
> useful and powerful configuration option) in XML since the type would
> necessarily be constrained to xsd:string in that case).
>
> Again, I emphasis that adding Properties should be done with care as it
> increases the "surface area" and complexity of any public API (yes,
> configuration Properties are part of the public API).  Properties are also
> only suitable for simple configuration attributes (like a port).
>
> When complex configuration is needed, there is not better option than
> providing adequate API support with right abstractions, hence 1 of the
> reasons *Spring* is moving away from XML (which can get overly verbose) to
> Java config.
>
> -j

Re: New client/server protocol - seeking feedback

[Jacob Barrett]

On Mon, Oct 2, 2017 at 1:19 PM Udo Kohlmeyer  wrote:

> How to multiplex
> the different major version messages is still up for design and
> implementation though.
>
>
Than I think to Dan's question the correlation ID should go away now until
a design is determined. Adding it because we had it before doesn't make
sense if we are considering different approaches to multiplexing.

-Jake

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #697 was SUCCESSFUL (with 2182 tests). Change made by Mark Paluch.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #697 was successful.
---
Scheduled with changes by Mark Paluch.
2184 tests in total.

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




--
Code Changes
--
Mark Paluch (32322a35d3ff4903bfc51464b631c8c7ca8b39ee):

>DATAGEODE-39 - Prepare next development iteration.

Mark Paluch (bd51bdeba019f0dc17a0db198b7a13e94ab1a84c):

>DATAGEODE-39 - Release version 2.0 GA (Kay).

Mark Paluch (424f562f72c125c4c8d767db6d37e4047f8eb78f):

>DATAGEODE-39 - Prepare 2.0 GA (Kay).



--
This message is automatically generated by Atlassian Bamboo

Passed: apache/geode#4081 (revert-799-feature/GEODE-3647 - d383382)

[Travis CI]

Build Update for apache/geode
-

Build: #4081
Status: Passed

Duration: 10 minutes and 59 seconds
Commit: d383382 (revert-799-feature/GEODE-3647)
Author: Darrel Schneider
Message: Revert "GEODE-3647: Fix race condition"

This reverts commit 96149530d82e0b62e9df1a043bfd7d0e01d3411a.

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

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/282433007?utm_source=email&utm_medium=notification

--

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

Fixed: apache/geode#4083 (develop - 5cb2a59)

[Travis CI]

Build Update for apache/geode
-

Build: #4083
Status: Fixed

Duration: 12 minutes and 18 seconds
Commit: 5cb2a59 (develop)
Author: Darrel Schneider
Message: Revert "GEODE-3647: Fix race condition"

This reverts commit 96149530d82e0b62e9df1a043bfd7d0e01d3411a.

View the changeset: 
https://github.com/apache/geode/compare/96149530d82e...5cb2a5911998

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/282433539?utm_source=email&utm_medium=notification

--

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

Broken: apache/geode#4080 (develop - 9614953)

[Travis CI]

Build Update for apache/geode
-

Build: #4080
Status: Broken

Duration: 6 minutes and 57 seconds
Commit: 9614953 (develop)
Author: Nick Reich
Message: GEODE-3647: Fix race condition

  Partitioned region attributes mutation can fail to be applied to
  buckets created concurrently. Preventing bucket creation during the
  mutation of attributes solves this issue.

View the changeset: 
https://github.com/apache/geode/compare/75c8a74b7a97...96149530d82e

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/282427687?utm_source=email&utm_medium=notification

--

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