Re: Unable to get behavior described in documentation when using durable native client

[Jakov Varenina]

Hi Jacob,

Native durable client reconnects to the servers hosting the queue in a 
following way:


1. Always sends QueueConnectionRequest (redundant=-1,
   findDurable=false, ClientProxyMembershipID="Not set, except uniqueID
   which is hard-coded to 1") requesting all available servers
   regardless of the value used in "setSubscriptionRedundancy".
2. Native client then sends its ClientProxyMembershipID in handshake
   towards received servers. Each server based on
   ClientProxyMembershipID will return within handshake indication if
   it is primary, redundant or non-redundant server for the event queue.
 * if it is first time durable client connects then all severs will
   be non-redundant (non of them hosting subscription region
   queue). Then native client algorithm will select primary server
   and number of redundant servers based on
   "setSubscriptionRedundancy" and perform subscriptions to them
   accordingly.
 * if it is reconnect case, then the native client will get
   indication in handshake which of the servers are primary and
   redundant and reconnect to them accordingly.

So it seems that below native client document incorrectly describes 
locator behavior when native client is used.  Maybe it would be good to 
update it to reflect correct behavior?


https://geode.apache.org/docs/geode-native/cpp/112/connection-pools/subscription-properties.html

    ...

   /When a client registers interest for a region, if the connection
   pool does not already have a subscription channel, the connection
   pool sends a message to the server locator, and the server locator
   chooses servers to host the queue and return those server names to
   the client. The client then contacts the chosen servers and asks
   them to create the queue./

   //
   /For durable subscriptions, the server locator must be able to
   locate the servers that host the queues for the durable client. When
   a durable client sends a request, the server locator queries all the
   available servers to see if they are hosting the subscription region
   queue for the durable client. If the server is located, the client
   is connected to the server hosting the subscription region queue./

BRs,

Jakov

On 20. 04. 2020. 08:10, Jakov Varenina wrote:

Yes I can. IOException is not thrown and the client works in that case.

BRs,

Jakov

On 17. 04. 2020. 16:24, Jacob Barrett wrote:
Can you confirm that when log level less than debug that the 
IOException goes away and the client appears to function?


-Jake


On Apr 17, 2020, at 1:12 AM, Jakov Varenina 
 wrote:


Hi Jacob,

Thanks for your response!

Regarding GEODE-7944, "Unable to deserialize *membership id* 
java.io.EOFException" is not logged but thrown, and it breaks 
processing of QueueConnectionRequest in locator. This reflects in 
native client with "No locators found" even though they are 
available. Happens only when native client with subscription is 
enabled and locator started with --log-level=debug.


I haven't had time to test and analyze in detail native durable 
client yet. So far I could only confirm that when using native 
durable client then locator behaves differently than how it is 
described in documentation (see previous mail) and how java client 
works:


It seems that native durable client always requests from locator all 
available servers (redundant= -1, findDurable=false) with 
QueueConnectionRequest. Locator returns them in 
QueueConnectionResponse ordered by load (best...worst). While for 
java durable client, locator use *membership id *from 
QueueConnectionRequest to locate servers that host client queue and 
send them back in QueueConnectionResponse as described in previous 
mail. I expect that native durable client is handling re-connection 
to same servers queue somehow also, but this has to be investigated 
yet. Any hints or comments related to this would be really appreciated.


BRs,

Jakov

On 15. 04. 2020. 10:07, Jacob Barrett wrote:
Looking back at history the native library has always only ever set 
that findDurable flag to false. I traced it back to its initial 
commit. Aside from the annoying log message, does client durable 
connection work correctly?


On Apr 14, 2020, at 10:56 PM, Jakov Varenina 
 wrote:


Hi all,

Could you please help me understand behavior of the native client 
when configured as durable?


I have been working on a bug GEODE-7944 
 which results 
with exception "Unable to deserialize membership id 
java.io.EOFException" on locator only when debug is enabled. This 
happens because native client, only when subscription is enabled, 
sends towards locator QueueConnectionRequest that doesn't 
encapsulate ClientProxyMembershipID (not properly serialized) and 
therefore exception occurs when locator tries to deserialize 
membership id to log it at debug level.


I was trying to figure out why would locator need 
ClientProxyMembershi

Switching default branch in .net core repo

[Blake Bender]

Good morning,

We created a repo yesterday for the .net core client work, and the default
branch out of the gate is set to master.  I'd like to switch it to develop,
like the rest of the Geode repos, which apparently requires a quick
heads-up and a couple of +1s to go ahead with.  So... is everyone okay with
this change?

Thanks,

Blake

Re: Switching default branch in .net core repo

[Anthony Baker]

Please do, this will match our default approach to development (gitflow-ish).

+1

Anthony


> On Apr 23, 2020, at 7:35 AM, Blake Bender  wrote:
> 
> Good morning,
> 
> We created a repo yesterday for the .net core client work, and the default
> branch out of the gate is set to master.  I'd like to switch it to develop,
> like the rest of the Geode repos, which apparently requires a quick
> heads-up and a couple of +1s to go ahead with.  So... is everyone okay with
> this change?
> 
> Thanks,
> 
> Blake

Re: Switching default branch in .net core repo

[Dan Smith]

+1

-Dan

On Thu, Apr 23, 2020, 8:05 AM Anthony Baker  wrote:

> Please do, this will match our default approach to development
> (gitflow-ish).
>
> +1
>
> Anthony
>
>
> > On Apr 23, 2020, at 7:35 AM, Blake Bender  wrote:
> >
> > Good morning,
> >
> > We created a repo yesterday for the .net core client work, and the
> default
> > branch out of the gate is set to master.  I'd like to switch it to
> develop,
> > like the rest of the Geode repos, which apparently requires a quick
> > heads-up and a couple of +1s to go ahead with.  So... is everyone okay
> with
> > this change?
> >
> > Thanks,
> >
> > Blake
>
>

Re: Switching default branch in .net core repo

[Karen Miller]

+1
Karen


On Thu, Apr 23, 2020 at 8:14 AM Dan Smith  wrote:

> +1
>
> -Dan
>
> On Thu, Apr 23, 2020, 8:05 AM Anthony Baker  wrote:
>
> > Please do, this will match our default approach to development
> > (gitflow-ish).
> >
> > +1
> >
> > Anthony
> >
> >
> > > On Apr 23, 2020, at 7:35 AM, Blake Bender  wrote:
> > >
> > > Good morning,
> > >
> > > We created a repo yesterday for the .net core client work, and the
> > default
> > > branch out of the gate is set to master.  I'd like to switch it to
> > develop,
> > > like the rest of the Geode repos, which apparently requires a quick
> > > heads-up and a couple of +1s to go ahead with.  So... is everyone okay
> > with
> > > this change?
> > >
> > > Thanks,
> > >
> > > Blake
> >
> >
>

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Anthony Baker]

