RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

[Udo Kohlmeyer]

Hi there Alberto,

There is no explicit requirement to receive any “+1” messages.

I think a good rule of thumb is to:
a) To provide a little more time to review any RFC. One week might be a little 
short, given that we cannot assume that everyone has time to review/work on the 
project in a full-time capacity. I always think 2-3 weeks is safe.
b) If no explicit “+1”s are received after 50% of the allotted review time, 
maybe a nudge in the DEV list to review the RFC.

After those steps have been followed, it would be safe to assume that 
“consensus by lack of objection” is reached if the deadline has been reached.

Thank you for extending.

—Udo
On May 29, 2020, 12:02 PM -0700, Alberto Bustamante Reyes 
, wrote:
Hi Udo,

Thanks for your message, I was not sure if I had to receive explicit +1 
messages or not. Of course I prefer to have some feedback before continue so I 
will extend the deadline until end of next Thursday (4th June), I hope its fine.

BR/

Alberto B.

De: Udo Kohlmeyer 
Enviado: viernes, 29 de mayo de 2020 19:30
Para: dev@geode.apache.org 
Asunto: RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads 
start

Hi there Alberto,

Thank you for the RFC.

Tbh, I don’t know if there should some guidance around the period that we 
invite comments on.

I personally had a really busy week and could not get to the RFC review in the 
1 week that I was given.

I would like to request that this RFC is extended by 1 more week, to invite 
comments.
I understand that without comments it is reasonable to assume that everyone 
agrees, but I would prefer that, in this case, we need to get some amount of 
“+1” comments on this RFC.

I fear that we might fall under a false-positive mentality here, if we assume 
that everyone has read the RFC, had time to think and consider its 
repercussions, within the 1 week dead line.

Hope you can accommodate the extra 1 week extension request.

—Udo
On May 29, 2020, 1:56 AM -0700, Alberto Bustamante Reyes 
, wrote:
Hi,

No comments have been received so far. I have moved the RFC to "in development" 
state and I will continue with the code implementation.

BR/

Alberto B.

De: Alberto Bustamante Reyes 
Enviado: sábado, 23 de mayo de 2020 0:26
Para: dev@geode.apache.org 
Asunto: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

Hi Geode community,

I have posted on the wiki a new RFC about implementing a new option for serial 
gateway sender creation related with how the dispatcher threads are started. 
This option will be used only when gateway receivers are configured to share 
same host and port. This configuration was already discussed on a previous RFC.

Please send your comments by Thursday 28th May.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FNew%2Boption%2Bfor%2Bserial%2Bgw%2Bsender%2Bdispatcher%2Bthreads%2Bstartdata=02%7C01%7Cudo%40vmware.com%7C286cd3ccd1c544f2e50308d80402cc16%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263757351787094sdata=ij1HPHVvJQKZMnrfv%2Fj147ULRhyYtDrDX2StQyD3WKM%3Dreserved=0

Thanks,

Alberto B.

RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

[Alberto Bustamante Reyes]

Hi Udo,

Thanks for your message, I was not sure if I had to receive explicit +1 
messages or not. Of course I prefer to have some feedback before continue so I 
will extend the deadline until end of next Thursday (4th June), I hope its fine.

BR/

Alberto B.

De: Udo Kohlmeyer 
Enviado: viernes, 29 de mayo de 2020 19:30
Para: dev@geode.apache.org 
Asunto: RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads 
start

Hi there Alberto,

Thank you for the RFC.

Tbh, I don’t know if there should some guidance around the period that we 
invite comments on.

I personally had a really busy week and could not get to the RFC review in the 
1 week that I was given.

I would like to request that this RFC is extended by 1 more week, to invite 
comments.
I understand that without comments it is reasonable to assume that everyone 
agrees, but I would prefer that, in this case, we need to get some amount of 
“+1” comments on this RFC.

I fear that we might fall under a false-positive mentality here, if we assume 
that everyone has read the RFC, had time to think and consider its 
repercussions, within the 1 week dead line.

