RE: About "change loglevel" command

[Alberto Bustamante Reyes]

Thanks Kirk. Could I ask what was the reason behind this change? In older Geode 
version (1.10 I think) we were using our own log4j files, and the command was 
working fine.

Digging into the code I saw that its possible to start servers with a system 
property (--J=-Dgeode.LOG_LEVEL_UPDATE_OCCURS=ALWAYS) that also allows the 
"change loglevel" command to work. I think that could be a better alternative 
to document, as it is more command specific, instead of documenting the 
"geode-default" property.

For example (in italics the part that could be added to the documentation of 
the command):

"Changes the logging level on specified members. This command only will take 
effect if the default Geode logging configuration is used.

In case of using custom log4j configuration files, this command will not work 
unless the member whose logging level you want to change was started using the 
'--J=-Dgeode.LOG_LEVEL_UPDATE_OCCURS=ALWAYS' system property."

BR/

Alberto B.





De: Kirk Lund 
Enviado: martes, 7 de abril de 2020 0:17
Para: geode 
Asunto: Re: About "change loglevel" command

Yes, this behavior is correct. If the User provides their own logging
configuration (or a different logging impl such as logback) then none of
the log-* configuration properties in Geode have any effect.

On Mon, Apr 6, 2020 at 9:26 AM Alberto Bustamante Reyes
 wrote:

> Hi all,
>
> I have observed that "change loglevel" command doesn't work if the
> "log4j2.xml" file used doesn't contain the "geode-default" property set to
> true. This requirement is not documented [1], so I would like to confirm if
> this is the correct behavior.
>
> If we add "geode-default=true" in our log4j2 files, the "change loglevel"
> works fine, but Im not sure if its ok to use that property on a custom log
> config file.
>
> Thanks,
>
>
> Alberto B.
>
> [1]
> https://geode.apache.org/docs/guide/112/tools_modules/gfsh/command-pages/change.html
>
>

Re: [DISCUSS] Adding Google Analytics to our website

[Michael Oleske]

What things are we looking to learn?  Without knowing what we are
interested in learning I would be hesitant to add anything.  If we know
what we want to learn then a conversation about analytics would be more
fruitful (to me at least)

-michael


On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann 
wrote:

> Hi all,
>
> In promoting our project it might be valuable to get a better idea of where
> visitors on our website come from, what they look for and where we lose
> them. This should help us improve the website and learn what kind of blogs
> articles, videos etc. drive user interest to the website.
>
> To gain those insights I'd like to add Google Analytics (GA). While GA
> isn't open source, it is commonly used by other Apache projects. Apache
> Cassandra, Kafka, Samza and Spark all have GA trackers on their website.
>
> I've heard rumors that we at some point had it on our website as well. Is
> this true? If so, why did we remove it?
>
> Thank you for your thoughts and concerns!
>

Proposal to bring GEODE-7969 to support/1.12

[Owen Nichols]

Recently it’s been noticed that netty-all-4.1.42.Final.jar is getting flagged 
for “high" security vulnerability CVE-2019-20444 and CVE-2019-20445.

Analysis shows that Geode does not use Netty in a manner that would expose this 
vulnerability.

The risk of bringing GEODE-7969 is very low.  Netty is only imported for some 
I/O libraries in geode-redis, not used as a server.  GEODE-7969 has passed all 
PR checks on support/1.12, and the same version bump to 4.1.45.Final has been 
on develop since February via GEODE-7798.

This fix is critical to avoid false positives in automated vulnerability scans.

-Owen

Re: Proposal to bring GEODE-7969 to support/1.12

[Ju@N]

+1

On Wed, 8 Apr 2020 at 17:21, Owen Nichols  wrote:

> Recently it’s been noticed that netty-all-4.1.42.Final.jar is getting
> flagged for “high" security vulnerability CVE-2019-20444 and CVE-2019-20445.
>
> Analysis shows that Geode does not use Netty in a manner that would expose
> this vulnerability.
>
> The risk of bringing GEODE-7969 is very low.  Netty is only imported for
> some I/O libraries in geode-redis, not used as a server.  GEODE-7969 has
> passed all PR checks on support/1.12, and the same version bump to
> 4.1.45.Final has been on develop since February via GEODE-7798.
>
> This fix is critical to avoid false positives in automated vulnerability
> scans.
>
> -Owen



-- 
Ju@N

Re: About "change loglevel" command

[Kirk Lund]

This behavior has always worked like this since the internal implementation
of logging changed from GemFire LogWriters to using Log4j. The reason is
for performance. Geode is optimized for log level INFO with no filters --
it does this by wrapping all Log4j Loggers in a class called FastLogger
which prevents Log4j from performing a bunch of filter checks as well as
checking the timestamp of the log4j2.xml file. For some reason, the Log4j
devs decided to have the check for changes to the configuration file occur
within the thread performing a logging statement -- when this is allowed to
happen, it kills the performance of Geode. So FastLogger has a volatile
boolean that short circuits all of this extra checking, but it can only do
this if the code can be sure that there are no filters and that the log
level is INFO (or WARN or ERROR). Geode knows that it can bypass all of
that extra Log4j behavior only if it's the default log4j2.xml that is
bundled inside of the Geode jar (geode-core in older releases and now moved
to geode-log4j).

On Wed, Apr 8, 2020 at 8:40 AM Alberto Bustamante Reyes
 wrote:

> Thanks Kirk. Could I ask what was the reason behind this change? In older
> Geode version (1.10 I think) we were using our own log4j files, and the
> command was working fine.
>
> Digging into the code I saw that its possible to start servers with a
> system property (--J=-Dgeode.LOG_LEVEL_UPDATE_OCCURS=ALWAYS) that also
> allows the "change loglevel" command to work. I think that could be a
> better alternative to document, as it is more command specific, instead of
> documenting the "geode-default" property.
>
> For example (in italics the part that could be added to the documentation
> of the command):
>
> "Changes the logging level on specified members. This command only will
> take effect if the default Geode logging configuration is used.
>
> In case of using custom log4j configuration files, this command will not
> work unless the member whose logging level you want to change was started
> using the '--J=-Dgeode.LOG_LEVEL_UPDATE_OCCURS=ALWAYS' system property."
>
> BR/
>
> Alberto B.
>
>
>
>
> 
> De: Kirk Lund 
> Enviado: martes, 7 de abril de 2020 0:17
> Para: geode 
> Asunto: Re: About "change loglevel" command
>
> Yes, this behavior is correct. If the User provides their own logging
> configuration (or a different logging impl such as logback) then none of
> the log-* configuration properties in Geode have any effect.
>
> On Mon, Apr 6, 2020 at 9:26 AM Alberto Bustamante Reyes
>  wrote:
>
> > Hi all,
> >
> > I have observed that "change loglevel" command doesn't work if the
> > "log4j2.xml" file used doesn't contain the "geode-default" property set
> to
> > true. This requirement is not documented [1], so I would like to confirm
> if
> > this is the correct behavior.
> >
> > If we add "geode-default=true" in our log4j2 files, the "change loglevel"
> > works fine, but Im not sure if its ok to use that property on a custom
> log
> > config file.
> >
> > Thanks,
> >
> >
> > Alberto B.
> >
> > [1]
> >
> https://geode.apache.org/docs/guide/112/tools_modules/gfsh/command-pages/change.html
> >
> >
>

Re: Proposal to bring GEODE-7969 to support/1.12

[Joris Melchior]

+1

On Wed, Apr 8, 2020 at 12:21 PM Owen Nichols  wrote:

> Recently it’s been noticed that netty-all-4.1.42.Final.jar is getting
> flagged for “high" security vulnerability CVE-2019-20444 and CVE-2019-20445.
>
> Analysis shows that Geode does not use Netty in a manner that would expose
> this vulnerability.
>
> The risk of bringing GEODE-7969 is very low.  Netty is only imported for
> some I/O libraries in geode-redis, not used as a server.  GEODE-7969 has
> passed all PR checks on support/1.12, and the same version bump to
> 4.1.45.Final has been on develop since February via GEODE-7798.
>
> This fix is critical to avoid false positives in automated vulnerability
> scans.
>
> -Owen



-- 
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427

“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*

Review for PR #4815

[Mario Kevo]

Hi all,

please could someone review PR #4815.
Jira ticket https://issues.apache.org/jira/browse/GEODE-7838

Thanks and BR,
Mario

Re: Proposal to bring GEODE-7969 to support/1.12

[Dick Cavender]

+1

On Wed, Apr 8, 2020 at 10:08 AM Joris Melchior  wrote:

> +1
>
> On Wed, Apr 8, 2020 at 12:21 PM Owen Nichols  wrote:
>
> > Recently it’s been noticed that netty-all-4.1.42.Final.jar is getting
> > flagged for “high" security vulnerability CVE-2019-20444 and
> CVE-2019-20445.
> >
> > Analysis shows that Geode does not use Netty in a manner that would
> expose
> > this vulnerability.
> >
> > The risk of bringing GEODE-7969 is very low.  Netty is only imported for
> > some I/O libraries in geode-redis, not used as a server.  GEODE-7969 has
> > passed all PR checks on support/1.12, and the same version bump to
> > 4.1.45.Final has been on develop since February via GEODE-7798.
> >
> > This fix is critical to avoid false positives in automated vulnerability
> > scans.
> >
> > -Owen
>
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> 
>

Re: [DISCUSS] Adding Google Analytics to our website

[Alexander Murmann]

Hi Michael,

A few things I'd like to know and potential associated actions:
* Where do our visitors come from (referrer)? -> We might be able to lean
in to those sources.
* Are we getting any traffic from our Twitter presence? -> If certain
tweets bring more traffic, let's do more of tweets like it!
* Some people in our community started blogging more. Are we seeing any
traffic from that? Are some topics driving more traffic than others ->
Might inform what topics or types of articles we should write more or less
off.


On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske  wrote:

> What things are we looking to learn?  Without knowing what we are
> interested in learning I would be hesitant to add anything.  If we know
> what we want to learn then a conversation about analytics would be more
> fruitful (to me at least)
>
> -michael
>
>
> On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann 
> wrote:
>
> > Hi all,
> >
> > In promoting our project it might be valuable to get a better idea of
> where
> > visitors on our website come from, what they look for and where we lose
> > them. This should help us improve the website and learn what kind of
> blogs
> > articles, videos etc. drive user interest to the website.
> >
> > To gain those insights I'd like to add Google Analytics (GA). While GA
> > isn't open source, it is commonly used by other Apache projects. Apache
> > Cassandra, Kafka, Samza and Spark all have GA trackers on their website.
> >
> > I've heard rumors that we at some point had it on our website as well. Is
> > this true? If so, why did we remove it?
> >
> > Thank you for your thoughts and concerns!
> >
>

Re: [DISCUSS] Adding Google Analytics to our website

[Bob Glithero]

Hi All,

Hopefully it's ok for me to add my $.02 here.  While understanding where the 
traffic is coming from is always helpful, it's possible to take a more active 
approach to driving traffic.  I also help with community marketing at RabbitMQ 
(rabbitmq.com), which uses their platform to host tutorials, best practices, 
and other content.  I could find $$$ in my budget to help modernize the Geode 
site and make it more generally useful as a content platform for developers and 
others interested in the project. 

Bob

On 4/8/20, 1:59 PM, "Alexander Murmann"  wrote:

Hi Michael,

A few things I'd like to know and potential associated actions:
* Where do our visitors come from (referrer)? -> We might be able to lean
in to those sources.
* Are we getting any traffic from our Twitter presence? -> If certain
tweets bring more traffic, let's do more of tweets like it!
* Some people in our community started blogging more. Are we seeing any
traffic from that? Are some topics driving more traffic than others ->
Might inform what topics or types of articles we should write more or less
off.