Naba, do you have any updates to share?  I’m curious if you have found this 
useful compared to JIRA.  

Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How does 
that compare with centralizing our information in the ASF confluence wiki?

Thanks,
Anthony


> On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
> 
> Hello team,
> 
> We are planning to experiment with using Github issues and wiki for the
> Apache project *Geode-Kafka-Connector. *(not Apache Geode project). Please
> do give your vote on this as we need to send the vote link to infra to
> activate it.
> 
> *Why are we doing this ? / Advantages* :
> 1. *Unified location* to have documentation, code and issue tracking.
> 2. Leverage Github tools like Github pages to create websites hosting
> information about the project.
> 3. No separate JIRA accounts or permission required to create issues.
> 4. This will have *no impact on the broader Geode community* as right now
> only 3-4 developers involved in this project.
> 5. *This is an experiment.* If things do not work out we can always revert
> back to the traditional way of having separate JIRA, documentation,
> websites etc.
> 
> *Precedence*:
> 1. Kubernetes uses the github issues
> 2. RabbitMQ uses github issues.
> 
> 
> *NOTE: *- Please be cordial and do not use any condescending language and
> absolutely no bullying.
> - Please treat this email as a professional business email and maintain
> email etiquette while replying.
> 
> Regards
> Nabarun

Re: Switching default branch in .net core repo

[Dave Barnes]

+1
Dave

On 4/23/20, 8:29 AM, "Karen Miller"  wrote:

+1
Karen


On Thu, Apr 23, 2020 at 8:14 AM Dan Smith  wrote:

> +1
>
> -Dan
>
> On Thu, Apr 23, 2020, 8:05 AM Anthony Baker  wrote:
>
> > Please do, this will match our default approach to development
> > (gitflow-ish).
> >
> > +1
> >
> > Anthony
> >
> >
> > > On Apr 23, 2020, at 7:35 AM, Blake Bender  wrote:
> > >
> > > Good morning,
> > >
> > > We created a repo yesterday for the .net core client work, and the
> > default
> > > branch out of the gate is set to master.  I'd like to switch it to
> > develop,
> > > like the rest of the Geode repos, which apparently requires a quick
> > > heads-up and a couple of +1s to go ahead with.  So... is everyone okay
> > with
> > > this change?
> > >
> > > Thanks,
> > >
> > > Blake
> >
> >
>

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Blake Bender]

