Re: [VOTE] Backporting of GEODE-8261 to 1.13 release branch.

[Ivan Godwin]

+1

On 6/19/20, 12:16 PM, "Nabarun Nag"  wrote:

Hi Geode devs,

Requesting vote to backport of GEODE-8261 to 1.13

Why?
This commit fixes an issue with servers throwing null pointer exceptions 
while a member is being shutdown and registering interest is in process.

SHA
720a4caea2ddb22296aa3225fc5264d2096cdf20


Regards
Nabarun

Re: [PROPOSAL]: Include GEODE-7728 in Release 1.12.0

[Ivan Godwin]

+1

On Wed, Feb 5, 2020 at 10:16 AM Nabarun Nag  wrote:

> ++
>
> On Wed, Feb 5, 2020 at 9:54 AM Alexander Murmann 
> wrote:
>
> > +1
> >
> > On Wed, Feb 5, 2020 at 9:29 AM Udo Kohlmeyer  wrote:
> >
> > > +1 - for inclusion
> > >
> > > On 2/5/20 4:22 AM, Ju@N wrote:
> > > > Hello devs,
> > > >
> > > > I'd like to include the fix for GEODE-7728 [1] in release 1.12.0.
> > > > The change is basically to avoid throwing an exception and return the
> > > > correct result whenever a query has more than one condition and one
> of
> > > them
> > > > compares two indexed fields.
> > > > This is not a new issue but it can be hit by any user under the
> > > conditions
> > > > I've mentioned, it is also considered critical for one of the
> > customers I
> > > > work for, thus I'm eagerly asking to include the fix in the next
> > release.
> > > > The SHA is 6e35c201ea605075433203d4e64ca887bafd8fcb [2].
> > > > Best regards.
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/GEODE-7728
> > > > [2]:
> > > >
> > >
> >
> https://github.com/apache/geode/commit/6e35c201ea605075433203d4e64ca887bafd8fcb
> > > >
> > >
> >
>

Re: Proposal to including GEODE-7593 in release/1.11.0

[Ivan Godwin]

+1

On Thu, Dec 19, 2019 at 11:43 AM Dick Cavender  wrote:

> +1
>
> On Thu, Dec 19, 2019 at 11:27 AM Udo Kohlmeyer  wrote:
>
> > +1
> >
> > On 12/19/19 10:05 AM, Owen Nichols wrote:
> > > GEODE-7593 fixes a memory leak where indexes could retain references to
> > pdx values when eviction should have released that memory.
> > >
> > > This is not a new issue, but is critical because system stability is
> > threatened when eviction does not release memory as expected.
> > >
> > > The SHA is 1beec9e3930a071031b960f045874fb337e72e7c.
> >
>

Re: [DISCUSS/VOTE] Proposal to bring GEODE-7465 to release/1.11.0

[Ivan Godwin]

+1

On Tue, Nov 26, 2019 at 1:31 PM Xiaojian Zhou  wrote:

> +1
>
> On Tue, Nov 26, 2019 at 12:48 PM Joris Melchior 
> wrote:
>
> > +1
> >
> > On Tue, Nov 26, 2019 at 2:41 PM Jason Huynh  wrote:
> >
> > > +1
> > >
> > > On Tue, Nov 26, 2019 at 11:34 AM Anilkumar Gingade <
> aging...@pivotal.io>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Tue, Nov 26, 2019 at 11:32 AM Udo Kohlmeyer 
> wrote:
> > > >
> > > > > This is no-brainer
> > > > >
> > > > > *+1*
> > > > >
> > > > > On 11/26/19 11:27 AM, Owen Nichols wrote:
> > > > > > I would like to propose bringing “GEODE-7465: Set eventProcessor
> to
> > > > null
> > > > > in serial AEQ when it is stopped” into the 1.11 release
> > (necessitating
> > > an
> > > > > RC4).
> > > > > >
> > > > > > Without the fix, a sequence of ordinary gfsh commands will leave
> > the
> > > > WAN
> > > > > gateway in an unrecoverable hung state:
> > > > > > stop gateway-sender
> > > > > > start gateway-sender
> > > > > > The only recourse is to restart the server.
> > > > > >
> > > > > > This fix is critical because the distributed system fails to sync
> > > data
> > > > > between WAN sites as the user would expect.
> > > > > > This issue did exist in previous releases, but recent
> enhancements
> > to
> > > > > WAN/AEQ such as AEQ-pause are increasing user interaction with
> > > > WAN-related
> > > > > gfsh commands.
> > > > > >
> > > > > > The fix is simple, low risk, tested, and has been on develop for
> 5
> > > > days:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/geode/commit/e148cef9cb63eba283cf86bc490eb280023567ce
> > > > >
> > > >
> > >
> >
> >
> > --
> > *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: Cache.close is not synchronous?

