[jira] [Created] (GEODE-5255) In a race condition, a colocated bucket may not be created during rebalance when member nodes are restarted

[Eric Shu (JIRA)]

Eric Shu created GEODE-5255:
---

 Summary: In a race condition, a colocated bucket may not be 
created during rebalance when member nodes are restarted
 Key: GEODE-5255
 URL: https://issues.apache.org/jira/browse/GEODE-5255
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Eric Shu


During rebalance, a member node may request a newly started member node to grab 
a bucket from a parent partitioned region based on its calculated model. When 
the new member creates the parent bucket, it is required to grab the bucket's 
colocated child buckets. If the colocated child bucket underlying partitioned 
region is not yet initialized, the child bucket will not be created on the 
member.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5254) Configure spotless to allow line breaks in method chains (and elsewhere)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-5254:
--
Labels: pull-request-available  (was: )

> Configure spotless to allow line breaks in method chains (and elsewhere)
> 
>
> Key: GEODE-5254
> URL: https://issues.apache.org/jira/browse/GEODE-5254
> Project: Geode
>  Issue Type: Improvement
>Reporter: Dale Emery
>Priority: Major
>  Labels: pull-request-available
>
> Spotless sometimes joins consecutive lines in a way that makes the code less 
> readable.
> For some constructs, such as "fluent" method chains on Streams, Mocks, and 
> AssertJ assertions, the code is much more readable if the chained methods can 
> be aligned vertically, one per line, rather than being joined to fill lines.
> Spotless's current behavior is configured by this setting in 
> etc/eclipse-java-google-style.xml:
> {code:java}
>  value="true"/>{code}
> Changing this value to {{false}} would instruct spotless/eclipse *not* to 
> join already-wrapped lines.
> Changing this setting will not alter any existing code. It will instruct 
> spotless/eclipse to *refrain* from joining lines in the future.
> Note that changing this setting would cause spotless/eclipse to refrain from 
> joining *any* already-wrapped lines, not just lines in method chains. I have 
> been unable to find a more context-sensitive setting that refrains from 
> joining lines only in method chains.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5236) Intermittent NoSubscriptionServersAvailableException

[John Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490008#comment-16490008
 ] 

John Blum commented on GEODE-5236:
--

As it turns out, there is also another, related problem that occurs when 
cycling the cache instance used in _Integration Tests_, which can happen rather 
quickly.  This is particularly problematic when different tests in the 
_Integration Test Suite_ cycle between {{ClientCache}} instances and peer 
{{Cache}} instances as well, which is not at all uncommon.

It seems Apache Geode is not very timely or mutually exclusive about cleaning 
up the "cache reference" (and associated resources), as obtained from 
[{{CacheFactory.getAnyInstance()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/CacheFactory.html#getAnyInstance--]
 or 
[{{ClientCacheFactory.getAnyInstance()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientCacheFactory.html#getAnyInstance--],
 and creating a "*new*" instance (in subsequent tests in the suite).

As such, what happens is, a test can acquire an "existing" cache instance, 
created previously from some other test class (which is especially problematic 
when the cache types are different, i.e. "client" vs. "peer", or vice versa) 
even despite the fact the the previous test may have properly called 
{{GemFireCache.close()}}.

As such, undesirable logic like 
[this|https://github.com/spring-projects/spring-boot-data-geode/blob/master/geode-spring-boot-starter/src/test/java/org/springframework/boot/data/geode/cache/client/SpringBootApacheGeodeClientCacheApplicationIntegrationTests.java#L65-L68]
 (which is supported by 
[this|https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-test-data-geode/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L45-L67])
 is required.

Again, this is something I already support and handle on the user's behalf in 
the [*_Spring Test for Apache Geode & Pivotal GemFire (using Spring 
Data)_*|https://github.com/spring-projects/spring-test-data-geode] project.

> Intermittent NoSubscriptionServersAvailableException 
> -
>
> Key: GEODE-5236
> URL: https://issues.apache.org/jira/browse/GEODE-5236
> Project: Geode
>  Issue Type: Bug
>  Components: client queues, cq
>Reporter: Swapnil Bawaskar
>Priority: Major
>
> When the client connects to the server, the server creates a queue for the 
> events to send the client, whether the client is *durable* or not. If that 
> server-side queue is not ready, then a interest registration or CQ will cause 
> the \{{NoSubscriptionServersAvailableException}}.
> When the request for RI or CQ reaches the server, I think, the server should 
> be able to check if queue initialization is in progress, and the call should 
> block until the queue is ready.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5236) Intermittent NoSubscriptionServersAvailableException

[John Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489995#comment-16489995
 ] 

John Blum commented on GEODE-5236:
--

As such, additional logic is required at runtime, in the test (suite) class no 
less, to coordinate between the client and server, especially when the cache 
instance maybe be cycled rather quickly between tests, as explained in this 
email thread on the Apache Geode Dev Mailing List, with original question 
posted [here|http://markmail.org/message/rgrzv2rlcjt3z6rh and my follow up 
response (with solution) [here|http://markmail.org/message/66zgutdxs3cqyk6y].

This is something I plan to handle for users in the new [*_Spring Test for 
Apache Geode & Pivotal GemFire (using Spring 
Data)_*|https://github.com/spring-projects/spring-test-data-geode] project.

> Intermittent NoSubscriptionServersAvailableException 
> -
>
> Key: GEODE-5236
> URL: https://issues.apache.org/jira/browse/GEODE-5236
> Project: Geode
>  Issue Type: Bug
>  Components: client queues, cq
>Reporter: Swapnil Bawaskar
>Priority: Major
>
> When the client connects to the server, the server creates a queue for the 
> events to send the client, whether the client is *durable* or not. If that 
> server-side queue is not ready, then a interest registration or CQ will cause 
> the \{{NoSubscriptionServersAvailableException}}.
> When the request for RI or CQ reaches the server, I think, the server should 
> be able to check if queue initialization is in progress, and the call should 
> block until the queue is ready.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5224) statistics of Type DiskRegionStatistics is not correct after recovery from eviction

[Anilkumar Gingade (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489992#comment-16489992
 ] 

Anilkumar Gingade commented on GEODE-5224:
--

[~yossireg] can you please share your cache configuration and eviction setting. 

We have test verifying entriesOnlyOnDisk and entriesInVM 
(DiskRegionJUnitTest.testStats), it seems to be working fine. We modified the 
test to see if it reproduce with large number of entries, we were not 
successful.

If you have reproducible scenario; it will help us a lot.

> statistics of Type DiskRegionStatistics is not correct after recovery from 
> eviction
> ---
>
> Key: GEODE-5224
> URL: https://issues.apache.org/jira/browse/GEODE-5224
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Reporter: yossi reginiano
>Priority: Major
> Attachments: EntriesInVM.png, EntriesOnlyOnDisk.png
>
>
> we are using geode 1.4 and facing the following issue
> after getting into eviction we can see that entriesOnlyOnDisk is shown 
> correctly, the problem is when getting out of eviction - we can see that the 
> summarize is getting messed up and that entriesOnlyOnDisk is not reduced to 0 
> but rather stay high and on the other end - entriesInVM is reduced under 0.
> the numbers sum up ok - the issue is only that we reduce too much from 
> entriesInVM while part of it should have been removed from entriesOnlyOnDisk.
> the issue can be reproduced very simply by getting into and out of eviction 
> and monitoring the statistics.
> please see following screen shots that describes the issue-
> !image-2018-05-16-15-02-35-522.png!
>  
>  
> !image-2018-05-16-15-03-18-815.png!
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GEODE-5236) Intermittent NoSubscriptionServersAvailableException

[John Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489987#comment-16489987
 ] 

John Blum edited comment on GEODE-5236 at 5/24/18 11:37 PM:


Here is an example _Stack Trace_...

{code}
Caused by: org.springframework.context.ApplicationContextException: Failed to 
start bean 'continuousQueryListenerContainer'; nested exception is 
org.springframework.data.gemfire.GemfireQueryException: Could not execute query 
[BoilingTemperatures]; state is [UNKNOWN]; nested exception is 
org.apache.geode.cache.query.CqException: Failed to execute the CQ. CqName: 
BoilingTemperatures, Query String is: SELECT * FROM /TemperatureReadings r 
WHERE r.temperature >= 212, Error from last server: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:184)
at 
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:52)
at 
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:356)
at 
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:157)
at 
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:121)
at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:885)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:553)
at 
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:759)
at 
org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:395)
at 
org.springframework.boot.SpringApplication.run(SpringApplication.java:327)
at 
org.springframework.boot.test.context.SpringBootContextLoader.loadContext(SpringBootContextLoader.java:138)
at 
org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:99)
at 
org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:117)
... 35 more
Caused by: org.springframework.data.gemfire.GemfireQueryException: Could not 
execute query [BoilingTemperatures]; state is [UNKNOWN]; nested exception is 
org.apache.geode.cache.query.CqException: Failed to execute the CQ. CqName: 
BoilingTemperatures, Query String is: SELECT * FROM /TemperatureReadings r 
WHERE r.temperature >= 212, Error from last server: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.execute(ContinuousQueryListenerContainer.java:682)
at java.lang.Iterable.forEach(Iterable.java:75)
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.doStart(ContinuousQueryListenerContainer.java:672)
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.start(ContinuousQueryListenerContainer.java:661)
at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:181)
... 47 more
Caused by: org.apache.geode.cache.query.CqException: Failed to execute the CQ. 
CqName: BoilingTemperatures, Query String is: SELECT * FROM 
/TemperatureReadings r WHERE r.temperature >= 212, Error from last server: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.apache.geode.cache.query.internal.cq.ClientCQImpl.executeCqOnRedundantsAndPrimary(ClientCQImpl.java:443)
at 
org.apache.geode.cache.query.internal.cq.ClientCQImpl.execute(ClientCQImpl.java:272)
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.execute(ContinuousQueryListenerContainer.java:679)
... 51 more
Caused by: org.apache.geode.cache.NoSubscriptionServersAvailableException: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:190)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:540)
at 
org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:831)
at 