GitHub Wiki supports Markdown, our current one does not.  This means GitHub
wins by default in my book.

Thanks,

Blake


On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker  wrote:

> Naba, do you have any updates to share?  I’m curious if you have found
> this useful compared to JIRA.
>
> Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How
> does that compare with centralizing our information in the ASF confluence
> wiki?
>
> Thanks,
> Anthony
>
>
> > On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
> >
> > Hello team,
> >
> > We are planning to experiment with using Github issues and wiki for the
> > Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
> Please
> > do give your vote on this as we need to send the vote link to infra to
> > activate it.
> >
> > *Why are we doing this ? / Advantages* :
> > 1. *Unified location* to have documentation, code and issue tracking.
> > 2. Leverage Github tools like Github pages to create websites hosting
> > information about the project.
> > 3. No separate JIRA accounts or permission required to create issues.
> > 4. This will have *no impact on the broader Geode community* as right now
> > only 3-4 developers involved in this project.
> > 5. *This is an experiment.* If things do not work out we can always
> revert
> > back to the traditional way of having separate JIRA, documentation,
> > websites etc.
> >
> > *Precedence*:
> > 1. Kubernetes uses the github issues
> > 2. RabbitMQ uses github issues.
> >
> >
> > *NOTE: *- Please be cordial and do not use any condescending language and
> > absolutely no bullying.
> > - Please treat this email as a professional business email and maintain
> > email etiquette while replying.
> >
> > Regards
> > Nabarun
>
>

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Anthony Baker]

Having used pretty every style of wiki, I care less about the wiki tech and 
more about making the content easily accessible and discoverable for our users 
and contributors.  Our current wiki has a lot of useful information.  I’d like 
to understand how we want to use repo-specific wiki’s to augment or replace our 
current project wiki (or neither)\ before taking any decisions.

Anthony


> On Apr 23, 2020, at 12:54 PM, Blake Bender  wrote:
> 
> GitHub Wiki supports Markdown, our current one does not.  This means GitHub
> wins by default in my book.
> 
> Thanks,
> 
> Blake
> 
> 
> On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker  wrote:
> 
>> Naba, do you have any updates to share?  I’m curious if you have found
>> this useful compared to JIRA.
>> 
>> Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How
>> does that compare with centralizing our information in the ASF confluence
>> wiki?
>> 
>> Thanks,
>> Anthony
>> 
>> 
>>> On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
>>> 
>>> Hello team,
>>> 
>>> We are planning to experiment with using Github issues and wiki for the
>>> Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
>> Please
>>> do give your vote on this as we need to send the vote link to infra to
>>> activate it.
>>> 
>>> *Why are we doing this ? / Advantages* :
>>> 1. *Unified location* to have documentation, code and issue tracking.
>>> 2. Leverage Github tools like Github pages to create websites hosting
>>> information about the project.
>>> 3. No separate JIRA accounts or permission required to create issues.
>>> 4. This will have *no impact on the broader Geode community* as right now
>>> only 3-4 developers involved in this project.
>>> 5. *This is an experiment.* If things do not work out we can always
>> revert
>>> back to the traditional way of having separate JIRA, documentation,
>>> websites etc.
>>> 
>>> *Precedence*:
>>> 1. Kubernetes uses the github issues
>>> 2. RabbitMQ uses github issues.
>>> 
>>> 
>>> *NOTE: *- Please be cordial and do not use any condescending language and
>>> absolutely no bullying.
>>> - Please treat this email as a professional business email and maintain
>>> email etiquette while replying.
>>> 
>>> Regards
>>> Nabarun
>> 
>> 

Re: [DISCUSS] preparing for Geode 1.13.0 release

[Dave Barnes]

I'm willing.

On 4/22/20, 11:43 AM, "Owen Nichols"  wrote:

Geode is scheduled to cut support/1.13 on May 4, as per the quarterly 
release schedule approved [1] in 2018 and affirmed in last month’s “Shipping 
patch releases” RFC [2].

Please volunteer if you are interested in serving as Release Manager for 
Geode 1.13.0.