[Ivan Godwin]

+1 for fixing.

On Tue, Nov 26, 2019 at 6:53 AM Alberto Bustamante Reyes
 wrote:

> +1 for fixing it.
> 
> De: Anilkumar Gingade 
> Enviado: martes, 26 de noviembre de 2019 0:24
> Para: geode 
> Asunto: Re: Cache.close is not synchronous?
>
> Looking at the code, the cache.close() and InternalCacheBuilder.create()
> are synchronized on "GemFireCacheImpl.class"'; it's the
> internalCachebuilder create that seems to be using reference to the old
> distributed-system.
> The GemFireCacheImpl.getInstance() and getExisting() both perform
> "isClosing" check and does early return. The InternalCacheBuilder is new;
> not sure if its missing early checks.
>
> -Anil.
>
> On Mon, Nov 25, 2019 at 2:47 PM Mark Hanson  wrote:
>
> > +1 to fix.
> >
> > > On Nov 25, 2019, at 2:02 PM, John Blum  wrote:
> > >
> > > +1 ^ 64!
> > >
> > > I found this out the hard way some time ago and is why STDG exists in
> the
> > > first place (i.e. usability issues, particularly with testing).
> > >
> > > On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund  wrote:
> > >
> > >> I found a test that closes the cache and then recreates the cache
> > multiple
> > >> times with 2 second sleep between each. I tried to remove the
> > Thread.sleep
> > >> and found that recreating the cache
> > >> throws DistributedSystemDisconnectedException (see below).
> > >>
> > >> This seems like a usability nightmare. Anyone have any ideas WHY it's
> > this
> > >> way?
> > >>
> > >> Personally, I want Cache.close() to block until both Cache and
> > >> DistributedSystem are closed and the API is ready to create a new
> Cache.
> > >>
> > >> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> > This
> > >> connection to a distributed system has been disconnected.
> > >>at
> > >>
> > >>
> >
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:945)
> > >>at
> > >>
> > >>
> >
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1665)
> > >>at
> > >>
> > >>
> >
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:791)
> > >>at
> > >>
> > >>
> >
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> > >>at
> > >>
> > >>
> >
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> > >>at
> > >> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> > >>
> > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> >
> >
>

Re: Proposal of new config property "ssl-server-name-extension"

[Ivan Godwin]

Thank you for the reference to the other thread, Jens. I hope my questions
aren't too late in the process.

Mario, are there any limitations that should be understood about the types
of certificates used or how they're generated? Do you have the freedom to
use certificate chaining and have the root CA in each component's
truststore? Dan's concern of a future, valid use case resonates quite a bit
with me.

Ivan


On Wed, Nov 20, 2019, 18:43 Jens Deppe  wrote:

> This thread contains more background on the reasons for this proposal:
>
> https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
>
> On Wed, Nov 20, 2019 at 10:46 AM Ivan Godwin  wrote:
>
> > I've reviewed the PR and I believe I understand the use case, but I feel
> a
> > bit uncomfortable with the misuse of SNI. As I understand it, and as it
> has
> > been already mentioned, SNI is used to determine which SSL certificate
> > should be presented to a client.
> >
> > I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
> > and that a new client property should be used instead. That is, a
> different
> > property, unrelated to SSL, should be used to set what will be verified
> > against CLIENT_HELLO_EXTENSION.
> >
> > On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe  wrote:
> >
> > > I'd like to add my comment from the original PR here again:
> > >
> > >
> > > Although I support the particular use case, I would prefer the
> > > implementation being a bit more abstracted. Specifically, if we
> provided
> > an
> > > extension point which would allow modification of SSLParameters then we
> > > wouldn't be coupling to a particular use case. So I'm thinking that the
> > > user would define (via say a ssl-parameter-extension parameter) a class
> > > that takes in a SSLParameter and perhaps SSLConfig and whatever else
> for
> > > this use-case and does what it needs. The user class would need to
> > > implement an interface something like this:
> > >
> > > public interface SSLParameterExtension {
> > >   SSLParameter modify(SSLParameter, SSLConfig);
> > > }
> > >
> > > I would imagine seeing the user implementation of this being attached
> to
> > > SSLConfig.
> > >
> > >
> > > (https://github.com/apache/geode/pull/4310)
> > >
> > > I don't mind (mis)using the Server Name field to convey some other
> > > information, but since it's possible to abstract the specific nature
> and
> > > application of that information, I think we should do so. Anyone else
> who
> > > looks at the code is going to wonder what the use is especially if the
> > > consumer of that particular piece of info is going to be provided via
> an
> > > external SSLEngine implementation.
> > >
> > > --Jens
> > >
> > > On Tue, Nov 19, 2019 at 1:18 PM Dan Smith  wrote:
> > >
> > > > Can you clarify which connections will use this
> > ssl-server-name-extension
> > > > as part of the Client Hello? client to locator, client to server,
> > server
> > > to
> > > > server, WAN site to WAN site, ... all of the above?
> > > >
> > > > I'm fine with adding the new property.
> > > >
> > > > At some point, I think we need to think about making it easier to
> plug
> > in
> > > > custom logic to control the entire socket creation and TLS
> handshake. I
> > > > think technically you can take over the whole process if you set the
> > > > ssl-use-default-context property and then configure the default
> > > SSLContext
> > > > for your entire process, but that is not ideal.
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black 
> > wrote:
> > > >
> > > > > I have read the e-mail and the ticket I am not sure how this field
> is
> > > > going
> > > > > to be used.   Maybe you can expand on the intent of this field.
> > > > >
> > > > > From the property "ssl-server-name-extension" it feels like we are
> > > > > intending to correlate with something presented in the SSL
> > certificate.
> > > > > It would be great if that was explained plainly for the reader in
> > more
> > > > > detail.
> > > > >
> > > > > For now I can only -1.
> > > > >
> > > > > Charlie
> > > > >
> > > > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac  >
> > > > > wrote:
> > > > >
> > > > > > Hi geode dev,
> > > > > >
> > > > > > as a part of solution for
> > > > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > > > we would like to introduce new config property
> > > > > "ssl-server-name-extension".
> > > > > >
> > > > > > This property will contain generic string, which will be added as
> > > > Server
> > > > > > Name Indication (SNI) parameter to Client Hello message.
> > > > > >
> > > > > > Do you agree with this proposal?
> > > > > >
> > > > > > Thanks,
> > > > > > Mario
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Charlie Black | cbl...@pivotal.io
> > > > >
> > > >
> > >
> >
>

Re: Proposal of new config property "ssl-server-name-extension"

[Ivan Godwin]

I've reviewed the PR and I believe I understand the use case, but I feel a
bit uncomfortable with the misuse of SNI. As I understand it, and as it has
been already mentioned, SNI is used to determine which SSL certificate
should be presented to a client.

I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
and that a new client property should be used instead. That is, a different
property, unrelated to SSL, should be used to set what will be verified
against CLIENT_HELLO_EXTENSION.

On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe  wrote:

> I'd like to add my comment from the original PR here again:
>
>
> Although I support the particular use case, I would prefer the
> implementation being a bit more abstracted. Specifically, if we provided an
> extension point which would allow modification of SSLParameters then we
> wouldn't be coupling to a particular use case. So I'm thinking that the
> user would define (via say a ssl-parameter-extension parameter) a class
> that takes in a SSLParameter and perhaps SSLConfig and whatever else for
> this use-case and does what it needs. The user class would need to
> implement an interface something like this:
>
> public interface SSLParameterExtension {
>   SSLParameter modify(SSLParameter, SSLConfig);
> }
>
> I would imagine seeing the user implementation of this being attached to
> SSLConfig.
>
>
> (https://github.com/apache/geode/pull/4310)
>
> I don't mind (mis)using the Server Name field to convey some other
> information, but since it's possible to abstract the specific nature and
> application of that information, I think we should do so. Anyone else who
> looks at the code is going to wonder what the use is especially if the
> consumer of that particular piece of info is going to be provided via an
> external SSLEngine implementation.
>
> --Jens
>
> On Tue, Nov 19, 2019 at 1:18 PM Dan Smith  wrote:
>
> > Can you clarify which connections will use this ssl-server-name-extension
> > as part of the Client Hello? client to locator, client to server, server
> to
> > server, WAN site to WAN site, ... all of the above?
> >
> > I'm fine with adding the new property.
> >
> > At some point, I think we need to think about making it easier to plug in
> > custom logic to control the entire socket creation and TLS handshake. I
> > think technically you can take over the whole process if you set the
> > ssl-use-default-context property and then configure the default
> SSLContext
> > for your entire process, but that is not ideal.
> >
> > -Dan
> >
> > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black  wrote:
> >
> > > I have read the e-mail and the ticket I am not sure how this field is
> > going
> > > to be used.   Maybe you can expand on the intent of this field.
> > >
> > > From the property "ssl-server-name-extension" it feels like we are
> > > intending to correlate with something presented in the SSL certificate.
> > > It would be great if that was explained plainly for the reader in more
> > > detail.
> > >
> > > For now I can only -1.
> > >
> > > Charlie
> > >
> > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac 
> > > wrote:
> > >
> > > > Hi geode dev,
> > > >
> > > > as a part of solution for
> > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > we would like to introduce new config property
> > > "ssl-server-name-extension".
> > > >
> > > > This property will contain generic string, which will be added as
> > Server
> > > > Name Indication (SNI) parameter to Client Hello message.
> > > >
> > > > Do you agree with this proposal?
> > > >
> > > > Thanks,
> > > > Mario
> > > >
> > >
> > >
> > > --
> > > Charlie Black | cbl...@pivotal.io
> > >
> >
>

Re: [VOTE] Apache Geode 1.10.0.RC1

[Ivan Godwin]

gt;>>
> >>
> org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$0(SkipUpToDateStep.java:89)
> >>>>>>  at java.util.Optional.map(Optional.java:215)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:54)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:38)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:77)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:37)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:36)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:26)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:90)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:48)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.internal.execution.impl.DefaultWorkExecutor.execute(DefaultWorkExecutor.java:33)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:120)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.ResolveBeforeExecutionStateTaskExecuter.execute(ResolveBeforeExecutionStateTaskExecuter.java:75)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:62)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:108)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.ResolveBeforeExecutionOutputsTaskExecuter.execute(ResolveBeforeExecutionOutputsTaskExecuter.java:67)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.StartSnapshotTaskInputsBuildOperationTaskExecuter.execute(StartSnapshotTaskInputsBuildOperationTaskExecuter.java:62)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.ResolveAfterPreviousExecutionStateTaskExecuter.execute(ResolveAfterPreviousExecutionStateTaskExecuter.java:46)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:94)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:95)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
> >>>>>>  at
> >>>>>>
> >>>>>
> >>
> org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
> >>>>>>  at
> >>>>>>
> >&g