[jira] [Commented] (GEODE-5236) Intermittent NoSubscriptionServersAvailableException

[John Blum (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489987#comment-16489987
 ] 

John Blum commented on GEODE-5236:
--

Here is an example _Stack Trace_...

{code}
Caused by: org.springframework.context.ApplicationContextException: Failed to 
start bean 'continuousQueryListenerContainer'; nested exception is 
org.springframework.data.gemfire.GemfireQueryException: Could not execute query 
[BoilingTemperatures]; state is [UNKNOWN]; nested exception is 
org.apache.geode.cache.query.CqException: Failed to execute the CQ. CqName: 
BoilingTemperatures, Query String is: SELECT * FROM /TemperatureReadings r 
WHERE r.temperature >= 212, Error from last server: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:184)
at 
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:52)
at 
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:356)
at 
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:157)
at 
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:121)
at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:885)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:553)
at 
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:759)
at 
org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:395)
at 
org.springframework.boot.SpringApplication.run(SpringApplication.java:327)
at 
org.springframework.boot.test.context.SpringBootContextLoader.loadContext(SpringBootContextLoader.java:138)
at 
org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:99)
at 
org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:117)
... 35 more
Caused by: org.springframework.data.gemfire.GemfireQueryException: Could not 
execute query [BoilingTemperatures]; state is [UNKNOWN]; nested exception is 
org.apache.geode.cache.query.CqException: Failed to execute the CQ. CqName: 
BoilingTemperatures, Query String is: SELECT * FROM /TemperatureReadings r 
WHERE r.temperature >= 212, Error from last server: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.execute(ContinuousQueryListenerContainer.java:682)
at java.lang.Iterable.forEach(Iterable.java:75)
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.doStart(ContinuousQueryListenerContainer.java:672)
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.start(ContinuousQueryListenerContainer.java:661)
at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:181)
... 47 more
Caused by: org.apache.geode.cache.query.CqException: Failed to execute the CQ. 
CqName: BoilingTemperatures, Query String is: SELECT * FROM 
/TemperatureReadings r WHERE r.temperature >= 212, Error from last server: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.apache.geode.cache.query.internal.cq.ClientCQImpl.executeCqOnRedundantsAndPrimary(ClientCQImpl.java:443)
at 
org.apache.geode.cache.query.internal.cq.ClientCQImpl.execute(ClientCQImpl.java:272)
at 
org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer.execute(ContinuousQueryListenerContainer.java:679)
... 51 more
Caused by: org.apache.geode.cache.NoSubscriptionServersAvailableException: 
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not 
initialize a primary queue on startup. No queue servers available.
at 
org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:190)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:540)
at 
org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:831)
at 

[jira] [Resolved] (GEODE-5249) need test methods to display content of serial gateway sender queue

[xiaojian zhou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

xiaojian zhou resolved GEODE-5249.
--
   Resolution: Fixed
Fix Version/s: 1.8.0

> need test methods to display content of serial gateway sender queue
> ---
>
> Key: GEODE-5249
> URL: https://issues.apache.org/jira/browse/GEODE-5249
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: xiaojian zhou
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have method to display Parallel Gateway Sender Queue's content. We need 
> the same thing for serial gateway sender queue. 
>  
> Also we need to display the content for unprocessedEvents and 
> unprocessedTokens. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-4245) Support for Tombstone GC setting at region level

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely updated GEODE-4245:

Description: 
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting
 # Internal API to change the setting based on known batch operations
 # Batch operations (lucene index, aeq usage)
 # Require region level be lower than the cache level setting
 # Investigate tombstone shut-off functionality

 

Historical information:
 * Possible longer timeout used for replicated regions.

  was:
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting
 # Internal API to change the setting based on known batch operations
 # Batch operations (lucene index, aeq usage)
 # Require region level be lower than the cache level setting

 

Historical information:
 * Possible longer timeout used for replicated regions.


> Support for Tombstone GC setting at region level
> 
>
> Key: GEODE-4245
> URL: https://issues.apache.org/jira/browse/GEODE-4245
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>Priority: Major
>
> The Tombstone GC setting is at cache level. Which is applied across all the 
> regions in the cache.
> Having these at region gives a better control on managing Tombstone in the 
> system. They can be configured based on their usage and consistency 
> requirement.
> Also, Tombstone GC settings are time based (default 10minutes). Adding 
> Tombstone GC configuration based on number of tombstones will also help 
> managing tombstones and its impact on memory.
> The proposal is to:
>  # Have Tombstone GC setting at region level.
>  # Add count based Tombstone GC setting
>  # Internal API to change the setting based on known batch operations
>  # Batch operations (lucene index, aeq usage)
>  # Require region level be lower than the cache level setting
>  # Investigate tombstone shut-off functionality
>  
> Historical information:
>  * Possible longer timeout used for replicated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-4245) Support for Tombstone GC setting at region level

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely updated GEODE-4245:

Description: 
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting
 # Internal API to change the setting based on known batch operations
 # Batch operations (lucene index, aeq usage)
 # Require region level be lower than the cache level setting

 

Historical information:
 * Possible longer timeout used for replicated regions.

  was:
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting
 # Consider also heap utilization or give a max utilization
 # Batch operations (lucene index, aeq usage)

 

Historical information:
 * Possible longer timeout used for replicated regions.


> Support for Tombstone GC setting at region level
> 
>
> Key: GEODE-4245
> URL: https://issues.apache.org/jira/browse/GEODE-4245
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>Priority: Major
>
> The Tombstone GC setting is at cache level. Which is applied across all the 
> regions in the cache.
> Having these at region gives a better control on managing Tombstone in the 
> system. They can be configured based on their usage and consistency 
> requirement.
> Also, Tombstone GC settings are time based (default 10minutes). Adding 
> Tombstone GC configuration based on number of tombstones will also help 
> managing tombstones and its impact on memory.
> The proposal is to:
>  # Have Tombstone GC setting at region level.
>  # Add count based Tombstone GC setting
>  # Internal API to change the setting based on known batch operations
>  # Batch operations (lucene index, aeq usage)
>  # Require region level be lower than the cache level setting
>  
> Historical information:
>  * Possible longer timeout used for replicated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5209) Code Coverage Integration

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489897#comment-16489897
 ] 

ASF subversion and git services commented on GEODE-5209:


Commit 20ee9cd77c6169e068dd6735edd1adbbc6ed6ef6 in geode-native's branch 
refs/heads/develop from [~bbender]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=20ee9cd ]

GEODE-5209: Adding GCC code coverage (#300)

Co-authored-by: Ryan McMahon 
Co-authored-by: Mike Martell 
Co-authored-by: Ernest Burghardt 
Co-authored-by: Blake Bender 

> Code Coverage Integration
> -
>
> Key: GEODE-5209
> URL: https://issues.apache.org/jira/browse/GEODE-5209
> Project: Geode
>  Issue Type: Test
>  Components: native client
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> _As_ a Geode-Native contributor/developer
> _I want to_ use code coverage tools
> _So that_ see what code is currently covered by our unit and integration tests
>  
> We will want to add this to CMake so we can run code coverage analysis on 
> demand.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-4245) Support for Tombstone GC setting at region level

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely updated GEODE-4245:

Description: 
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting
 # Consider also heap utilization or give a max utilization
 # Batch operations (lucene index, aeq usage)

 

Historical information:
 * Possible longer timeout used for replicated regions.

  was:
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting
 # Batch operations (lucene index, aeq usage)

 

Historical information:
 * Possible longer timeout used for replicated regions.


> Support for Tombstone GC setting at region level
> 
>
> Key: GEODE-4245
> URL: https://issues.apache.org/jira/browse/GEODE-4245
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>Priority: Major
>
> The Tombstone GC setting is at cache level. Which is applied across all the 
> regions in the cache.
> Having these at region gives a better control on managing Tombstone in the 
> system. They can be configured based on their usage and consistency 
> requirement.
> Also, Tombstone GC settings are time based (default 10minutes). Adding 
> Tombstone GC configuration based on number of tombstones will also help 
> managing tombstones and its impact on memory.
> The proposal is to:
>  # Have Tombstone GC setting at region level.
>  # Add count based Tombstone GC setting
>  # Consider also heap utilization or give a max utilization
>  # Batch operations (lucene index, aeq usage)
>  
> Historical information:
>  * Possible longer timeout used for replicated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-4245) Support for Tombstone GC setting at region level

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely updated GEODE-4245:

Description: 
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting
 # Batch operations (lucene index, aeq usage)

 

Historical information:
 * Possible longer timeout used for replicated regions.

  was:
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting.

 

Historical information:
 * Possible longer timeout used for replicated regions.


> Support for Tombstone GC setting at region level
> 
>
> Key: GEODE-4245
> URL: https://issues.apache.org/jira/browse/GEODE-4245
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>Priority: Major
>
> The Tombstone GC setting is at cache level. Which is applied across all the 
> regions in the cache.
> Having these at region gives a better control on managing Tombstone in the 
> system. They can be configured based on their usage and consistency 
> requirement.
> Also, Tombstone GC settings are time based (default 10minutes). Adding 
> Tombstone GC configuration based on number of tombstones will also help 
> managing tombstones and its impact on memory.
> The proposal is to:
>  # Have Tombstone GC setting at region level.
>  # Add count based Tombstone GC setting
>  # Batch operations (lucene index, aeq usage)
>  
> Historical information:
>  * Possible longer timeout used for replicated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-4245) Support for Tombstone GC setting at region level

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely updated GEODE-4245:

Description: 
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting.

 

Historical information:
 * Possible longer timeout used for replicated regions.

  was:
The Tombstone GC setting is at cache level. Which is applied across all the 
regions in the cache.

Having these at region gives a better control on managing Tombstone in the 
system. They can be configured based on their usage and consistency requirement.

Also, Tombstone GC settings are time based (default 10minutes). Adding 
Tombstone GC configuration based on number of tombstones will also help 
managing tombstones and its impact on memory.

The proposal is to:
 # Have Tombstone GC setting at region level.
 # Add count based Tombstone GC setting.


> Support for Tombstone GC setting at region level
> 
>
> Key: GEODE-4245
> URL: https://issues.apache.org/jira/browse/GEODE-4245
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Reporter: Fred Krone
>Priority: Major
>
> The Tombstone GC setting is at cache level. Which is applied across all the 
> regions in the cache.
> Having these at region gives a better control on managing Tombstone in the 
> system. They can be configured based on their usage and consistency 
> requirement.
> Also, Tombstone GC settings are time based (default 10minutes). Adding 
> Tombstone GC configuration based on number of tombstones will also help 
> managing tombstones and its impact on memory.
> The proposal is to:
>  # Have Tombstone GC setting at region level.
>  # Add count based Tombstone GC setting.
>  
> Historical information:
>  * Possible longer timeout used for replicated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5237) DiskAccessException can sometimes state that actual usage is less than critical

[Lynn Gallinat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lynn Gallinat resolved GEODE-5237.
--
   Resolution: Fixed
Fix Version/s: 1.8.0

commit 5321796cc5f2cfdbe78ec9be60a80b194ea0cc71 (HEAD -> develop, 
origin/develop)
Author: lgallinat 
Date:   Thu May 24 14:24:37 2018 -0700

GEODE-5237 DiskAccessException can sometimes state that actual usage is 
less than critical (#1990)

> DiskAccessException can sometimes state that actual usage is less than 
> critical
> ---
>
> Key: GEODE-5237
> URL: https://issues.apache.org/jira/browse/GEODE-5237
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Lynn Gallinat
>Assignee: Lynn Gallinat
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It's possible that GEODE can throw a DiskAccessException stating that the 
> current file system usage exceeds the critical threshold, but the exception's 
> message states that the file system usage is UNDER the critical threshold, as 
> follows. This appears to be only an error in what is logged and GEODE really 
> is over critical.
> org.apache.geode.cache.DiskAccessException: For DiskStore: dmDiskStore_3604: 
> Critical disk usage threshold exceeded for volume 
> /var/vcap/data/scratch/serialParRegHABridgePersistParOffline-0516-200217/vm_2_bridge3_disk_1:
>  the file system is 5% full, which exceeds the critical threshold of 
> 5.203678%.
> The problem is that GEODE rounds the file system usage before logging it in 
> the message in the method DiskUsage.update(float, float), and this can cause 
> the problem when it gets rounded down:
>  double use = 100.0 * (total - remaining) / total;
>  recordStats(total, remaining, elapsed);
>  String pct = Math.round(use) + "%";  <=



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-3820) CI failure: DataSerializerPropogationDUnitTest.testDataSerializersEventIdVerification

[Shelley Lynn Hughes-Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shelley Lynn Hughes-Godfrey updated GEODE-3820:
---
Affects Version/s: 1.7.0

> CI failure: 
> DataSerializerPropogationDUnitTest.testDataSerializersEventIdVerification
> -
>
> Key: GEODE-3820
> URL: https://issues.apache.org/jira/browse/GEODE-3820
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Affects Versions: 1.7.0
>Reporter: Bruce Schuchardt
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This test contains many pauses & needs to be converted to use Awaitility.
> The spelling of this class name should also be corrected.
> org.apache.geode.internal.cache.tier.sockets.DataSerializerPropogationDUnitTest
>  > testDataSerializersEventIdVerificationClientsAndServers FAILED
> java.lang.AssertionError: EventId found Different
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.internal.cache.tier.sockets.DataSerializerPropogationDUnitTest.testDataSerializersEventIdVerificationClientsAndServers(DataSerializerPropogationDUnitTest.java:673)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-3820) CI failure: DataSerializerPropogationDUnitTest.testDataSerializersEventIdVerification

[Shelley Lynn Hughes-Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489779#comment-16489779
 ] 

Shelley Lynn Hughes-Godfrey commented on GEODE-3820:


Reopened as this failure reproduced on geode 1.7 branch:
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.7.0/jobs/DistributedTest/builds/3

{noformat}
org.apache.geode.internal.cache.tier.sockets.DataSerializerPropagationDUnitTest 
> testDataSerializersEventIdVerificationClientsAndServers FAILED
java.lang.AssertionError: EventId found Different
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.geode.internal.cache.tier.sockets.DataSerializerPropagationDUnitTest.testDataSerializersEventIdVerificationClientsAndServers(DataSerializerPropagationDUnitTest.java:408)
{noformat}

Comments from Barry:
I know Jason and I looked at a bug awhile ago (GEODE-4144) with event ids being 
different. It was a timing issue with the port being set, but I'm not sure if 
this could affect this.

If I were debugging this, I would add some logging in the 
afterReceivingFromServer callback if the event ids were different here:
{noformat}
private static void setClientServerObserver2() {
PoolImpl.IS_INSTANTIATOR_CALLBACK = true;
ClientServerObserverHolder.setInstance(new ClientServerObserverAdapter() {
@Override
public void afterReceivingFromServer(EventID eventID) {
testEventIDResult = eventID.equals(eventId);
}
});
}
{noformat}

> CI failure: 
> DataSerializerPropogationDUnitTest.testDataSerializersEventIdVerification
> -
>
> Key: GEODE-3820
> URL: https://issues.apache.org/jira/browse/GEODE-3820
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Affects Versions: 1.7.0
>Reporter: Bruce Schuchardt
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This test contains many pauses & needs to be converted to use Awaitility.
> The spelling of this class name should also be corrected.
> org.apache.geode.internal.cache.tier.sockets.DataSerializerPropogationDUnitTest
>  > testDataSerializersEventIdVerificationClientsAndServers FAILED
> java.lang.AssertionError: EventId found Different
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at 
> org.apache.geode.internal.cache.tier.sockets.DataSerializerPropogationDUnitTest.testDataSerializersEventIdVerificationClientsAndServers(DataSerializerPropogationDUnitTest.java:673)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5253) PDX Object corrupted in remove(K,V) or put(K,V,V) operations

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-5253:
---

 Summary: PDX Object corrupted in remove(K,V) or put(K,V,V) 
