Re: Starter tickets

[Brian Baynes]

+1  on starter/starter++

It will be nice to already have a group of possibilities to point folks to.


On Mar 2, 2018 2:26 PM, "Kirk Lund"  wrote:

+1 for using starter and starter++

On Fri, Mar 2, 2018 at 1:45 PM, Joey McAllister 
wrote:

> +1 to "starter" over "newbie." I think the ++ plan makes sense, too.
>
> Thanks for the initiative on this, Alexander. It seems like a very
valuable
> effort for the community.
>
> On Fri, Mar 2, 2018 at 1:35 PM Alexander Murmann 
> wrote:
>
> > I am glad this already revealed that we aren't consistent in what labels
> we
> > are using. I assume the idea of newbie++ was to facilitate a
> progression? I
> > really like that and would love to keep something like that.
> >
> > I don't think the term "newbie" is great. To me it has a little bit of a
> > negative connotation.
> >
> > Does anyone have an issue with adopting "starter" and "starter++"
> > consistently? I am happy to do the conversion work and make sure the
> > communication in the wiki etc. is consistent going forward.
> >
> > Mike, I agree that there is probably a lot of great work that someone
who
> > doesn't know the code base well can do in Pulse. I'd suggest that we
> still
> > decide on a case by case basis. A quick glance showed a few bugs that
> > probably should be tackled sooner rather than later. I'll take a pass at
> > all Pulse related tickets and see if they are a good fit.
> >
> > On Fri, Mar 2, 2018 at 10:45 AM, Michael Stolz 
> wrote:
> >
> > > I'd love to tag all the pulse issues as newbie if we could.
> > >
> > >
> > >
> > > On Fri, Mar 2, 2018 at 1:34 PM, Anthony Baker 
> wrote:
> > >
> > > > Good idea!  We he have a few other labels relevant to this as well:
> > > >
> > > > - newbie
> > > > - low-hanging-fruit
> > > >
> > > > Anthony
> > > >
> > > >
> > > > > On Mar 2, 2018, at 10:03 AM, Alexander Murmann <
> amurm...@pivotal.io>
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I think we could make it easier for people to find tasks that can
> be
> > > > their
> > > > > first contribution to Geode. The wiki page on how to contribute
> > > > >  to+Contribute
> > >
> > > > has a
> > > > > list of suggested projects. Most of those are pretty ambitious and
> > > likely
> > > > > would be overwhelming to first time contributors. There also is a
> > link
> > > > > to tickets
> > > > > labeled with "Starter"
> > > > >  > > > 3D%20Geode%20AND%20labels%20%3D%20starter%20AND%20status%
> > > > 20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29>.
> > > > > I think the later is probably a much better angle for someone to
> > start
> > > > > contributing to Geode. Unfortunately there was less than a handful
> of
> > > > > tickets labeled as starter tickets.
> > > > >
> > > > > My suggestion is to find tickets that strike a healthy balance
> > between
> > > > being
> > > > >
> > > > >   - simple enough that someone new to the code base can
> realistically
> > > > take
> > > > >   them on
> > > > >   - rewarding enough that someone can feel a sense of
> accomplishment
> > > > after
> > > > >   having their PR merged
> > > > >   - small enough that it can be accomplished in an evening or at
> > most a
> > > > >   long weekend
> > > > >   - unlikely to result in conflicts with larger efforts that
> someone
> > is
> > > > >   already undertaking
> > > > >
> > > > > It would be great to have a variety of tickets that have different
> > > levels
> > > > > of complexity and required effort to allow new contributors of
> > varying
> > > > > experience levels to start contributing meaningfully and maybe
even
> > > > support
> > > > > somewhat of a progression curve for someone who wants to become a
> > > regular
> > > > > contributor or even committer.
> > > > >
> > > > > I'd also suggest to not allow the list to grow too large. If the
> list
> > > > gets
> > > > > bigger than 20-30 tickets it might get too hard to keep a clear
> grasp
> > > on
> > > > it
> > > > > and the risk of having tickets that aren't relevant anymore
> > increases.
> > > > > Nothing would be more frustrating to a new contributor than
> investing
> > > > their
> > > > > personal time just to find out that it was wasted. So let's be
> > mindful
> > > of
> > > > > not using this as a dumping ground for everything we'd like to
see,
> > but
> > > > > know we'll never get to.
> > > > >
> > > > > I already labeled a few more tickets as starter. Please feel free
> to
> > > > > validate that I didn't violate my own suggestions in doing so.
> > > > >
> > > > > Thoughts?
> > > >
> > > >
> > >
> >
>

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=GEODE=planning=
> GEODE-2788=visible=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: New client/server protocol - seeking feedback