Re: [VOTE] Apache Geode 1.9.1.RC3

[Ivan Godwin]

I know that 1.9.1 has already been release, but I'm working to verify the
native client, now.

Ivan

On Fri, Sep 6, 2019 at 8:42 AM Nabarun Nag  wrote:

> Can anyone confirm that the native client test failure happening in 1.10 RC
> does not occur in this candidate.
> I can test it if someone can point me to the instructions to do that.
>
>
> Regards
> Naba
>
>
> On Fri, Sep 6, 2019 at 8:38 AM Robert Houghton 
> wrote:
>
> > +1 given the pre-existence of threw class path bug, and it's fix in 1.10
> >
> > On Wed, Sep 4, 2019, 11:26 Jens Deppe  wrote:
> >
> > > No, It's fixed in 1.10.x.
> > >
> > > On Wed, Sep 4, 2019 at 10:16 AM Robert Houghton 
> > > wrote:
> > >
> > > > Hi Jens,
> > > >
> > > > Does this issue appear in 1.10.0.RC1?
> > > >
> > > > On Tue, Sep 3, 2019, 13:03 Jens Deppe  wrote:
> > > >
> > > > > TL;DR: +0
> > > > >
> > > > > When using gfsh over http, the following exception occurs:
> > > > >
> > > > > (1) Executing - connect --url=https://localhost:7070/geode-mgmt/v1
> > > > >
> > > > >
> > > >
> > >
> >
> --security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > > > <
> > > >
> > >
> >
> https://localhost:7070/geode-mgmt/v1--security-properties-file=/Users/jdeppe/workspace/gemfire-develop/open/security.properties
> > > > >
> > > > >
> > > > > Exception in thread "main" java.lang.NoClassDefFoundError:
> > > > > org/apache/geode/management/internal/web/shell/HttpOperationInvoker
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.httpConnect(ConnectCommand.java:284)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.commands.ConnectCommand.connect(ConnectCommand.java:153)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > > at java.lang.reflect.Method.invoke(Method.java:498)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:111)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:121)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:63)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:57)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:84)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:584)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.springframework.shell.core.AbstractShell.executeScriptLine(AbstractShell.java:74)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.shell.Gfsh.executeScriptLine(Gfsh.java:615)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseOptions(Launcher.java:232)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.geode.management.internal.cli.Launcher.parseCommandLine(Launcher.java:250)
> > > > > at
> > > > >
> > >
> org.apache.geode.management.internal.cli.Launcher.main(Launcher.java:135)
> > > > > Caused by: java.lang.ClassNotFoundException:
> > > > > org.apache.geode.management.internal.web.shell.HttpOperationInvoker
> > > > > at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > > > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> > > > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > > > > ... 19 more
> > > > >
> > > > > The problem is that the geode-web.jar is not included in
> > > > > gfsh-dependencies.jar as part of the build.
> > > > >
> > > > > Since this issue appears to also exist on 1.9.0 I'm going to +0
> > > (instead
> > > > of
> > > > > -1). Others may feel differently. A workaround exists simply by
> > adding
> > > > the
> > > > > missing jar when running gfsh.
> > > > >
> > > > > --Jens
> > > > >
> > > > > On Tue, Sep 3, 2019 at 10:45 AM John Blum 
> wrote:
> > > > >
> > > > > > 1 more thing...
> > > > > >
> > > > > > I would additio