Hope you can accommodate the extra 1 week extension request.

—Udo
On May 29, 2020, 1:56 AM -0700, Alberto Bustamante Reyes 
, wrote:
Hi,

No comments have been received so far. I have moved the RFC to "in development" 
state and I will continue with the code implementation.

BR/

Alberto B.

De: Alberto Bustamante Reyes 
Enviado: sábado, 23 de mayo de 2020 0:26
Para: dev@geode.apache.org 
Asunto: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

Hi Geode community,

I have posted on the wiki a new RFC about implementing a new option for serial 
gateway sender creation related with how the dispatcher threads are started. 
This option will be used only when gateway receivers are configured to share 
same host and port. This configuration was already discussed on a previous RFC.

Please send your comments by Thursday 28th May.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FNew%2Boption%2Bfor%2Bserial%2Bgw%2Bsender%2Bdispatcher%2Bthreads%2Bstartdata=02%7C01%7Cudo%40vmware.com%7Cfed54db06b9d4fce3dd808d803ae255b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263393774343460sdata=vMECgNzw6IFbbToYpGtrXxrSsjEJ%2FddrDdQv4npWvx8%3Dreserved=0

Thanks,

Alberto B.

Re: LGTM check failed

[Robert Houghton]

I’m looking at the logs, and doing some digging.

From: Mario Kevo 
Date: Friday, May 29, 2020 at 3:42 AM
To: dev@geode.apache.org 
Subject: LGTM check failed
Hi all,

LGTM analysis: Java check failed for last six opened PRs.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5182data=02%7C01%7Crhoughton%40vmware.com%7C61c908bdfa0644b8333c08d803bcff8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263457565949790sdata=iyGw1RZmwBahoKqOJKwuQYPoXaXXVbQUwfcFueIE%2F6o%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5181data=02%7C01%7Crhoughton%40vmware.com%7C61c908bdfa0644b8333c08d803bcff8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263457565959783sdata=uA2xsWRzyZrHENilhuk5JHt2jS1ipJMiab%2BGrIGbqyA%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5180data=02%7C01%7Crhoughton%40vmware.com%7C61c908bdfa0644b8333c08d803bcff8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263457565959783sdata=bTNodLY9BJLA58zXS4TRPcd7PNFbgyCUoShsDTkM90M%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5179data=02%7C01%7Crhoughton%40vmware.com%7C61c908bdfa0644b8333c08d803bcff8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263457565959783sdata=O2sQjP6w4DEI%2BBH4M8GtOGU8JhJn54Yu1Kon6hVNpH0%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5176data=02%7C01%7Crhoughton%40vmware.com%7C61c908bdfa0644b8333c08d803bcff8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263457565959783sdata=qsSWsMRHzz59XnrP13qXMvTSbFliZCt1yAtyZTPJB%2Fg%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5175data=02%7C01%7Crhoughton%40vmware.com%7C61c908bdfa0644b8333c08d803bcff8b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263457565959783sdata=6ZDC8jIlnUINz3n24uZK2CPlnRvHVojXybqqVdmpg%2Fk%3Dreserved=0

[2020-05-29 00:08:56] [analysis] [EVALUATION 115/177] [FAIL] Error running 
query semmlecode-queries/Security/CWE/CWE-022/TaintedPath.ql: OutOfMemory
Query evaluation ran out of memory (maximum allowed memory: 3012MB).

I take a look on the last few merged commit but don't think that they caused 
this failure.
Please can someone, who is more familiar with this, take a look to see if it is 
problem with this check?

BR,
Mario

RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

[Udo Kohlmeyer]

Hi there Alberto,

Thank you for the RFC.

Tbh, I don’t know if there should some guidance around the period that we 
invite comments on.

I personally had a really busy week and could not get to the RFC review in the 
1 week that I was given.