On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske  wrote:

> What things are we looking to learn?  Without knowing what we are
> interested in learning I would be hesitant to add anything.  If we know
> what we want to learn then a conversation about analytics would be more
> fruitful (to me at least)
>
> -michael
>
>
> On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann 
> wrote:
>
> > Hi all,
> >
> > In promoting our project it might be valuable to get a better idea of
> where
> > visitors on our website come from, what they look for and where we lose
> > them. This should help us improve the website and learn what kind of
> blogs
> > articles, videos etc. drive user interest to the website.
> >
> > To gain those insights I'd like to add Google Analytics (GA). While GA
> > isn't open source, it is commonly used by other Apache projects. Apache
> > Cassandra, Kafka, Samza and Spark all have GA trackers on their website.
> >
> > I've heard rumors that we at some point had it on our website as well. 
Is
> > this true? If so, why did we remove it?
> >
> > Thank you for your thoughts and concerns!
> >
>

Re: Proposal to bring GEODE-7969 to support/1.12

[Owen Nichols]

There appears to be consensus to bring this critical fix to support/1.12

https://github.com/apache/geode/pull/4926 
 has been merged to support/1.12 and 
Jira updated with correct fix versions.


> On Apr 8, 2020, at 1:41 PM, Dick Cavender  wrote:
> 
> +1
> 
> On Wed, Apr 8, 2020 at 10:08 AM Joris Melchior  wrote:
> 
>> +1
>> 
>> On Wed, Apr 8, 2020 at 12:21 PM Owen Nichols  wrote:
>> 
>>> Recently it’s been noticed that netty-all-4.1.42.Final.jar is getting
>>> flagged for “high" security vulnerability CVE-2019-20444 and
>> CVE-2019-20445.
>>> 
>>> Analysis shows that Geode does not use Netty in a manner that would
>> expose
>>> this vulnerability.
>>> 
>>> The risk of bringing GEODE-7969 is very low.  Netty is only imported for
>>> some I/O libraries in geode-redis, not used as a server.  GEODE-7969 has
>>> passed all PR checks on support/1.12, and the same version bump to
>>> 4.1.45.Final has been on develop since February via GEODE-7798.
>>> 
>>> This fix is critical to avoid false positives in automated vulnerability
>>> scans.
>>> 
>>> -Owen
>> 
>> 
>> 
>> --
>> *Joris Melchior *
>> CF Engineering
>> Pivotal Toronto
>> 416 877 5427
>> 
>> “Programs must be written for people to read, and only incidentally for
>> machines to execute.” – *Hal Abelson*
>> 
>> 

Website refresh (was Re: [DISCUSS] Adding Google Analytics to our website)

[Anthony Baker]

Bob, I think a refresh of the Geode website is a great idea.  I look forward to 
hearing more of your ideas.  I’ve included a link below [1] to provide context 
on ASF policies around websites.

Thanks,
Anthony

[1] https://www.apache.org/foundation/marks/pmcs#introduction 