operations
 Key: GEODE-5253
 URL: https://issues.apache.org/jira/browse/GEODE-5253
 Project: Geode
  Issue Type: Improvement
  Components: serialization
Reporter: Bruce Schuchardt


A regression test ran into corruption in the expectedValue argument of 
remove(K,V) and put(K,V,V) operations when readPdxSerialized was enabled in 
clients and servers.  Here's an example:

{noformat}
bridgegemfire5_28694/system.log: [error 2018/05/24 11:55:13.360 PDT 
bridgegemfire5_trout_28694  tid=0x92] 
Caught Exception
org.apache.geode.pdx.PdxSerializationException: Exception deserializing a PDX 
field
at 
org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:250)
at 
org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:93)
at 
org.apache.geode.pdx.internal.PdxReaderImpl.readObject(PdxReaderImpl.java:333)
at 
org.apache.geode.pdx.internal.PdxInstanceImpl.readObject(PdxInstanceImpl.java:560)
at 
org.apache.geode.pdx.internal.PdxInstanceImpl.equals(PdxInstanceImpl.java:408)
at 
org.apache.geode.internal.cache.entries.AbstractRegionEntry.checkPdxEquals(AbstractRegionEntry.java:1163)
at 
org.apache.geode.internal.cache.entries.AbstractRegionEntry.checkEquals(AbstractRegionEntry.java:1030)
at 
org.apache.geode.internal.cache.entries.AbstractRegionEntry.checkExpectedOldValue(AbstractRegionEntry.java:955)
at 
org.apache.geode.internal.cache.entries.AbstractRegionEntry.destroy(AbstractRegionEntry.java:829)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyEntry(RegionMapDestroy.java:723)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:387)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:238)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:149)
at 
org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1035)
at 
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6544)
at 
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6518)
at 
org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1194)
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.destroyLocally(PartitionedRegionDataStore.java:1330)
at 
org.apache.geode.internal.cache.PartitionedRegionDataView.destroyOnRemote(PartitionedRegionDataView.java:107)
at 
org.apache.geode.internal.cache.partitioned.DestroyMessage.operateOnPartitionedRegion(DestroyMessage.java:268)
at 
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:334)
at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:378)
at 
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:444)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:945)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Unknown header byte: 116
at 
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:3100)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
at 
org.apache.geode.pdx.internal.PdxInputStream.readObject(PdxInputStream.java:248)
... 28 more
{noformat}

I was able to reproduce this and found that the bytes in the PdxInstance were 
corrupted.  Sometimes the length of the underlying byte buffer (which holds the 
serialized state of the object) was wrong, sometimes other bytes had been 
copied over the state of the PdxInstance leading to "bad header byte" errors, 
BufferUnderflowExceptions, etc.

I tracked this down to the PDX implementation having borrowed heavily from the 
TCPConduit buffer management classes.  If an object is deserialized into 
PdxInstance form in a P2P reader thread, the object retains a reference to the 
area in the P2P buffer that holds its serialized state.  If the object is then 
handed off to another thread, such as an executor thread, the object still 
points back to the P2P 

[jira] [Commented] (GEODE-4858) refactor internal commands to use the public ClusterConfigService

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489753#comment-16489753
 ] 

ASF subversion and git services commented on GEODE-4858:


Commit 71145b6f09efe5dbf8627a0525acef33777b8bed in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=71145b6 ]

GEODE-4858: Convert *DefinedIndex commands to use ResultModel and Sin… (#1983)



> refactor internal commands to use the public ClusterConfigService
> -
>
> Key: GEODE-4858
> URL: https://issues.apache.org/jira/browse/GEODE-4858
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 21h
>  Remaining Estimate: 0h
>
> # except the ones that would need to access the internal cluster 
> configuration regions, like importClusterConfigCommand, 
> exportClusterConfigCommand or deploy
>  # use the configuration object as much as possible to pass parameters to the 
> functions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5145) Lucene index needs to support being destroyed while region is being created

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489725#comment-16489725
 ] 

ASF subversion and git services commented on GEODE-5145:


Commit 8047a18ba27065a1001f12102442a813f37e in geode's branch 
refs/heads/feature/GEODE-5145 from [~barry.oglesby]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8047a18 ]

GEODE-5145: Incorporated review comments


> Lucene index needs to support being destroyed while region is being created
> ---
>
> Key: GEODE-5145
> URL: https://issues.apache.org/jira/browse/GEODE-5145
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Attempting to destroy a lucene index while the region is being created may 
> leave the lucene service in an inconsistent state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-4418) PersistentPartitionedRegionDUnitTest.testCleanupAfterConflict fails intermittently

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489723#comment-16489723
 ] 

ASF subversion and git services commented on GEODE-4418:


Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> PersistentPartitionedRegionDUnitTest.testCleanupAfterConflict fails 
> intermittently
> --
>
> Key: GEODE-4418
> URL: https://issues.apache.org/jira/browse/GEODE-4418
> Project: Geode
>  Issue Type: Bug
>  Components: persistence, regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: Flaky
>
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDUnitTest
>  > testCleanupAfterConflict FAILED
> java.lang.AssertionError: should have seen a conflicting data exception
> at org.junit.Assert.fail(Assert.java:88)
> at 
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDUnitTest.testCleanupAfterConflict(PersistentPartitionedRegionDUnitTest.java:2076)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-1738) CI Failure: PersistentPartitionedRegionOldConfigDUnitTest.testCrashDuringBucketCreation CacheClosedException

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489722#comment-16489722
 ] 

ASF subversion and git services commented on GEODE-1738:


Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> CI Failure: 
> PersistentPartitionedRegionOldConfigDUnitTest.testCrashDuringBucketCreation 
> CacheClosedException
> 
>
> Key: GEODE-1738
> URL: https://issues.apache.org/jira/browse/GEODE-1738
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.0.0-incubating
>Reporter: Scott Jewell
>Assignee: Kirk Lund
>Priority: Major
>  Labels: ci, flaky
>
> GemFire Distributed Tests build 3526
> CacheClosedException
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionTestBase$14.run
>  in VM 0 running on Host cc4-rh6.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
>   at 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionTestBase.createPR(PersistentPartitionedRegionTestBase.java:298)
>   at 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionDUnitTest.testCrashDuringBucketCreation(PersistentPartitionedRegionDUnitTest.java:1514)
>   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:497)
>   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 
> 

[jira] [Commented] (GEODE-1582) CI failure: PersistentPartitionedRegionOldConfigDUnitTest.testCleanStop

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489721#comment-16489721
 ] 

ASF subversion and git services commented on GEODE-1582:


Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> CI failure: PersistentPartitionedRegionOldConfigDUnitTest.testCleanStop
> ---
>
> Key: GEODE-1582
> URL: https://issues.apache.org/jira/browse/GEODE-1582
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Hitesh Khamesra
>Assignee: Kirk Lund
>Priority: Major
>  Labels: CI, flaky
>
> https://brazil.gemstone.com:8080//job/Geode_develop_DistributedTests/2963/testReport/com.gemstone.gemfire.internal.cache.partitioned/PersistentPartitionedRegionOldConfigDUnitTest/testCleanStop
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionTestBase$1.run
>  in VM 1 running on Host japan.gemstone.com with 4 VMs
> Stacktrace
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionTestBase$1.run
>  in VM 1 running on Host japan.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
>   at 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkRecoveredFromDisk(PersistentPartitionedRegionTestBase.java:100)
>   at 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionDUnitTest.testCleanStop(PersistentPartitionedRegionDUnitTest.java:1353)
>   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:497)
>   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:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> 

[jira] [Commented] (GEODE-974) CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup failed with AssertionError

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489718#comment-16489718
 ] 