[1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F8626f7cc73b49cc90129ec5f6021adab3815469048787032935bfc1e%2540%253Cdev.geode.apache.org%253E&data=02%7C01%7Cdaveba%40vmware.com%7Ccee476d475d84a2a3ceb08d7e6ed0867%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637231778047185914&sdata=%2BC7sDyrQloYd%2F4UxmBPEXvDKmeKHXzKV6rxPdghbZIE%3D&reserved=0
[2] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FShipping%2Bpatch%2Breleases&data=02%7C01%7Cdaveba%40vmware.com%7Ccee476d475d84a2a3ceb08d7e6ed0867%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637231778047190906&sdata=CAMNC6g7u9GconPgjQF1Qvk90EIFvPvQ449jHjitRIY%3D&reserved=0

Re: [DISCUSS] preparing for Geode 1.13.0 release

[Owen Nichols]

Awesome, thanks for stepping up, Dave!

Please familiarize yourself with the instructions at 
https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode. If 
you have any questions along the way, there are quite a few past release 
managers on the dev list you can reach out to.

> On Apr 23, 2020, at 2:40 PM, Dave Barnes  wrote:
> 
> I'm willing.
> 
> On 4/22/20, 11:43 AM, "Owen Nichols"  wrote:
> 
>Geode is scheduled to cut support/1.13 on May 4, as per the quarterly 
> release schedule approved [1] in 2018 and affirmed in last month’s “Shipping 
> patch releases” RFC [2].
> 
>Please volunteer if you are interested in serving as Release Manager for 
> Geode 1.13.0.
> 
>[1] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F8626f7cc73b49cc90129ec5f6021adab3815469048787032935bfc1e%2540%253Cdev.geode.apache.org%253E&data=02%7C01%7Cdaveba%40vmware.com%7Ccee476d475d84a2a3ceb08d7e6ed0867%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637231778047185914&sdata=%2BC7sDyrQloYd%2F4UxmBPEXvDKmeKHXzKV6rxPdghbZIE%3D&reserved=0
>[2] 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FShipping%2Bpatch%2Breleases&data=02%7C01%7Cdaveba%40vmware.com%7Ccee476d475d84a2a3ceb08d7e6ed0867%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637231778047190906&sdata=CAMNC6g7u9GconPgjQF1Qvk90EIFvPvQ449jHjitRIY%3D&reserved=0
> 

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Jacob Barrett]

How about keeping things in the GitHub wiki that are very tightly couple to the 
use of that repo? Like style guides? Building guides? Eh... does ASF have any 
input on using the GitHub wiki over the ASF wiki?

> On Apr 23, 2020, at 2:40 PM, Anthony Baker  wrote:
> 
> Having used pretty every style of wiki, I care less about the wiki tech and 
> more about making the content easily accessible and discoverable for our 
> users and contributors.  Our current wiki has a lot of useful information.  
> I’d like to understand how we want to use repo-specific wiki’s to augment or 
> replace our current project wiki (or neither)\ before taking any decisions.
> 
> Anthony
> 
> 
>> On Apr 23, 2020, at 12:54 PM, Blake Bender  wrote:
>> 
>> GitHub Wiki supports Markdown, our current one does not.  This means GitHub
>> wins by default in my book.
>> 
>> Thanks,
>> 
>> Blake
>> 
>> 
>>> On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker  wrote:
>>> 
>>> Naba, do you have any updates to share?  I’m curious if you have found
>>> this useful compared to JIRA.
>>> 
>>> Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How
>>> does that compare with centralizing our information in the ASF confluence
>>> wiki?
>>> 
>>> Thanks,
>>> Anthony
>>> 
>>> 
 On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
 
 Hello team,
 
 We are planning to experiment with using Github issues and wiki for the
 Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
>>> Please
 do give your vote on this as we need to send the vote link to infra to
 activate it.
 
 *Why are we doing this ? / Advantages* :
 1. *Unified location* to have documentation, code and issue tracking.
 2. Leverage Github tools like Github pages to create websites hosting
 information about the project.
 3. No separate JIRA accounts or permission required to create issues.
 4. This will have *no impact on the broader Geode community* as right now
 only 3-4 developers involved in this project.
 5. *This is an experiment.* If things do not work out we can always