I would like to request that this RFC is extended by 1 more week, to invite 
comments.
I understand that without comments it is reasonable to assume that everyone 
agrees, but I would prefer that, in this case, we need to get some amount of 
“+1” comments on this RFC.

I fear that we might fall under a false-positive mentality here, if we assume 
that everyone has read the RFC, had time to think and consider its 
repercussions, within the 1 week dead line.

Hope you can accommodate the extra 1 week extension request.

—Udo
On May 29, 2020, 1:56 AM -0700, Alberto Bustamante Reyes 
, wrote:
Hi,

No comments have been received so far. I have moved the RFC to "in development" 
state and I will continue with the code implementation.

BR/

Alberto B.

De: Alberto Bustamante Reyes 
Enviado: sábado, 23 de mayo de 2020 0:26
Para: dev@geode.apache.org 
Asunto: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

Hi Geode community,

I have posted on the wiki a new RFC about implementing a new option for serial 
gateway sender creation related with how the dispatcher threads are started. 
This option will be used only when gateway receivers are configured to share 
same host and port. This configuration was already discussed on a previous RFC.

Please send your comments by Thursday 28th May.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FNew%2Boption%2Bfor%2Bserial%2Bgw%2Bsender%2Bdispatcher%2Bthreads%2Bstartdata=02%7C01%7Cudo%40vmware.com%7Cfed54db06b9d4fce3dd808d803ae255b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637263393774343460sdata=vMECgNzw6IFbbToYpGtrXxrSsjEJ%2FddrDdQv4npWvx8%3Dreserved=0

Thanks,

Alberto B.

LGTM check failed

[Mario Kevo]

Hi all,

LGTM analysis: Java check failed for last six opened PRs.
https://github.com/apache/geode/pull/5182
https://github.com/apache/geode/pull/5181
https://github.com/apache/geode/pull/5180
https://github.com/apache/geode/pull/5179
https://github.com/apache/geode/pull/5176
https://github.com/apache/geode/pull/5175

[2020-05-29 00:08:56] [analysis] [EVALUATION 115/177] [FAIL] Error running 
query semmlecode-queries/Security/CWE/CWE-022/TaintedPath.ql: OutOfMemory
Query evaluation ran out of memory (maximum allowed memory: 3012MB).

I take a look on the last few merged commit but don't think that they caused 
this failure.
Please can someone, who is more familiar with this, take a look to see if it is 
problem with this check?

BR,
Mario

RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

[Alberto Bustamante Reyes]

Hi,

No comments have been received so far. I have moved the RFC to "in development" 
state and I will continue with the code implementation.

BR/

Alberto B.

De: Alberto Bustamante Reyes 
Enviado: sábado, 23 de mayo de 2020 0:26
Para: dev@geode.apache.org 
Asunto: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

Hi Geode community,

I have posted on the wiki a new RFC about implementing a new option for serial 
gateway sender creation related with how the dispatcher threads are started. 
This option will be used only when gateway receivers are configured to share 
same host and port. This configuration was already discussed on a previous RFC.

Please send your comments by Thursday 28th May.

https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start

Thanks,

Alberto B.

Odg: Certificate based authorization - CN authorization in jmx

[Mario Kevo]

Hi all,

Kindly reminder on this question.
Thanks in an advance!

BR,
Mario

Šalje: Mario Kevo 
Poslano: 22. svibnja 2020. 13:56
Prima: dev@geode.apache.org 
Predmet: Certificate based authorization - CN authorization in jmx

Hi geode-dev,

We are working on implementing a new feature regarding to this 
RFC.

The main idea is to combine the TLS and access control features, but to use the 
certificate subject common name for access control authentication/authorization 
instead of user credentials.
We need to get client certificate on the server side to extract common name 
from it. The problem is that gfsh client connects towards to jmx using RMI TCP 
connections. We have tried many things to get client certificate from 
established RMI Connection but unfortunately without success.

Did anyone have the similar problem and able to extract certificate from RMI 
Connection after TLS handshake has been completed?

BR,
Mario