ASF subversion and git services commented on GEODE-974:
---

Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup 
> failed with AssertionError
> ---
>
> Key: GEODE-974
> URL: https://issues.apache.org/jira/browse/GEODE-974
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Barry Oglesby
>Assignee: Kirk Lund
>Priority: Major
>  Labels: CI, Flaky, pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Geode_develop_DistributedTests
> Private Build #1602 (Feb 13, 2016 9:09:53 AM)
> Revision: 781277f31f37388f7247cbdf05025c12de825d2a
> Error Message
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during 
> this run.
> Fix the strings or use DistributedTestCase.addExpectedException to ignore.
> ---
> Found suspect string in log4j at line 2919
> [fatal 2016/02/13 11:30:42.638 PST  tid=0x580] 
> Uncaught exception processing  Alert "Error processing request class 
> com.gemstone.gemfire.internal.admin.remote.PrepareRevokePersistentIDRequest." 
> level ERROR
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getApplicationById(RemoteGfManagerAgent.java:606)
>   at 
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getMemberById(RemoteGfManagerAgent.java:592)
>   at 
> com.gemstone.gemfire.internal.admin.remote.AlertListenerMessage.process(AlertListenerMessage.java:83)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:380)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:451)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:656)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:930)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Stacktrace
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase$1.call
>  in VM 0 running on Host cc4-rh6.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:372)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:315)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:281)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.createDefaultSetup(CliCommandTestBase.java:105)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest.testCreateRegion46391(CreateAlterDestroyRegionCommandsDUnitTest.java:290)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at 

[jira] [Commented] (GEODE-1047) CI failure: PersistentPartitionedRegionOldConfigDUnitTest.testMissingMemberRedundancy1

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489719#comment-16489719
 ] 

ASF subversion and git services commented on GEODE-1047:


Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> CI failure: 
> PersistentPartitionedRegionOldConfigDUnitTest.testMissingMemberRedundancy1
> --
>
> Key: GEODE-1047
> URL: https://issues.apache.org/jira/browse/GEODE-1047
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Jason Huynh
>Assignee: Kirk Lund
>Priority: Major
>  Labels: CI, Flaky
>
> junit.framework.AssertionFailedError: expected:<[]> but was:<[12]>
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:86)
>   at junit.framework.TestCase.assertEquals(TestCase.java:253)
>   at 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionDUnitTest.testMissingMemberRedundancy1(PersistentPartitionedRegionDUnitTest.java:1103)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   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:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 

[jira] [Commented] (GEODE-5145) Lucene index needs to support being destroyed while region is being created

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489724#comment-16489724
 ] 

ASF subversion and git services commented on GEODE-5145:


Commit d95c4cf315a4ab0de1457c4d7c11a6157b1f515d in geode's branch 
refs/heads/feature/GEODE-5145 from [~barry.oglesby]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d95c4cf ]

GEODE-5145: Added support for destroying an index during region creation


> Lucene index needs to support being destroyed while region is being created
> ---
>
> Key: GEODE-5145
> URL: https://issues.apache.org/jira/browse/GEODE-5145
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Attempting to destroy a lucene index while the region is being created may 
> leave the lucene service in an inconsistent state.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-1208) PersistentPartitionedRegionDUnitTest.testBug42226

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489720#comment-16489720
 ] 

ASF subversion and git services commented on GEODE-1208:


Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> PersistentPartitionedRegionDUnitTest.testBug42226
> -
>
> Key: GEODE-1208
> URL: https://issues.apache.org/jira/browse/GEODE-1208
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>Priority: Major
>  Labels: CI, Flaky
>
> Geode_develop_DistributedTests/2215/
> Revision: 616bc27de8621224a9c7fba19a84dfc4eb4d520f
> {noformat}
> java.lang.Exception: An exception occured during async invocation
>   at 
> com.gemstone.gemfire.test.dunit.AsyncInvocation.getResult(AsyncInvocation.java:195)
>   at 
> com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionDUnitTest.testBug42226(PersistentPartitionedRegionDUnitTest.java:1701)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor396.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   at sun.reflect.GeneratedMethodAccessor395.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> 

[jira] [Commented] (GEODE-5175) Remove PersistentPartitionedRegionTestBase

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489717#comment-16489717
 ] 

ASF subversion and git services commented on GEODE-5175:


Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> Remove PersistentPartitionedRegionTestBase
> --
>
> Key: GEODE-5175
> URL: https://issues.apache.org/jira/browse/GEODE-5175
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
>
> Remove PersistentPartitionedRegionTestBase and overhaul the tests that extend 
> it:
> {noformat}
> JUnit4DistributedTestCase (org.apache.geode.test.dunit.internal)
> JUnit4CacheTestCase (org.apache.geode.test.dunit.cache.internal)
> PersistentPartitionedRegionTestBase 
> (org.apache.geode.internal.cache.partitioned)
> PersistentPartitionedRegionWithTransactionDUnitTest 
> (org.apache.geode.internal.cache.partitioned)
> PersistentPartitionedRegionWithDistTXDUnitTest 
> (org.apache.geode.disttx)
> PersistentColocatedPartitionedRegionDUnitTest 
> (org.apache.geode.internal.cache.partitioned)
> PersistentPartitionedRegionDUnitTest 
> (org.apache.geode.internal.cache.partitioned)
> PersistentPartitionedRegionOldConfigDUnitTest 
> (org.apache.geode.internal.cache.partitioned)
> BackupDistributedTest (org.apache.geode.internal.cache.backup)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-974) CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup failed with AssertionError

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489716#comment-16489716
 ] 

ASF subversion and git services commented on GEODE-974:
---

Commit d6d97aaea4c5fef060ff918c8d85a85f3a7f123a in geode's branch 
refs/heads/feature/GEODE-5145 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6d97aa ]

GEODE-974: Fix PersistentPartitionedRegionDistributedTest

* Rename PersistentPartitionedRegionDUnitTest -> 
PersistentPartitionedRegionDistributedTest
* Remove dependency on PersistentPartitionedRegionTestBase (GEODE-5175)
* Rename all test methods
* Overhaul test to use JUnit Rules, Awaitility and AssertJ

Fix all flaky issues in this test:
* GEODE-974: testRevokeBeforeStartup
* GEODE-1047: testMissingMemberRedundancy1
* GEODE-1208: testBug42226
* GEODE-1582: testCleanStop
* GEODE-1738: testCrashDuringBucketCreation
* GEODE-4418: testCleanupAfterConflict


> CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup 
> failed with AssertionError
> ---
>
> Key: GEODE-974
> URL: https://issues.apache.org/jira/browse/GEODE-974
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Barry Oglesby
>Assignee: Kirk Lund
>Priority: Major
>  Labels: CI, Flaky, pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Geode_develop_DistributedTests
> Private Build #1602 (Feb 13, 2016 9:09:53 AM)
> Revision: 781277f31f37388f7247cbdf05025c12de825d2a
> Error Message
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during 
> this run.
> Fix the strings or use DistributedTestCase.addExpectedException to ignore.
> ---
> Found suspect string in log4j at line 2919
> [fatal 2016/02/13 11:30:42.638 PST  tid=0x580] 
> Uncaught exception processing  Alert "Error processing request class 
> com.gemstone.gemfire.internal.admin.remote.PrepareRevokePersistentIDRequest." 
> level ERROR
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getApplicationById(RemoteGfManagerAgent.java:606)
>   at 
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getMemberById(RemoteGfManagerAgent.java:592)
>   at 
> com.gemstone.gemfire.internal.admin.remote.AlertListenerMessage.process(AlertListenerMessage.java:83)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:380)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:451)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:656)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:930)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Stacktrace
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase$1.call
>  in VM 0 running on Host cc4-rh6.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:372)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:315)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:281)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.createDefaultSetup(CliCommandTestBase.java:105)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest.testCreateRegion46391(CreateAlterDestroyRegionCommandsDUnitTest.java:290)
>   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:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at 

[jira] [Commented] (GEODE-4858) refactor internal commands to use the public ClusterConfigService

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489715#comment-16489715
 ] 

ASF subversion and git services commented on GEODE-4858:


Commit 9203ccd1a8fe6006b7a6e9e0f8ebcd8145a2ca99 in geode's branch 
refs/heads/feature/GEODE-5145 from [~khowe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9203ccd ]

GEODE-4858: Refactor destroy gateway-receiver command (#1968)

* GEODE-4858: Refactor destroy gateway-receiver command

Refactored to use SingleGfshCommand and ResultModel

Added tests for more complete unit test coverage of
DestroyGatewayReceiverFuntion


> refactor internal commands to use the public ClusterConfigService
> -
>
> Key: GEODE-4858
> URL: https://issues.apache.org/jira/browse/GEODE-4858
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20h 50m
>  Remaining Estimate: 0h
>
> # except the ones that would need to access the internal cluster 
> configuration regions, like importClusterConfigCommand, 
> exportClusterConfigCommand or deploy
>  # use the configuration object as much as possible to pass parameters to the 
> functions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-4858) refactor internal commands to use the public ClusterConfigService

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489714#comment-16489714
 ] 

