[jira] [Resolved] (GEODE-2091) PartitionedRegion containsValueForKey() in transaction may return false if there is a rebalance
[ https://issues.apache.org/jira/browse/GEODE-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-2091. - Resolution: Fixed Fix Version/s: 1.1.0-incubating > PartitionedRegion containsValueForKey() in transaction may return false if > there is a rebalance > --- > > Key: GEODE-2091 > URL: https://issues.apache.org/jira/browse/GEODE-2091 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu > Fix For: 1.1.0-incubating > > > PartitionedRegion containsValueForKey() in transaction may return false if > the bucket contains the entry is moved to other node due to rebalance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2091) PartitionedRegion containsValueForKey() in transaction may return false if there is a rebalance
[ https://issues.apache.org/jira/browse/GEODE-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-2091: --- Assignee: Eric Shu > PartitionedRegion containsValueForKey() in transaction may return false if > there is a rebalance > --- > > Key: GEODE-2091 > URL: https://issues.apache.org/jira/browse/GEODE-2091 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu > Fix For: 1.1.0-incubating > > > PartitionedRegion containsValueForKey() in transaction may return false if > the bucket contains the entry is moved to other node due to rebalance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2080) Rest POST put call not working with region valueConstraint
[ https://issues.apache.org/jira/browse/GEODE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-2080. - Resolution: Fixed Fix Version/s: 1.1.0-incubating > Rest POST put call not working with region valueConstraint > -- > > Key: GEODE-2080 > URL: https://issues.apache.org/jira/browse/GEODE-2080 > Project: Geode > Issue Type: Bug > Components: rest (dev) >Reporter: Bruce Schuchardt > Fix For: 1.1.0-incubating > > > Gemfire REST POST call does not work on a region with value constraint eg If > I have a region definition like > > > > >com.support.pivotal.domain.Company > > > > and try to do a POST call like > ResponseEntity< String> result = RestClientUtils.getRestTemplate().exchange( > "http://localhost:8080/gemfire-api/v1/regionOne?key=CITI-123"; , > HttpMethod.POST, >entity, String.class); > It fails, whereas If I remove the value constraint in the region definition > it works fine. It is eaily reproducible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2089) entry-idle-time setting on the client side cache is not working as expected
[ https://issues.apache.org/jira/browse/GEODE-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-2089. - Resolution: Fixed Fix Version/s: 1.1.0-incubating > entry-idle-time setting on the client side cache is not working as expected > > > Key: GEODE-2089 > URL: https://issues.apache.org/jira/browse/GEODE-2089 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt > Fix For: 1.1.0-incubating > > > I wrote a unit test that sets an entry-idle-time timeout on a client cache > with action local-destroy. When the client cache pulls an old entry from the > server the cache appears to ignore the entry-idle-time and expires the entry > immediately after it is put in the cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2080) Rest POST put call not working with region valueConstraint
[ https://issues.apache.org/jira/browse/GEODE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655495#comment-15655495 ] ASF subversion and git services commented on GEODE-2080: Commit d65b79a4634325edb73e2136f1e59d6879845faf in incubator-geode's branch refs/heads/develop from [~bschuchardt] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d65b79a ] GEODE-2080 Rest POST put call not working with region valueConstraint If you set a value constraint on a cache Region you will be unable to store objects in the region via the Rest API. This change-set modifies LocalRegion's constraint check to look for a Rest document and use its type name in the constraint check > Rest POST put call not working with region valueConstraint > -- > > Key: GEODE-2080 > URL: https://issues.apache.org/jira/browse/GEODE-2080 > Project: Geode > Issue Type: Bug > Components: rest (dev) >Reporter: Bruce Schuchardt > > Gemfire REST POST call does not work on a region with value constraint eg If > I have a region definition like > > > > >com.support.pivotal.domain.Company > > > > and try to do a POST call like > ResponseEntity< String> result = RestClientUtils.getRestTemplate().exchange( > "http://localhost:8080/gemfire-api/v1/regionOne?key=CITI-123"; , > HttpMethod.POST, >entity, String.class); > It fails, whereas If I remove the value constraint in the region definition > it works fine. It is eaily reproducible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2091) PartitionedRegion containsValueForKey() in transaction may return false if there is a rebalance
[ https://issues.apache.org/jira/browse/GEODE-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655469#comment-15655469 ] ASF subversion and git services commented on GEODE-2091: Commit e01dbe6f557a11aa99cd6ec4da349a38a97d678e in incubator-geode's branch refs/heads/develop from [~eshu] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=e01dbe6 ] GEODE-2091: Do not return false when containsValueForKey call failed in a transaction Correctly handle exception to fail the transaction instead of returning null. Add check for colocated buckets so that correct TrasactionException can be thrown. Fix containsKey method call as well. Add test cases in dunit test. > PartitionedRegion containsValueForKey() in transaction may return false if > there is a rebalance > --- > > Key: GEODE-2091 > URL: https://issues.apache.org/jira/browse/GEODE-2091 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu > > PartitionedRegion containsValueForKey() in transaction may return false if > the bucket contains the entry is moved to other node due to rebalance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1993) value returned through /region/key rest service needs to be post processed
[ https://issues.apache.org/jira/browse/GEODE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655458#comment-15655458 ] ASF subversion and git services commented on GEODE-1993: Commit bd229d7681376a11ba2e37747e48844ffe65584c in incubator-geode's branch refs/heads/develop from [~kduling] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=bd229d7 ] GEODE-1993: postprocess region/key in developer rest api * This closes #276 > value returned through /region/key rest service needs to be post processed > -- > > Key: GEODE-1993 > URL: https://issues.apache.org/jira/browse/GEODE-1993 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > The new rest security did not use post processor before returning the value > back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1993) value returned through /region/key rest service needs to be post processed
[ https://issues.apache.org/jira/browse/GEODE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655461#comment-15655461 ] ASF GitHub Bot commented on GEODE-1993: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-geode/pull/276 > value returned through /region/key rest service needs to be post processed > -- > > Key: GEODE-1993 > URL: https://issues.apache.org/jira/browse/GEODE-1993 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > The new rest security did not use post processor before returning the value > back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2096) CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart
Eric Shu created GEODE-2096: --- Summary: CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart Key: GEODE-2096 URL: https://issues.apache.org/jira/browse/GEODE-2096 Project: Geode Issue Type: Bug Components: regions Reporter: Eric Shu This test failed in one precheckin run, but passes when run individually. org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest > testMultipleColocatedChildPRsMissingWithSequencedStart FAILED java.lang.AssertionError: An exception occurred during asynchronous invocation. at org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148) at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:374) at org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart(PersistentColocatedPartitionedRegionDUnitTest.java:1029) Caused by: Wanted but not invoked: appender.append(); -> at org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest$11.call(PersistentColocatedPartitionedRegionDUnitTest.java:579) However, there were other interactions with this mock: appender.getName(); -> at org.apache.logging.log4j.core.config.AbstractConfiguration.addLoggerAppender(AbstractConfiguration.java:675) appender.getName(); -> at org.apache.logging.log4j.core.config.AppenderControl.(AppenderControl.java:51) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2096) CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart
[ https://issues.apache.org/jira/browse/GEODE-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-2096: Labels: ci flaky (was: ) > CI Failure: > PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart > > > Key: GEODE-2096 > URL: https://issues.apache.org/jira/browse/GEODE-2096 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu > Labels: ci, flaky > > This test failed in one precheckin run, but passes when run individually. > org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest > > testMultipleColocatedChildPRsMissingWithSequencedStart FAILED > java.lang.AssertionError: An exception occurred during asynchronous > invocation. > at > org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148) > at > org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:374) > at > org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart(PersistentColocatedPartitionedRegionDUnitTest.java:1029) > Caused by: > Wanted but not invoked: > appender.append(); > -> at > org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest$11.call(PersistentColocatedPartitionedRegionDUnitTest.java:579) > However, there were other interactions with this mock: > appender.getName(); > -> at > org.apache.logging.log4j.core.config.AbstractConfiguration.addLoggerAppender(AbstractConfiguration.java:675) > appender.getName(); > -> at > org.apache.logging.log4j.core.config.AppenderControl.(AppenderControl.java:51) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2095) CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild
[ https://issues.apache.org/jira/browse/GEODE-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-2095: Labels: ci flaky (was: ) > CI Failure: > PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild > --- > > Key: GEODE-2095 > URL: https://issues.apache.org/jira/browse/GEODE-2095 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu > Labels: ci, flaky > > Failed in a precheckin run. > org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest > > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED > java.util.concurrent.TimeoutException: Timed out waiting 6 > milliseconds for AsyncInvocation to complete. > at > org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:423) > at > org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:373) > at > org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:1143) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2095) CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild
Eric Shu created GEODE-2095: --- Summary: CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild Key: GEODE-2095 URL: https://issues.apache.org/jira/browse/GEODE-2095 Project: Geode Issue Type: Bug Components: regions Reporter: Eric Shu Failed in a precheckin run. org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds for AsyncInvocation to complete. at org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:423) at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:373) at org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:1143) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2089) entry-idle-time setting on the client side cache is not working as expected
[ https://issues.apache.org/jira/browse/GEODE-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655423#comment-15655423 ] ASF subversion and git services commented on GEODE-2089: Commit e584c4e658a082155613323748f4d849bc531bdb in incubator-geode's branch refs/heads/develop from [~bschuchardt] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=e584c4e ] GEODE-2089 entry-idle-time on client side cache is not working as expected When we pull an entry in from another cache in LocalRegion.findObjectInSystem() we end up invoking updateStatsForPut and then updateStatsForGet. The former method installs a lastModifiedTime from the version tag that came from the other cache and this is used in updateStatsForPut to schedule an expiry-task for the entry. Then updateStatsForGet is invoked to set the lastAccessed time of the entry to the current time. However, by the time this is done the entry may have already been removed by the expiry-task if the lastModified time was too far in the past. The fix is to establish both the lastModified and lastAccessed times in updateStatsForPut. I've included two of the "leaf" RegionEntry classes in the diff but all of them had to be modified in the same way. > entry-idle-time setting on the client side cache is not working as expected > > > Key: GEODE-2089 > URL: https://issues.apache.org/jira/browse/GEODE-2089 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt > > I wrote a unit test that sets an entry-idle-time timeout on a client cache > with action local-destroy. When the client cache pulls an old entry from the > server the cache appears to ignore the entry-idle-time and expires the entry > immediately after it is put in the cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655413#comment-15655413 ] ASF GitHub Bot commented on GEODE-2084: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-geode/pull/281 > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug > Components: configuration, rest (dev) >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655405#comment-15655405 ] ASF subversion and git services commented on GEODE-2084: Commit aac49f3f0c17c1e396e6dbe9fb84849bd6c9b2c6 in incubator-geode's branch refs/heads/develop from [~kduling] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=aac49f3 ] GEODE-2084 - When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly * Changed RestSecurityConfiguration to not call login(), which will bring up the browsers Authentication dialog instead. * this closes #281 > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug > Components: configuration, rest (dev) >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2050) Update documentation of statistics
[ https://issues.apache.org/jira/browse/GEODE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655383#comment-15655383 ] ASF subversion and git services commented on GEODE-2050: Commit 89569fd3956c175d073592503a475b3d157c1579 in incubator-geode's branch refs/heads/feature/GEODE-1930 from [~karensmolermiller] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=89569fd ] GEODE-2050 Add docs for new membership svc statistics > Update documentation of statistics > -- > > Key: GEODE-2050 > URL: https://issues.apache.org/jira/browse/GEODE-2050 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.1.0-incubating > > > With JGroups 3.6.10, a set of statistics have been removed. They need to be > removed from the documentation: > - "batchCopyTime", "Total amount of time, in nanoseconds, spent copying > messages for batched transmission", "nanoseconds"), > - "batchFlushTime", "Total amount of time, in nanoseconds, spent flushing > batched messages to the network", "nanoseconds"), > - "ucastFlushes", "Total number of flushes of the unicast datagram protocol, > prior to sending a multicast message", "flushes"), > - "ucastFlushTime", "Total amount of time, in nanoseconds, spent waiting for > acknowledgements for outstanding unicast datagram messages", "nanoseconds"), > - "flowControlRequests", "Total number of flow control credit requests sent > to other processes", "messages"), > - "flowControlResponses", "Total number of flow control credit responses sent > to a requestor", "messages"), > "flowControlWaitsInProgress", "Number of threads blocked waiting for > flow-control recharges from other processes", "threads"), > - "flowControlWaitTime", "Total amount of time, in nanoseconds, spent waiting > for other processes to recharge the flow of control meter", "nanoseconds"), > - "flowControlThrottleWaitsInProgress", "Number of threads blocked waiting > due to flow-control throttle requests from other members", "threads"), > - "jgNAKACKreceivedMessages", "Number of received messages awaiting stability > in NAKACK", "messages"), > - "jgNAKACKsentMessages", "Number of sent messages awaiting stability in > NAKACK", "messages"), > - "jgQueuedMessages", "Number of messages queued by transport and awaiting > processing", "messages"), *is not in the documentation* > - "jgUNICASTreceivedMessages", "Number of received messages awaiting receipt > of prior messages", "messages"), > - "jgUNICASTsentMessages", "Number of un-acked normal priority messages", > "messages"), > - "jgUNICASTsentHighPriorityMessages", "Number of un-acked high priority > messages", "messages"), > - "jgUNICASTdataReceivedTime", "Amount of time spent in JGroups UNICAST > send", "nanoseconds"), > - "jgSTABLEsuspendTime", "Amount of time JGroups STABLE is suspended", > "nanoseconds"), > - "jgSTABLEmessages", "Number of STABLE messages received by JGroups", > "messages"), > - "jgSTABLEmessagesSent", "Number of STABLE messages sent by JGroups", > "messages"), > - "jgSTABILITYmessages", "Number of STABILITY messages received by JGroups", > "messages"), > - "jgDownTime", "Down Time spent in JGroups stacks", "nanoseconds"), > - "jgUpTime", "Up Time spent in JGroups stacks", "nanoseconds"), > - "jChannelUpTime", "Up Time spent in JChannel including jgroup stack", > "nanoseconds"), > - "jgFCsendBlocks", "Number of times JGroups FC halted sends due to > backpressure", "events"), > - "jgFCautoRequests", "Number of times JGroups FC automatically sent > replenishment requests", "events"), > - "jgFCreplenish", "Number of times JGroups FC received replenishments from > receivers", "messages"), > - "jgFCresumes", "Number of times JGroups FC resumed sends due to > backpressure", "events"), > - "jgFCsentCredits", "Number of times JGroups FC sent credits to a sender", > "events"), > - "jgFCsentThrottleRequests","Number of times JGroups FC sent throttle > requests to a sender", "events"), > - "jgNAKACKwaits", "Number of delays created by NAKACK sent_msgs overflow", > "events"), *is not in the documentation* > With the new membership service, these statistics have been added. Each has > a name, a description, and a unit of measure: > - "heartbeatRequestsSent", "Heartbeat request messages that this member has > sent.", "messages"), > - "heartbeatRequestsReceived", "Heartbeat request messages that this member > has received.", "messages"), > - "heartbeatsSent", "Heartbeat messages that this member has sent.", > "messages"), > - "heartbeatsReceived", "Heartbeat messages that this member has received.", > "messages"), > - "suspectsSent", "Suspect member messages that this member has sent.", > "messages"), > - "sus
[jira] [Commented] (GEODE-2051) CI failure: RegionCloseDUnitTest.testCloseRegionOnClient
[
https://issues.apache.org/jira/browse/GEODE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655385#comment-15655385
]
ASF subversion and git services commented on GEODE-2051:
Commit 5000bbe449c5881d608cdfb0e0e3f8c2f2bb6373 in incubator-geode's branch
refs/heads/feature/GEODE-1930 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=5000bbe ]
GEODE-2051 - marking this test as flaky
> CI failure: RegionCloseDUnitTest.testCloseRegionOnClient
>
>
> Key: GEODE-2051
> URL: https://issues.apache.org/jira/browse/GEODE-2051
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Bruce Schuchardt
> Labels: ci, flaky
>
> This test closes a region in the client and then waits for the queue proxies
> in the server to shut down. In one CI run (at least) this did not happen.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.RegionCloseDUnitTest$$Lambda$14/306382798.run
> in VM 0 running on Host a81cbe5930a0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at
> org.apache.geode.internal.cache.tier.sockets.RegionCloseDUnitTest.testCloseRegionOnClient(RegionCloseDUnitTest.java:97)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.Nat
[jira] [Commented] (GEODE-2028) Fix license issues from 1.0.0-incubating release
[
https://issues.apache.org/jira/browse/GEODE-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655382#comment-15655382
]
ASF subversion and git services commented on GEODE-2028:
Commit 9aa7fa120781e77eaa905e63bd9f9346dfa99260 in incubator-geode's branch
refs/heads/feature/GEODE-1930 from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=9aa7fa1 ]
GEODE-2028: Fix license issues from 1.0.0-incubating release
Remove bootstrap from LICENSE as v3.0.0 that we bundle is Apache
licensed.
> Fix license issues from 1.0.0-incubating release
>
>
> Key: GEODE-2028
> URL: https://issues.apache.org/jira/browse/GEODE-2028
> Project: Geode
> Issue Type: Bug
>Reporter: Anthony Baker
> Fix For: 1.1.0-incubating
>
>
> See
> http://mail-archives.apache.org/mod_mbox/incubator-general/201610.mbox/%3cca53f203-bef1-4bdb-a8b3-313ab035c...@classsoftware.com%3e
> {quote}
> - How is this this file licensed? [1]
> - Looks like the bundled version of bootstrap is Apache licensed and not MIT
> licensed as mentioned in the LICENSE file.
> - License is missing MIT/GPL licensed jQuery hashchange bundled inside this
> file [2]
> 1. ./geode-web-api/src/main/webapp/docs/css/screen.css
> 2. ./geode-web-api/src/main/webapp/docs/lib/jquery.ba-bbq.min.js
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2050) Update documentation of statistics
[ https://issues.apache.org/jira/browse/GEODE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655386#comment-15655386 ] ASF subversion and git services commented on GEODE-2050: Commit a00a2ff2920fd273747e3852b00ec91e48b3b390 in incubator-geode's branch refs/heads/feature/GEODE-1930 from [~karensmolermiller] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=a00a2ff ] Merge branch 'feature/GEODE-2050' into develop > Update documentation of statistics > -- > > Key: GEODE-2050 > URL: https://issues.apache.org/jira/browse/GEODE-2050 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.1.0-incubating > > > With JGroups 3.6.10, a set of statistics have been removed. They need to be > removed from the documentation: > - "batchCopyTime", "Total amount of time, in nanoseconds, spent copying > messages for batched transmission", "nanoseconds"), > - "batchFlushTime", "Total amount of time, in nanoseconds, spent flushing > batched messages to the network", "nanoseconds"), > - "ucastFlushes", "Total number of flushes of the unicast datagram protocol, > prior to sending a multicast message", "flushes"), > - "ucastFlushTime", "Total amount of time, in nanoseconds, spent waiting for > acknowledgements for outstanding unicast datagram messages", "nanoseconds"), > - "flowControlRequests", "Total number of flow control credit requests sent > to other processes", "messages"), > - "flowControlResponses", "Total number of flow control credit responses sent > to a requestor", "messages"), > "flowControlWaitsInProgress", "Number of threads blocked waiting for > flow-control recharges from other processes", "threads"), > - "flowControlWaitTime", "Total amount of time, in nanoseconds, spent waiting > for other processes to recharge the flow of control meter", "nanoseconds"), > - "flowControlThrottleWaitsInProgress", "Number of threads blocked waiting > due to flow-control throttle requests from other members", "threads"), > - "jgNAKACKreceivedMessages", "Number of received messages awaiting stability > in NAKACK", "messages"), > - "jgNAKACKsentMessages", "Number of sent messages awaiting stability in > NAKACK", "messages"), > - "jgQueuedMessages", "Number of messages queued by transport and awaiting > processing", "messages"), *is not in the documentation* > - "jgUNICASTreceivedMessages", "Number of received messages awaiting receipt > of prior messages", "messages"), > - "jgUNICASTsentMessages", "Number of un-acked normal priority messages", > "messages"), > - "jgUNICASTsentHighPriorityMessages", "Number of un-acked high priority > messages", "messages"), > - "jgUNICASTdataReceivedTime", "Amount of time spent in JGroups UNICAST > send", "nanoseconds"), > - "jgSTABLEsuspendTime", "Amount of time JGroups STABLE is suspended", > "nanoseconds"), > - "jgSTABLEmessages", "Number of STABLE messages received by JGroups", > "messages"), > - "jgSTABLEmessagesSent", "Number of STABLE messages sent by JGroups", > "messages"), > - "jgSTABILITYmessages", "Number of STABILITY messages received by JGroups", > "messages"), > - "jgDownTime", "Down Time spent in JGroups stacks", "nanoseconds"), > - "jgUpTime", "Up Time spent in JGroups stacks", "nanoseconds"), > - "jChannelUpTime", "Up Time spent in JChannel including jgroup stack", > "nanoseconds"), > - "jgFCsendBlocks", "Number of times JGroups FC halted sends due to > backpressure", "events"), > - "jgFCautoRequests", "Number of times JGroups FC automatically sent > replenishment requests", "events"), > - "jgFCreplenish", "Number of times JGroups FC received replenishments from > receivers", "messages"), > - "jgFCresumes", "Number of times JGroups FC resumed sends due to > backpressure", "events"), > - "jgFCsentCredits", "Number of times JGroups FC sent credits to a sender", > "events"), > - "jgFCsentThrottleRequests","Number of times JGroups FC sent throttle > requests to a sender", "events"), > - "jgNAKACKwaits", "Number of delays created by NAKACK sent_msgs overflow", > "events"), *is not in the documentation* > With the new membership service, these statistics have been added. Each has > a name, a description, and a unit of measure: > - "heartbeatRequestsSent", "Heartbeat request messages that this member has > sent.", "messages"), > - "heartbeatRequestsReceived", "Heartbeat request messages that this member > has received.", "messages"), > - "heartbeatsSent", "Heartbeat messages that this member has sent.", > "messages"), > - "heartbeatsReceived", "Heartbeat messages that this member has received.", > "messages"), > - "suspectsSent", "Suspect member messages that this member has sent.", > "messages"), > - "suspectsRe
[jira] [Commented] (GEODE-2051) CI failure: RegionCloseDUnitTest.testCloseRegionOnClient
[
https://issues.apache.org/jira/browse/GEODE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655384#comment-15655384
]
ASF subversion and git services commented on GEODE-2051:
Commit 76efb2513d4672abf137aeb00d5a67679ef30da3 in incubator-geode's branch
refs/heads/feature/GEODE-1930 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=76efb25 ]
GEODE-2051 - marking this test as flaky
> CI failure: RegionCloseDUnitTest.testCloseRegionOnClient
>
>
> Key: GEODE-2051
> URL: https://issues.apache.org/jira/browse/GEODE-2051
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Bruce Schuchardt
> Labels: ci, flaky
>
> This test closes a region in the client and then waits for the queue proxies
> in the server to shut down. In one CI run (at least) this did not happen.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.RegionCloseDUnitTest$$Lambda$14/306382798.run
> in VM 0 running on Host a81cbe5930a0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at
> org.apache.geode.internal.cache.tier.sockets.RegionCloseDUnitTest.testCloseRegionOnClient(RegionCloseDUnitTest.java:97)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.Nat
[jira] [Commented] (GEODE-2050) Update documentation of statistics
[ https://issues.apache.org/jira/browse/GEODE-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655381#comment-15655381 ] ASF subversion and git services commented on GEODE-2050: Commit 4c5fca6ef20ff9c529d0adce888cd9f2302fdf7a in incubator-geode's branch refs/heads/feature/GEODE-1930 from [~karensmolermiller] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=4c5fca6 ] GEODE-2050 Remove doc of statistics no longer present JGroups-related statistics were removed. > Update documentation of statistics > -- > > Key: GEODE-2050 > URL: https://issues.apache.org/jira/browse/GEODE-2050 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > Fix For: 1.1.0-incubating > > > With JGroups 3.6.10, a set of statistics have been removed. They need to be > removed from the documentation: > - "batchCopyTime", "Total amount of time, in nanoseconds, spent copying > messages for batched transmission", "nanoseconds"), > - "batchFlushTime", "Total amount of time, in nanoseconds, spent flushing > batched messages to the network", "nanoseconds"), > - "ucastFlushes", "Total number of flushes of the unicast datagram protocol, > prior to sending a multicast message", "flushes"), > - "ucastFlushTime", "Total amount of time, in nanoseconds, spent waiting for > acknowledgements for outstanding unicast datagram messages", "nanoseconds"), > - "flowControlRequests", "Total number of flow control credit requests sent > to other processes", "messages"), > - "flowControlResponses", "Total number of flow control credit responses sent > to a requestor", "messages"), > "flowControlWaitsInProgress", "Number of threads blocked waiting for > flow-control recharges from other processes", "threads"), > - "flowControlWaitTime", "Total amount of time, in nanoseconds, spent waiting > for other processes to recharge the flow of control meter", "nanoseconds"), > - "flowControlThrottleWaitsInProgress", "Number of threads blocked waiting > due to flow-control throttle requests from other members", "threads"), > - "jgNAKACKreceivedMessages", "Number of received messages awaiting stability > in NAKACK", "messages"), > - "jgNAKACKsentMessages", "Number of sent messages awaiting stability in > NAKACK", "messages"), > - "jgQueuedMessages", "Number of messages queued by transport and awaiting > processing", "messages"), *is not in the documentation* > - "jgUNICASTreceivedMessages", "Number of received messages awaiting receipt > of prior messages", "messages"), > - "jgUNICASTsentMessages", "Number of un-acked normal priority messages", > "messages"), > - "jgUNICASTsentHighPriorityMessages", "Number of un-acked high priority > messages", "messages"), > - "jgUNICASTdataReceivedTime", "Amount of time spent in JGroups UNICAST > send", "nanoseconds"), > - "jgSTABLEsuspendTime", "Amount of time JGroups STABLE is suspended", > "nanoseconds"), > - "jgSTABLEmessages", "Number of STABLE messages received by JGroups", > "messages"), > - "jgSTABLEmessagesSent", "Number of STABLE messages sent by JGroups", > "messages"), > - "jgSTABILITYmessages", "Number of STABILITY messages received by JGroups", > "messages"), > - "jgDownTime", "Down Time spent in JGroups stacks", "nanoseconds"), > - "jgUpTime", "Up Time spent in JGroups stacks", "nanoseconds"), > - "jChannelUpTime", "Up Time spent in JChannel including jgroup stack", > "nanoseconds"), > - "jgFCsendBlocks", "Number of times JGroups FC halted sends due to > backpressure", "events"), > - "jgFCautoRequests", "Number of times JGroups FC automatically sent > replenishment requests", "events"), > - "jgFCreplenish", "Number of times JGroups FC received replenishments from > receivers", "messages"), > - "jgFCresumes", "Number of times JGroups FC resumed sends due to > backpressure", "events"), > - "jgFCsentCredits", "Number of times JGroups FC sent credits to a sender", > "events"), > - "jgFCsentThrottleRequests","Number of times JGroups FC sent throttle > requests to a sender", "events"), > - "jgNAKACKwaits", "Number of delays created by NAKACK sent_msgs overflow", > "events"), *is not in the documentation* > With the new membership service, these statistics have been added. Each has > a name, a description, and a unit of measure: > - "heartbeatRequestsSent", "Heartbeat request messages that this member has > sent.", "messages"), > - "heartbeatRequestsReceived", "Heartbeat request messages that this member > has received.", "messages"), > - "heartbeatsSent", "Heartbeat messages that this member has sent.", > "messages"), > - "heartbeatsReceived", "Heartbeat messages that this member has received.", > "messages"), > - "suspectsSent", "Suspect member messages that this m
[jira] [Commented] (GEODE-1993) value returned through /region/key rest service needs to be post processed
[ https://issues.apache.org/jira/browse/GEODE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655344#comment-15655344 ] ASF GitHub Bot commented on GEODE-1993: --- Github user kjduling commented on the issue: https://github.com/apache/incubator-geode/pull/276 Precheckin successful > value returned through /region/key rest service needs to be post processed > -- > > Key: GEODE-1993 > URL: https://issues.apache.org/jira/browse/GEODE-1993 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > The new rest security did not use post processor before returning the value > back to the client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2094) Update admin/dev REST API documentation
[ https://issues.apache.org/jira/browse/GEODE-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-2094: --- Description: These 3 options for the gfsh start server command are not documented, so also add them to the command reference page: --http-service-port --http-service-bind-address --start-rest-api The commands to start a server can be simplified in the prose on using gfsh with REST commands. 1. In the docs file geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using the admin REST interface, the sample gfsh start server command can be simplified. --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com becomes --http-service-bind-address=myremotecluster.example.com 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about using the dev REST API, the gfsh start server commands given in steps 2 and 3 can be simplified (corrected). --J=-Dgemfire.start-dev-rest-api=true becomes --start-rest-api=true --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=localhost becomes --http-service-bind-address=localhost was: The commands to start a server can be simplified in the prose on using gfsh with REST commands. 1. In the docs file geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using the admin REST interface, the sample gfsh start server command can be simplified. --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com becomes --http-service-bind-address=myremotecluster.example.com 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about using the dev REST API, the gfsh start server commands given in steps 2 and 3 can be simplified (corrected). --J=-Dgemfire.start-dev-rest-api=true becomes --start-rest-api=true --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=localhost becomes --http-service-bind-address=localhost > Update admin/dev REST API documentation > --- > > Key: GEODE-2094 > URL: https://issues.apache.org/jira/browse/GEODE-2094 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > > These 3 options for the gfsh start server command are not documented, so also > add them to the command reference page: > --http-service-port > --http-service-bind-address > --start-rest-api > The commands to start a server can be simplified in the prose on using gfsh > with REST commands. > 1. In the docs file > geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using > the admin REST interface, the sample gfsh start server command can be > simplified. > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com > becomes > --http-service-bind-address=myremotecluster.example.com > 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about > using the dev REST API, the gfsh start server commands given in steps 2 and 3 > can be simplified (corrected). > --J=-Dgemfire.start-dev-rest-api=true > becomes > --start-rest-api=true > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=localhost > becomes > --http-service-bind-address=localhost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2094) Update admin/dev REST API documentation
[ https://issues.apache.org/jira/browse/GEODE-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-2094: -- Assignee: Karen Smoler Miller > Update admin/dev REST API documentation > --- > > Key: GEODE-2094 > URL: https://issues.apache.org/jira/browse/GEODE-2094 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller > > These 3 options for the gfsh start server command are not documented, so also > add them to the command reference page: > --http-service-port > --http-service-bind-address > --start-rest-api > The commands to start a server can be simplified in the prose on using gfsh > with REST commands. > 1. In the docs file > geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using > the admin REST interface, the sample gfsh start server command can be > simplified. > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com > becomes > --http-service-bind-address=myremotecluster.example.com > 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about > using the dev REST API, the gfsh start server commands given in steps 2 and 3 > can be simplified (corrected). > --J=-Dgemfire.start-dev-rest-api=true > becomes > --start-rest-api=true > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=localhost > becomes > --http-service-bind-address=localhost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling resolved GEODE-2084. - Resolution: Fixed > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug > Components: configuration, rest (dev) >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling updated GEODE-2084: Component/s: configuration > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug > Components: configuration, rest (dev) >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling updated GEODE-2084: Affects Version/s: 1.0.0-incubating > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug > Components: rest (dev) >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling reopened GEODE-2084: - Reopening to import in to tracker > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug > Components: rest (dev) >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling updated GEODE-2084: Component/s: rest (dev) > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug > Components: rest (dev) >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2092) Examples should not be in the product code
[ https://issues.apache.org/jira/browse/GEODE-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-2092: - Summary: Examples should not be in the product code (was: Examples should not be in the product code: SampleSecurityManager, SimpleSecurityManager, SamplePostProcessor) > Examples should not be in the product code > -- > > Key: GEODE-2092 > URL: https://issues.apache.org/jira/browse/GEODE-2092 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund > > These three classes are currently in geode-core product package which implies > they are fully supported user API. They cannot be released in a user API > package. They must be moved to geode-examples: > geode-core/src/main/java/org/apache/geode/security/templates/SampleSecurityManager.java > geode-core/src/main/java/org/apache/geode/security/templates/SamplePostProcessor.java > geode-core/src/main/java/org/apache/geode/security/templates/SimpleSecurityManager.java > If they need to be available within a jar, then geode-examples should be > altered to build a jar can be added to the classpath of a running application. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2092) Security examples should not be in the product code
[ https://issues.apache.org/jira/browse/GEODE-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-2092: - Summary: Security examples should not be in the product code (was: Examples should not be in the product code) > Security examples should not be in the product code > --- > > Key: GEODE-2092 > URL: https://issues.apache.org/jira/browse/GEODE-2092 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund > > These three classes are currently in geode-core product package which implies > they are fully supported user API. They cannot be released in a user API > package. They must be moved to geode-examples: > geode-core/src/main/java/org/apache/geode/security/templates/SampleSecurityManager.java > geode-core/src/main/java/org/apache/geode/security/templates/SamplePostProcessor.java > geode-core/src/main/java/org/apache/geode/security/templates/SimpleSecurityManager.java > If they need to be available within a jar, then geode-examples should be > altered to build a jar can be added to the classpath of a running application. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2094) Update admin/dev REST API documentation
[ https://issues.apache.org/jira/browse/GEODE-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-2094: --- Description: The commands to start a server can be simplified in the prose on using gfsh with REST commands. 1. In the docs file geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using the admin REST interface, the sample gfsh start server command can be simplified. --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com becomes --http-service-bind-address=myremotecluster.example.com 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about using the dev REST API, the gfsh start server commands given in steps 2 and 3 can be simplified (corrected). --J=-Dgemfire.start-dev-rest-api=true becomes --start-rest-api=true --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=localhost becomes --http-service-bind-address=localhost was: The commands to start a server can be simplified in the prose on using gfsh with REST commands. 1. In the docs file geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using the admin REST interface, the sample gfsh start server command can be simplified. --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com becomes --http-service-bind-address=myremotecluster.example.com 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about using the dev REST API, the gfsh start server commands given in steps 2 and 3 can be simplified (corrected). --J=-Dgemfire.start-dev-rest-api=true becomes --J=-Dgemfire.start-rest-api=true --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=localhost becomes --http-service-bind-address=localhost > Update admin/dev REST API documentation > --- > > Key: GEODE-2094 > URL: https://issues.apache.org/jira/browse/GEODE-2094 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller > > The commands to start a server can be simplified in the prose on using gfsh > with REST commands. > 1. In the docs file > geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using > the admin REST interface, the sample gfsh start server command can be > simplified. > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com > becomes > --http-service-bind-address=myremotecluster.example.com > 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about > using the dev REST API, the gfsh start server commands given in steps 2 and 3 > can be simplified (corrected). > --J=-Dgemfire.start-dev-rest-api=true > becomes > --start-rest-api=true > --J=-Dgemfire.http-service-port=8080 > becomes > --http-service-port=8080 > --J=-Dgemfire.http-service-bind-address=localhost > becomes > --http-service-bind-address=localhost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654819#comment-15654819 ] ASF GitHub Bot commented on GEODE-2084: --- Github user kjduling commented on the issue: https://github.com/apache/incubator-geode/pull/281 Precheckin is running > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2094) Update admin/dev REST API documentation
Karen Smoler Miller created GEODE-2094: -- Summary: Update admin/dev REST API documentation Key: GEODE-2094 URL: https://issues.apache.org/jira/browse/GEODE-2094 Project: Geode Issue Type: Bug Components: docs Reporter: Karen Smoler Miller The commands to start a server can be simplified in the prose on using gfsh with REST commands. 1. In the docs file geode-docs/configuring/cluster_config/gfsh_remote.html.md.erb, about using the admin REST interface, the sample gfsh start server command can be simplified. --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=myremotecluster.example.com becomes --http-service-bind-address=myremotecluster.example.com 2. In the docs file geode-docs/rest_apps/setup_config.html.md.erb, about using the dev REST API, the gfsh start server commands given in steps 2 and 3 can be simplified (corrected). --J=-Dgemfire.start-dev-rest-api=true becomes --J=-Dgemfire.start-rest-api=true --J=-Dgemfire.http-service-port=8080 becomes --http-service-port=8080 --J=-Dgemfire.http-service-bind-address=localhost becomes --http-service-bind-address=localhost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654816#comment-15654816 ] ASF GitHub Bot commented on GEODE-2084: --- GitHub user kjduling opened a pull request: https://github.com/apache/incubator-geode/pull/281 GEODE-2084 - When executing a rest api in a browser, the login page p… …resented in the browser is not setting the username/password correctly Changed RestSecurityConfiguration to not call login(), which will bring up the browsers Authentication dialog instead. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kjduling/incubator-geode feature/GEODE-2084 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-geode/pull/281.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #281 commit d51ebc32a2da6afd7d7c483872a06e9ddafe5960 Author: Kevin Duling Date: 2016-11-10T18:44:37Z GEODE-2084 - When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly Changed RestSecurityConfiguration to not call login(), which will bring up the browsers Authentication dialog instead. > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2093) generated AbstractRegionEntry subclasses as part of build and do not check them in
[ https://issues.apache.org/jira/browse/GEODE-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654791#comment-15654791 ] Darrel Schneider commented on GEODE-2093: - See GEODE-1785 for how these files are currently generated. > generated AbstractRegionEntry subclasses as part of build and do not check > them in > -- > > Key: GEODE-2093 > URL: https://issues.apache.org/jira/browse/GEODE-2093 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Darrel Schneider > > Currently a large number of leaf subclasses of AbstractRegionEntry are > generated manually by running a script. The generated source is under source > control instead of being transient. A C preprocessor file is used to describe > how to generate the files. > It might be better to do this generation as part of the build instead of it > being a manual step. > It might be better for the generated source to be transient instead of under > source control. > A better, Java based way, may exist to deal with this instead of using the C > preprocessor. > One of the things to keep in mind would be how we would debug issues with > this code and how will the IDEs support working with the code. Having the > generated source checked in helps in both these areas but also can lead to > developers directly modifying the generated source and not updating the cpp > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling resolved GEODE-2084. - Resolution: Resolved Fix Version/s: 1.1.0-incubating > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2093) generated AbstractRegionEntry subclasses as part of build and do not check them in
Darrel Schneider created GEODE-2093: --- Summary: generated AbstractRegionEntry subclasses as part of build and do not check them in Key: GEODE-2093 URL: https://issues.apache.org/jira/browse/GEODE-2093 Project: Geode Issue Type: Improvement Components: build Reporter: Darrel Schneider Currently a large number of leaf subclasses of AbstractRegionEntry are generated manually by running a script. The generated source is under source control instead of being transient. A C preprocessor file is used to describe how to generate the files. It might be better to do this generation as part of the build instead of it being a manual step. It might be better for the generated source to be transient instead of under source control. A better, Java based way, may exist to deal with this instead of using the C preprocessor. One of the things to keep in mind would be how we would debug issues with this code and how will the IDEs support working with the code. Having the generated source checked in helps in both these areas but also can lead to developers directly modifying the generated source and not updating the cpp file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654789#comment-15654789 ] Kevin Duling commented on GEODE-2084: - Modified RestSecurityConfiguration to not bring up the login form. This will generate the normal Authentication login we expect to see. > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.1.0-incubating > > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2084) When executing a rest api in a browser, the login page presented in the browser is not setting the username/password correctly
[ https://issues.apache.org/jira/browse/GEODE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling reassigned GEODE-2084: --- Assignee: Kevin Duling > When executing a rest api in a browser, the login page presented in the > browser is not setting the username/password correctly > -- > > Key: GEODE-2084 > URL: https://issues.apache.org/jira/browse/GEODE-2084 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Kevin Duling > > Steps to reproduce: > 1. start up a server with security > 2. in a browser address bar, type in: http:// address>:7070/geode/v1/servers, after putting in username/password, I should > see the result json, but instead, I keep getting the login page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1785) generated AbstractRegionEntry subclasses can no longer be generated
[ https://issues.apache.org/jira/browse/GEODE-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-1785. - Resolution: Fixed Fix Version/s: 1.1.0-incubating commit df2f0c964d4fe62fa12b69266747deeccef3aac5 Author: Darrel Schneider Date: Wed Nov 9 14:34:33 2016 -0800 GEODE-1785: add script to generate region entry source Added generateRegionEntryClasses.sh and LeafRegionEntry.cpp. To modify the leaf subclasses of AbstractRegionEntry edit LeafeRegionEntry.cpp, run dev-tools/generatedRegionEntryClasses.sh, and then do a gradlew spotlessApply since the generated code > generated AbstractRegionEntry subclasses can no longer be generated > --- > > Key: GEODE-1785 > URL: https://issues.apache.org/jira/browse/GEODE-1785 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.1.0-incubating > > > A large number of the subclasses of AbstractRegionEntry are generated. > They have comments instructing developers to not modify them. For example: > /** > * Do not modify this class. It was generated. > * Instead modify LeafRegionEntry.cpp and then run > * bin/generateRegionEntryClasses.sh from the directory > * that contains your build.xml. > */ > But Geode does not include LeafRegionEntry.cpp nor > bin/generateRegionEntryClasses.sh. It also no longer has a build.xml. > This is not a show stopper since the classes can be modified in place just > like any other java file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2090) Update off-heap statistics documentation
[
https://issues.apache.org/jira/browse/GEODE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-2090.
Resolution: Fixed
> Update off-heap statistics documentation
>
>
> Key: GEODE-2090
> URL: https://issues.apache.org/jira/browse/GEODE-2090
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0-incubating
>
>
> The {{gfsh show metrics}} command reference page is missing the optional
> {{--category=offheap}} option.
> Also, verify if the statistic {{compactions}} ought to be called
> {{defragmentations}}. If so, fix the error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2090) Update off-heap statistics documentation
[
https://issues.apache.org/jira/browse/GEODE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-2090:
---
Fix Version/s: 1.1.0-incubating
> Update off-heap statistics documentation
>
>
> Key: GEODE-2090
> URL: https://issues.apache.org/jira/browse/GEODE-2090
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.1.0-incubating
>
>
> The {{gfsh show metrics}} command reference page is missing the optional
> {{--category=offheap}} option.
> Also, verify if the statistic {{compactions}} ought to be called
> {{defragmentations}}. If so, fix the error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2090) Update off-heap statistics documentation
[
https://issues.apache.org/jira/browse/GEODE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654539#comment-15654539
]
ASF subversion and git services commented on GEODE-2090:
Commit 88e5d0f154b919d1f73316cd0ea01970e40a4067 in incubator-geode's branch
refs/heads/develop from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=88e5d0f ]
GEODE-2090 Update off-heap statistics documentation
- add/correct the gfsh show metrics command reference
page to include the offheap category for when the member
is specified
- in the list of OffHeapMemoryStats, correct the name of
a statistic: compactions should be defragmentations
> Update off-heap statistics documentation
>
>
> Key: GEODE-2090
> URL: https://issues.apache.org/jira/browse/GEODE-2090
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> The {{gfsh show metrics}} command reference page is missing the optional
> {{--category=offheap}} option.
> Also, verify if the statistic {{compactions}} ought to be called
> {{defragmentations}}. If so, fix the error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1530) geode-examples setEnv.sh script needs to export path
[
https://issues.apache.org/jira/browse/GEODE-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-1530.
Resolution: Fixed
> geode-examples setEnv.sh script needs to export path
>
>
> Key: GEODE-1530
> URL: https://issues.apache.org/jira/browse/GEODE-1530
> Project: Geode
> Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Labels: bug-hunt
>
> Work currently on the feature/GEODE-33 branch.
> In the replicated example, the {{scripts/setEnv.sh}} script should to prepend
> the {{GEODE_HOME}} environment variable it finds to the PATH, so that the
> {{startAll.sh}} uses that path.
> Append this line to the {{scripts/setEnv.sh}} script:
> {{export PATH=$GEODE_HOME/bin:$PATH}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1531) geode-examples: add final step to run stop script
[
https://issues.apache.org/jira/browse/GEODE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-1531.
Resolution: Fixed
> geode-examples: add final step to run stop script
> --
>
> Key: GEODE-1531
> URL: https://issues.apache.org/jira/browse/GEODE-1531
> Project: Geode
> Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Labels: bug-hunt
>
> {{replicated/README.md}} steps 1-5 of the replicated example in
> geode-examples on the feature/GEODE-33 branch are fine. (Well, step 4 to
> kill a *server* needs to be specified.)
> A Step 6 needs to be added to the {{replicated/README.md}} file to run
> {{$ scripts/stopAll.sh}}
> Without this, novice users will not realize that they still have servers and
> a locator running.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1523) geode-examples README.md markdown improvement
[
https://issues.apache.org/jira/browse/GEODE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller resolved GEODE-1523.
Resolution: Fixed
> geode-examples README.md markdown improvement
> -
>
> Key: GEODE-1523
> URL: https://issues.apache.org/jira/browse/GEODE-1523
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Labels: bug-hunt
>
> The markdown in the feature/GEODE-33 branch file {{geode-examples/README.md}}
> is not yet right.
> There are problems with the references and with the bulleted list.
> (A separate ticket will address the content of the file. This ticket is only
> to fix the markdown, so it displays correctly.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GEODE-1955) JMX suspect string causes tests to fail
[
https://issues.apache.org/jira/browse/GEODE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654469#comment-15654469
]
Bruce Schuchardt edited comment on GEODE-1955 at 11/10/16 4:31 PM:
---
This happened again in an overnight precheckin run on develop,
7973d578ec16b8c9d185d8e291193b8828fde856
{noformat}
:geode-core:distributedTest
org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest >
testSystemClientEventsInServer FAILED
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 462
[fatal 2016/11/09 21:20:41.070 PST tid=0x58]
(tid=88 msgId=31) No longer connected to trout.gemstone.com[1099].
{noformat}
Previously run tests: [NoShowValue1PostProcessorDUnitTest, JMXMBeanDUnitTest,
ConnectToLocatorSSLDUnitTest, UniversalMembershipListenerAdapterDUnitTest]
was (Author: bschuchardt):
This happened again in an overnight precheckin run on develop,
7973d578ec16b8c9d185d8e291193b8828fde856
{noformat}
:geode-core:distributedTest
org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest >
testSystemClientEventsInServer FAILED
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 462
[fatal 2016/11/09 21:20:41.070 PST tid=0x58]
(tid=88 msgId=31) No longer connected to trout.gemstone.com[1099].
{noformat}
> JMX suspect string causes tests to fail
> ---
>
> Key: GEODE-1955
> URL: https://issues.apache.org/jira/browse/GEODE-1955
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Bruce Schuchardt
>Assignee: Jinmei Liao
> Labels: ci
>
> This suspect string is causing periodic failures in a number of unit tests:
> Error Message
> 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 283
> [fatal 2016/09/29 12:12:03.891 PDT tid=0x18d]
> (tid=397 msgId=39) No longer connected to cc6-co6.gemstone.com[27162].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (GEODE-1955) JMX suspect string causes tests to fail
[
https://issues.apache.org/jira/browse/GEODE-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt reopened GEODE-1955:
-
This happened again in an overnight precheckin run on develop,
7973d578ec16b8c9d185d8e291193b8828fde856
{noformat}
:geode-core:distributedTest
org.apache.geode.management.UniversalMembershipListenerAdapterDUnitTest >
testSystemClientEventsInServer FAILED
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 462
[fatal 2016/11/09 21:20:41.070 PST tid=0x58]
(tid=88 msgId=31) No longer connected to trout.gemstone.com[1099].
{noformat}
> JMX suspect string causes tests to fail
> ---
>
> Key: GEODE-1955
> URL: https://issues.apache.org/jira/browse/GEODE-1955
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Bruce Schuchardt
>Assignee: Jinmei Liao
> Labels: ci
>
> This suspect string is causing periodic failures in a number of unit tests:
> Error Message
> 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 283
> [fatal 2016/09/29 12:12:03.891 PDT tid=0x18d]
> (tid=397 msgId=39) No longer connected to cc6-co6.gemstone.com[27162].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1523) geode-examples README.md markdown improvement
[
https://issues.apache.org/jira/browse/GEODE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654371#comment-15654371
]
Anthony Baker commented on GEODE-1523:
--
Can this ticket be closed?
> geode-examples README.md markdown improvement
> -
>
> Key: GEODE-1523
> URL: https://issues.apache.org/jira/browse/GEODE-1523
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Labels: bug-hunt
>
> The markdown in the feature/GEODE-33 branch file {{geode-examples/README.md}}
> is not yet right.
> There are problems with the references and with the bulleted list.
> (A separate ticket will address the content of the file. This ticket is only
> to fix the markdown, so it displays correctly.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1808) gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java version 1.7.0_101
[
https://issues.apache.org/jira/browse/GEODE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-1808.
--
Resolution: Fixed
Fix Version/s: 1.1.0-incubating
> gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java
> version 1.7.0_101
> -
>
> Key: GEODE-1808
> URL: https://issues.apache.org/jira/browse/GEODE-1808
> Project: Geode
> Issue Type: Bug
> Components: general
>Reporter: Sergio Valenti
> Fix For: 1.1.0-incubating
>
>
> We have recently updated out Java version to 1.7.0_101 on our server.
> However, after starting our java component which runs Gemfire version 8, we
> get the following log line:
> | FATAL | 20160821 18:05:30,626 | main |
> gemstone.gemfire.internal.cache.MinimumSystemRequirements | Java version
> older than 1.7.0_72.
> After looking at the source, it is apparent that the issue is in
> com.gemstone.gemfire.internal.lang.SystemUtils when dealing with java
> revisions which are 3 digits long
> public static boolean isJavaVersionAtLeast(String expectedVersion)
> {
> String actualVersionDigits =
> StringUtils.getDigitsOnly(System.getProperty("java.version"));
> String expectedVersionDigits =
> StringUtils.padEnding(StringUtils.getDigitsOnly(expectedVersion), '0',
> actualVersionDigits.length());
> try
> {
> return Long.parseLong(actualVersionDigits) >=
> Long.parseLong(expectedVersionDigits);
> }
> catch(NumberFormatException ignore)
> {
> return false;
> }
> }
> If you walk through this code with an expected version of java: 1.7.0_72 and
> an actual version of java: 1.7.0_101, it will create the following two long
> variables and compare them:
> actualVersionDigits "170101"
> expectedVersionDigits "170720"
> Which causes the comparison check to fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1808) gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java version 1.7.0_101
[
https://issues.apache.org/jira/browse/GEODE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654343#comment-15654343
]
ASF subversion and git services commented on GEODE-1808:
Commit e7e372368941dc391669015716e7e03f1e163679 in incubator-geode's branch
refs/heads/develop from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=e7e3723 ]
GEODE-1808 Remove broken check for jdk1.7.0_72
The logic for evaluating jdk versions is incorrect for 3-digit builds.
Since we require a jdk1.8 version anyway, remove the check.
> gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java
> version 1.7.0_101
> -
>
> Key: GEODE-1808
> URL: https://issues.apache.org/jira/browse/GEODE-1808
> Project: Geode
> Issue Type: Bug
> Components: general
>Reporter: Sergio Valenti
>
> We have recently updated out Java version to 1.7.0_101 on our server.
> However, after starting our java component which runs Gemfire version 8, we
> get the following log line:
> | FATAL | 20160821 18:05:30,626 | main |
> gemstone.gemfire.internal.cache.MinimumSystemRequirements | Java version
> older than 1.7.0_72.
> After looking at the source, it is apparent that the issue is in
> com.gemstone.gemfire.internal.lang.SystemUtils when dealing with java
> revisions which are 3 digits long
> public static boolean isJavaVersionAtLeast(String expectedVersion)
> {
> String actualVersionDigits =
> StringUtils.getDigitsOnly(System.getProperty("java.version"));
> String expectedVersionDigits =
> StringUtils.padEnding(StringUtils.getDigitsOnly(expectedVersion), '0',
> actualVersionDigits.length());
> try
> {
> return Long.parseLong(actualVersionDigits) >=
> Long.parseLong(expectedVersionDigits);
> }
> catch(NumberFormatException ignore)
> {
> return false;
> }
> }
> If you walk through this code with an expected version of java: 1.7.0_72 and
> an actual version of java: 1.7.0_101, it will create the following two long
> variables and compare them:
> actualVersionDigits "170101"
> expectedVersionDigits "170720"
> Which causes the comparison check to fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
