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

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

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

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

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

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.

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

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

Re: New client/server protocol - seeking feedback

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

Geode configuration (was: New client protocol configuration)

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

Re: New client/server protocol - seeking feedback

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

Re: New client protocol configuration

*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

Re: New client protocol configuration

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

Re: New client protocol configuration

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

Re: New client/server protocol - seeking feedback

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

Re: New client protocol configuration

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

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

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:

Re: New client protocol configuration

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

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

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.

Re: New client/server protocol - seeking feedback

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

Re: New client protocol configuration

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

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

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

Re: New client protocol configuration

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

Re: New client protocol configuration

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

New client protocol configuration

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

Re: New client/server protocol - seeking feedback

+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

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

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:

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

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

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

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

Re: 1.3.0 release

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

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

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

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

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

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

+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

Build failed in Jenkins: Geode-nightly #972

See -- [...truncated 1.33 MB...] at org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:330) at