ASF subversion and git services commented on GEODE-4858:


Commit 9203ccd1a8fe6006b7a6e9e0f8ebcd8145a2ca99 in geode's branch 
refs/heads/feature/GEODE-5145 from [~khowe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9203ccd ]

GEODE-4858: Refactor destroy gateway-receiver command (#1968)

* GEODE-4858: Refactor destroy gateway-receiver command

Refactored to use SingleGfshCommand and ResultModel

Added tests for more complete unit test coverage of
DestroyGatewayReceiverFuntion


> refactor internal commands to use the public ClusterConfigService
> -
>
> Key: GEODE-4858
> URL: https://issues.apache.org/jira/browse/GEODE-4858
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20h 50m
>  Remaining Estimate: 0h
>
> # except the ones that would need to access the internal cluster 
> configuration regions, like importClusterConfigCommand, 
> exportClusterConfigCommand or deploy
>  # use the configuration object as much as possible to pass parameters to the 
> functions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5252) Race in management adapter could fail to create MXBeans.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-5252:
--
Labels: pull-request-available  (was: )

> Race in management adapter could fail to create MXBeans.
> 
>
> Key: GEODE-5252
> URL: https://issues.apache.org/jira/browse/GEODE-5252
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
>
> Handling DiskStore creation event to create DiskStoreMXBean could result into 
> a null pointer due to race in ManagementAdapter.java.
> {noformat}
> java.lang.NullPointerException
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleDiskCreation(ManagementAdapter.java:380)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:122)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:590)
>   at 
> org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:143)
> {noformat}
> ManagementAdapter.handleDiskCreation throws NullPointerException on line 380 
> which means the thread invoking handleDiskCreation is seeing null for the 
> field service.
> {noformat}
> service.federate(changedMBeanName, DiskStoreMXBean.class, true);
> {noformat}
> Looks like service is SystemManagementService and it's set to a non-null 
> value in ManagementAdaptor.handleCacheCreation:
> {noformat}
>   this.service =
>   (SystemManagementService) 
> ManagementService.getManagementService(internalCache);
> {noformat}
> The field is not volatile and it's not protected by any synchronization:
> {noformat}
>   /** Internal ManagementService Instance **/
>   private SystemManagementService service;
> {noformat}
> Lots of other fields in ManagementAdaptor also appear to NOT be thread-safe. 
> Looks like ManagementAdaptor concurrency in general needs to be fixed up to 
> fix this bug.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5186) set operation in a client transaction could cause the transaction to hang

[Eric Shu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Shu resolved GEODE-5186.
-
   Resolution: Fixed
Fix Version/s: 1.8.0

> set operation in a client transaction could cause the transaction to hang
> -
>
> Key: GEODE-5186
> URL: https://issues.apache.org/jira/browse/GEODE-5186
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 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
>Reporter: Eric Shu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> During an entry operation in a client transaction, server connection could be 
> lost. In this case, client will failover to another server and try to resume 
> the transaction and retry the operation if the original transaction host node 
> is found. 
> If this operation happens to be a keySet operation (or other set operations) 
> on a partitioned region, the transaction could hang due to a deadlock.
> The scenario is the original tx host node holds its transactional lock when 
> sending fetchKey request to other nodes hosting the partitioned region data. 
> The node on which the client transaction failed over, will hold its 
> transactional lock while sending the FetchKey message to transaction hosting 
> node.
> These two FetchKeyMessage will not be able to be processed as processing 
> these tx message requires to hold the lock. But the locks are already been 
> held by the nodes handing the client message of the transaction.
> {noformat}
> vm_6_bridge7_latvia_25133:PartitionedRegion Message Processor10 ID=0xe2(226) 
> state=WAITING
> waiting to lock 
> 
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at 
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at 
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at 
> org.apache.geode.internal.cache.TXManagerImpl.getLock(TXManagerImpl.java:921)
> at 
> org.apache.geode.internal.cache.TXManagerImpl.masqueradeAs(TXManagerImpl.java:881)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:332)
> at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:378)
> at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:444)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$8$1.run(ClusterDistributionManager.java:945)
> at java.lang.Thread.run(Thread.java:745)
> Locked synchronizers:
> java.util.concurrent.ThreadPoolExecutor$Worker@c84d7d4
> vm_6_bridge7_latvia_25133:ServerConnection on port 23931 Thread 10 
> ID=0x128(296) state=TIMED_WAITING
> waiting to lock 
> at sun.misc.Unsafe.park(Native Method)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at 
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:61)
> at 
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:715)
> at 
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:790)
> at 
> 

[jira] [Updated] (GEODE-5249) need test methods to display content of serial gateway sender queue

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-5249:
--
Labels: pull-request-available  (was: )

> need test methods to display content of serial gateway sender queue
> ---
>
> Key: GEODE-5249
> URL: https://issues.apache.org/jira/browse/GEODE-5249
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: xiaojian zhou
>Priority: Major
>  Labels: pull-request-available
>
> We have method to display Parallel Gateway Sender Queue's content. We need 
> the same thing for serial gateway sender queue. 
>  
> Also we need to display the content for unprocessedEvents and 
> unprocessedTokens. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5249) need test methods to display content of serial gateway sender queue

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489569#comment-16489569
 ] 

ASF subversion and git services commented on GEODE-5249:


Commit 4f5e41f429ca49490e9ace6db99ef182bea50eca in geode's branch 
refs/heads/feature/GEODE-5249 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f5e41f ]

GEODE-5249: add test code to display serial gateway sender queue's content


> need test methods to display content of serial gateway sender queue
> ---
>
> Key: GEODE-5249
> URL: https://issues.apache.org/jira/browse/GEODE-5249
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: xiaojian zhou
>Priority: Major
>
> We have method to display Parallel Gateway Sender Queue's content. We need 
> the same thing for serial gateway sender queue. 
>  
> Also we need to display the content for unprocessedEvents and 
> unprocessedTokens. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5249) need test methods to display content of serial gateway sender queue

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489544#comment-16489544
 ] 

ASF subversion and git services commented on GEODE-5249:


Commit 40f51112fb8759c4063f650b3bb7b7a90cac59dc in geode's branch 
refs/heads/feature/GEODE-5249 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=40f5111 ]

GEODE-5249: add test code to display serial gateway sender queue's content


> need test methods to display content of serial gateway sender queue
> ---
>
> Key: GEODE-5249
> URL: https://issues.apache.org/jira/browse/GEODE-5249
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: xiaojian zhou
>Priority: Major
>
> We have method to display Parallel Gateway Sender Queue's content. We need 
> the same thing for serial gateway sender queue. 
>  
> Also we need to display the content for unprocessedEvents and 
> unprocessedTokens. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5252) Race in management adapter could fail to create MXBeans.

[Sai Boorlagadda (JIRA)]

Sai Boorlagadda created GEODE-5252:
--

 Summary: Race in management adapter could fail to create MXBeans.
 Key: GEODE-5252
 URL: https://issues.apache.org/jira/browse/GEODE-5252
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Sai Boorlagadda


Handling DiskStore creation event to create DiskStoreMXBean could result into a 
null pointer due to race in ManagementAdapter.java.

{noformat}
java.lang.NullPointerException
at 
org.apache.geode.management.internal.beans.ManagementAdapter.handleDiskCreation(ManagementAdapter.java:380)
at 
org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:122)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:590)
at 
org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:143)
{noformat}
ManagementAdapter.handleDiskCreation throws NullPointerException on line 380 
which means the thread invoking handleDiskCreation is seeing null for the field 
service.
{noformat}
service.federate(changedMBeanName, DiskStoreMXBean.class, true);
{noformat}
Looks like service is SystemManagementService and it's set to a non-null value 
in ManagementAdaptor.handleCacheCreation:
{noformat}
  this.service =
  (SystemManagementService) 
ManagementService.getManagementService(internalCache);
{noformat}
The field is not volatile and it's not protected by any synchronization:
{noformat}
  /** Internal ManagementService Instance **/
  private SystemManagementService service;
{noformat}
Lots of other fields in ManagementAdaptor also appear to NOT be thread-safe. 
Looks like ManagementAdaptor concurrency in general needs to be fixed up to fix 
this bug.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-4658) Expose how much time it takes to write to disk and what is the disk store size

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely reassigned GEODE-4658:
---