[Brian Baynes]

Thanks for your thoughts, Dan.  Some additional info, taking your items #
by #:

1) correlationID was put in with the thought that we could support
out-of-order messages in a future version.  You have any input on that plan?

2) Create/destroy region will be added after GA v1.0, so these messages
should be removed before GA.

3) Idea has been that GetRegion would provide limited metadata on a region,
similar to what the REST API does.  Do see your point on "data policy" and
"persistent" being redundant.

4) This could go either way -- we've gone with ease-of-use for clients,
thinking it's not worth the added complexity for a potentially small
over-the-wire savings. Would be interested in a good/strong argument for
the other approach.

Finally, we'll be working on a "how to implement a client" document soon,
including the details you mention.  We'd also like to have a simple client
implemented in Go to go along with the "how-to".


-Brian

On Thu, Sep 21, 2017 at 10:48 AM, Dan Smith <dsm...@pivotal.io> wrote:

> I'm curious about few things I see in the .proto files.
>
> 1) I see there is a correlationId in the MessageHeader definition. What is
> that used for? I remember we had a discussion a while back where I thought
> we had decided that might not be not necessary?
>
> 2) I also see a CreateRegionRequest and DestroyRegionRequest in the .proto
> files. Are those actually going to be part of the 1.0 GA? Should these be
> removed?
>
> 3) The GetRegion command seems like it is returning either too much
> information or to little. It returns some of the attributes of the region,
> like data policy, scope, whether it's persistent (duplicate of data
> policy?). What is this command for, and should it really be returning this
> information which seems irrelevant to the client?
>
> 4) For GetAll, PutAll, the old client server protocol did not return the
> keys in the response, it just sent back the results in the same order as
> the request. This saves some data on the wire. I"m not sure if it's worth
> complexity for this new protocol or not.
>
> Looking forward to seeing some more information about how to actually use
> these messages to communicate with a server - IE what type of connection
> should I create, how SSL works, how authentication works, etc.
>
> -Dan
>
> On Fri, Sep 15, 2017 at 5:50 PM, Brian Baynes <bbay...@pivotal.io> wrote:
>
> > You can find them in the code, but we'll be providing better
> documentation
> > on the messages shortly. The proto files have the message definitions and
> > they're pretty straightforward, but we'll have a more user-friendly
> > write-up soon.
> >
> >
> > On Sep 15, 2017 5:27 PM, "Dan Smith" <dsm...@pivotal.io> wrote:
> >
> > What's the best place to look for more details on the specific protocol
> for
> > the v1.0 messages? The other pages on https://cwiki.apache.org/
> > confluence/display/GEODE/New+Client+Server+Protocol? Or directly in the
> > code somewhere?
> >
> > -Dan
> >
> > On Fri, Sep 15, 2017 at 11:15 AM, Brian Baynes <bbay...@pivotal.io>
> wrote:
> >
> > > Greetings, friends of Geode.
> > >
> > > Work has been progressing on the new client/server protocol for Geode
> and
> > > we're approaching a GA v1.0.  Completed work/features include put/get,
> > > putAll, getAll, remove, one-way SSL, authentication and authorization,
> > and
> > > support for primitive types and JSON documents as values (saved in PDX
> on
> > > the server).
> > >
> > > Invite you to review the road map toward GA v1.0, the features proposed
> > for
> > > post-v1.0, and give us your feedback!  (Directly in Confluence or here
> on
> > > dev@geode.apache.org)
> > >
> > > New Client/Server Protocol - Road Map, Proposed
> > > <https://cwiki.apache.org/confluence/display/GEODE/Road+
> Map%2C+Proposed>
> > >
> > >
> > > Thanks for your input,
> > >
> > > Brian
> > >
> >
>

Re: []DISCUSS] Using package names to identify public API's

[Brian Baynes]

Yep, GEODE-3473 will make it in -- have been waiting for a good moment when
there aren't other items in flight that would need to be rebased.


On Fri, Sep 22, 2017 at 2:31 PM, Dan Smith  wrote:

> I found bug GEODE-3473 which was created based on this discussion. I marked
> that as requiring a fix for 1.3.0, so we don't ship these protobuf related
> internal classes as part of the public API.
>
> -Dan
>
> On Sat, Aug 12, 2017 at 9:42 AM, John Blum  wrote:
>
> > On the flip side of internal vs. external APIs, I definitely feel there
> are
> > many classes under "*.internal" packages that should be reviewed and made
> > public.  I realize it increases the surface area of maintainability and
> > support for backwards compatibility, but anytime an application needs
> > access to the functionality the "internal" API provides, those are good
> > candidates.  Keep in mind that there is a huge disparity between the
> public
> > API and cache.xml at the moment and applications coded to the API (rather
> > than XML) are going to suffer.
> >
> > On Fri, Aug 11, 2017 at 11:46 AM, Ernest Burghardt <
> eburgha...@pivotal.io>
> > wrote:
> >
> > > +1 for protobuf being internal as they are not intended to be first
> class
> > > OO citizens you can read more about there here
> > > 
> (the
> > > same warning exists for all supported languages btw)
> > >
> > > On Fri, Aug 11, 2017 at 12:34 PM, Michael William Dodge <
> > mdo...@pivotal.io
> > > >
> > > wrote:
> > >
> > > > The user shouldn't need to access any of the protobuf classes
> directly.
> > > > I'm in favor of making all of the protobuf-related packages internal,
> > > > including any classes generated from .proto files.
> > > >
> > > > Sarge
> > > >
> > > > > On 11 Aug, 2017, at 11:30, Anthony Baker 
> wrote:
> > > > >
> > > > > We have policies in place for versioning [1] and backwards
> > > compatibility
> > > > [2].  How do we identify which API’s need to be controlled?
> > > > >
> > > > > In many cases we use the *.internal.* package naming format to
> signal
> > > > API’s that aren’t subject to backwards compatibility requirements.
> > API’s
> > > > within these internal packages can change and do change even within
> > minor
> > > > or patch releases.  If a user creates an application that relies on
> an
> > > > internal API, it may need to be changed during an upgrade.
> > > > >
> > > > > I’ve noticed that we haven’t been following this convention for
> some
> > > > newer changes (such as in geode-protobuf).  Should we review and
> modify
> > > the
> > > > packages names continue using the *.internal.* format?
> > > > >
> > > > >
> > > > > Anthony
> > > > >
> > > > > [1] https://cwiki.apache.org/confluence/pages/viewpage.
> > > > action?pageId=57311457
> > > > > [1] https://cwiki.apache.org/confluence/display/GEODE/
> > > Managing+Backward+
> > > > Compatibility
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>

Re: New client/server protocol - seeking feedback

[Brian Baynes]

You can find them in the code, but we'll be providing better documentation
on the messages shortly. The proto files have the message definitions and
they're pretty straightforward, but we'll have a more user-friendly
write-up soon.


On Sep 15, 2017 5:27 PM, "Dan Smith" <dsm...@pivotal.io> wrote:

What's the best place to look for more details on the specific protocol for
the v1.0 messages? The other pages on https://cwiki.apache.org/
confluence/display/GEODE/New+Client+Server+Protocol? Or directly in the
code somewhere?

-Dan

On Fri, Sep 15, 2017 at 11:15 AM, Brian Baynes <bbay...@pivotal.io> wrote:

> Greetings, friends of Geode.
>
> Work has been progressing on the new client/server protocol for Geode and
> we're approaching a GA v1.0.  Completed work/features include put/get,
> putAll, getAll, remove, one-way SSL, authentication and authorization, and
> support for primitive types and JSON documents as values (saved in PDX on
> the server).
>
> Invite you to review the road map toward GA v1.0, the features proposed
for
> post-v1.0, and give us your feedback!  (Directly in Confluence or here on
> dev@geode.apache.org)
>
> New Client/Server Protocol - Road Map, Proposed
> <https://cwiki.apache.org/confluence/display/GEODE/Road+Map%2C+Proposed>
>
>
> Thanks for your input,
>
> Brian
>

New client/server protocol - seeking feedback

[Brian Baynes]

Greetings, friends of Geode.

Work has been progressing on the new client/server protocol for Geode and
we're approaching a GA v1.0.  Completed work/features include put/get,
putAll, getAll, remove, one-way SSL, authentication and authorization, and
support for primitive types and JSON documents as values (saved in PDX on
the server).

Invite you to review the road map toward GA v1.0, the features proposed for
post-v1.0, and give us your feedback!  (Directly in Confluence or here on
dev@geode.apache.org)

New Client/Server Protocol - Road Map, Proposed



Thanks for your input,

Brian

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" <bschucha...@pivotal.io> 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 <bschucha...@pivotal.io>
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