Re: [VOTE] Apache Geode 1.10.0.RC1

[Ivan Godwin]

Hello,

I don't know that this will be cause to hold anything up, but geode-native
has two integration tests failing when trying to perform Region::remove().
This is the case for all platforms supported by native client. The two
tests are testThinClientCallbackArg and
testThinClientListenerCallbackArgTest.

Here's the stacktrace, and I will continue investigating in the morning.

Region::remove: An exception (java.lang.ClassCastException:
java.lang.Byte cannot be cast to org.apache.geode.cache.Operation

at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.getOperation(BaseCommand.java:1466)

at 
org.apache.geode.internal.cache.tier.sockets.command.Destroy65.cmdExecute(Destroy65.java:114)

at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)

at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)

at 
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)

at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)

at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at 
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:666)

at 
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)

at java.lang.Thread.run(Thread.java:748)

) happened at remote server.


On Thu, Sep 5, 2019 at 9:00 PM Nabarun Nag  wrote:

> Thank you Dan for the explanation.
>
> Regards
> Naba
>
>
> On Thu, Sep 5, 2019 at 4:34 PM Dan Smith  wrote:
>
> > Hi Naba,
> >
> > This sanctioned-serializable stuff is not an issue.
> >
> > When you removed those files from sanctioned-geode-core-serializables,
> they
> > get rejected by the serialization filter. Look at the error message you
> see
> > when you remove them - it is failing to serialize a class that has a
> > *nested* EvictionAttributes.
> >
> > Those classes need to be in the sanctioned file, if they are embedded in
> > another serialized object. They are probably not showing up in the
> > actualSerializables file because they are DataSerializable.
> >
> > -Dan
> >
> > On Thu, Sep 5, 2019 at 3:49 PM Kirk Lund  wrote:
> >
> > > Ah, ok. I think I see what you're asking about. I don't have an answer,
> > but
> > > someone else such as Bruce could explain it.
> > >
> > > /Users/klund/dev/geode3 [610]$ diff
> > >
> > >
> >
> geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt
> > > geode-core/build/integrationTest/actualSerializables.dat
> > > 69d68
> > > < org/apache/geode/cache/EvictionAttributes,false
> > > 71d69
> > > < org/apache/geode/cache/ExpirationAttributes,false
> > > 79d76
> > > < org/apache/geode/cache/MembershipAttributes,false
> > > 99d95
> > > < org/apache/geode/cache/SubscriptionAttributes,false
> > > 262d257
> > > < org/apache/geode/internal/cache/EvictionAttributesImpl,false
> > > 276d270
> > > < org/apache/geode/internal/cache/PartitionAttributesImpl,false
> > > 517d510
> > > <
> > >
> > >
> >
> org/apache/geode/management/internal/cli/functions/CacheRealizationFunction,false
> > >
> > > On Thu, Sep 5, 2019 at 3:44 PM Nabarun Nag  wrote:
> > >
> > > > Hi Kirk,
> > > >
> > > > The test does not fail.
> > > > When you run the test (testSerializable) it creates a list of
> > > serializable
> > > > classes and puts it in the actualSerializables.dat file and them
> > compares
> > > > if all the classes listed are present in the
> > > > sanctioned-geode-core-serializables.txt.
> > > > If we did not change any serializabale classes then these two files
> > > > remain the same. However now in this release, there are classes in
> > > > sanctioned-geode-core-serializables.txt which are not present in
> > > > actualSerializables.dat.
> > > >
> > > > I wanted to know why are those classes are not listed in
> > > > actualSerializables.dat
> > > > and if you remove them from sanctioned-geode-core-serializables.txt
> > > > testSerializables passes but
> testSanctionedClassesExistAndDoDeserialize
> > > > fails.
> > > >
> > > > Regards
> > > > Naba
> > > >
> > > >
> > > > On Thu, Sep 5, 2019 at 3:21 PM Kirk Lund  wrote:
> > > >
> > > > > Hi Naba,
> > > > >
> > > > > I failed to reproduce the problem you reported on Mac OS, and our
> > > > pipeline
> > > > > didn't fail this test. What OS are you running integrationTest on?
> > > Here's
> > > > > the steps I followed:
> > > > >
> > > > > 1) checkout tag rel/v1.10.0.RC1
> > > > >
> > > > > $ git checkout tags/rel/v1.10.0.RC1
> > > > >
> > > > > 2) clean, then build with unit tests
> > > > >
> > > > > $ ./gradlew clean
> > > > > $ ./gradlew build
> > > > >
> > > > > 3) run Analy