Assignee: Nick Vallely

> Expose how much time it takes to write to disk and what is the disk store size
> --
>
> Key: GEODE-4658
> URL: https://issues.apache.org/jira/browse/GEODE-4658
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Fred Krone
>Assignee: Nick Vallely
>Priority: Major
>  Labels: starter++
>
> *Given* I have a persistent region with a default disk store
> *When* I write data on the region
> *Then* I can see  2 new metrics {{average write time to disk}} ns time and 
> {{size of disk store}} in bytes
> h3. Documentation
> Add these new metrics to the docs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-788) Provide region.clear() implementation for Partitioned Regions

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely updated GEODE-788:
---
Component/s: core

> Provide region.clear() implementation for Partitioned Regions
> -
>
> Key: GEODE-788
> URL: https://issues.apache.org/jira/browse/GEODE-788
> Project: Geode
>  Issue Type: New Feature
>  Components: core
>Reporter: William Markito Oliveira
>Assignee: Nick Vallely
>Priority: Major
>
> The current PartitionedRegion API doesn't offer a clear operation.
> {code}
> // from PartitionedRegion.java 
>  /**
>* @since 5.0
>* @throws UnsupportedOperationException
>* OVERRIDES
>*/
>  @Override
>  public void clear() {
> throw new UnsupportedOperationException();
>   }
>   @Override
>   void basicClear(RegionEventImpl regionEvent, boolean cacheWrite) {
> throw new UnsupportedOperationException();
>   }
>   @Override
>   void basicLocalClear(RegionEventImpl event) {
> throw new UnsupportedOperationException();
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-788) Provide region.clear() implementation for Partitioned Regions

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely updated GEODE-788:
---
Component/s: (was: core)

> Provide region.clear() implementation for Partitioned Regions
> -
>
> Key: GEODE-788
> URL: https://issues.apache.org/jira/browse/GEODE-788
> Project: Geode
>  Issue Type: New Feature
>  Components: core
>Reporter: William Markito Oliveira
>Assignee: Nick Vallely
>Priority: Major
>
> The current PartitionedRegion API doesn't offer a clear operation.
> {code}
> // from PartitionedRegion.java 
>  /**
>* @since 5.0
>* @throws UnsupportedOperationException
>* OVERRIDES
>*/
>  @Override
>  public void clear() {
> throw new UnsupportedOperationException();
>   }
>   @Override
>   void basicClear(RegionEventImpl regionEvent, boolean cacheWrite) {
> throw new UnsupportedOperationException();
>   }
>   @Override
>   void basicLocalClear(RegionEventImpl event) {
> throw new UnsupportedOperationException();
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (GEODE-788) Provide region.clear() implementation for Partitioned Regions

[Nick Vallely (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vallely reassigned GEODE-788:
--

Assignee: Nick Vallely  (was: Kirk Lund)

> Provide region.clear() implementation for Partitioned Regions
> -
>
> Key: GEODE-788
> URL: https://issues.apache.org/jira/browse/GEODE-788
> Project: Geode
>  Issue Type: New Feature
>  Components: core
>Reporter: William Markito Oliveira
>Assignee: Nick Vallely
>Priority: Major
>
> The current PartitionedRegion API doesn't offer a clear operation.
> {code}
> // from PartitionedRegion.java 
>  /**
>* @since 5.0
>* @throws UnsupportedOperationException
>* OVERRIDES
>*/
>  @Override
>  public void clear() {
> throw new UnsupportedOperationException();
>   }
>   @Override
>   void basicClear(RegionEventImpl regionEvent, boolean cacheWrite) {
> throw new UnsupportedOperationException();
>   }
>   @Override
>   void basicLocalClear(RegionEventImpl event) {
> throw new UnsupportedOperationException();
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-4399) .NET Region API should not require callback argument.

[Michael Oleske (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489345#comment-16489345
 ] 

Michael Oleske commented on GEODE-4399:
---

Just gonna do all the callbacks we find for now

> .NET Region API should not require callback argument.
> -
>
> Key: GEODE-4399
> URL: https://issues.apache.org/jira/browse/GEODE-4399
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Michael Oleske
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5237) DiskAccessException can sometimes state that actual usage is less than critical

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-5237:
--
Labels: pull-request-available  (was: )

> DiskAccessException can sometimes state that actual usage is less than 
> critical
> ---
>
> Key: GEODE-5237
> URL: https://issues.apache.org/jira/browse/GEODE-5237
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Lynn Gallinat
>Assignee: Lynn Gallinat
>Priority: Major
>  Labels: pull-request-available
>
> It's possible that GEODE can throw a DiskAccessException stating that the 
> current file system usage exceeds the critical threshold, but the exception's 
> message states that the file system usage is UNDER the critical threshold, as 
> follows. This appears to be only an error in what is logged and GEODE really 
> is over critical.
> org.apache.geode.cache.DiskAccessException: For DiskStore: dmDiskStore_3604: 
> Critical disk usage threshold exceeded for volume 
> /var/vcap/data/scratch/serialParRegHABridgePersistParOffline-0516-200217/vm_2_bridge3_disk_1:
>  the file system is 5% full, which exceeds the critical threshold of 
> 5.203678%.
> The problem is that GEODE rounds the file system usage before logging it in 
> the message in the method DiskUsage.update(float, float), and this can cause 
> the problem when it gets rounded down:
>  double use = 100.0 * (total - remaining) / total;
>  recordStats(total, remaining, elapsed);
>  String pct = Math.round(use) + "%";  <=



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (GEODE-5204) Add 'get/set cluster-config' gfsh command

[Barbara Pruijn (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489235#comment-16489235
 ] 

Barbara Pruijn edited comment on GEODE-5204 at 5/24/18 4:28 PM:


After more consideration, we have decided to add the set functionality to the 
existing import cluster-configuration command.

The following options will be added:
{code:java}
import cluster-configuration --xml  --group --action{code}
The options --xml and --group will work combined.
 Default value for --action is apply. This will apply the given configuration 
to the cluster and will store the configuration in the cluster configuration. 
If the cluster is running and has configuration and data, this will fail.
 The other value for --action is stage. This will put the configuration in the 
cluster configuration but will not apply it to the running servers.
 The --action will also work with the --zip option.

 

The get functionality will be added to the existing export 
cluster-configuration command:
{code:java}
export cluster-configuration --file{code}
 will export the cluster configuration xml in one file and not a zipped 
directory structure. It will also not include the jar files.


was (Author: bpruijn):
After more consideration, we have decided to add this functionality to the 
existing import cluster-configuration command.

The following options will be added:
{code:java}
import cluster-configuration --xml  --group --action{code}

The options --xml and --group will work combined.
Default value for --action is apply. This will apply the given configuration to 
the cluster and will store the configuration in the cluster configuration. If 
the cluster is running and has configuration and data, this will fail.
The other value for --action is stage. This will put the configuration in the 
cluster configuration but will not apply it to the running servers.
The --action will also work with the --zip option.

> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the 
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and 
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes 
> propagated to all other locators.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5249) need test methods to display content of serial gateway sender queue

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489268#comment-16489268
 ] 

ASF subversion and git services commented on GEODE-5249:


Commit 19a00c75da0e3b9d478f33b410e040cff96ea04b in geode's branch 
refs/heads/feature/GEODE-5249 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=19a00c7 ]

GEODE-5249: add test code to display serial gateway sender queue's content


> need test methods to display content of serial gateway sender queue
> ---
>
> Key: GEODE-5249
> URL: https://issues.apache.org/jira/browse/GEODE-5249
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: xiaojian zhou
>Priority: Major
>
> We have method to display Parallel Gateway Sender Queue's content. We need 
> the same thing for serial gateway sender queue. 
>  
> Also we need to display the content for unprocessedEvents and 
> unprocessedTokens. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5204) Add 'get/set cluster-config' gfsh command