> On Apr 8, 2020, at 2:08 PM, Bob Glithero  wrote:
> 
> Hi All,
> 
> Hopefully it's ok for me to add my $.02 here.  While understanding where the 
> traffic is coming from is always helpful, it's possible to take a more active 
> approach to driving traffic.  I also help with community marketing at 
> RabbitMQ (rabbitmq.com), which uses their platform to host tutorials, best 
> practices, and other content.  I could find $$$ in my budget to help 
> modernize the Geode site and make it more generally useful as a content 
> platform for developers and others interested in the project. 
> 
> Bob
> 
> On 4/8/20, 1:59 PM, "Alexander Murmann"  wrote:
> 
>Hi Michael,
> 
>A few things I'd like to know and potential associated actions:
>* Where do our visitors come from (referrer)? -> We might be able to lean
>in to those sources.
>* Are we getting any traffic from our Twitter presence? -> If certain
>tweets bring more traffic, let's do more of tweets like it!
>* Some people in our community started blogging more. Are we seeing any
>traffic from that? Are some topics driving more traffic than others ->
>Might inform what topics or types of articles we should write more or less
>off.
> 
> 
>On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske  wrote:
> 
>> What things are we looking to learn?  Without knowing what we are
>> interested in learning I would be hesitant to add anything.  If we know
>> what we want to learn then a conversation about analytics would be more
>> fruitful (to me at least)
>> 
>> -michael
>> 
>> 
>> On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> In promoting our project it might be valuable to get a better idea of
>> where
>>> visitors on our website come from, what they look for and where we lose
>>> them. This should help us improve the website and learn what kind of
>> blogs
>>> articles, videos etc. drive user interest to the website.
>>> 
>>> To gain those insights I'd like to add Google Analytics (GA). While GA
>>> isn't open source, it is commonly used by other Apache projects. Apache
>>> Cassandra, Kafka, Samza and Spark all have GA trackers on their website.
>>> 
>>> I've heard rumors that we at some point had it on our website as well. Is
>>> this true? If so, why did we remove it?
>>> 
>>> Thank you for your thoughts and concerns!
>>> 
>> 
> 
> 

Re: [DISCUSS] Adding Google Analytics to our website

[Charlie Black]

If we could add page analytics on docs and other pages that would awesome.
  That would allow us to create focused content blogs, videos, investment
on those pages where we find the hottest views.

Charlie

On Wed, Apr 8, 2020 at 2:08 PM Bob Glithero 
wrote:

> Hi All,
>
> Hopefully it's ok for me to add my $.02 here.  While understanding where
> the traffic is coming from is always helpful, it's possible to take a more
> active approach to driving traffic.  I also help with community marketing
> at RabbitMQ (rabbitmq.com), which uses their platform to host tutorials,
> best practices, and other content.  I could find $$$ in my budget to help
> modernize the Geode site and make it more generally useful as a content
> platform for developers and others interested in the project.
>
> Bob
>
> On 4/8/20, 1:59 PM, "Alexander Murmann"  wrote:
>
> Hi Michael,
>
> A few things I'd like to know and potential associated actions:
> * Where do our visitors come from (referrer)? -> We might be able to
> lean
> in to those sources.
> * Are we getting any traffic from our Twitter presence? -> If certain
> tweets bring more traffic, let's do more of tweets like it!
> * Some people in our community started blogging more. Are we seeing any
> traffic from that? Are some topics driving more traffic than others ->
> Might inform what topics or types of articles we should write more or
> less
> off.
>
>
> On Wed, Apr 8, 2020 at 9:18 AM Michael Oleske 
> wrote:
>
> > What things are we looking to learn?  Without knowing what we are
> > interested in learning I would be hesitant to add anything.  If we
> know
> > what we want to learn then a conversation about analytics would be
> more
> > fruitful (to me at least)
> >
> > -michael
> >
> >
> > On Tue, Apr 7, 2020 at 3:31 PM Alexander Murmann <
> amurm...@apache.org>
> > wrote:
> >
> > > Hi all,
> > >
> > > In promoting our project it might be valuable to get a better idea
> of
> > where
> > > visitors on our website come from, what they look for and where we
> lose
> > > them. This should help us improve the website and learn what kind
> of
> > blogs
> > > articles, videos etc. drive user interest to the website.
> > >
> > > To gain those insights I'd like to add Google Analytics (GA).
> While GA
> > > isn't open source, it is commonly used by other Apache projects.
> Apache
> > > Cassandra, Kafka, Samza and Spark all have GA trackers on their
> website.
> > >
> > > I've heard rumors that we at some point had it on our website as
> well. Is
> > > this true? If so, why did we remove it?
> > >
> > > Thank you for your thoughts and concerns!
> > >
> >
>
>
> --
Charlie Black | cbl...@pivotal.io