[jira] [Assigned] (GEODE-7230) CI failure: ClientServerTransactionFailoverDistributedTest fails with org.junit.ComparisonFailure: expected:<"TxValue-1"> but was:
[ https://issues.apache.org/jira/browse/GEODE-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Jewell reassigned GEODE-7230: --- Assignee: Eric Shu > CI failure: ClientServerTransactionFailoverDistributedTest fails with > org.junit.ComparisonFailure: expected:<"TxValue-1"> but was: > > > Key: GEODE-7230 > URL: https://issues.apache.org/jira/browse/GEODE-7230 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Scott Jewell >Assignee: Eric Shu >Priority: Major > > org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest > > > txCommitGetsAppliedOnAllTheReplicasAfterHostIsShutDownAndIfOneOfTheNodeHasCommitted > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest$$Lambda$201/1728798195.run > in VM 1 running on Host 1495863a8b47 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) > at org.apache.geode.test.dunit.VM.invoke(VM.java:406) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest.txCommitGetsAppliedOnAllTheReplicasAfterHostIsShutDownAndIfOneOfTheNodeHasCommitted(ClientServerTransactionFailoverDistributedTest.java:434) > Caused by: > org.junit.ComparisonFailure: expected:<"TxValue-1"> but was: > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest.lambda$txCommitGetsAppliedOnAllTheReplicasAfterHostIsShutDownAndIfOneOfTheNodeHasCommitted$bb17a952$7(ClientServerTransactionFailoverDistributedTest.java:436) > Concourse job: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1114 > Test results: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0150/test-results/distributedTest/1569011095/ > Test artifacts: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0150/test-artifacts/1569011095/distributedtestfiles-OpenJDK8-1.11.0-SNAPSHOT.0150.tgz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7230) CI failure: ClientServerTransactionFailoverDistributedTest fails with org.junit.ComparisonFailure: expected:<"TxValue-1"> but was:
Scott Jewell created GEODE-7230: --- Summary: CI failure: ClientServerTransactionFailoverDistributedTest fails with org.junit.ComparisonFailure: expected:<"TxValue-1"> but was: Key: GEODE-7230 URL: https://issues.apache.org/jira/browse/GEODE-7230 Project: Geode Issue Type: Bug Components: transactions Reporter: Scott Jewell org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest > txCommitGetsAppliedOnAllTheReplicasAfterHostIsShutDownAndIfOneOfTheNodeHasCommitted FAILED org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest$$Lambda$201/1728798195.run in VM 1 running on Host 1495863a8b47 with 4 VMs at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) at org.apache.geode.test.dunit.VM.invoke(VM.java:406) at org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest.txCommitGetsAppliedOnAllTheReplicasAfterHostIsShutDownAndIfOneOfTheNodeHasCommitted(ClientServerTransactionFailoverDistributedTest.java:434) Caused by: org.junit.ComparisonFailure: expected:<"TxValue-1"> but was: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at org.apache.geode.internal.cache.ClientServerTransactionFailoverDistributedTest.lambda$txCommitGetsAppliedOnAllTheReplicasAfterHostIsShutDownAndIfOneOfTheNodeHasCommitted$bb17a952$7(ClientServerTransactionFailoverDistributedTest.java:436) Concourse job: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1114 Test results: http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0150/test-results/distributedTest/1569011095/ Test artifacts: http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0150/test-artifacts/1569011095/distributedtestfiles-OpenJDK8-1.11.0-SNAPSHOT.0150.tgz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7229) v2 rest api should make it easier to use the pdx ReflectionBasedAutoSerializer
Darrel Schneider created GEODE-7229: --- Summary: v2 rest api should make it easier to use the pdx ReflectionBasedAutoSerializer Key: GEODE-7229 URL: https://issues.apache.org/jira/browse/GEODE-7229 Project: Geode Issue Type: Improvement Components: management Reporter: Darrel Schneider gfsh configure pdx makes it somewhat easy to configure the ReflectionBasedAutoSerializer. All you need to do is give say --auto-serializable-classes=PATTERN and any classes that match PATTERN will be auto serialized with pdx. Currently the v2 api requires that you set the Pdx.setPdxSerializer to a ClassName instance whose name is "org.apache.geode.pdx.ReflectionBasedAutoSerializer" and whose Properties contain one with the key "classes" and the value PATTERN. The v2 rest api should make it at least as easy as gfsh and it could probably make it even easier. We should consider making the auto serializer the default if pdx is being configured. The only issue with this is the auto serializer needs to know which classes it should serialize and which it should leave alone. So just giving it the pattern ".*" could cause jdk and other framework classes to be serialized as pdx instead of just the domain classes. Another thing that makes it more complicated with gfsh is it has two options; one for auto-serializable-classes and another for "--portable-auto-serializable-classes". This makes the command line look more complicated then it should be. I think we could instead just have the auto serializer pattern and then another boolean attribute that says if the auto serializer should check that the classes are portable. The whole portable thing has to do with making sure all the fields can be converted to the native client. Perhaps we don't need to expose this boolean if we now thing it should always be true or false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7215) Include status of G1 GC compatibility in documentation
[ https://issues.apache.org/jira/browse/GEODE-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934781#comment-16934781 ] ASF subversion and git services commented on GEODE-7215: Commit 9275edf8b26aab587f1c41f2d838a14f0615d47f in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9275edf ] GEODE-7215: Include status of G1 GC compatibility in documentation (#4066) * GEODE-7215: Include status of G1 GC compatibility in documentation * GEODE-7215: Style and ordering changes > Include status of G1 GC compatibility in documentation > -- > > Key: GEODE-7215 > URL: https://issues.apache.org/jira/browse/GEODE-7215 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Improve heap management documentation including information about the current > status of G1 garbage collector compatibility with Geode. > Although CMS seems the recommended GC, it is known G1 can be used, but it > should be stated that Geode is not fully compatible and memory issues could > arise. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7215) Include status of G1 GC compatibility in documentation
[ https://issues.apache.org/jira/browse/GEODE-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-7215. Fix Version/s: 1.11.0 Resolution: Fixed > Include status of G1 GC compatibility in documentation > -- > > Key: GEODE-7215 > URL: https://issues.apache.org/jira/browse/GEODE-7215 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Fix For: 1.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Improve heap management documentation including information about the current > status of G1 garbage collector compatibility with Geode. > Although CMS seems the recommended GC, it is known G1 can be used, but it > should be stated that Geode is not fully compatible and memory issues could > arise. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7215) Include status of G1 GC compatibility in documentation
[ https://issues.apache.org/jira/browse/GEODE-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934782#comment-16934782 ] ASF subversion and git services commented on GEODE-7215: Commit 9275edf8b26aab587f1c41f2d838a14f0615d47f in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9275edf ] GEODE-7215: Include status of G1 GC compatibility in documentation (#4066) * GEODE-7215: Include status of G1 GC compatibility in documentation * GEODE-7215: Style and ordering changes > Include status of G1 GC compatibility in documentation > -- > > Key: GEODE-7215 > URL: https://issues.apache.org/jira/browse/GEODE-7215 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Improve heap management documentation including information about the current > status of G1 garbage collector compatibility with Geode. > Although CMS seems the recommended GC, it is known G1 can be used, but it > should be stated that Geode is not fully compatible and memory issues could > arise. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7215) Include status of G1 GC compatibility in documentation
[ https://issues.apache.org/jira/browse/GEODE-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934783#comment-16934783 ] ASF subversion and git services commented on GEODE-7215: Commit 9275edf8b26aab587f1c41f2d838a14f0615d47f in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9275edf ] GEODE-7215: Include status of G1 GC compatibility in documentation (#4066) * GEODE-7215: Include status of G1 GC compatibility in documentation * GEODE-7215: Style and ordering changes > Include status of G1 GC compatibility in documentation > -- > > Key: GEODE-7215 > URL: https://issues.apache.org/jira/browse/GEODE-7215 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Improve heap management documentation including information about the current > status of G1 garbage collector compatibility with Geode. > Although CMS seems the recommended GC, it is known G1 can be used, but it > should be stated that Geode is not fully compatible and memory issues could > arise. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7209) Improve geode-native IPv6 check if hostname resolved
[ https://issues.apache.org/jira/browse/GEODE-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-7209. - Resolution: Fixed > Improve geode-native IPv6 check if hostname resolved > > > Key: GEODE-7209 > URL: https://issues.apache.org/jira/browse/GEODE-7209 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available > Fix For: 1.11.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Improve current solution for IPv6 geode-native, since integration tests were > failing on RHEL7 and Windows. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7203) C++ examples need to be updated
[ https://issues.apache.org/jira/browse/GEODE-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934769#comment-16934769 ] ASF subversion and git services commented on GEODE-7203: Commit 98520276ecf1ce5551c4c655b9ac8f686fd8695f in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=9852027 ] GEODE-7203: Update transaction example README files (#525) > C++ examples need to be updated > --- > > Key: GEODE-7203 > URL: https://issues.apache.org/jira/browse/GEODE-7203 > Project: Geode > Issue Type: Bug > Components: examples, native client >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > After reviewing the C++ native client examples I found several problems: > # Transaction - README should be updated to indicate random output; > currently it says to expect the following output, but this will be different > each time: Created cache > Created region 'exampleRegion' > Rolled back transaction - retrying(4) > Rolled back transaction - retrying(3) > Rolled back transaction - retrying(2) > Committed transaction - exiting > # functionexecution - this is the only example that spins up a server named > 'the-server'; the startserver.sh script should be updated to reflect the same > name used in all other examples 'server'. > # pdxserializable - either the README needs to change to show the actual > output of running the client app, or main.cpp should be changed to produce > the same output presented in the README. The second get (of Customer2) is > currently not formatted for printing like the first get (of Customer1). > # All examples: stopserver.sh should cleanup leftover directories locator/, > server/, and any *.gfs. If there is any reason to keep these around for > failing tests, then a separate cleanup.sh script should do this. > # authinitialize - startserver.sh fails due to extra spaces around '=' when > setting RESOLVEDPATH and AUTHENTICATOR. This example also fails to run, > instead hangs when executing getCredentials, but this was filed as GEODE-7198. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7220) NPE in the logs on reconnect
[
https://issues.apache.org/jira/browse/GEODE-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-7220.
-
Fix Version/s: 1.11.0
Resolution: Fixed
> NPE in the logs on reconnect
>
>
> Key: GEODE-7220
> URL: https://issues.apache.org/jira/browse/GEODE-7220
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
>Priority: Minor
> Fix For: 1.11.0
>
> Attachments: npe.txt
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> We saw a NullPointerException in the logs when a member reconnects, see below.
> It looks like it is likely caused by this code in JGroupsMessenger.start(),
> which is setting the receiver to null for a window of time. Because myChannel
> here is the same channel that was created before the reconnect, this means it
> may be receiving messages at this time:
> {code:java}
> myChannel.setReceiver(null);
> jgroupsReceiver = new JGroupsReceiver();
> myChannel.setReceiver(jgroupsReceiver);
> {code}
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2233
> [error 2019/09/19 17:14:01.998 GMT
> tid=81] JGRP27: failed passing message up
> java.lang.NullPointerException
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:442)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7219) BufferUnderflowException in PutReplyMessage deserialization
[
https://issues.apache.org/jira/browse/GEODE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-7219.
-
Fix Version/s: 1.11.0
Resolution: Fixed
> BufferUnderflowException in PutReplyMessage deserialization
> ---
>
> Key: GEODE-7219
> URL: https://issues.apache.org/jira/browse/GEODE-7219
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I ran into this exception in three different regression tests and see history
> of it happening in other people's tests. I think it's due to
> VersionTag.toData() making serialization decisions at the same time some
> other thread is modifying the version tag.
> {noformat}
> [fatal 2019/09/18 00:47:52.835 PDT rs-Awesome-549-1146a0i3large-hydra-client-10(bridgegemfire1_host1_12399:12399):41001
> unshared ordered uid=452 dom #2 port=46062> tid=0xdd] Error deserializing
> message
> java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:500)
> at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:249)
> at
> org.apache.geode.internal.tcp.ByteBufferInputStream$ByteBufferByteSource.get(ByteBufferInputStream.java:206)
> at
> org.apache.geode.internal.tcp.ByteBufferInputStream.readByte(ByteBufferInputStream.java:892)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readArrayLength(StaticSerialization.java:102)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readByteArray(StaticSerialization.java:321)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readInetAddress(StaticSerialization.java:254)
> at
> org.apache.geode.DataSerializer.readInetAddress(DataSerializer.java:463)
> at
> org.apache.geode.distributed.internal.membership.InternalDistributedMember._readEssentialData(InternalDistributedMember.java:1085)
> at
> org.apache.geode.distributed.internal.membership.InternalDistributedMember.readEssentialData(InternalDistributedMember.java:1079)
> at
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:58)
> at
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:31)
> at
> org.apache.geode.internal.cache.versions.VersionTag.fromData(VersionTag.java:412)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.cache.partitioned.PutMessage$PutReplyMessage.fromData(PutMessage.java:940)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2520)
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2534)
> at
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3118)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2927)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1752)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1584)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This code is trying to read a "previous member ID" for the version tag but
> there isn't one. The decision to write one or not comes from this code:
> {code}
> if (this.previousMemberID != null
> && (this.previousMemberID != this.memberID || !includeMember)) {
> writeMember(this.previousMemberID, out);
> }
> {code}
> but flags have already been written telling deserialization code whether or
> not to read this field:
> {code}
> if (this.previousMemberID != null) {
> flags |= HAS_PREVIOUS_MEMBER_ID;
> if
[jira] [Commented] (GEODE-7219) BufferUnderflowException in PutReplyMessage deserialization
[
https://issues.apache.org/jira/browse/GEODE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934729#comment-16934729
]
ASF subversion and git services commented on GEODE-7219:
Commit ea475faf8e9266eb67db618cea41ca881a1b1ed3 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ea475fa ]
GEODE-7219 BufferUnderflowException in PutReplyMessage deserialization (#4073)
* GEODE-7219 BufferUnderflowException in PutReplyMessage deserialization
VersionTag serialization was being affected by concurrent modification
of its memberId/previousMemberId fields, causing the HAS_PREVIOUS_MEMBER_ID
flag bit to be set and the DUPLICATE_MEMBER_IDS flag to _not_ be set.
It then went on to perform the same checks later in toData() and make
different decisions, winding up by not serializing the previousMemberId
field because it was then == to the memberId field.
1) decide on what the flags are going to be in toData and do not perform
the same calculations again.
2) use equals() when seeing if memberId and previousMemberId are equal.
* record used ints to avoid flakiness
> BufferUnderflowException in PutReplyMessage deserialization
> ---
>
> Key: GEODE-7219
> URL: https://issues.apache.org/jira/browse/GEODE-7219
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I ran into this exception in three different regression tests and see history
> of it happening in other people's tests. I think it's due to
> VersionTag.toData() making serialization decisions at the same time some
> other thread is modifying the version tag.
> {noformat}
> [fatal 2019/09/18 00:47:52.835 PDT rs-Awesome-549-1146a0i3large-hydra-client-10(bridgegemfire1_host1_12399:12399):41001
> unshared ordered uid=452 dom #2 port=46062> tid=0xdd] Error deserializing
> message
> java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:500)
> at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:249)
> at
> org.apache.geode.internal.tcp.ByteBufferInputStream$ByteBufferByteSource.get(ByteBufferInputStream.java:206)
> at
> org.apache.geode.internal.tcp.ByteBufferInputStream.readByte(ByteBufferInputStream.java:892)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readArrayLength(StaticSerialization.java:102)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readByteArray(StaticSerialization.java:321)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readInetAddress(StaticSerialization.java:254)
> at
> org.apache.geode.DataSerializer.readInetAddress(DataSerializer.java:463)
> at
> org.apache.geode.distributed.internal.membership.InternalDistributedMember._readEssentialData(InternalDistributedMember.java:1085)
> at
> org.apache.geode.distributed.internal.membership.InternalDistributedMember.readEssentialData(InternalDistributedMember.java:1079)
> at
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:58)
> at
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:31)
> at
> org.apache.geode.internal.cache.versions.VersionTag.fromData(VersionTag.java:412)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.cache.partitioned.PutMessage$PutReplyMessage.fromData(PutMessage.java:940)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2520)
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2534)
> at
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3118)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2927)
> at
[jira] [Commented] (GEODE-7219) BufferUnderflowException in PutReplyMessage deserialization
[
https://issues.apache.org/jira/browse/GEODE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934730#comment-16934730
]
ASF subversion and git services commented on GEODE-7219:
Commit ea475faf8e9266eb67db618cea41ca881a1b1ed3 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ea475fa ]
GEODE-7219 BufferUnderflowException in PutReplyMessage deserialization (#4073)
* GEODE-7219 BufferUnderflowException in PutReplyMessage deserialization
VersionTag serialization was being affected by concurrent modification
of its memberId/previousMemberId fields, causing the HAS_PREVIOUS_MEMBER_ID
flag bit to be set and the DUPLICATE_MEMBER_IDS flag to _not_ be set.
It then went on to perform the same checks later in toData() and make
different decisions, winding up by not serializing the previousMemberId
field because it was then == to the memberId field.
1) decide on what the flags are going to be in toData and do not perform
the same calculations again.
2) use equals() when seeing if memberId and previousMemberId are equal.
* record used ints to avoid flakiness
> BufferUnderflowException in PutReplyMessage deserialization
> ---
>
> Key: GEODE-7219
> URL: https://issues.apache.org/jira/browse/GEODE-7219
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> I ran into this exception in three different regression tests and see history
> of it happening in other people's tests. I think it's due to
> VersionTag.toData() making serialization decisions at the same time some
> other thread is modifying the version tag.
> {noformat}
> [fatal 2019/09/18 00:47:52.835 PDT rs-Awesome-549-1146a0i3large-hydra-client-10(bridgegemfire1_host1_12399:12399):41001
> unshared ordered uid=452 dom #2 port=46062> tid=0xdd] Error deserializing
> message
> java.nio.BufferUnderflowException
> at java.nio.Buffer.nextGetIndex(Buffer.java:500)
> at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:249)
> at
> org.apache.geode.internal.tcp.ByteBufferInputStream$ByteBufferByteSource.get(ByteBufferInputStream.java:206)
> at
> org.apache.geode.internal.tcp.ByteBufferInputStream.readByte(ByteBufferInputStream.java:892)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readArrayLength(StaticSerialization.java:102)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readByteArray(StaticSerialization.java:321)
> at
> org.apache.geode.internal.serialization.StaticSerialization.readInetAddress(StaticSerialization.java:254)
> at
> org.apache.geode.DataSerializer.readInetAddress(DataSerializer.java:463)
> at
> org.apache.geode.distributed.internal.membership.InternalDistributedMember._readEssentialData(InternalDistributedMember.java:1085)
> at
> org.apache.geode.distributed.internal.membership.InternalDistributedMember.readEssentialData(InternalDistributedMember.java:1079)
> at
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:58)
> at
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:31)
> at
> org.apache.geode.internal.cache.versions.VersionTag.fromData(VersionTag.java:412)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.cache.partitioned.PutMessage$PutReplyMessage.fromData(PutMessage.java:940)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
> at
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2520)
> at
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2534)
> at
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3118)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2927)
> at
[jira] [Commented] (GEODE-7220) NPE in the logs on reconnect
[
https://issues.apache.org/jira/browse/GEODE-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934727#comment-16934727
]
ASF subversion and git services commented on GEODE-7220:
Commit 8aad7468e53e9eb08958116e549d9db7ea36df79 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8aad746 ]
GEODE-7220 NPE in the logs on reconnect (#4074)
* GEODE-7220 NPE in the logs on reconnect
Use reflection to poke a new Receiver into JGroups to avoid
synchronization problems in JGroups code.
No new tests were needed.
* rewrote comment - we're trying to avoid a warning message and an NPE
> NPE in the logs on reconnect
>
>
> Key: GEODE-7220
> URL: https://issues.apache.org/jira/browse/GEODE-7220
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
>Priority: Minor
> Attachments: npe.txt
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> We saw a NullPointerException in the logs when a member reconnects, see below.
> It looks like it is likely caused by this code in JGroupsMessenger.start(),
> which is setting the receiver to null for a window of time. Because myChannel
> here is the same channel that was created before the reconnect, this means it
> may be receiving messages at this time:
> {code:java}
> myChannel.setReceiver(null);
> jgroupsReceiver = new JGroupsReceiver();
> myChannel.setReceiver(jgroupsReceiver);
> {code}
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2233
> [error 2019/09/19 17:14:01.998 GMT
> tid=81] JGRP27: failed passing message up
> java.lang.NullPointerException
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:442)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7220) NPE in the logs on reconnect
[
https://issues.apache.org/jira/browse/GEODE-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934728#comment-16934728
]
ASF subversion and git services commented on GEODE-7220:
Commit 8aad7468e53e9eb08958116e549d9db7ea36df79 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8aad746 ]
GEODE-7220 NPE in the logs on reconnect (#4074)
* GEODE-7220 NPE in the logs on reconnect
Use reflection to poke a new Receiver into JGroups to avoid
synchronization problems in JGroups code.
No new tests were needed.
* rewrote comment - we're trying to avoid a warning message and an NPE
> NPE in the logs on reconnect
>
>
> Key: GEODE-7220
> URL: https://issues.apache.org/jira/browse/GEODE-7220
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Assignee: Bruce Schuchardt
>Priority: Minor
> Attachments: npe.txt
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> We saw a NullPointerException in the logs when a member reconnects, see below.
> It looks like it is likely caused by this code in JGroupsMessenger.start(),
> which is setting the receiver to null for a window of time. Because myChannel
> here is the same channel that was created before the reconnect, this means it
> may be receiving messages at this time:
> {code:java}
> myChannel.setReceiver(null);
> jgroupsReceiver = new JGroupsReceiver();
> myChannel.setReceiver(jgroupsReceiver);
> {code}
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2233
> [error 2019/09/19 17:14:01.998 GMT
> tid=81] JGRP27: failed passing message up
> java.lang.NullPointerException
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:442)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-3124) Extract gfsh into its own module
[ https://issues.apache.org/jira/browse/GEODE-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-3124. Resolution: Duplicate Marking as duplicate. > Extract gfsh into its own module > > > Key: GEODE-3124 > URL: https://issues.apache.org/jira/browse/GEODE-3124 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Swapnil Bawaskar >Priority: Major > > gfsh is embedded in the geode-core, it should move to its own module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7209) Improve geode-native IPv6 check if hostname resolved
[ https://issues.apache.org/jira/browse/GEODE-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934688#comment-16934688 ] ASF subversion and git services commented on GEODE-7209: Commit d15dc7a320566e49eef86de307c916b3616b5cfb in geode-native's branch refs/heads/develop from mivanac [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d15dc7a ] GEODE-7209: Modify check if hostname is resolved (#521) > Improve geode-native IPv6 check if hostname resolved > > > Key: GEODE-7209 > URL: https://issues.apache.org/jira/browse/GEODE-7209 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available > Fix For: 1.11.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Improve current solution for IPv6 geode-native, since integration tests were > failing on RHEL7 and Windows. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7228) v2 rest api configuration classes need more test coverage
Darrel Schneider created GEODE-7228: --- Summary: v2 rest api configuration classes need more test coverage Key: GEODE-7228 URL: https://issues.apache.org/jira/browse/GEODE-7228 Project: Geode Issue Type: Improvement Components: management Reporter: Darrel Schneider Some of the settor methods on the AbstractConfiguration subclasses are never called in tests that actually serialize the configuration into json. This caused us to miss bug GEODE-7227. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7227) ClassName attributes do not work with v2 rest api
Darrel Schneider created GEODE-7227: --- Summary: ClassName attributes do not work with v2 rest api Key: GEODE-7227 URL: https://issues.apache.org/jira/browse/GEODE-7227 Project: Geode Issue Type: Bug Components: management Reporter: Darrel Schneider If you try to specify a ClassName attribute with the v2 rest api, by calling Pdx.setPdxSerializer or GatewayReceiver.setGatewayTransportFilters then an exception will occur saying it could not create an instance of ClassName. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7076) Pdx should not have group, groups
[ https://issues.apache.org/jira/browse/GEODE-7076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-7076. - Fix Version/s: 1.11.0 Resolution: Fixed > Pdx should not have group, groups > - > > Key: GEODE-7076 > URL: https://issues.apache.org/jira/browse/GEODE-7076 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Gang Yan >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.11.0 > > Time Spent: 40m > Remaining Estimate: 0h > > For REST API V2 for management, Swagger shows that the model for Pdx includes > "group", "groups". > None of these should be specified when doing a POST Pdx. If you do specify > group you get an error saying Pdx is only at the cluster level. > group and groups comes from CacheElement. Could the Pdx class override them > and mark them with @JsonIgnore? > The java-api exposes these on Pdx and it would be best if it didn't. If we > did some refactoring so that Pdx did not have these methods on it them this > would clean up the rest-api automatically. > Objective: > # find a way to hide these attributes from Swagger docs. > # is there a way to hide "group"/"groups" from the java api as well > The best solution might be to just have "group" and not "groups". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7203) C++ examples need to be updated
[ https://issues.apache.org/jira/browse/GEODE-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934641#comment-16934641 ] ASF subversion and git services commented on GEODE-7203: Commit a255fe804ac789e51e299d42392c4211f74f2bf7 in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=a255fe8 ] GEODE-7203: Fix build break in examples (#524) - std::endl doesn't work in string concatenation expression > C++ examples need to be updated > --- > > Key: GEODE-7203 > URL: https://issues.apache.org/jira/browse/GEODE-7203 > Project: Geode > Issue Type: Bug > Components: examples, native client >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > After reviewing the C++ native client examples I found several problems: > # Transaction - README should be updated to indicate random output; > currently it says to expect the following output, but this will be different > each time: Created cache > Created region 'exampleRegion' > Rolled back transaction - retrying(4) > Rolled back transaction - retrying(3) > Rolled back transaction - retrying(2) > Committed transaction - exiting > # functionexecution - this is the only example that spins up a server named > 'the-server'; the startserver.sh script should be updated to reflect the same > name used in all other examples 'server'. > # pdxserializable - either the README needs to change to show the actual > output of running the client app, or main.cpp should be changed to produce > the same output presented in the README. The second get (of Customer2) is > currently not formatted for printing like the first get (of Customer1). > # All examples: stopserver.sh should cleanup leftover directories locator/, > server/, and any *.gfs. If there is any reason to keep these around for > failing tests, then a separate cleanup.sh script should do this. > # authinitialize - startserver.sh fails due to extra spaces around '=' when > setting RESOLVEDPATH and AUTHENTICATOR. This example also fails to run, > instead hangs when executing getCredentials, but this was filed as GEODE-7198. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7206) met exception when run "gfsh sh"
[ https://issues.apache.org/jira/browse/GEODE-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934617#comment-16934617 ] Gang Yan commented on GEODE-7206: - thanks, Mario. after added "--use-console=true", it works. maybe , we need to update documentation to cover this case. > met exception when run "gfsh sh" > > > Key: GEODE-7206 > URL: https://issues.apache.org/jira/browse/GEODE-7206 > Project: Geode > Issue Type: Bug > Components: gfsh, management >Reporter: Gang Yan >Priority: Minor > Attachments: Screen Shot 2019-09-13 at 10.05.46 AM.png > > > met exception , when run "sh ls -al" in gfsh as documentation > [https://gemfire.docs.pivotal.io/98/geode/tools_modules/gfsh/command-pages/sh.html] > > please refer to the attachment. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7221) Management regions never close dedicated CachePerfStats
[
https://issues.apache.org/jira/browse/GEODE-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934606#comment-16934606
]
ASF subversion and git services commented on GEODE-7221:
Commit 6d3dd7b37cf4b7f64b383b9e8087fbf21c0303f6 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d3dd7b ]
GEODE-7221: Set hasOwnStats true for management regions
Ensure that managements regions close CachePerfStats by setting
hasOwnStats to true from FederatingManager and LocalManager.
> Management regions never close dedicated CachePerfStats
> ---
>
> Key: GEODE-7221
> URL: https://issues.apache.org/jira/browse/GEODE-7221
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The FederatingManager and LocalManager classes create the monitoring and
> notification regions for management of each member. They are constructing
> injecting HasCachePerfStats instances with their own dedicated instances of
> CachePerfStats into InternalRegionArgs:
> {noformat}
> InternalRegionArgs.setCachePerfStatsHolder(HasCachePerfStats)
> {noformat}
> Over in LocalRegion, the field hasOwnStats is set to false:
> {noformat}
> if (internalRegionArgs.getCachePerfStatsHolder() != null) {
> hasOwnStats = false;
> cachePerfStats =
> internalRegionArgs.getCachePerfStatsHolder().getCachePerfStats();
> {noformat}
> Which results in region destroy not closing the CachePerfStats.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7221) Management regions never close dedicated CachePerfStats
[
https://issues.apache.org/jira/browse/GEODE-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934604#comment-16934604
]
ASF subversion and git services commented on GEODE-7221:
Commit c19c1742fc89a4ef9ec6372f289e6b6e639943bd in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c19c174 ]
GEODE-7221: Cleanup and unit test FederatingManager
* Move inner classes to bottom of outer class
* Extract addMemberArtifacts from GIITask
* Remove unnecessary code
* Create FederatingManagerTest
> Management regions never close dedicated CachePerfStats
> ---
>
> Key: GEODE-7221
> URL: https://issues.apache.org/jira/browse/GEODE-7221
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The FederatingManager and LocalManager classes create the monitoring and
> notification regions for management of each member. They are constructing
> injecting HasCachePerfStats instances with their own dedicated instances of
> CachePerfStats into InternalRegionArgs:
> {noformat}
> InternalRegionArgs.setCachePerfStatsHolder(HasCachePerfStats)
> {noformat}
> Over in LocalRegion, the field hasOwnStats is set to false:
> {noformat}
> if (internalRegionArgs.getCachePerfStatsHolder() != null) {
> hasOwnStats = false;
> cachePerfStats =
> internalRegionArgs.getCachePerfStatsHolder().getCachePerfStats();
> {noformat}
> Which results in region destroy not closing the CachePerfStats.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7221) Management regions never close dedicated CachePerfStats
[
https://issues.apache.org/jira/browse/GEODE-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-7221.
--
Fix Version/s: 1.11.0
Resolution: Fixed
> Management regions never close dedicated CachePerfStats
> ---
>
> Key: GEODE-7221
> URL: https://issues.apache.org/jira/browse/GEODE-7221
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The FederatingManager and LocalManager classes create the monitoring and
> notification regions for management of each member. They are constructing
> injecting HasCachePerfStats instances with their own dedicated instances of
> CachePerfStats into InternalRegionArgs:
> {noformat}
> InternalRegionArgs.setCachePerfStatsHolder(HasCachePerfStats)
> {noformat}
> Over in LocalRegion, the field hasOwnStats is set to false:
> {noformat}
> if (internalRegionArgs.getCachePerfStatsHolder() != null) {
> hasOwnStats = false;
> cachePerfStats =
> internalRegionArgs.getCachePerfStatsHolder().getCachePerfStats();
> {noformat}
> Which results in region destroy not closing the CachePerfStats.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7221) Management regions never close dedicated CachePerfStats
[
https://issues.apache.org/jira/browse/GEODE-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934605#comment-16934605
]
ASF subversion and git services commented on GEODE-7221:
Commit a3fba6ceab204b2086d6224688653c9f6837c2e8 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a3fba6c ]
GEODE-7221: Cleanup and unit test LocalManager
* Move inner class to bottom of outer class
* Remove unnecessary code
* Extract doManagementTask from ManagementTask
* Create LocalManagerTest
> Management regions never close dedicated CachePerfStats
> ---
>
> Key: GEODE-7221
> URL: https://issues.apache.org/jira/browse/GEODE-7221
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Fix For: 1.11.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The FederatingManager and LocalManager classes create the monitoring and
> notification regions for management of each member. They are constructing
> injecting HasCachePerfStats instances with their own dedicated instances of
> CachePerfStats into InternalRegionArgs:
> {noformat}
> InternalRegionArgs.setCachePerfStatsHolder(HasCachePerfStats)
> {noformat}
> Over in LocalRegion, the field hasOwnStats is set to false:
> {noformat}
> if (internalRegionArgs.getCachePerfStatsHolder() != null) {
> hasOwnStats = false;
> cachePerfStats =
> internalRegionArgs.getCachePerfStatsHolder().getCachePerfStats();
> {noformat}
> Which results in region destroy not closing the CachePerfStats.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7196) Simplify ClusterDistributionManager
[ https://issues.apache.org/jira/browse/GEODE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934594#comment-16934594 ] ASF subversion and git services commented on GEODE-7196: Commit 702f8bdf369ed0ee4e5139fa4c071b544200906f in geode's branch refs/heads/feature/GEODE-7196 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=702f8bd ] GEODE-7196 Simplify ClusterDistributionManage Initial commit - move executors out of ClusterDistributionManager / LonerDistributionManager. The executors are still owned by the distribution manager but no longer clutter up the class. > Simplify ClusterDistributionManager > --- > > Key: GEODE-7196 > URL: https://issues.apache.org/jira/browse/GEODE-7196 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce Schuchardt >Priority: Major > > ClusterDistributionManager maintains its own idea of cluster membership apart > from the membership manager. It also holds Executors for processing > messages. Let's get rid of the membership management and move the executors > some-place else. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7146) Document Aggregate Function Limitations
[
https://issues.apache.org/jira/browse/GEODE-7146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934593#comment-16934593
]
ASF subversion and git services commented on GEODE-7146:
Commit 003b213309574b3a00bfa3283ce5aeb5cfddc762 in geode's branch
refs/heads/feature/GEODE-7196 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=003b213 ]
GEODE-7146: Improve Aggregate Function Docs (#3996)
- Remove "no-quick-link" class from anchors.
- Corrected the return type description for SUM, COUNT and AVG.
- Re-introduced the standalone page entirely dedicated to aggregate
functions, along with the relevant menu item.
- Documented current limitations of aggregate functions in relation
to overflow.
> Document Aggregate Function Limitations
> ---
>
> Key: GEODE-7146
> URL: https://issues.apache.org/jira/browse/GEODE-7146
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.11.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Make sure the docs cover the concerns about things that can't be done with
> aggregate functions.
> Some of the concerns/limitations to add in the documentation:
> * Can't be used in {{CQ}}.
> * What happens if {{SUM}} result is higher than {{Double.MAX_VALUE}}.
> * What happens if {{COUNT}} result is higher than {{Long.MAX_VALUE}}.
> * What happens if {{AVG}} result is {{Infinity}} (floating-point operation
> that overflows).
> * What happens if the intermediate count, when calculating the {{AVG}}
> operation, is higher than {{Long.MAX_VALUE}}.
> * What happens if the intermediate summation, when calculating the {{AVG}}
> operation, is higher than {{Double.MAX_VALUE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6014) Remove unnecessary null checks in the code.
[ https://issues.apache.org/jira/browse/GEODE-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934592#comment-16934592 ] ASF subversion and git services commented on GEODE-6014: Commit a505682dbaccc878ef80579b12b7bdf8b941aed7 in geode's branch refs/heads/develop from nabarunnag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a505682 ] GEODE-6014: Removed redundant null check > Remove unnecessary null checks in the code. > --- > > Key: GEODE-6014 > URL: https://issues.apache.org/jira/browse/GEODE-6014 > Project: Geode > Issue Type: Bug >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7226) StaticFieldsMustBeImmutable Rule Fails to detect @Immutable at the class level
[
https://issues.apache.org/jira/browse/GEODE-7226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-7226:
---
Assignee: Juan José Ramos Cassella
> StaticFieldsMustBeImmutable Rule Fails to detect @Immutable at the class level
> --
>
> Key: GEODE-7226
> URL: https://issues.apache.org/jira/browse/GEODE-7226
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> The {{StaticFieldsMustBeImmutable}} rule fails to detect the {{@Immutable}}
> annotation at the class level, forcing you to annotate every single
> effectively immutable static field individually.
> According to the rule documentation, however, annotating the class directly
> is supported:
> {quote}If the value of your static field is actually immutable, you can
> annotate that class or the field itself with @Immutable, and it will be
> ignored by this rule.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7226) StaticFieldsMustBeImmutable Rule Fails to detect @Immutable at the class level
Juan José Ramos Cassella created GEODE-7226:
---
Summary: StaticFieldsMustBeImmutable Rule Fails to detect
@Immutable at the class level
Key: GEODE-7226
URL: https://issues.apache.org/jira/browse/GEODE-7226
Project: Geode
Issue Type: Bug
Components: build
Reporter: Juan José Ramos Cassella
The {{StaticFieldsMustBeImmutable}} rule fails to detect the {{@Immutable}}
annotation at the class level, forcing you to annotate every single effectively
immutable static field individually.
According to the rule documentation, however, annotating the class directly is
supported:
{quote}If the value of your static field is actually immutable, you can
annotate that class or the field itself with @Immutable, and it will be ignored
by this rule.
{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7226) StaticFieldsMustBeImmutable Rule Fails to detect @Immutable at the class level
[
https://issues.apache.org/jira/browse/GEODE-7226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-7226:
Labels: GeodeCommons (was: )
> StaticFieldsMustBeImmutable Rule Fails to detect @Immutable at the class level
> --
>
> Key: GEODE-7226
> URL: https://issues.apache.org/jira/browse/GEODE-7226
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> The {{StaticFieldsMustBeImmutable}} rule fails to detect the {{@Immutable}}
> annotation at the class level, forcing you to annotate every single
> effectively immutable static field individually.
> According to the rule documentation, however, annotating the class directly
> is supported:
> {quote}If the value of your static field is actually immutable, you can
> annotate that class or the field itself with @Immutable, and it will be
> ignored by this rule.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7224) Add metrics for FunctionExecution
[ https://issues.apache.org/jira/browse/GEODE-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934506#comment-16934506 ] Aaron Lindsey commented on GEODE-7224: -- [~mhansonp] Is this a duplicate of GEODE-7184? > Add metrics for FunctionExecution > - > > Key: GEODE-7224 > URL: https://issues.apache.org/jira/browse/GEODE-7224 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Mark Hanson >Priority: Major > > Add metrics so that FunctionExecutions information is available to micrometer. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-1929) Specifying ORDER BY in a OQL Query should not require the SELECT to be DISTINCT
[
https://issues.apache.org/jira/browse/GEODE-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-1929.
-
Resolution: Not A Problem
I've tested this with the latest Geode version and it works just fine,
apparently using {{DISTINCT}} is not a requirement anymore for {{ORDER BY}} to
work properly.
> Specifying ORDER BY in a OQL Query should not require the SELECT to be
> DISTINCT
> ---
>
> Key: GEODE-1929
> URL: https://issues.apache.org/jira/browse/GEODE-1929
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: John Blum
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Currently, when a user writes a sorted OQL query, the user would specify an
> {{ORDER BY}} clause indicating which object properties to sort on along with
> the direction of the sort. Additionally, for some non-apparent reason, Geode
> also requires the result of the query to be unique (a.k.a. {{DISTINCT}}).
> Therefore, the following query would be considered invalid by Geode...
> {code:sql}
> SELECT * FROM /People p WHERE p.lastname = 'Doe' ORDER BY p.lastname ASC,
> p.birthDate DESC
> {code}
> To correct this query, a user much specify the {{DISTINCT}} OQL keyword...
> {code:sql}
> SELECT DISTINCT * FROM /People p WHERE p.lastname = 'Doe' ORDER BY p.lastname
> ASC, p.birthDate DESC
> {code}
> However, sorting has nothing to do with uniqueness as it is still possible to
> sort results even when they contain duplicates.
> This seems to be a technical limitation in Geode rather than an apparent
> limitation of data grid technology, which has be inappropriately exposed to
> the end user.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-1929) Specifying ORDER BY in a OQL Query should not require the SELECT to be DISTINCT
[
https://issues.apache.org/jira/browse/GEODE-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-1929:
---
Assignee: Juan José Ramos Cassella
> Specifying ORDER BY in a OQL Query should not require the SELECT to be
> DISTINCT
> ---
>
> Key: GEODE-1929
> URL: https://issues.apache.org/jira/browse/GEODE-1929
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: John Blum
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Currently, when a user writes a sorted OQL query, the user would specify an
> {{ORDER BY}} clause indicating which object properties to sort on along with
> the direction of the sort. Additionally, for some non-apparent reason, Geode
> also requires the result of the query to be unique (a.k.a. {{DISTINCT}}).
> Therefore, the following query would be considered invalid by Geode...
> {code:sql}
> SELECT * FROM /People p WHERE p.lastname = 'Doe' ORDER BY p.lastname ASC,
> p.birthDate DESC
> {code}
> To correct this query, a user much specify the {{DISTINCT}} OQL keyword...
> {code:sql}
> SELECT DISTINCT * FROM /People p WHERE p.lastname = 'Doe' ORDER BY p.lastname
> ASC, p.birthDate DESC
> {code}
> However, sorting has nothing to do with uniqueness as it is still possible to
> sort results even when they contain duplicates.
> This seems to be a technical limitation in Geode rather than an apparent
> limitation of data grid technology, which has be inappropriately exposed to
> the end user.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-126) Provide pre-canned Geode Functions out-of-the-box for useful, common Geode operations.
[
https://issues.apache.org/jira/browse/GEODE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella updated GEODE-126:
---
Labels: ApacheGeode Canned Functions Out-of-the-Box affects-spring docs
(was: ApacheGeode Canned Functions Out-of-the-Box docs)
> Provide pre-canned Geode Functions out-of-the-box for useful, common Geode
> operations.
> --
>
> Key: GEODE-126
> URL: https://issues.apache.org/jira/browse/GEODE-126
> Project: Geode
> Issue Type: Improvement
> Components: functions
>Affects Versions: 1.0.0-incubating
> Environment: Apache Geode + Cache Clients
>Reporter: John Blum
>Priority: Major
> Labels: ApacheGeode, Canned, Functions, Out-of-the-Box,
> affects-spring, docs
>
> There were many useful _Geode_
> [Function(s)|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/cache/execute/Function.java]
> created to implement many of _Geode's_ features.
> For instance, _Gfsh_ commands were nearly all implemented with _Geode_
> [Functions|https://github.com/apache/incubator-geode/tree/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions].
> Some of these {{Functions}} should be provided out-of-the-box, as pre-canned
> {{Functions}} that users can use and documented as such.
> One good +example+ of such a {{Function}} is the _Gfsh's_ {{list functions}}
> command {{Function}}...
> [ListFunctionFunction|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/ListFunctionFunction.java].
> There are many more like
> [ListFunctionFunction|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/ListFunctionFunction.java]
> that would be equally useful to provide in a non-internal API, supported by
> Geode out-of-the-box.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7225) Update OpenSSL download URL in Windows Packer script
[ https://issues.apache.org/jira/browse/GEODE-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934429#comment-16934429 ] ASF subversion and git services commented on GEODE-7225: Commit b4c688df4c3fa34e7170cd58266afb93e0970f11 in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=b4c688d ] GEODE-7225: Change download URL from 'c' to 'd', to reflect update on OpenSSL site (#523) > Update OpenSSL download URL in Windows Packer script > > > Key: GEODE-7225 > URL: https://issues.apache.org/jira/browse/GEODE-7225 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > The Windows build of OpenSSL has bumped from 1.1c to 1.1d, and our download > script for Windows is now failing with 404 errors. Just need to change one > character in the URL and we're good to go. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7225) Update OpenSSL download URL in Windows Packer script
Blake Bender created GEODE-7225: --- Summary: Update OpenSSL download URL in Windows Packer script Key: GEODE-7225 URL: https://issues.apache.org/jira/browse/GEODE-7225 Project: Geode Issue Type: Bug Components: native client Reporter: Blake Bender The Windows build of OpenSSL has bumped from 1.1c to 1.1d, and our download script for Windows is now failing with 404 errors. Just need to change one character in the URL and we're good to go. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7203) C++ examples need to be updated
[ https://issues.apache.org/jira/browse/GEODE-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-7203. - Resolution: Fixed > C++ examples need to be updated > --- > > Key: GEODE-7203 > URL: https://issues.apache.org/jira/browse/GEODE-7203 > Project: Geode > Issue Type: Bug > Components: examples, native client >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > After reviewing the C++ native client examples I found several problems: > # Transaction - README should be updated to indicate random output; > currently it says to expect the following output, but this will be different > each time: Created cache > Created region 'exampleRegion' > Rolled back transaction - retrying(4) > Rolled back transaction - retrying(3) > Rolled back transaction - retrying(2) > Committed transaction - exiting > # functionexecution - this is the only example that spins up a server named > 'the-server'; the startserver.sh script should be updated to reflect the same > name used in all other examples 'server'. > # pdxserializable - either the README needs to change to show the actual > output of running the client app, or main.cpp should be changed to produce > the same output presented in the README. The second get (of Customer2) is > currently not formatted for printing like the first get (of Customer1). > # All examples: stopserver.sh should cleanup leftover directories locator/, > server/, and any *.gfs. If there is any reason to keep these around for > failing tests, then a separate cleanup.sh script should do this. > # authinitialize - startserver.sh fails due to extra spaces around '=' when > setting RESOLVEDPATH and AUTHENTICATOR. This example also fails to run, > instead hangs when executing getCredentials, but this was filed as GEODE-7198. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7203) C++ examples need to be updated
[ https://issues.apache.org/jira/browse/GEODE-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-7203. --- > C++ examples need to be updated > --- > > Key: GEODE-7203 > URL: https://issues.apache.org/jira/browse/GEODE-7203 > Project: Geode > Issue Type: Bug > Components: examples, native client >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > After reviewing the C++ native client examples I found several problems: > # Transaction - README should be updated to indicate random output; > currently it says to expect the following output, but this will be different > each time: Created cache > Created region 'exampleRegion' > Rolled back transaction - retrying(4) > Rolled back transaction - retrying(3) > Rolled back transaction - retrying(2) > Committed transaction - exiting > # functionexecution - this is the only example that spins up a server named > 'the-server'; the startserver.sh script should be updated to reflect the same > name used in all other examples 'server'. > # pdxserializable - either the README needs to change to show the actual > output of running the client app, or main.cpp should be changed to produce > the same output presented in the README. The second get (of Customer2) is > currently not formatted for printing like the first get (of Customer1). > # All examples: stopserver.sh should cleanup leftover directories locator/, > server/, and any *.gfs. If there is any reason to keep these around for > failing tests, then a separate cleanup.sh script should do this. > # authinitialize - startserver.sh fails due to extra spaces around '=' when > setting RESOLVEDPATH and AUTHENTICATOR. This example also fails to run, > instead hangs when executing getCredentials, but this was filed as GEODE-7198. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7203) C++ examples need to be updated
[ https://issues.apache.org/jira/browse/GEODE-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934392#comment-16934392 ] ASF subversion and git services commented on GEODE-7203: Commit e68052d90fa08f7d256a1cc1c745926bfd02d0ea in geode-native's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=e68052d ] GEODE-7203: Some updates in examples (#522) Clean up server and locator directories after running examples. Aside from keeping things tidy, this makes a big difference in startup times when running examples multiple times. > C++ examples need to be updated > --- > > Key: GEODE-7203 > URL: https://issues.apache.org/jira/browse/GEODE-7203 > Project: Geode > Issue Type: Bug > Components: examples, native client >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > After reviewing the C++ native client examples I found several problems: > # Transaction - README should be updated to indicate random output; > currently it says to expect the following output, but this will be different > each time: Created cache > Created region 'exampleRegion' > Rolled back transaction - retrying(4) > Rolled back transaction - retrying(3) > Rolled back transaction - retrying(2) > Committed transaction - exiting > # functionexecution - this is the only example that spins up a server named > 'the-server'; the startserver.sh script should be updated to reflect the same > name used in all other examples 'server'. > # pdxserializable - either the README needs to change to show the actual > output of running the client app, or main.cpp should be changed to produce > the same output presented in the README. The second get (of Customer2) is > currently not formatted for printing like the first get (of Customer1). > # All examples: stopserver.sh should cleanup leftover directories locator/, > server/, and any *.gfs. If there is any reason to keep these around for > failing tests, then a separate cleanup.sh script should do this. > # authinitialize - startserver.sh fails due to extra spaces around '=' when > setting RESOLVEDPATH and AUTHENTICATOR. This example also fails to run, > instead hangs when executing getCredentials, but this was filed as GEODE-7198. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7203) C++ examples need to be updated
[ https://issues.apache.org/jira/browse/GEODE-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-7203: Labels: pull-request-available (was: ) > C++ examples need to be updated > --- > > Key: GEODE-7203 > URL: https://issues.apache.org/jira/browse/GEODE-7203 > Project: Geode > Issue Type: Bug > Components: examples, native client >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > After reviewing the C++ native client examples I found several problems: > # Transaction - README should be updated to indicate random output; > currently it says to expect the following output, but this will be different > each time: Created cache > Created region 'exampleRegion' > Rolled back transaction - retrying(4) > Rolled back transaction - retrying(3) > Rolled back transaction - retrying(2) > Committed transaction - exiting > # functionexecution - this is the only example that spins up a server named > 'the-server'; the startserver.sh script should be updated to reflect the same > name used in all other examples 'server'. > # pdxserializable - either the README needs to change to show the actual > output of running the client app, or main.cpp should be changed to produce > the same output presented in the README. The second get (of Customer2) is > currently not formatted for printing like the first get (of Customer1). > # All examples: stopserver.sh should cleanup leftover directories locator/, > server/, and any *.gfs. If there is any reason to keep these around for > failing tests, then a separate cleanup.sh script should do this. > # authinitialize - startserver.sh fails due to extra spaces around '=' when > setting RESOLVEDPATH and AUTHENTICATOR. This example also fails to run, > instead hangs when executing getCredentials, but this was filed as GEODE-7198. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7203) C++ examples need to be updated
[ https://issues.apache.org/jira/browse/GEODE-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-7203: Priority: Minor (was: Major) > C++ examples need to be updated > --- > > Key: GEODE-7203 > URL: https://issues.apache.org/jira/browse/GEODE-7203 > Project: Geode > Issue Type: Bug > Components: examples, native client >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > After reviewing the C++ native client examples I found several problems: > # Transaction - README should be updated to indicate random output; > currently it says to expect the following output, but this will be different > each time: Created cache > Created region 'exampleRegion' > Rolled back transaction - retrying(4) > Rolled back transaction - retrying(3) > Rolled back transaction - retrying(2) > Committed transaction - exiting > # functionexecution - this is the only example that spins up a server named > 'the-server'; the startserver.sh script should be updated to reflect the same > name used in all other examples 'server'. > # pdxserializable - either the README needs to change to show the actual > output of running the client app, or main.cpp should be changed to produce > the same output presented in the README. The second get (of Customer2) is > currently not formatted for printing like the first get (of Customer1). > # All examples: stopserver.sh should cleanup leftover directories locator/, > server/, and any *.gfs. If there is any reason to keep these around for > failing tests, then a separate cleanup.sh script should do this. > # authinitialize - startserver.sh fails due to extra spaces around '=' when > setting RESOLVEDPATH and AUTHENTICATOR. This example also fails to run, > instead hangs when executing getCredentials, but this was filed as GEODE-7198. -- This message was sent by Atlassian Jira (v8.3.4#803005)