Re: Updating geode-native-build docker image

[Ivan Godwin]

Anthony,

I would like access to the geode docker account. My docker username is
igodwin.

Ivan

On Wed, Aug 7, 2019 at 3:54 PM Anthony Baker  wrote:

> Committers can request access to the geode docker account to push new
> images.  Note that any geode source or binaries in these images should
> *only* include releases that have been voted on and approved by the PMC
> (e.g. v1.9.0, v1.8.0, …).
>
> Can you send me your docker username?
>
> Anthony
>
>
> > On Aug 7, 2019, at 3:47 PM, Michael Oleske  wrote:
> >
> > Hi Geode Devs!
> >
> > Geode Native merged https://github.com/apache/geode-native/pull/509 this
> > morning since our docker image was using an old Geode version.  What is
> the
> > proper way to update docker hub (
> > https://hub.docker.com/r/apachegeode/geode-native-build) with the new
> > image?  Is that something committers should be able to do?  Or is there
> an
> > automated build that updates docker hub?
> >
> > Thanks!
> > -michael
>
>

Re: PR reviewers needed

[Ivan Godwin]

Hi Alberto,

I'll have this wrapped up, this morning (PDT).

Iva

On Tue, Aug 27, 2019, 08:17 Alberto Gomez  wrote:

> Hi community,
>
> Any volunteers to review the following PR?
>
> PR in github: https://github.com/apache/geode-native/pull/511
>
> JIRA: https://issues.apache.org/jira/browse/GEODE-7061
>
> Thanks in advance,
>
> Alberto
>
>

Re: Apache Jira access

[Ivan Godwin]

igodwin

Thank you, Dan.

On Thu, Mar 22, 2018 at 9:55 AM, Dan Smith  wrote:

> Hi Ivan,
>
> What's your JIRA username?
>
> -Dan
>
> On Thu, Mar 22, 2018 at 9:53 AM, Ivan Godwin  wrote:
>
> > Hello,
> >
> > I am requesting access to Jira so that I may open issues.
> >
> > Ivan Godwin
> >
>

Apache Jira access

[Ivan Godwin]

Hello,

I am requesting access to Jira so that I may open issues.

Ivan Godwin