[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 : Monitor the neighbour JVM using neihbour's member-timeout (GEODE-3411)

[Brian Baynes]

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

Update on new client/server protocol

[Brian Baynes]

Greetings, Geode friends.

This is a summary of the progress in the development of the new
client/server protocol.  We’ve had some good input along the way and are
getting close to an alpha release — exciting stuff!

We’ve continued implementing Protobuf, now using it for serialization of
primitive types.  It should streamline the development of new clients —
proto files define each message type, reducing the amount of code needed to
get a new client rolling.

A good amount of work has been completed around error messaging and
standardization.  The Geode Wiki contains the spec for error messages and
codes along with other pertinent info on the protocol.

Basic user/password authentication is in place, utilizing the existing
security manager for validating credentials.  Client authorization (using
the existing role-based authorization configuration) is wrapping up as well.
The longer term plan is to use SASL (Simple Authentication and Security
Layer), a framework which will allow for a number of authentication
mechanisms in a standardized implementation.  In the interest of completing
an alpha release soon, that effort will come post-alpha.

It’s always great to get feedback, so we’d love to see folks test out the
new protocol and write some new clients — Ruby, Go, Python, anything
supported by Protobuf.  As we get to an alpha release and beyond, that will
only get more interesting.  On the horizon are PDX encoding/decoding, query
execution, function execution, and some additional operations (remove-all,
put-if-absent).

As always, your input is invited.

Thanks,

Brian

[jira] [Updated] (GEODE-2997) New flow: putAll/getAll

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2997:

Description: 
Create proto message definitions and op handler for putAll/getAll messages.

Client should be able to complete putAll/getAll of primitives and JSON with 
response.

  was:
Create proto message definitions and op handler for get/getAll messages.

Client should be able to complete get/getAll of primitives and JSON with 
response.

Summary: New flow: putAll/getAll  (was: New flow: get/getAll)

> New flow: putAll/getAll
> ---
>
> Key: GEODE-2997
> URL: https://issues.apache.org/jira/browse/GEODE-2997
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>    Reporter: Brian Baynes
>
> Create proto message definitions and op handler for putAll/getAll messages.
> Client should be able to complete putAll/getAll of primitives and JSON with 
> response.



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

[jira] [Updated] (GEODE-2996) New flow: put/get

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2996:

Description: 
Create proto message definitions and op handler for put/get messages.

Client should be able to complete put/get of primitives and JSON with response.

  was:
Create proto message definitions and op handler for put/putAll messages.

Client should be able to complete put/putAll of primitives and JSON with 
response.

Summary: New flow: put/get  (was: New flow: put/putAll)

> New flow: put/get
> -
>
> Key: GEODE-2996
> URL: https://issues.apache.org/jira/browse/GEODE-2996
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>    Reporter: Brian Baynes
>
> Create proto message definitions and op handler for put/get messages.
> Client should be able to complete put/get of primitives and JSON with 
> response.



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

[jira] [Updated] (GEODE-2997) New flow: get/getAll

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2997:

Description: 
Create proto message definitions and op handler for get/getAll messages.

Client should be able to complete get/getAll of primitives and JSON with 
response.

  was:
Create proto message definitions and op handler for putAll/getAll messages.

Client should be able to complete putAll/getAll of primitives and JSON with 
response.

Summary: New flow: get/getAll  (was: New flow: putAll/getAll)

> New flow: get/getAll
> 
>
> Key: GEODE-2997
> URL: https://issues.apache.org/jira/browse/GEODE-2997
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>    Reporter: Brian Baynes
>
> Create proto message definitions and op handler for get/getAll messages.
> Client should be able to complete get/getAll of primitives and JSON with 
> response.



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

[jira] [Created] (GEODE-2999) New flow: replace/put if absent

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2999:
---

 Summary: New flow: replace/put if absent
 Key: GEODE-2999
 URL: https://issues.apache.org/jira/browse/GEODE-2999
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for replace/put if absent 
messages.

Client should be able to complete replace/put if absent of primitives and JSON 
with response.



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

[jira] [Updated] (GEODE-2996) New flow: put/putAll

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2996:

Description: 
Create proto message definitions and op handler for put/putAll messages.

Client should be able to complete put/putAll of primitives and JSON with 
response.

  was:
Create proto message definitions and op handler for put/get messages.

Client should be able to complete put/get of primitives and JSON with response.

Summary: New flow: put/putAll  (was: New flow: put/get)

> New flow: put/putAll
> 
>
> Key: GEODE-2996
> URL: https://issues.apache.org/jira/browse/GEODE-2996
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>    Reporter: Brian Baynes
>
> Create proto message definitions and op handler for put/putAll messages.
> Client should be able to complete put/putAll of primitives and JSON with 
> response.



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

[jira] [Created] (GEODE-2998) New flow: remove/removeAll

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2998:
---

 Summary: New flow: remove/removeAll
 Key: GEODE-2998
 URL: https://issues.apache.org/jira/browse/GEODE-2998
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for remove/removeAll messages.

Client should be able to complete remove/removeAll with response.



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

[jira] [Created] (GEODE-2997) New flow: putAll/getAll

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2997:
---

 Summary: New flow: putAll/getAll
 Key: GEODE-2997
 URL: https://issues.apache.org/jira/browse/GEODE-2997
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for putAll/getAll messages.

Client should be able to complete putAll/getAll of primitives and JSON with 
response.



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

[jira] [Created] (GEODE-2996) New flow: put/get

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2996:
---

 Summary: New flow: put/get
 Key: GEODE-2996
 URL: https://issues.apache.org/jira/browse/GEODE-2996
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create proto message definitions and op handler for put/get messages.

Client should be able to complete put/get of primitives and JSON with response.



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

[jira] [Created] (GEODE-2995) Introduce new protocol flow into core

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2995:
---

 Summary: Introduce new protocol flow into core
 Key: GEODE-2995
 URL: https://issues.apache.org/jira/browse/GEODE-2995
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Create new protocol flow in core to handle incoming client messages, 
serialize/de-serialize primitives and JSON, construct/de-construct messages, 
and complete operations with response.

New protocol flow should handle put/get messages with response, covering 
primitives and JSON.



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

[jira] [Created] (GEODE-2978) Add feature toggle for new protocol & merge into develop

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2978:
---

 Summary: Add feature toggle for new protocol & merge into develop
 Key: GEODE-2978
 URL: https://issues.apache.org/jira/browse/GEODE-2978
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Add a feature toggle for new protocol so we can merge into develop and simplify 
collaboration.

Final deliverable:  new protocol code under feature toggle on develop.



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

[jira] [Updated] (GEODE-2940) Remove verification of locator host on start

[Brian Baynes (JIRA)]

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

Brian Baynes updated GEODE-2940:

Issue Type: New Feature  (was: Bug)

> Remove verification of locator host on start
> 
>
> Key: GEODE-2940
> URL: https://issues.apache.org/jira/browse/GEODE-2940
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>    Reporter: Brian Baynes
>




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

[jira] [Created] (GEODE-2940) Remove verification of locator host on start

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2940:
---

 Summary: Remove verification of locator host on start
 Key: GEODE-2940
 URL: https://issues.apache.org/jira/browse/GEODE-2940
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Brian Baynes






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

[jira] [Resolved] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

[Brian Baynes (JIRA)]

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

Brian Baynes resolved GEODE-2746.
-
Resolution: Duplicate

Superseded by GEODE-2781/2782/2783

> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> * [Avro|https://avro.apache.org/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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

[jira] [Resolved] (GEODE-2585) Client can get an object from the server

[Brian Baynes (JIRA)]

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

Brian Baynes resolved GEODE-2585.
-
Resolution: Implemented

Protocol changing; will be repeated.

> Client can get an object from the server
> 
>
> Key: GEODE-2585
> URL: https://issues.apache.org/jira/browse/GEODE-2585
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Addison
>
> The client should be able to send a message to the server with a region and a 
> key and get the serialized object back.



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

[jira] [Resolved] (GEODE-2734) Investigate/discuss message encoding

[Brian Baynes (JIRA)]

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

Brian Baynes resolved GEODE-2734.
-
Resolution: Duplicate

This story on message encoding options superseded by other stories covering 
testing of different options.  Closing as duplicate.

> Investigate/discuss message encoding
> 
>
> Key: GEODE-2734
> URL: https://issues.apache.org/jira/browse/GEODE-2734
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>    Reporter: Brian Baynes
>
> Out of all the great ways to encode messages (Thrift, Protobuf, etc), which 
> should we use here?  Let's discuss and come to consensus.



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

[jira] [Created] (GEODE-2783) Test framework: Avro

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2783:
---

 Summary: Test framework: Avro
 Key: GEODE-2783
 URL: https://issues.apache.org/jira/browse/GEODE-2783
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Brian Baynes


Test framework Avro, referring to 
https://cwiki.apache.org/confluence/display/GEODE/Message+Serialization+and+Transmission




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

[jira] [Created] (GEODE-2782) Test framework: Thrift

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2782:
---

 Summary: Test framework: Thrift
 Key: GEODE-2782
 URL: https://issues.apache.org/jira/browse/GEODE-2782
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Brian Baynes


Test framework Thrift, referring to 
https://cwiki.apache.org/confluence/display/GEODE/Message+Serialization+and+Transmission




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

[jira] [Created] (GEODE-2781) Test framework: gRPC

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2781:
---

 Summary: Test framework: gRPC
 Key: GEODE-2781
 URL: https://issues.apache.org/jira/browse/GEODE-2781
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Brian Baynes


Test framework gRPC, referring to 
https://cwiki.apache.org/confluence/display/GEODE/Message+Serialization+and+Transmission




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

Re: Request for edit permissions

[Brian Baynes]

Thank you!

On Mar 30, 2017 3:49 PM, "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:

> Done!
>
> On Thu, Mar 30, 2017 at 9:08 AM, Brian Baynes <bbay...@pivotal.io> wrote:
> > Hi, Roman.
> >
> > Sure, understood -- that info was by way of introduction, not a claim to
> > anything :)
> > Thanks for making it clear.
> >
> > Both IDs are bbaynes.
> >
> > Thanks for helping me get set up!
> >
> > Bran
> >
> > On Thu, Mar 30, 2017 at 8:50 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> >> Hi Brian!
> >>
> >> On Thu, Mar 30, 2017 at 8:32 AM, Brian Baynes <bbay...@pivotal.io>
> wrote:
> >> > Hello,
> >> >
> >> > I'm a new PM at Pivotal working with the Communications team.
> >>
> >> Quick note on the Apache way of doing things. While we appreciate
> >> knowing your relationship with Pivotal please realize that neither your
> >> title nor your affiliation with this particular employer have any
> bearings
> >> on what kind of access you get with the project. We're all contributing
> >> to Apache Geode as individual contributors and a lot of times we don't
> >> even know the employment affiliation of others.
> >>
> >> This is a good thing. This is how Apache Way works.
> >>
> >> > I'd like to request edit access for wikis and Jira tickets for Geode.
> >> For
> >> > example, I'd like to edit the description for GEODE-2580, a project
> our
> >> > team is working on.
> >>
> >> Now, for both of these -- we welcome all levels of contributions -
> giving
> >> you
> >> an access is not a problem.
> >>
> >> What's your ASF wiki and JIRA ID?
> >>
> >> Thanks,
> >> Roman.
> >>
>

Re: Request for edit permissions

[Brian Baynes]

Hi, Roman.

Sure, understood -- that info was by way of introduction, not a claim to
anything :)
Thanks for making it clear.