>>> revert
 back to the traditional way of having separate JIRA, documentation,
 websites etc.
 
 *Precedence*:
 1. Kubernetes uses the github issues
 2. RabbitMQ uses github issues.
 
 
 *NOTE: *- Please be cordial and do not use any condescending language and
 absolutely no bullying.
 - Please treat this email as a professional business email and maintain
 email etiquette while replying.
 
 Regards
 Nabarun
>>> 
>>> 
> 

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Nabarun Nag]

Hi Anthony!

Sorry for the late reply but I was doing some research. The issues and wiki
section as of now has been used by few engineers only and Confluent has not
yet entered any issues as they are still reviewing the project. I went
ahead and looked into all projects in the Apache domain using issues and
the extra features they enable.
*JIRA vs Issues:*

   - There are a sizable number of Apache projects who are using GitHub
   issues
   - One clear advantage is the automatic linking of PRs and Issues. Issues
   can be closed automatically once the PR is merged.
   - It can also enable a feature to delete the feature branch
   automatically once the PRs is merged (we have lot unused feature/GEODE-
   branches in origin which were not deleted after merging PRs)
   - It enables us to use Github Project management(Github version of
   PivotalTracker)  which is integrated with Github issues and PRs and all the
   movement from "To-do", "In-progress", "resolved" and "closed" are automated
   depending on if a PR is opened, requires reviews, reviewed and merged state.

*Github Wiki vs Confluence Wiki:*

   - As you have mentioned that visibility is more important, we can follow
   other open-source products like Greenplum, Hystrix and we can use the wiki
   page to explain stuff like how to contribute, basic architecture, internal
   knowledge, i.e information that is needed to contribute to Geode.
   - A signification advantage is the colocation of code and wiki. Any
   developer can find Geode GitHub repo and that person now has all the tools
   needed to start contributing.


A few examples of well-written wikis on GitHub:

   - https://github.com/d3/d3/wiki
   - https://github.com/Netflix/Hystrix/wiki
   - https://github.com/apache/helix/wiki


ASF: word on the street is that it was mentioned in ApacheCon, that they
support the use of Github wiki and issues in ASF projects, and this can
also be seen in multiple INFRA tickets mentioning enabling wiki.

I am also looking into ZenHub to improve our workflow. ZenHub is a very
robust project management tools used by Apache Contributors and
corporations like VMware.

Regards
Nabarun Nag


On Thu, Apr 23, 2020 at 2:40 PM Anthony Baker  wrote:

> Having used pretty every style of wiki, I care less about the wiki tech
> and more about making the content easily accessible and discoverable for
> our users and contributors.  Our current wiki has a lot of useful
> information.  I’d like to understand how we want to use repo-specific
> wiki’s to augment or replace our current project wiki (or neither)\ before
> taking any decisions.
>
> Anthony
>
>
> > On Apr 23, 2020, at 12:54 PM, Blake Bender  wrote:
> >
> > GitHub Wiki supports Markdown, our current one does not.  This means
> GitHub
> > wins by default in my book.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker  wrote:
> >
> >> Naba, do you have any updates to share?  I’m curious if you have found
> >> this useful compared to JIRA.
> >>
> >> Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How
> >> does that compare with centralizing our information in the ASF
> confluence
> >> wiki?
> >>
> >> Thanks,
> >> Anthony
> >>
> >>
> >>> On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
> >>>
> >>> Hello team,
> >>>
> >>> We are planning to experiment with using Github issues and wiki for the
> >>> Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
> >> Please
> >>> do give your vote on this as we need to send the vote link to infra to
> >>> activate it.
> >>>
> >>> *Why are we doing this ? / Advantages* :
> >>> 1. *Unified location* to have documentation, code and issue tracking.
> >>> 2. Leverage Github tools like Github pages to create websites hosting
> >>> information about the project.
> >>> 3. No separate JIRA accounts or permission required to create issues.
> >>> 4. This will have *no impact on the broader Geode community* as right
> now
> >>> only 3-4 developers involved in this project.
> >>> 5. *This is an experiment.* If things do not work out we can always
> >> revert
> >>> back to the traditional way of having separate JIRA, documentation,
> >>> websites etc.
> >>>
> >>> *Precedence*:
> >>> 1. Kubernetes uses the github issues
> >>> 2. RabbitMQ uses github issues.
> >>>
> >>>
> >>> *NOTE: *- Please be cordial and do not use any condescending language
> and
> >>> absolutely no bullying.
> >>> - Please treat this email as a professional business email and maintain
> >>> email etiquette while replying.
> >>>
> >>> Regards
> >>> Nabarun
> >>
> >>
>
>