geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Lindsey <alind...@pivotal.io>
Subject Re: [DISCUSS] Release Geode 1.9.1 with logging improvements
Date Tue, 13 Aug 2019 19:40:21 GMT
Thanks, Udo.

+1 for doing a 1.9.1 patch release, assuming there is enough time for SBDG to include it in
their 1.2.x line.

- Aaron 

> On Aug 13, 2019, at 12:38 PM, Udo Kohlmeyer <udo@apache.com> wrote:
> 
> No, 1.9.1 IS something we require. SBDG 1.2 CAN use 1.9.1, we'd have to wait for SBDG
1.3 to use 1.10 or 1.11
> 
> SBDG 1.3 is still a few months off, so maybe getting critical fixes in patch versions
is required.
> 
> On 8/13/19 11:26 AM, Kirk Lund wrote:
>> Udo, Thanks for the info! Sounds like we shouldn't bother with Geode 1.9.1
>> then. If I'm misinterpreting what you wrote, let me know.
>> 
>> On Tue, Aug 13, 2019 at 10:36 AM Udo Kohlmeyer <udo@apache.com> wrote:
>> 
>>> The latest version of SBDG 1.2 is already in RC stage. Which means the
>>> dependent Geode version cannot be changed any more. Currently SBDG 1.2
>>> is based on Geode 1.9. This will not change. Patch versions to 1.9 are
>>> supported, but not changes to 1.10 or later.
>>> 
>>> THUS,
>>> 
>>> Once SBDG 1.3 (Neuman) is released, it will be based on the latest GA of
>>> Geode, which at this point would be 1.10 or possibly 1.11 depending on
>>> release cycles.
>>> 
>>> In addition...
>>> 
>>> @Aaron, Whilst it would also be possible to override the underlying
>>> Geode version that SBDG uses, to a later version, I would just like to
>>> point out that all testing of SBDG will be against a named supported
>>> version of Geode / GemFire. Which means, if failures arise using SBDG /
>>> SDG with a non-supported version of Geode / GemFire would effectively be
>>> unsupported. (due diligence to confirm origin of failure will of course
>>> be applied)
>>> 
>>> Hope this helps...
>>> 
>>> --Udo
>>> 
>>> On 8/13/19 10:03 AM, Aaron Lindsey wrote:
>>>> Assuming Geode 1.10 is released with the three logging fixes in Kirk’s
>>> message, can the next GA release of Spring Boot Data Geode consume 1.10
>>> instead of 1.9? Also, when would SBDG need this patch release by (whether
>>> we do a 1.9.1 release or 1.10 release)?
>>>> - Aaron
>>>> 
>>>>> On Aug 13, 2019, at 9:31 AM, Bruce Schuchardt <bschuchardt@pivotal.io>
>>> wrote:
>>>>> If we release a 1.9.1 I'd like to include the SSL/NIO fix. Cluster SSL
>>> communications with conserve-sockets=false is currently broken in 1.9.
>>>>> On 8/13/19 9:25 AM, Kirk Lund wrote:
>>>>>> I'd like to discuss if and how we can release Geode 1.9.1 with logging
>>>>>> improvements. This is primarily to provide a patch release for Spring
>>> Data
>>>>>> Geode and Spring Boot to ensure a smoother User experience out-of-the
>>> box.
>>>>>> They have very near-future releases that need this as soon as possible.
>>>>>> 
>>>>>> The specific tickets and commits that would be back-ported are:
>>>>>> 
>>>>>> *1. GEODE-7058 Log4j-core dependency should be optional in geode-core*
>>>>>> 
>>>>>> commit 413800bc16d05df689a2af5c30797f180aad6088
>>>>>> Author: Kirk Lund <klund@apache.org>
>>>>>> Date:   Wed Aug 7 14:33:21 2019 -0700
>>>>>> 
>>>>>>      GEODE-7058: Mark log4j-core optional in geode-core
>>>>>> 
>>>>>>      Note: this change requires all commits from GEODE-2644 and
>>> GEODE-6122.
>>>>>> *2. GEODE-7050 Log4jAgent should avoid casting non-log4j loggers*
>>>>>> 
>>>>>> commit e5c9c420f462149fd062847904e3435fbe99afb4
>>>>>> Author: Kirk Lund <klund@apache.org>
>>>>>> Date:   Thu Aug 8 18:17:32 2019 -0700
>>>>>> 
>>>>>>      GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
>>> (#3892)
>>>>>>      This change prevents Geode from using Log4jAgent if Log4j Core
is
>>>>>>      present but not using Log4jProvider.
>>>>>> 
>>>>>>      For example, Log4j uses SLF4JProvider when log4j-to-slf4j is
in
>>> the
>>>>>>     classpath.
>>>>>> 
>>>>>>      By disabling Log4jAgent when other Log4j Providers are in use,
>>> this
>>>>>>      prevents problems such as ClassCastExceptions when attemping
to
>>> cast
>>>>>>      loggers from org.apache.logging.slf4j.SLF4JLogger to
>>>>>>      org.apache.logging.log4j.core.Logger to get the LoggerConfig
or
>>>>>>      LoggerContext.
>>>>>> 
>>>>>>      Co-Authored-By: Aaron Lindsey <alindsey@pivotal.io>
>>>>>> 
>>>>>> *3. GEODE-6959 NPE if AlertAppender is not defined*
>>>>>> 
>>>>>> commit dd15fec1f2ecbc3bc0cdfc42072252c379e0bb89
>>>>>> Author: Kirk Lund <klund@apache.org>
>>>>>> Date:   Thu Aug 8 14:59:44 2019 -0700
>>>>>> 
>>>>>>      GEODE-6959: Prevent NPE in GMSMembershipManager for null
>>> AlertAppender
>>>>>> (#3899)
>>>>>> 
>>>>>>      If a custom log4j2.xml is used without specifying the Geode
>>>>>> AlertAppender,
>>>>>>      GMSMembershipManager may throw a NullPointerException when
>>> invoking
>>>>>>      AlertAppender.getInstance().stopSession() during a
>>> forceDisconnect. This
>>>>>>      change prevents the NullPointerException allowing forceDisconnect
>>> to
>>>>>> finish.
>>>>>> 
>>>>>>      Users using Spring Boot with Logback are more likely to hit
this
>>> bug.
>>>>>>      Co-authored-by: Mark Hanson mhanson@pivotal.io
>>>>>> 


Mime
View raw message