Both IDs are bbaynes.

Thanks for helping me get set up!

Bran

On Thu, Mar 30, 2017 at 8:50 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> Hi Brian!
>
> On Thu, Mar 30, 2017 at 8:32 AM, Brian Baynes <bbay...@pivotal.io> wrote:
> > Hello,
> >
> > I'm a new PM at Pivotal working with the Communications team.
>
> Quick note on the Apache way of doing things. While we appreciate
> knowing your relationship with Pivotal please realize that neither your
> title nor your affiliation with this particular employer have any bearings
> on what kind of access you get with the project. We're all contributing
> to Apache Geode as individual contributors and a lot of times we don't
> even know the employment affiliation of others.
>
> This is a good thing. This is how Apache Way works.
>
> > I'd like to request edit access for wikis and Jira tickets for Geode.
> For
> > example, I'd like to edit the description for GEODE-2580, a project our
> > team is working on.
>
> Now, for both of these -- we welcome all levels of contributions - giving
> you
> an access is not a problem.
>
> What's your ASF wiki and JIRA ID?
>
> Thanks,
> Roman.
>

Request for edit permissions

[Brian Baynes]

Hello,

I'm a new PM at Pivotal working with the Communications team.
I'd like to request edit access for wikis and Jira tickets for Geode.  For
example, I'd like to edit the description for GEODE-2580, a project our
team is working on.

Thanks,
Brian Baynes

[jira] [Created] (GEODE-2734) Investigate/discuss message encoding

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2734:
---

 Summary: Investigate/discuss message encoding
 Key: GEODE-2734
 URL: https://issues.apache.org/jira/browse/GEODE-2734
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Brian Baynes


Out of all the great ways to encode messages (Thrift, Protobuf, etc), which 
should we use here?  Let's discuss and come to consensus.



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