[Barbara Pruijn (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489235#comment-16489235
 ] 

Barbara Pruijn commented on GEODE-5204:
---

After more consideration, we have decided to add this functionality to the 
existing import cluster-configuration command.

The following options will be added:
{code:java}
import cluster-configuration --xml  --group --action{code}

The options --xml and --group will work combined.
Default value for --action is apply. This will apply the given configuration to 
the cluster and will store the configuration in the cluster configuration. If 
the cluster is running and has configuration and data, this will fail.
The other value for --action is stage. This will put the configuration in the 
cluster configuration but will not apply it to the running servers.
The --action will also work with the --zip option.

> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the 
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and 
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes 
> propagated to all other locators.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (GEODE-5204) Add 'get/set cluster-config' gfsh command

[Barbara Pruijn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barbara Pruijn updated GEODE-5204:
--
Component/s: docs

> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the 
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and 
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes 
> propagated to all other locators.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-5234) Geode OSS should include Geode-Native tar

[Anthony Baker (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489088#comment-16489088
 ] 

Anthony Baker commented on GEODE-5234:
--

AFAICT, this is not needed.  Please reopen and add more detail if I 
misunderstood.

> Geode OSS should include Geode-Native tar
> -
>
> Key: GEODE-5234
> URL: https://issues.apache.org/jira/browse/GEODE-5234
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Addison
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5234) Geode OSS should include Geode-Native tar

[Anthony Baker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony Baker resolved GEODE-5234.
--
Resolution: Invalid

> Geode OSS should include Geode-Native tar
> -
>
> Key: GEODE-5234
> URL: https://issues.apache.org/jira/browse/GEODE-5234
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Addison
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-1416) Prepare geode-native for a source release

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489053#comment-16489053
 ] 

ASF subversion and git services commented on GEODE-1416:


Commit aa52e2fa7969ee7082794940530e45ee1042366a in geode-native's branch 
refs/heads/develop from [~amb]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=aa52e2f ]

GEODE-1416 Corrected minor wording to refer to Geode


> Prepare geode-native for a source release
> -
>
> Key: GEODE-1416
> URL: https://issues.apache.org/jira/browse/GEODE-1416
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Anthony Baker
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The next-gen-native-client-software-grant branch [1] contains the GemFire 
> native client. In order to merge this code into the develop branch, we need 
> to: 
> 1) Review the code and determine what 3rd party libraries are bundled with 
> the source and binary distributions. These will need to be properly 
> attributed in the respective LICENSE and NOTICE files. 
> 2) Update the source headers to remove old copyrights and replace with the 
> Apache source header. 
> 3) Improve the build process to make it simpler for contributors and users. 
> This includes writing up build instructions. 
> 4) Incorporate other suggestions from the community. 
> [1] 
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=shortlog;h=refs/heads/next-gen-native-client-software-grant



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (GEODE-1416) Prepare geode-native for a source release

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489054#comment-16489054
 ] 

ASF subversion and git services commented on GEODE-1416:


Commit 8088058116dc9ed2d45776882add7386582f42f1 in geode-native's branch 
refs/heads/develop from [~amb]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=8088058 ]

Merge pull request #297 from metatype/develop

GEODE-1416 Corrected minor wording to refer to Geode

> Prepare geode-native for a source release
> -
>
> Key: GEODE-1416
> URL: https://issues.apache.org/jira/browse/GEODE-1416
> Project: Geode
>  Issue Type: New Feature
>  Components: native client
>Reporter: Anthony Baker
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The next-gen-native-client-software-grant branch [1] contains the GemFire 
> native client. In order to merge this code into the develop branch, we need 
> to: 
> 1) Review the code and determine what 3rd party libraries are bundled with 
> the source and binary distributions. These will need to be properly 
> attributed in the respective LICENSE and NOTICE files. 
> 2) Update the source headers to remove old copyrights and replace with the 
> Apache source header. 
> 3) Improve the build process to make it simpler for contributors and users. 
> This includes writing up build instructions. 
> 4) Incorporate other suggestions from the community. 
> [1] 
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=shortlog;h=refs/heads/next-gen-native-client-software-grant



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (GEODE-5251) Parameterize assembly info

[Anthony Baker (JIRA)]

Anthony Baker created GEODE-5251:


 Summary: Parameterize assembly info
 Key: GEODE-5251
 URL: https://issues.apache.org/jira/browse/GEODE-5251
 Project: Geode
  Issue Type: Sub-task
  Components: native client
Reporter: Anthony Baker


Some of the fields in 
{{[clicache/src/impl/AssemblyInfo.cpp.in|https://github.com/apache/geode-native/pull/297/files/aa52e2fa7969ee7082794940530e45ee1042366a#diff-2ba30c65953794a80be3c9f17447aed8]}}
 should be filled in by CMake vars when creating the assembly.  See PR #297.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (GEODE-5220) DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes Earlier

[JIRA]

 [ 
https://issues.apache.org/jira/browse/GEODE-5220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Juan José Ramos Cassella resolved GEODE-5220.
-
   Resolution: Fixed
Fix Version/s: 1.7.0

Changes merged into develop by through 
[9e8dfb21d661d225fd579a6bccbfed9b4a1ea536|https://github.com/apache/geode/commit/9e8dfb21d661d225fd579a6bccbfed9b4a1ea536].
Setting the Fix Version to 1.7.0, as stated in the [Developer 
Workflow|https://cwiki.apache.org/confluence/display/GEODE/Developer+Workflow].

> DistributedRegion Should Validate AsyncEventQueue/GatewaySender Attributes 
> Earlier
> --
>
> Key: GEODE-5220
> URL: https://issues.apache.org/jira/browse/GEODE-5220
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, regions, wan
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
> Attachments: reproducer.zip
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The method {{DistributedRegion.postCreateRegion()}} currently validates that 
> the {{gateway-sender}} or {{async-event-queue}} associated with the region 
> upon creation (if any) is not of type {{parallel}} as that is not supported 
> by regions of type {{REPLICATED}}:
> {code:title=DistributedRegion.java|borderStyle=solid}
>   @Override
>   public void postCreateRegion() {
> super.postCreateRegion();
> ...
>   Set allGatewaySenderIds = getAllGatewaySenderIds();
>   if (!allGatewaySenderIds.isEmpty()) {
> for (GatewaySender sender : this.cache.getAllGatewaySenders()) {
>   if (sender.isParallel() && 
> allGatewaySenderIds.contains(sender.getId())) {
> // Fix for Bug#51491. Once decided to support this configuration 
> we have call
> // addShadowPartitionedRegionForUserRR
> if 
> (sender.getId().contains(AsyncEventQueueImpl.ASYNC_EVENT_QUEUE_PREFIX)) {
>   throw new AsyncEventQueueConfigurationException(
>   
> LocalizedStrings.ParallelAsyncEventQueue_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
>   .toLocalizedString(new Object[] {
>   
> AsyncEventQueueImpl.getAsyncEventQueueIdFromSenderId(sender.getId()),
>   this.getFullPath()}));
> }
> throw new GatewaySenderConfigurationException(
> 
> LocalizedStrings.ParallelGatewaySender_0_CAN_NOT_BE_USED_WITH_REPLICATED_REGION_1
> .toLocalizedString(new Object[] {sender.getId(), 
> this.getFullPath()}));
>   }
> }
>   }
> ...
> {code}
> However, the {{gateway-sender}}/{{async-event-queue}} has been associated to 
> the region before this last check and the code doesn't catch the 
> {{GatewaySenderConfigurationException}} / 
> {{AsyncEventQueueConfigurationException}} within that block:
> {code:title=GemFireCacheImpl.java|borderStyle=solid}
> public  Region createVMRegion(String name, RegionAttributes 
> p_attrs, InternalRegionArguments internalRegionArgs) throws 
> RegionExistsException, TimeoutException, IOException, ClassNotFoundException {
> ...
>   region.postCreateRegion();
> } catch (RegionExistsException ex) {
>   // outside of sync make sure region is initialized to fix bug 37563
>   InternalRegion internalRegion = (InternalRegion) ex.getRegion();
>   internalRegion.waitOnInitialization(); // don't give out ref until 
> initialized
>   throw ex;
> }
> ...
> {code}
> This ends up leaving the region unusable but already added to the 
> {{GemFireCacheImpl.rootRegions}} field, so the cache itself is left 
> inconsistent (could be even worse when the region is also configured as 
> persistent).
> No big deal when the user is configuring everything using a {{cache.xml}} 
> file as the exception will be propagated and the server startup will fail. 
> When using {{gfsh}}, on the other hand, the command {{create region}} reports 
> a failure but leaves the region partially created on every single member.
> According to [~dschneider]
> {quote}
> The intent of postCreateRegion is to do things after the region was created. 
> This is the wrong place to be doing validation.
> If you look at the super.postCreateRegion that DistributionRegion calls first 
> you will see it incs stats and delivers events to others telling them the 
> region was created. You really can't undo that well if postCreateRegion 
> fails. So I do not think it is a good idea to have postCreateRegion destroy 
> the region it created.
> I think the bug here is that gateway validation is in postCreateRegion. This 
> validation should be done earlier so that the region creation it self