[jira] [Updated] (GEODE-4626) deprecating create region using --template-region option in gfsh

[ASF GitHub Bot (JIRA)]

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

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

> deprecating create region using --template-region option in gfsh
> 
>
> Key: GEODE-4626
> URL: https://issues.apache.org/jira/browse/GEODE-4626
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Affects Versions: 1.4.0
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
>
> currently, there are two ways to create a region, either to use a --type 
> option indicating a region shortcut or a --template-region option specifying 
> another regionPath where you want to copy the attribute from. 
> First of all, we are not sure what set of attributes that make sense to copy 
> to the new region. e.g listeners/loaders/writers, normally these are 
> connected to a downstream database that user may/may not want the new region 
> to read/write the same table. And the current implementation would fail to 
> create a region from a template that has these custom callbacks (including 
> listeners, loader, writer, compressor, resolvers etc).



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

[jira] [Commented] (GEODE-4676) Activate call stacks capture on all tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4676:


Commit 6181a936b6466ccfe03cc839ee534ac5fc3ccfe1 in geode's branch 
refs/heads/develop from [~dcavender]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6181a93 ]

Merge pull request #1457 from smgoller/GEODE-4676

[GEODE-4676] Add callstack processing to non-dunit tests.

> Activate call stacks capture on all tests
> -
>
> Key: GEODE-4676
> URL: https://issues.apache.org/jira/browse/GEODE-4676
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Sean Goller
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently callstacks are only captured for AcceptanceTest and 
> DistributedTest. Add callstacks capturing to IntegrationTest and FlakyTests.



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

[jira] [Commented] (GEODE-4676) Activate call stacks capture on all tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4676:


Commit 6181a936b6466ccfe03cc839ee534ac5fc3ccfe1 in geode's branch 
refs/heads/develop from [~dcavender]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6181a93 ]

Merge pull request #1457 from smgoller/GEODE-4676

[GEODE-4676] Add callstack processing to non-dunit tests.

> Activate call stacks capture on all tests
> -
>
> Key: GEODE-4676
> URL: https://issues.apache.org/jira/browse/GEODE-4676
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Sean Goller
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently callstacks are only captured for AcceptanceTest and 
> DistributedTest. Add callstacks capturing to IntegrationTest and FlakyTests.



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

[jira] [Commented] (GEODE-4676) Activate call stacks capture on all tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4676:


Commit dae733262132fe786f762114478e792cae13880b in geode's branch 
refs/heads/develop from [~smgoller]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dae7332 ]

[GEODE-4676] Add callstack processing to non-dunit tests.

* Adjust capture-call-stacks.sh to handle non-dunit tests.
* Add callstacks capture to FlakyTest

Signed-off-by: Sean Goller 


> Activate call stacks capture on all tests
> -
>
> Key: GEODE-4676
> URL: https://issues.apache.org/jira/browse/GEODE-4676
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Sean Goller
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently callstacks are only captured for AcceptanceTest and 
> DistributedTest. Add callstacks capturing to IntegrationTest and FlakyTests.



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

[jira] [Created] (GEODE-4686) Remove ParallelQueueBatchRemovalMessage

[nabarun (JIRA)]

nabarun created GEODE-4686:
--

 Summary: Remove ParallelQueueBatchRemovalMessage 
 Key: GEODE-4686
 URL: https://issues.apache.org/jira/browse/GEODE-4686
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: nabarun


+*Issue*+:

Unused code - ParallelQueueBatchRemovalMessage.

 

+*Solution*+:

Remove ParallelQueueBatchRemovalMessage class as this is no more being used in 
the latest version of Apache Geode.



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

[jira] [Updated] (GEODE-4676) Activate call stacks capture on all tests

[ASF GitHub Bot (JIRA)]

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

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

> Activate call stacks capture on all tests
> -
>
> Key: GEODE-4676
> URL: https://issues.apache.org/jira/browse/GEODE-4676
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Sean Goller
>Priority: Major
>  Labels: pull-request-available
>
> Currently callstacks are only captured for AcceptanceTest and 
> DistributedTest. Add callstacks capturing to IntegrationTest and FlakyTests.



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

[jira] [Assigned] (GEODE-4541) Remove singleton calls from regions product code in org.apache.geode.internal.cache

[Darrel Schneider (JIRA)]

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

Darrel Schneider reassigned GEODE-4541:
---

Assignee: Darrel Schneider

> Remove singleton calls from regions product code in 
> org.apache.geode.internal.cache
> ---
>
> Key: GEODE-4541
> URL: https://issues.apache.org/jira/browse/GEODE-4541
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Kirk Lund
>Assignee: Darrel Schneider
>Priority: Major
>
> These regions product classes in org.apache.geode.internal.cache invoke 
> singleton getters.
> GemFireCacheImpl.getInstance():
> * CacheServerLauncher
> * EntryEventImpl
> * GemFireCacheImpl
> * DistributedPutAllOperation
> InternalDistributedSystem.getAnyInstance():
> * EventStateHelper
> * GemFireCacheImpl
> * PartitionAttributesImpl
> * PartitionedRegionHelper



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

[jira] [Updated] (GEODE-4684) Replace setPdxReadSerialized and getPdxReadSerialized in org.apache.geode.internal.cache

[nabarun (JIRA)]

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

nabarun updated GEODE-4684:
---
Summary: Replace setPdxReadSerialized and getPdxReadSerialized in 
org.apache.geode.internal.cache  (was: Replace setPdxReadSerialized in 
org.apache.geode.internal.cache)

> Replace setPdxReadSerialized and getPdxReadSerialized in 
> org.apache.geode.internal.cache
> 
>
> Key: GEODE-4684
> URL: https://issues.apache.org/jira/browse/GEODE-4684
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Priority: Major
>
> Replace with the solution from GEODE-4679



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

[jira] [Updated] (GEODE-4682) Remove setPdxReadSerialized and getPdxReadSerialized from org.apache.geode.cache.query.internal.index

[nabarun (JIRA)]

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

nabarun updated GEODE-4682:
---
Summary: Remove setPdxReadSerialized and getPdxReadSerialized  from 
org.apache.geode.cache.query.internal.index  (was: Remove setPdxReadSerialized  
from org.apache.geode.cache.query.internal.index)

> Remove setPdxReadSerialized and getPdxReadSerialized  from 
> org.apache.geode.cache.query.internal.index
> --
>
> Key: GEODE-4682
> URL: https://issues.apache.org/jira/browse/GEODE-4682
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Priority: Major
>
> The solution / outcome of GEODE-4682 must be used as the replacement for 
> org.apache.geode.cache.query.internal.index



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

[jira] [Created] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal

[nabarun (JIRA)]

nabarun created GEODE-4685:
--

 Summary: Replace setPdxReadSerialized in 
org.apache.geode.cache.lucene.internal
 Key: GEODE-4685
 URL: https://issues.apache.org/jira/browse/GEODE-4685
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: nabarun


Replace with the solution from GEODE-4679



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

[jira] [Created] (GEODE-4684) Replace setPdxReadSerialized in org.apache.geode.internal.cache

[nabarun (JIRA)]

nabarun created GEODE-4684:
--

 Summary: Replace setPdxReadSerialized in 
org.apache.geode.internal.cache
 Key: GEODE-4684
 URL: https://issues.apache.org/jira/browse/GEODE-4684
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: nabarun


Replace with the solution from GEODE-4679



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

[jira] [Created] (GEODE-4683) Replace setPdxReadSerialized in org.apache.geode.distributed.internal.streaming;

[nabarun (JIRA)]

nabarun created GEODE-4683:
--

 Summary: Replace setPdxReadSerialized in 
org.apache.geode.distributed.internal.streaming;
 Key: GEODE-4683
 URL: https://issues.apache.org/jira/browse/GEODE-4683
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: nabarun


Replace with the fix available from GEODE-4679



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

[jira] [Updated] (GEODE-4682) Remove setPdxReadSerialized from org.apache.geode.cache.query.internal.index

[nabarun (JIRA)]

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

nabarun updated GEODE-4682:
---
Description: 
The solution / outcome of GEODE-4682 must be used as the replacement for 

org.apache.geode.cache.query.internal.index

  was:The solution / outcome of GEODE-4682 must be used as the replacement for 


> Remove setPdxReadSerialized  from org.apache.geode.cache.query.internal.index
> -
>
> Key: GEODE-4682
> URL: https://issues.apache.org/jira/browse/GEODE-4682
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Priority: Major
>
> The solution / outcome of GEODE-4682 must be used as the replacement for 
> org.apache.geode.cache.query.internal.index



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

[jira] [Updated] (GEODE-4682) Remove setPdxReadSerialized from org.apache.geode.cache.query.internal.index

[nabarun (JIRA)]

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

nabarun updated GEODE-4682:
---
Description: The solution / outcome of GEODE-4682 must be used as the 
replacement for 

> Remove setPdxReadSerialized  from org.apache.geode.cache.query.internal.index
> -
>
> Key: GEODE-4682
> URL: https://issues.apache.org/jira/browse/GEODE-4682
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Priority: Major
>
> The solution / outcome of GEODE-4682 must be used as the replacement for 



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

[jira] [Commented] (GEODE-4682) Remove setPdxReadSerialized from org.apache.geode.cache.query.internal.index

[nabarun (JIRA)]

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

nabarun commented on GEODE-4682:


GEODE-4679 must be fixed before this ticket is worked on.

> Remove setPdxReadSerialized  from org.apache.geode.cache.query.internal.index
> -
>
> Key: GEODE-4682
> URL: https://issues.apache.org/jira/browse/GEODE-4682
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Priority: Major
>




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

[jira] [Created] (GEODE-4682) Remove setPdxReadSerialized from org.apache.geode.cache.query.internal.index

[nabarun (JIRA)]

nabarun created GEODE-4682:
--

 Summary: Remove setPdxReadSerialized  from 
org.apache.geode.cache.query.internal.index
 Key: GEODE-4682
 URL: https://issues.apache.org/jira/browse/GEODE-4682
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: nabarun






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

[jira] [Commented] (GEODE-4681) Remove all static methods involving pdxReadSerialized

[nabarun (JIRA)]

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

nabarun commented on GEODE-4681:


GEODE-4679 must be fixed before this ticket can be worked on

> Remove all static methods involving pdxReadSerialized 
> --
>
> Key: GEODE-4681
> URL: https://issues.apache.org/jira/browse/GEODE-4681
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>Priority: Major
>
> Remove the following static methods after GEODE-4679 is completed.
>  * setPdxReadSerialized()
>  * getPdxReadSerialized()



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

[jira] [Created] (GEODE-4681) Remove all static methods involving pdxReadSerialized

[nabarun (JIRA)]

nabarun created GEODE-4681:
--

 Summary: Remove all static methods involving pdxReadSerialized 
 Key: GEODE-4681
 URL: https://issues.apache.org/jira/browse/GEODE-4681
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: nabarun


Remove the following static methods after GEODE-4679 is completed.
 * setPdxReadSerialized()
 * getPdxReadSerialized()



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

[jira] [Updated] (GEODE-4680) Replace setPdxReadSerialized in org.apache.geode.connectors.jdbc;

[nabarun (JIRA)]

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

nabarun updated GEODE-4680:
---
Issue Type: Sub-task  (was: Bug)
Parent: GEODE-4679

> Replace setPdxReadSerialized in org.apache.geode.connectors.jdbc;
> -
>
> Key: GEODE-4680
> URL: https://issues.apache.org/jira/browse/GEODE-4680
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: nabarun
>Priority: Major
>
> After setPdxReadSerialized is moved to a more appropriate location in the 
> codebase as a part of GEODE-4679, all instances of setPdxReadSerialized must 
> be replaced with that new method.
>  
> -- This should include all the usage present in the test modules too.



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

[jira] [Created] (GEODE-4680) Replace setPdxReadSerialized in org.apache.geode.connectors.jdbc;

[nabarun (JIRA)]

nabarun created GEODE-4680:
--

 Summary: Replace setPdxReadSerialized in 
org.apache.geode.connectors.jdbc;
 Key: GEODE-4680
 URL: https://issues.apache.org/jira/browse/GEODE-4680
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: nabarun


After setPdxReadSerialized is moved to a more appropriate location in the 
codebase as a part of GEODE-4679, all instances of setPdxReadSerialized must be 
replaced with that new method.

 

-- This should include all the usage present in the test modules too.



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

[jira] [Commented] (GEODE-4628) Gfsh connect command should infer the correct connection method

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4628:


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

GEODE-4628: Gfsh connect should infer more about the conenction type (#1445)

- 'use-ssl' is not required for https URLs to enable SSL
- 'use-http' is deprecated
- there is no default for 'url' anymore

> Gfsh connect command should infer the correct connection method
> ---
>
> Key: GEODE-4628
> URL: https://issues.apache.org/jira/browse/GEODE-4628
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> There are 2 main points here:
> # If we want to connect with a URL (http) we have to give the {{--use-http}} 
> option as well as {{--url}}. {{--use-http}} is really redundant here and 
> should be deprecated and ultimately removed.
> # when connecting to the http service, the url (https or http) should have 
> already indicated whether it's {{use-ssl}} or not, in this case, we should 
> infer the value of use-ssl based on the protocol of the url.
> Note: this is only for --use-http case. the --use-ssl should still need to be 
> specified for jmx connection.



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

[jira] [Updated] (GEODE-4679) pdxReadSerialized accessors must be present in some product level component like Cache

[nabarun (JIRA)]

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

nabarun updated GEODE-4679:
---
Description: 
+*Current situation:*+

The getters/setters for pdxReadSerialized thread is present in DefaultQuery as 
static calls. 
 * DefaultQuery # getPdxReadSerialized()
 * DefaultQuery # setPdxReadSerialized()

 

+*Solution:*+

These getters/setters need to move to a more logical part of the code like 
cache and not be present in DeafaultQuery

 

  was:
Current situation:

The getters/setters for pdxReadSerialized thread is present in DefaultQuery as 
static calls. 

DefaultQuery # getPdxReadSerialized()

DefaultQuery # setPdxReadSerialized()

 

Solution:

These getters/setters need to move to a more logical part of the code like 
cache and not be present in DeafaultQuery

 


> pdxReadSerialized accessors must be present in some product level component 
> like Cache
> --
>
> Key: GEODE-4679
> URL: https://issues.apache.org/jira/browse/GEODE-4679
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: nabarun
>Priority: Major
>
> +*Current situation:*+
> The getters/setters for pdxReadSerialized thread is present in DefaultQuery 
> as static calls. 
>  * DefaultQuery # getPdxReadSerialized()
>  * DefaultQuery # setPdxReadSerialized()
>  
> +*Solution:*+
> These getters/setters need to move to a more logical part of the code like 
> cache and not be present in DeafaultQuery
>  



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

[jira] [Created] (GEODE-4679) pdxReadSerialized accessors must be present in some product level component like Cache

[nabarun (JIRA)]

nabarun created GEODE-4679:
--

 Summary: pdxReadSerialized accessors must be present in some 
product level component like Cache
 Key: GEODE-4679
 URL: https://issues.apache.org/jira/browse/GEODE-4679
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: nabarun


Current situation:

The getters/setters for pdxReadSerialized thread is present in DefaultQuery as 
static calls. 

DefaultQuery # getPdxReadSerialized()

DefaultQuery # setPdxReadSerialized()

 

Solution:

These getters/setters need to move to a more logical part of the code like 
cache and not be present in DeafaultQuery

 



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

[jira] [Updated] (GEODE-4678) Refactor or eliminate ServerHandshakeProcessor

[ASF GitHub Bot (JIRA)]

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

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

> Refactor or eliminate ServerHandshakeProcessor
> --
>
> Key: GEODE-4678
> URL: https://issues.apache.org/jira/browse/GEODE-4678
> Project: Geode
>  Issue Type: Task
>  Components: client/server
>Reporter: Brian Rowe
>Priority: Major
>  Labels: pull-request-available
>
> Currently the server side handshake code is lumped in 
> ServerHandshakeProcessor and consists of a bunch of static methods that make 
> intrusive changes into ServerConnection and Handshake objects.  This should 
> be refactored to the appropriate classes and the object boundary between 
> these classes should become more distinct.



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

[jira] [Resolved] (GEODE-2827) ClientCacheFactory might ignore a provided PoolFactory

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-2827.
-
   Resolution: Fixed
Fix Version/s: 1.5.0

commit 525241905050e9a192a1f36fc662735ab8e281d9
Author: Michael "Sarge" Dodge 
Date:   Wed Feb 14 09:03:03 2018 -0800

GEODE-4511: Ensure a pool is available for durable client subscription. 
(#1448)

* GEODE-4511: Ensure a pool is available for durable client subscription.

* GEODE-4511: Restrict default pool creation for subscription to clients.


> ClientCacheFactory might ignore a provided PoolFactory
> --
>
> Key: GEODE-2827
> URL: https://issues.apache.org/jira/browse/GEODE-2827
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Kirk Lund
>Priority: Major
> Fix For: 1.5.0
>
>
> I found a weird double assignment of the GemFireCacheImpl variable 
> "poolFactory" that is most likely a bug. This might result in 
> ClientCacheFactory replacing a provided poolFactory with a default 
> poolFactory.
> {noformat}
> private PoolFactory poolFactory;
> {noformat}
> The constructor accepts an argument and sets it to that value:
> {noformat}
> private GemFireCacheImpl(boolean isClient, PoolFactory pf, DistributedSystem 
> system, CacheConfig cacheConfig, boolean asyncEventListeners, TypeRegistry 
> typeRegistry) {
>   this.isClient = isClient;
>   this.poolFactory = pf;
> {noformat}
> But then in "private void initialize()" it blindly sets it to null thus 
> wiping out whatever was passed in:
> {noformat}
> this.poolFactory = null;
> {noformat}
> Later during "private void initializeDeclarativeCache()" it calls 
> "determineDefaultPool()" but only if isClient is true:
> {noformat}
> if (this.poolFactory == null) {
>   Map pools = PoolManager.getAll();
>   if (pools.isEmpty()) {
> this.poolFactory = createDefaultPF();
> {noformat}



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

[jira] [Updated] (GEODE-4656) gfsh command describe region should list custom expiry setting

[ASF GitHub Bot (JIRA)]

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

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

> gfsh command describe region should list custom expiry setting
> --
>
> Key: GEODE-4656
> URL: https://issues.apache.org/jira/browse/GEODE-4656
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Barbara Pruijn
>Priority: Major
>  Labels: pull-request-available
>
> The gfsh command
> {code:java}
> describe region --name=region1{code}
> should list the MyCustomExpiry class as the value for the options given on 
> the alter/create region command:
> --entry-idle-time-custom-expiry
> --entry-time-to-live-custom-expiry
> {code:java}
> Type | Name | Value
> -- | --- | ---
> Region | data-policy   | REPLICATE
> | entry-idle-time-custom-expiry | MyCustomExpiry
> | size   | 0
> | statistics-enabled | true
> | scope | distributed-ack{code}



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

[jira] [Updated] (GEODE-3967) if put hits concurrent modification exception should still notify serial gateway sender

[xiaojian zhou (JIRA)]

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

xiaojian zhou updated GEODE-3967:
-
Fix Version/s: 1.5.0

> if put hits concurrent modification exception should still notify serial 
> gateway sender
> ---
>
> Key: GEODE-3967
> URL: https://issues.apache.org/jira/browse/GEODE-3967
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In serial gateway sender, the event arrives at secondary will be put into 
> unprocessedMap and wait for event from primary queue to distribute over, then 
> remove it from the unprocessedMap.
> If the put at primary member (member with primary queue) failed with CME, the 
> event in unprocessedMap will never be removed. 



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

[jira] [Created] (GEODE-4678) Refactor or eliminate ServerHandshakeProcessor

[Brian Rowe (JIRA)]

Brian Rowe created GEODE-4678:
-

 Summary: Refactor or eliminate ServerHandshakeProcessor
 Key: GEODE-4678
 URL: https://issues.apache.org/jira/browse/GEODE-4678
 Project: Geode
  Issue Type: Task
  Components: client/server
Reporter: Brian Rowe


Currently the server side handshake code is lumped in ServerHandshakeProcessor 
and consists of a bunch of static methods that make intrusive changes into 
ServerConnection and Handshake objects.  This should be refactored to the 
appropriate classes and the object boundary between these classes should become 
more distinct.



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

[jira] [Updated] (GEODE-4579) Remove singleton calls from product code in org.apache.geode.internal.cache.execute.util

[ASF GitHub Bot (JIRA)]

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

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

> Remove singleton calls from product code in 
> org.apache.geode.internal.cache.execute.util
> 
>
> Key: GEODE-4579
> URL: https://issues.apache.org/jira/browse/GEODE-4579
> Project: Geode
>  Issue Type: Sub-task
>  Components: functions, rest (dev)
>Reporter: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
>
> [NOTE: no idea which component this one should be filed against]
> These product classes in org.apache.geode.internal.cache.execute.util invoke 
> singleton getters.
> InternalDistributedSystem.getAnyInstance():
> * FindRestEnabledServersFunction



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

[jira] [Created] (GEODE-4677) Remove FLAKY Designation from Tests That Are Now STABLE

[Michael Martell (JIRA)]

Michael Martell created GEODE-4677:
--

 Summary: Remove FLAKY Designation from Tests That Are Now STABLE
 Key: GEODE-4677
 URL: https://issues.apache.org/jira/browse/GEODE-4677
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Michael Martell


Recent removal of HostStats support (GEODE-4667) has made some of the flaky 
tests pass consistently. This ticket is to capture the work of removing the 
FLAKY designation from the CMakeLists.txt.



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

[jira] [Commented] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4377:


Commit e44bf9e7bdbd9684c3194fc56468fdcd4b910b80 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e44bf9e ]

GEODE-4377: Don't catch encoding exceptions in OperationHandlers

Galen pointed out that the changes for this ticket changed behavior when
we get an encoding error.  The changes cause the connection to be closed
but we used to leave it open.

This commit reverts to the old behavior.  The connection will remain open
and the client can continue to do goofy things and get error responses.


> Don't catch encoding exceptions in OperationHandlers
> 
>
> Key: GEODE-4377
> URL: https://issues.apache.org/jira/browse/GEODE-4377
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> In the protobuf protocol, we are currently catching EncodingException due to 
> values that we can't deserialize or result values that we can't serialize.
> Encoding and decoding exceptions should be handled differently, so clients 
> can tell if a value was present but could not be serialized.
> Encoding and decoding errors should be handled consistently across operation 
> handlers.
> Probably we could throw Encoding or Decoding exceptions and handle them at a 
> higher level than the individual op handler.



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

[jira] [Created] (GEODE-4676) Activate call stacks capture on all tests

[Sean Goller (JIRA)]

Sean Goller created GEODE-4676:
--

 Summary: Activate call stacks capture on all tests
 Key: GEODE-4676
 URL: https://issues.apache.org/jira/browse/GEODE-4676
 Project: Geode
  Issue Type: Task
  Components: ci
Reporter: Sean Goller


Currently callstacks are only captured for AcceptanceTest and DistributedTest. 
Add callstacks capturing to IntegrationTest and FlakyTests.



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

[jira] [Assigned] (GEODE-4624) Add a new stat for AyncEventQueue/GatewaySender to track the processing of queueRemovals

[xiaojian zhou (JIRA)]

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

xiaojian zhou reassigned GEODE-4624:


Assignee: xiaojian zhou

> Add a new stat for AyncEventQueue/GatewaySender to track the processing of 
> queueRemovals
> 
>
> Key: GEODE-4624
> URL: https://issues.apache.org/jira/browse/GEODE-4624
> Project: Geode
>  Issue Type: Bug
>  Components: docs, wan
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: xiaojian zhou
>Priority: Major
>
> We currently track the number of events queues, queue size and 
> eventsDistributed ... but we don't track the number of events removed via 
> queue removal. 



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

[jira] [Assigned] (GEODE-4647) Add a new stat for AyncEventQueue/GatewaySender to track secondaryEventsQueueSize

[xiaojian zhou (JIRA)]

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

xiaojian zhou reassigned GEODE-4647:


Assignee: xiaojian zhou

> Add a new stat for AyncEventQueue/GatewaySender to track 
> secondaryEventsQueueSize
> -
>
> Key: GEODE-4647
> URL: https://issues.apache.org/jira/browse/GEODE-4647
> Project: Geode
>  Issue Type: Bug
>  Components: docs, wan
>Reporter: Jason Huynh
>Assignee: xiaojian zhou
>Priority: Major
>
> Currently we have eventsQueueSize which tells us how big the queue is based 
> on how many primary events are in the queue.
> It would be nice to have the same type of stat for how many secondary events 
> are in the queue.



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

[jira] [Commented] (GEODE-2667) Need API to destroy gateway receiver

[Jason Huynh (JIRA)]

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

Jason Huynh commented on GEODE-2667:


Sorry, just realized this didn't have a docs tag.  Adding docs to component 
incase we need any documentation changes.

>  Need API to destroy gateway receiver
> -
>
> Key: GEODE-2667
> URL: https://issues.apache.org/jira/browse/GEODE-2667
> Project: Geode
>  Issue Type: Bug
>  Components: docs, wan
>Reporter: Swapnil Bawaskar
>Assignee: Jason Huynh
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> A {{GatewayReceiver}} can be created from {{GatewayReceiverFactory}}, 
> however, there is no API for destroying the {{GatewayReceiver}}. 



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

[jira] [Updated] (GEODE-4295) Setting domain class on region-mapping but initial instance is always PdxInstance

[ASF GitHub Bot (JIRA)]

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

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

> Setting domain class on region-mapping but initial instance is always 
> PdxInstance
> -
>
> Key: GEODE-4295
> URL: https://issues.apache.org/jira/browse/GEODE-4295
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Fred Krone
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
>
> For JDBC Connector 
> Read serialized on the cache is set to false.  Region mapping was created 
> with pdx-instance-type set to a specific domain class (example: Employee). 
> This means it should return this class on reads using the JdbcLoader.  
> However the initial instance is a PdxInstance which results in a collision. 
> Something like Employee employee = region.get(2); <-- blows up
> The type is correct (Employee) but wont cast.
> [vm1] PDX Instance: 
> PDX[14933766,org.apache.geode.connectors.jdbc.Employee]{first_name=Fred, 
> hire_date=2018-01-12 00:00:00.0, id=3, last_name=Krone} read serialized: false



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

[jira] [Updated] (GEODE-2667) Need API to destroy gateway receiver

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2667:
---
Component/s: docs

>  Need API to destroy gateway receiver
> -
>
> Key: GEODE-2667
> URL: https://issues.apache.org/jira/browse/GEODE-2667
> Project: Geode
>  Issue Type: Bug
>  Components: docs, wan
>Reporter: Swapnil Bawaskar
>Assignee: Jason Huynh
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> A {{GatewayReceiver}} can be created from {{GatewayReceiverFactory}}, 
> however, there is no API for destroying the {{GatewayReceiver}}. 



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

[jira] [Resolved] (GEODE-3398) Locator needs to talk new protocol

[Brian Baynes (JIRA)]

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

Brian Baynes resolved GEODE-3398.
-
   Resolution: Done
Fix Version/s: 1.3.0

> Locator needs to talk new protocol
> --
>
> Key: GEODE-3398
> URL: https://issues.apache.org/jira/browse/GEODE-3398
> Project: Geode
>  Issue Type: New Feature
>  Components: client/server
>Reporter: Brian Baynes
>Priority: Major
> Fix For: 1.3.0
>
>
> As a user of the new client/server protocol, I need to be able to interact 
> with locators in the grid.
> Implement client/server protocol on locator side.



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

[jira] [Updated] (GEODE-3200) ServerConnection.authzRequest is no longer used

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-3200:

Labels: newbie++  (was: )

> ServerConnection.authzRequest is no longer used
> ---
>
> Key: GEODE-3200
> URL: https://issues.apache.org/jira/browse/GEODE-3200
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, security
>Reporter: Galen O'Sullivan
>Priority: Major
>  Labels: newbie++
>
> ServerConnection has a private member called authzRequest that is no longer 
> used.
> ServerConnection.getAuthzRequest() is used in a few places, but may not be 
> relevant anymore.
> authzRequest should be removed or used to cache the value if it can be 
> cached, and we should probably have a look at getAuthzRequest to make sure 
> it's still used.
> This class is expected to undergo significant refactoring due to GEODE-3074, 
> you might want to have a chat with whoever is working on that to avoid merge 
> conflicts.



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

[jira] [Updated] (GEODE-3057) Keep Thread Local Comm Buffer in selector thread

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-3057:

Labels: newbie  (was: )

> Keep Thread Local Comm Buffer in selector thread
> 
>
> Key: GEODE-3057
> URL: https://issues.apache.org/jira/browse/GEODE-3057
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
>  Labels: newbie
>
> In {{ServerConnection.run()}}, we currently pull a comm buffer from the pool 
> every time that {run} is called by a selector, and release it back after the 
> particular message.
> This buffer is allocated in a {{ThreadLocal}}, so it would make more sense to 
> have the selector thread own a buffer that all commands running on that 
> selector can use.
> As a side note, maybe it would make sense to split the run function in two, 
> with {run} being called in the connection-per-thread case and 
> {{doMessageOnSelector}} or so being called by the selector?



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

[jira] [Updated] (GEODE-4640) CI Failure: RemoveCommandDUnitTest can fail to find region

[Barbara Pruijn (JIRA)]

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

Barbara Pruijn updated GEODE-4640:
--
Fix Version/s: 1.5.0

> CI Failure: RemoveCommandDUnitTest can fail to find region
> --
>
> Key: GEODE-4640
> URL: https://issues.apache.org/jira/browse/GEODE-4640
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The test has failed sporadically with
> {noformat}
> org.apache.geode.management.internal.cli.commands.RemoveCommandDUnitTest > 
> removeAllFromPartitionedRegion FAILED
> org.junit.ComparisonFailure: [Region  not found in 
> any of the members
> {noformat}
> This may be to the test waiting only for one region to be ready before 
> proceeding, resulting in a race condition between the testing VM and the 
> server VMs.
> See 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/124
> http://files.apachegeode-ci.info/builds/1.5.0-build.409/test-results/distributedTest/



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

[jira] [Resolved] (GEODE-4640) CI Failure: RemoveCommandDUnitTest can fail to find region

[Barbara Pruijn (JIRA)]

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

Barbara Pruijn resolved GEODE-4640.
---
Resolution: Fixed

> CI Failure: RemoveCommandDUnitTest can fail to find region
> --
>
> Key: GEODE-4640
> URL: https://issues.apache.org/jira/browse/GEODE-4640
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The test has failed sporadically with
> {noformat}
> org.apache.geode.management.internal.cli.commands.RemoveCommandDUnitTest > 
> removeAllFromPartitionedRegion FAILED
> org.junit.ComparisonFailure: [Region  not found in 
> any of the members
> {noformat}
> This may be to the test waiting only for one region to be ready before 
> proceeding, resulting in a race condition between the testing VM and the 
> server VMs.
> See 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/124
> http://files.apachegeode-ci.info/builds/1.5.0-build.409/test-results/distributedTest/



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

[jira] [Resolved] (GEODE-3037) A server process shuts down quietly when no locator is available

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-3037.
-
   Resolution: Resolved
Fix Version/s: 1.1.0

This behavior is already implemented and is controlled by the locator-wait-time 
setting.  If it's desired to have a different default for locator-wait-time 
please open another ticket.

> A server process shuts down quietly when no locator is available
> 
>
> Key: GEODE-3037
> URL: https://issues.apache.org/jira/browse/GEODE-3037
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Anton Mironenko
>Priority: Major
> Fix For: 1.1.0
>
>
> Geode version: 1.1.1, 1.3.0 (latest develop snapshot).
> If I start a server, when no one locator is available, it shuts down quietly 
> without any message in the log. Why doesn't it wait for a locator to start? 
> Why no message in the log?
> The expected behavior is that a cluster nodes can be started in any order, 
> waiting each other if needed.
> Here are the steps to reproduce, please use GEODE-3003 for zip files.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1 
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh 
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to 
> the values of your host1 and host2
> 4) do the bullets 1)-4) for host2, the folder where you unzip the file should 
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-server.sh on host1
> 3) observe in the server logs, server1/cacheserver.log:
> [info 2017/06/06 18:15:16.387 MSK host1-server-1  tid=0x1] Starting 
> membership services
> [info 2017/06/06 18:15:16.504 MSK host1-server-1  tid=0x1] JGroups 
> channel created (took 117ms)
> [info 2017/06/06 18:15:16.518 MSK host1-server-1  tid=0x1] GemFire P2P 
> Listener started on /10.50.3.38:38056
> [info 2017/06/06 18:15:16.520 MSK host1-server-1  Server thread 0> tid=0x1d] Started failure detection server thread on 
> /10.50.3.38:44771.
> [info 2017/06/06 18:15:16.547 MSK host1-server-1  tid=0x1] Stopping 
> membership services
> [info 2017/06/06 18:15:16.549 MSK host1-server-1  tid=0x1] 
> GMSHealthMonitor server socket is closed in stopServices().
> [info 2017/06/06 18:15:16.549 MSK host1-server-1  Server thread 0> tid=0x1d] GMSHealthMonitor server thread exiting
> [info 2017/06/06 18:15:16.549 MSK host1-server-1  tid=0x1] 
> GMSHealthMonitor serverSocketExecutor is terminated



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

[jira] [Commented] (GEODE-3037) A server process shuts down quietly when no locator is available

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-3037:
-

The distributed system property locator-wait-time governs how long a server 
will wait to find a running locator.  This setting, in seconds, defaults to 
zero.  Set it to something higher on your servers to give your locators time to 
spin up.

> A server process shuts down quietly when no locator is available
> 
>
> Key: GEODE-3037
> URL: https://issues.apache.org/jira/browse/GEODE-3037
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Anton Mironenko
>Priority: Major
>
> Geode version: 1.1.1, 1.3.0 (latest develop snapshot).
> If I start a server, when no one locator is available, it shuts down quietly 
> without any message in the log. Why doesn't it wait for a locator to start? 
> Why no message in the log?
> The expected behavior is that a cluster nodes can be started in any order, 
> waiting each other if needed.
> Here are the steps to reproduce, please use GEODE-3003 for zip files.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1 
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh 
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to 
> the values of your host1 and host2
> 4) do the bullets 1)-4) for host2, the folder where you unzip the file should 
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-server.sh on host1
> 3) observe in the server logs, server1/cacheserver.log:
> [info 2017/06/06 18:15:16.387 MSK host1-server-1  tid=0x1] Starting 
> membership services
> [info 2017/06/06 18:15:16.504 MSK host1-server-1  tid=0x1] JGroups 
> channel created (took 117ms)
> [info 2017/06/06 18:15:16.518 MSK host1-server-1  tid=0x1] GemFire P2P 
> Listener started on /10.50.3.38:38056
> [info 2017/06/06 18:15:16.520 MSK host1-server-1  Server thread 0> tid=0x1d] Started failure detection server thread on 
> /10.50.3.38:44771.
> [info 2017/06/06 18:15:16.547 MSK host1-server-1  tid=0x1] Stopping 
> membership services
> [info 2017/06/06 18:15:16.549 MSK host1-server-1  tid=0x1] 
> GMSHealthMonitor server socket is closed in stopServices().
> [info 2017/06/06 18:15:16.549 MSK host1-server-1  Server thread 0> tid=0x1d] GMSHealthMonitor server thread exiting
> [info 2017/06/06 18:15:16.549 MSK host1-server-1  tid=0x1] 
> GMSHealthMonitor serverSocketExecutor is terminated



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

[jira] [Assigned] (GEODE-4295) Setting domain class on region-mapping but initial instance is always PdxInstance

[Darrel Schneider (JIRA)]

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

Darrel Schneider reassigned GEODE-4295:
---

Assignee: Darrel Schneider

> Setting domain class on region-mapping but initial instance is always 
> PdxInstance
> -
>
> Key: GEODE-4295
> URL: https://issues.apache.org/jira/browse/GEODE-4295
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Fred Krone
>Assignee: Darrel Schneider
>Priority: Major
>
> For JDBC Connector 
> Read serialized on the cache is set to false.  Region mapping was created 
> with pdx-instance-type set to a specific domain class (example: Employee). 
> This means it should return this class on reads using the JdbcLoader.  
> However the initial instance is a PdxInstance which results in a collision. 
> Something like Employee employee = region.get(2); <-- blows up
> The type is correct (Employee) but wont cast.
> [vm1] PDX Instance: 
> PDX[14933766,org.apache.geode.connectors.jdbc.Employee]{first_name=Fred, 
> hire_date=2018-01-12 00:00:00.0, id=3, last_name=Krone} read serialized: false



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

[jira] [Closed] (GEODE-2853) Change of locator list request interval

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt closed GEODE-2853.
---

> Change of locator list request interval
> ---
>
> Key: GEODE-2853
> URL: https://issues.apache.org/jira/browse/GEODE-2853
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
> Fix For: 1.3.0
>
>
> If you connect to a Geode cluster using a locator from the client, the 
> locator list request will be executed at regular intervals in the background 
> thread. I want to tune this interval. I understand that this interval can be 
> changed by the ping-interval of the Pool attribute. However, I think that 
> ping-interval originally sets the ping interval for health check to the cache 
> server. Therefore, it is not possible to change the locator list request 
> interval without changing the health check interval to the cache server. So,I 
> want to add a java system property that can change the locator list request 
> interval.
> The locator list request interval is determined by the following priority 
> order.
>   1. java system property "gemfire.LOCATOR_UPDATE_INTERVAL"
>   2. ping-interval of the Pool attribute
> In addition, when changing this time, the background thread is activated only 
> when this value is a positive value.



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

[jira] [Resolved] (GEODE-2853) Change of locator list request interval

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-2853.
-
   Resolution: Fixed
Fix Version/s: 1.3.0

The PR for this ticket was merged in May 2017 so I'm closing this ticket.

> Change of locator list request interval
> ---
>
> Key: GEODE-2853
> URL: https://issues.apache.org/jira/browse/GEODE-2853
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
> Fix For: 1.3.0
>
>
> If you connect to a Geode cluster using a locator from the client, the 
> locator list request will be executed at regular intervals in the background 
> thread. I want to tune this interval. I understand that this interval can be 
> changed by the ping-interval of the Pool attribute. However, I think that 
> ping-interval originally sets the ping interval for health check to the cache 
> server. Therefore, it is not possible to change the locator list request 
> interval without changing the health check interval to the cache server. So,I 
> want to add a java system property that can change the locator list request 
> interval.
> The locator list request interval is determined by the following priority 
> order.
>   1. java system property "gemfire.LOCATOR_UPDATE_INTERVAL"
>   2. ping-interval of the Pool attribute
> In addition, when changing this time, the background thread is activated only 
> when this value is a positive value.



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

[jira] [Commented] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-4675:
-

This was caused by Darrel's recent commit, 
fc3e14440afbb66f19b3e6dc79ded168adb8dca3, that added a getDistributionManager() 
call to DistributionAdvisor.notifyListenersMemberRemoved().  The method used to 
get the distribution manager in this case should avoid checking to see if the 
DistributedSystem is closed.

> CI failure (suspect strings): DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected reported as fatal 
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Darrel Schneider
>Priority: Major
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
>  > testPartitionedParallelPropagationHA FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 9339
> [fatal 2018/02/13 21:12:48.099 UTC  tid=891] 
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected.
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
>   at 
> org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
>   at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
>   at java.lang.Thread.run(Thread.java:748)
> ---
> {noformat}
> According to the logs, this looks like it occurs during shutdown ... 
> {noformat}
> [vm1] [info 2018/02/13 21:12:48.075 UTC  
> tid=30] Stopping membership services
> [vm0] [info 2018/02/13 21:12:48.077 UTC  thread 0> tid=398] GMSHealthMonitor server thread exiting
> [vm0] [info 2018/02/13 21:12:48.078 UTC  
> tid=30] GMSHealthMonitor serverSocketExecutor is terminated
> [vm3] [info 2018/02/13 21:12:48.079 UTC  
> tid=896] received leave request from 172.17.0.2:32771 for 
> 172.17.0.2(180):32771
> [vm0] [info 2018/02/13 21:12:48.084 UTC  
> tid=30] DistributionManager stopped in 121ms.
> [vm0] [info 2018/02/13 

[jira] [Assigned] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt reassigned GEODE-4675:
---

Assignee: Darrel Schneider

> CI failure (suspect strings): DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected reported as fatal 
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Darrel Schneider
>Priority: Major
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
>  > testPartitionedParallelPropagationHA FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 9339
> [fatal 2018/02/13 21:12:48.099 UTC  tid=891] 
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected.
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
>   at 
> org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
>   at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
>   at java.lang.Thread.run(Thread.java:748)
> ---
> {noformat}
> According to the logs, this looks like it occurs during shutdown ... 
> {noformat}
> [vm1] [info 2018/02/13 21:12:48.075 UTC  
> tid=30] Stopping membership services
> [vm0] [info 2018/02/13 21:12:48.077 UTC  thread 0> tid=398] GMSHealthMonitor server thread exiting
> [vm0] [info 2018/02/13 21:12:48.078 UTC  
> tid=30] GMSHealthMonitor serverSocketExecutor is terminated
> [vm3] [info 2018/02/13 21:12:48.079 UTC  
> tid=896] received leave request from 172.17.0.2:32771 for 
> 172.17.0.2(180):32771
> [vm0] [info 2018/02/13 21:12:48.084 UTC  
> tid=30] DistributionManager stopped in 121ms.
> [vm0] [info 2018/02/13 21:12:48.086 UTC  
> tid=30] Marking DistributionManager 172.17.0.2(176):32770 as closed.
> [vm1] [info 2018/02/13 21:12:48.087 UTC  
> tid=30] GMSHealthMonitor server socket is closed in stopServices().
> [vm0] [info 2018/02/13 21:12:48.089 UTC  
> tid=30] Got result: null
> [vm0]  from 
> 

[jira] [Updated] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during s

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-4675:

Component/s: (was: membership)
 regions

> CI failure (suspect strings): DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected reported as fatal 
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
>  > testPartitionedParallelPropagationHA FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 9339
> [fatal 2018/02/13 21:12:48.099 UTC  tid=891] 
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected.
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
>   at 
> org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
>   at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
>   at java.lang.Thread.run(Thread.java:748)
> ---
> {noformat}
> According to the logs, this looks like it occurs during shutdown ... 
> {noformat}
> [vm1] [info 2018/02/13 21:12:48.075 UTC  
> tid=30] Stopping membership services
> [vm0] [info 2018/02/13 21:12:48.077 UTC  thread 0> tid=398] GMSHealthMonitor server thread exiting
> [vm0] [info 2018/02/13 21:12:48.078 UTC  
> tid=30] GMSHealthMonitor serverSocketExecutor is terminated
> [vm3] [info 2018/02/13 21:12:48.079 UTC  
> tid=896] received leave request from 172.17.0.2:32771 for 
> 172.17.0.2(180):32771
> [vm0] [info 2018/02/13 21:12:48.084 UTC  
> tid=30] DistributionManager stopped in 121ms.
> [vm0] [info 2018/02/13 21:12:48.086 UTC  
> tid=30] Marking DistributionManager 172.17.0.2(176):32770 as closed.
> [vm1] [info 2018/02/13 21:12:48.087 UTC  
> tid=30] GMSHealthMonitor server socket is closed in stopServices().
> [vm0] [info 2018/02/13 21:12:48.089 UTC  
> tid=30] Got result: null
> [vm0]  from 
> 

[jira] [Updated] (GEODE-2600) Inconsistent spacing of headers in Startup Configuration log

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2600:

Labels: LogBanner newbie  (was: LogBanner)

> Inconsistent spacing of headers in Startup Configuration log
> 
>
> Key: GEODE-2600
> URL: https://issues.apache.org/jira/browse/GEODE-2600
> Project: Geode
>  Issue Type: Bug
>  Components: logging
>Affects Versions: 1.2.0
>Reporter: Patrick Rhomberg
>Priority: Trivial
>  Labels: LogBanner, newbie
>
> Note the extra space before the initial ###.
> {noformat}
> [info 2017/03/06 14:29:30.003 PST loc1  tid=0x1] Startup Configuration:
>### GemFire Properties defined with system property ###
>   enable-cluster-configuration=true
>   load-cluster-configuration-from-dir=false
>   ### GemFire Properties defined with api ###
> {noformat}



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

[jira] [Resolved] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-4377.
-
   Resolution: Fixed
Fix Version/s: 1.5.0

> Don't catch encoding exceptions in OperationHandlers
> 
>
> Key: GEODE-4377
> URL: https://issues.apache.org/jira/browse/GEODE-4377
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> In the protobuf protocol, we are currently catching EncodingException due to 
> values that we can't deserialize or result values that we can't serialize.
> Encoding and decoding exceptions should be handled differently, so clients 
> can tell if a value was present but could not be serialized.
> Encoding and decoding errors should be handled consistently across operation 
> handlers.
> Probably we could throw Encoding or Decoding exceptions and handle them at a 
> higher level than the individual op handler.



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

[jira] [Commented] (GEODE-4377) Don't catch encoding exceptions in OperationHandlers

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4377:


Commit dec2cfe1e650d5adcfd41ecabe9b0c9a3f3dc91f in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dec2cfe ]

GEODE-4377: Don't catch encoding exceptions in OperationHandlers

This adds DecodingException and moves the handling of EncodingException
and this new exception to ProtobufOpsProcessor.

I've also added tests for getAll and putAll to ensure that their
handlers properly process all entries in the presence of a Key or
Entry decoding error.

This closes #1434


> Don't catch encoding exceptions in OperationHandlers
> 
>
> Key: GEODE-4377
> URL: https://issues.apache.org/jira/browse/GEODE-4377
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> In the protobuf protocol, we are currently catching EncodingException due to 
> values that we can't deserialize or result values that we can't serialize.
> Encoding and decoding exceptions should be handled differently, so clients 
> can tell if a value was present but could not be serialized.
> Encoding and decoding errors should be handled consistently across operation 
> handlers.
> Probably we could throw Encoding or Decoding exceptions and handle them at a 
> higher level than the individual op handler.



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

[jira] [Updated] (GEODE-4666) CI failures in geode examples - Network is unreachable; port (10334) is not available on localhost

[ASF GitHub Bot (JIRA)]

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

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

> CI failures in geode examples - Network is unreachable; port (10334) is not 
> available on localhost
> --
>
> Key: GEODE-4666
> URL: https://issues.apache.org/jira/browse/GEODE-4666
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Dan Smith
>Priority: Major
>  Labels: pull-request-available
>
> The geode-examples jobs are sometimes failing with port conflicts. Below is 
> an example
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/TestExamples/builds/24]
> {noformat}
> :serialization:start
> 1. Executing - start locator --name=locator --bind-address=127.0.0.1
> The Locator process terminated unexpectedly with exit status 1. Please 
> refer to the log file in 
> /tmp/build/ea3e9ea4/geode-examples/serialization/locator for full details.
> Feb 12, 2018 11:25:19 PM org.apache.geode.distributed.LocatorLauncher 
> failOnStart
> INFO: locator is exiting due to an exception
> java.net.BindException: Network is unreachable; port (10334) is not available 
> on localhost.
>     at 
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:131)
>     at 
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:635)
>     at 
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:549)
>     at 
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:192)
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred 
> while starting a Locator in 
> /tmp/build/ea3e9ea4/geode-examples/serialization/locator on localhost[10334]: 
> Network is unreachable; port (10334) is not available on localhost.
>     at 
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:655)
>     at 
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:549)
>     at 
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:192)
> Caused by: java.net.BindException: Network is unreachable; port (10334) is 
> not available on localhost.
>     at 
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:131)
>     at 
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:635)
>     ... 2 more
> :serialization:start FAILED
> {noformat}
> I did some digging, and I think the cause is that the gfsh shutdown command 
> from a previous test has not finished shutting down the locator.
> Looking at the code, it looks like there is some code that is intended to 
> shutdown and wait for a certain amount of time. But the logic is flawed, 
> because it is executing a function and not waiting for the results.
> {code:java}
>   Callable shutdownNodes = () -> {
> try {
>   Execution execution = FunctionService.onMembers(includeMembers);
>   
>//** HERE, execute submits the function asynchronously
>execution.execute(shutDownFunction);
> } catch (FunctionException functionEx) {
>   // Expected Exception as the function is shutting down the target 
> members and the result
>   // collector will get member departed exception
> }
> return "SUCCESS";
>   };
>   Future result = exec.submit(shutdownNodes);
>   result.get(timeout, TimeUnit.MILLISECONDS);
> {code}



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

[jira] [Resolved] (GEODE-2971) Inconsistency in gfsh status command

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg resolved GEODE-2971.
-
Resolution: Fixed

Per the ASF bot comments, this has been fixed since 
9db5c8e58ac6c53ce21a6c0dca3f8c64555f6cfc / PR 652.

> Inconsistency in gfsh status command
> 
>
> Key: GEODE-2971
> URL: https://issues.apache.org/jira/browse/GEODE-2971
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
>
> There is a general inconsistency in gfsh's exit status to the shell.  This 
> makes scripting rather difficult.  For instance:
> * Locator & Server Online (+)
> ** --pid: exit code {{0}} for both, all good.
> ** --name: exit code {{0}} for both, all good.
> ** --dir: exit code {{0}} for both, all good.
> * Locator Online, Server Offline (-)
> ** --pid: exit code is {{0}} for both. Nevertheless, the return string when 
> executing the command for the server returns a {{null}} within the message 
> (where the ip and port should be). As an example: {{Server in 
> /path/to/server/directory on null is currently not responding}}.
> ** --name: exit code is {{0}} for the locator, {{1}} for the server because 
> there's no online member with the specified name... which raises the 
> question: there wasn't any exceptions during the execution, shouldn't we 
> return {{0}}?.
> ** --dir: exit code is {{0}} for both. Nevertheless, the return string when 
> executing the command for the server returns a {{null}} within the message 
> (where the ip and port should be). As an example: {{Server in 
> /path/to/server/directory on null is currently not responding}}.
> * Locator & Server Offline (-)
> ** --pid: exit code for locator is {{1}}, and the return string only contains 
> {{null}}. The exit code for server is {{0}}, but the return string contains a 
> {{null}} within the message (where the ip and port should be). As an example: 
> {{Server in /path/to/server/directory on null is currently not responding}}.
> ** --name: both return {{1}}, which is expected since there's no jmx manager 
> running and this option requires gfsh to be connected.
> ** --dir: exit code for locator is {{1}}, and the return string only contains 
> {{null}}. The exit code for server is {{0}}, but the return string contains a 
> {{null}} within the message (where the ip and port should be). As an example: 
> {{Server in /path/to/server/directory on null is currently not responding}}.



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

[jira] [Resolved] (GEODE-4674) Make callbackArg an optional parameter in IRegion methods (Put, PutAll, etc)

[Addison (JIRA)]

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

Addison resolved GEODE-4674.

Resolution: Duplicate

> Make callbackArg an optional parameter in IRegion methods (Put, PutAll, etc)
> 
>
> Key: GEODE-4674
> URL: https://issues.apache.org/jira/browse/GEODE-4674
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Ryan McMahon
>Priority: Major
>
> The callbackArg should be an optional parameter because a user may not have 
> any event handlers e.g. CacheWriters defined.  The Java API has an overload 
> for Put() which does not have callbackArgs, but the C# API does not.  C# 
> allows for optional parameters which would be a good fit here.
> Example:
> IRegion(TKey key, TValue value, object callbackArg = null); 



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

[jira] [Assigned] (GEODE-4666) CI failures in geode examples - Network is unreachable; port (10334) is not available on localhost

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-4666:
---

Assignee: Patrick Rhomberg

> CI failures in geode examples - Network is unreachable; port (10334) is not 
> available on localhost
> --
>
> Key: GEODE-4666
> URL: https://issues.apache.org/jira/browse/GEODE-4666
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Dan Smith
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The geode-examples jobs are sometimes failing with port conflicts. Below is 
> an example
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/TestExamples/builds/24]
> {noformat}
> :serialization:start
> 1. Executing - start locator --name=locator --bind-address=127.0.0.1
> The Locator process terminated unexpectedly with exit status 1. Please 
> refer to the log file in 
> /tmp/build/ea3e9ea4/geode-examples/serialization/locator for full details.
> Feb 12, 2018 11:25:19 PM org.apache.geode.distributed.LocatorLauncher 
> failOnStart
> INFO: locator is exiting due to an exception
> java.net.BindException: Network is unreachable; port (10334) is not available 
> on localhost.
>     at 
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:131)
>     at 
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:635)
>     at 
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:549)
>     at 
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:192)
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred 
> while starting a Locator in 
> /tmp/build/ea3e9ea4/geode-examples/serialization/locator on localhost[10334]: 
> Network is unreachable; port (10334) is not available on localhost.
>     at 
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:655)
>     at 
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:549)
>     at 
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:192)
> Caused by: java.net.BindException: Network is unreachable; port (10334) is 
> not available on localhost.
>     at 
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:131)
>     at 
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:635)
>     ... 2 more
> :serialization:start FAILED
> {noformat}
> I did some digging, and I think the cause is that the gfsh shutdown command 
> from a previous test has not finished shutting down the locator.
> Looking at the code, it looks like there is some code that is intended to 
> shutdown and wait for a certain amount of time. But the logic is flawed, 
> because it is executing a function and not waiting for the results.
> {code:java}
>   Callable shutdownNodes = () -> {
> try {
>   Execution execution = FunctionService.onMembers(includeMembers);
>   
>//** HERE, execute submits the function asynchronously
>execution.execute(shutDownFunction);
> } catch (FunctionException functionEx) {
>   // Expected Exception as the function is shutting down the target 
> members and the result
>   // collector will get member departed exception
> }
> return "SUCCESS";
>   };
>   Future result = exec.submit(shutdownNodes);
>   result.get(timeout, TimeUnit.MILLISECONDS);
> {code}



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

[jira] [Updated] (GEODE-4402) Log exceptions to server log

[ASF GitHub Bot (JIRA)]

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

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

> Log exceptions to server log
> 
>
> Key: GEODE-4402
> URL: https://issues.apache.org/jira/browse/GEODE-4402
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Brian Baynes
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
>
> When the new protocol handles an exception, it should write the exception to 
> the server log (even if it only sends back an error to the client) -- this 
> will help in debugging efforts.
> All exceptions handled by the new protocol should be logged to the server log.



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

[jira] [Updated] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during s

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-4675:
---
Affects Version/s: 1.5.0

> CI failure (suspect strings): DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected reported as fatal 
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
>  > testPartitionedParallelPropagationHA FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 9339
> [fatal 2018/02/13 21:12:48.099 UTC  tid=891] 
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected.
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
>   at 
> org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
>   at 
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
>   at 
> org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
>   at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
>   at java.lang.Thread.run(Thread.java:748)
> ---
> {noformat}
> According to the logs, this looks like it occurs during shutdown ... 
> {noformat}
> [vm1] [info 2018/02/13 21:12:48.075 UTC  
> tid=30] Stopping membership services
> [vm0] [info 2018/02/13 21:12:48.077 UTC  thread 0> tid=398] GMSHealthMonitor server thread exiting
> [vm0] [info 2018/02/13 21:12:48.078 UTC  
> tid=30] GMSHealthMonitor serverSocketExecutor is terminated
> [vm3] [info 2018/02/13 21:12:48.079 UTC  
> tid=896] received leave request from 172.17.0.2:32771 for 
> 172.17.0.2(180):32771
> [vm0] [info 2018/02/13 21:12:48.084 UTC  
> tid=30] DistributionManager stopped in 121ms.
> [vm0] [info 2018/02/13 21:12:48.086 UTC  
> tid=30] Marking DistributionManager 172.17.0.2(176):32770 as closed.
> [vm1] [info 2018/02/13 21:12:48.087 UTC  
> tid=30] GMSHealthMonitor server socket is closed in stopServices().
> [vm0] [info 2018/02/13 21:12:48.089 UTC  
> tid=30] Got result: null
> [vm0]  from 
> 

[jira] [Resolved] (GEODE-4585) Remove singleton calls from product code in org.apache.geode.internal.cache.snapshot

[Darrel Schneider (JIRA)]

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

Darrel Schneider resolved GEODE-4585.
-
   Resolution: Fixed
Fix Version/s: 1.5.0

> Remove singleton calls from product code in 
> org.apache.geode.internal.cache.snapshot
> 
>
> Key: GEODE-4585
> URL: https://issues.apache.org/jira/browse/GEODE-4585
> Project: Geode
>  Issue Type: Sub-task
>  Components: snapshot
>Reporter: Kirk Lund
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> These product classes in org.apache.geode.internal.cache.snapshot invoke 
> singleton getters.
> InternalDistributedSystem.getAnyInstance():
> * RegionSnapshotServiceImpl



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

[jira] [Created] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during s

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-4675:
--

 Summary: CI failure (suspect strings): 
DistributedSystemDisconnectedException: This connection to a distributed system 
has been disconnected reported as fatal log message during shutdown
 Key: GEODE-4675
 URL: https://issues.apache.org/jira/browse/GEODE-4675
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Shelley Lynn Hughes-Godfrey


This failure occurred during CI on geode:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
{noformat}
org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
 > testPartitionedParallelPropagationHA FAILED
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 9339

[fatal 2018/02/13 21:12:48.099 UTC  tid=891] 
Unexpected exception:
org.apache.geode.distributed.DistributedSystemDisconnectedException: This 
connection to a distributed system has been disconnected.
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
at 
org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
at 
org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
at 
org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
at 
org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
at 
org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
at 
org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
at 
org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
at 
org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
at 
org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
at 
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
at java.lang.Thread.run(Thread.java:748)

---
{noformat}

According to the logs, this looks like it occurs during shutdown ... 
{noformat}
[vm1] [info 2018/02/13 21:12:48.075 UTC  
tid=30] Stopping membership services

[vm0] [info 2018/02/13 21:12:48.077 UTC  tid=398] GMSHealthMonitor server thread exiting

[vm0] [info 2018/02/13 21:12:48.078 UTC  
tid=30] GMSHealthMonitor serverSocketExecutor is terminated

[vm3] [info 2018/02/13 21:12:48.079 UTC  
tid=896] received leave request from 172.17.0.2:32771 for 
172.17.0.2(180):32771

[vm0] [info 2018/02/13 21:12:48.084 UTC  
tid=30] DistributionManager stopped in 121ms.

[vm0] [info 2018/02/13 21:12:48.086 UTC  
tid=30] Marking DistributionManager 172.17.0.2(176):32770 as closed.

[vm1] [info 2018/02/13 21:12:48.087 UTC  
tid=30] GMSHealthMonitor server socket is closed in stopServices().

[vm0] [info 2018/02/13 21:12:48.089 UTC  
tid=30] Got result: null
[vm0]  from 
org.apache.geode.internal.cache.wan.WANTestBase$$Lambda$45/1443408061.run with 
0 args on object: 
org.apache.geode.internal.cache.wan.WANTestBase$$Lambda$45/1443408061@13fa96af 
(took 139 ms)

[vm1] [info 2018/02/13 21:12:48.090 UTC  tid=402] GMSHealthMonitor server thread exiting

[vm1] [info 2018/02/13 21:12:48.090 UTC  
tid=30] GMSHealthMonitor serverSocketExecutor is terminated

[vm1] [info 2018/02/13 21:12:48.101 UTC  
tid=30] DistributionManager stopped in 135ms.

[vm1] [info 2018/02/13 21:12:48.102 UTC  
tid=30] Marking 

[jira] [Assigned] (GEODE-4643) Shutdown command should (optionally) wait for shutdown

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-4643:
---

Assignee: Patrick Rhomberg

> Shutdown command should (optionally) wait for shutdown
> --
>
> Key: GEODE-4643
> URL: https://issues.apache.org/jira/browse/GEODE-4643
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> Shutdown of a member is asynchronous.  The {{shutdown}} command will trigger 
> shutdown, but not guarantee it.
> Beyond the obvious benefit of guaranteeing cluster state, this has also 
> proven problematic in the {{runAll}} task of the {{geode-examples}} 
> repository, as subsequent tests can begin before the previous test has 
> finished tearing down.



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

[jira] [Resolved] (GEODE-3967) if put hits concurrent modification exception should still notify serial gateway sender

[xiaojian zhou (JIRA)]

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

xiaojian zhou resolved GEODE-3967.
--
Resolution: Fixed

> if put hits concurrent modification exception should still notify serial 
> gateway sender
> ---
>
> Key: GEODE-3967
> URL: https://issues.apache.org/jira/browse/GEODE-3967
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In serial gateway sender, the event arrives at secondary will be put into 
> unprocessedMap and wait for event from primary queue to distribute over, then 
> remove it from the unprocessedMap.
> If the put at primary member (member with primary queue) failed with CME, the 
> event in unprocessedMap will never be removed. 



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

[jira] [Assigned] (GEODE-4402) Log exceptions to server log

[Michael Dodge (JIRA)]

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

Michael Dodge reassigned GEODE-4402:


Assignee: Michael Dodge

> Log exceptions to server log
> 
>
> Key: GEODE-4402
> URL: https://issues.apache.org/jira/browse/GEODE-4402
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Brian Baynes
>Assignee: Michael Dodge
>Priority: Major
>
> When the new protocol handles an exception, it should write the exception to 
> the server log (even if it only sends back an error to the client) -- this 
> will help in debugging efforts.
> All exceptions handled by the new protocol should be logged to the server log.



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

[jira] [Resolved] (GEODE-4633) un-deprecate peer-auth-init

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-4633.

   Resolution: Fixed
Fix Version/s: 1.5.0

fixed

> un-deprecate peer-auth-init
> ---
>
> Key: GEODE-4633
> URL: https://issues.apache.org/jira/browse/GEODE-4633
> Project: Geode
>  Issue Type: Task
>  Components: docs, security
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
>  `peer-auth-init` is currently deprecated but allows the user to supply a 
> class that generates credentials for peer authentication (instead of reading 
> from cmd line or properties).  This might be useful for integration with a 
> key management system like CredHub, and allow user not to save password in a 
> plain text format on file. 
> please make sure this property still works as expected. and un-deprecate it 
> in the docs.



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

[jira] [Updated] (GEODE-4545) Remove singleton calls from product code in org.apache.geode.security

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-4545:
---
Fix Version/s: 1.5.0

> Remove singleton calls from product code in org.apache.geode.security
> -
>
> Key: GEODE-4545
> URL: https://issues.apache.org/jira/browse/GEODE-4545
> Project: Geode
>  Issue Type: Sub-task
>  Components: security
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>Priority: Major
> Fix For: 1.5.0
>
>
> These product classes in org.apache.geode.security invoke singleton getters.
> GemFireCacheImpl.getInstance():
> * AuthInitialize



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

[jira] [Updated] (GEODE-4674) Make callbackArg an optional parameter in IRegion methods (Put, PutAll, etc)

[Ryan McMahon (JIRA)]

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

Ryan McMahon updated GEODE-4674:

Priority: Major  (was: Minor)

> Make callbackArg an optional parameter in IRegion methods (Put, PutAll, etc)
> 
>
> Key: GEODE-4674
> URL: https://issues.apache.org/jira/browse/GEODE-4674
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Ryan McMahon
>Priority: Major
>
> The callbackArg should be an optional parameter because a user may not have 
> any event handlers e.g. CacheWriters defined.  The Java API has an overload 
> for Put() which does not have callbackArgs, but the C# API does not.  C# 
> allows for optional parameters which would be a good fit here.
> Example:
> IRegion(TKey key, TValue value, object callbackArg = null); 



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

[jira] [Updated] (GEODE-4674) Make callbackArg an optional parameter in IRegion methods (Put, PutAll, etc)

[Ryan McMahon (JIRA)]

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

Ryan McMahon updated GEODE-4674:

Priority: Minor  (was: Major)

> Make callbackArg an optional parameter in IRegion methods (Put, PutAll, etc)
> 
>
> Key: GEODE-4674
> URL: https://issues.apache.org/jira/browse/GEODE-4674
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Ryan McMahon
>Priority: Minor
>
> The callbackArg should be an optional parameter because a user may not have 
> any event handlers e.g. CacheWriters defined.  The Java API has an overload 
> for Put() which does not have callbackArgs, but the C# API does not.  C# 
> allows for optional parameters which would be a good fit here.
> Example:
> IRegion(TKey key, TValue value, object callbackArg = null); 



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

[jira] [Assigned] (GEODE-4545) Remove singleton calls from product code in org.apache.geode.security

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-4545:
--

Assignee: Jinmei Liao

> Remove singleton calls from product code in org.apache.geode.security
> -
>
> Key: GEODE-4545
> URL: https://issues.apache.org/jira/browse/GEODE-4545
> Project: Geode
>  Issue Type: Sub-task
>  Components: security
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>Priority: Major
>
> These product classes in org.apache.geode.security invoke singleton getters.
> GemFireCacheImpl.getInstance():
> * AuthInitialize



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

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

[Fred Krone (JIRA)]

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

Fred Krone reassigned GEODE-788:


Assignee: 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: Kirk Lund
>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] [Created] (GEODE-4674) Make callbackArg an optional parameter in IRegion methods (Put, PutAll, etc)

[Ryan McMahon (JIRA)]

Ryan McMahon created GEODE-4674:
---

 Summary: Make callbackArg an optional parameter in IRegion methods 
(Put, PutAll, etc)
 Key: GEODE-4674
 URL: https://issues.apache.org/jira/browse/GEODE-4674
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Ryan McMahon


The callbackArg should be an optional parameter because a user may not have any 
event handlers e.g. CacheWriters defined.  The Java API has an overload for 
Put() which does not have callbackArgs, but the C# API does not.  C# allows for 
optional parameters which would be a good fit here.

Example:

IRegion(TKey key, TValue value, object callbackArg = null); 



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

[jira] [Resolved] (GEODE-4545) Remove singleton calls from product code in org.apache.geode.security

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-4545.

Resolution: Fixed

> Remove singleton calls from product code in org.apache.geode.security
> -
>
> Key: GEODE-4545
> URL: https://issues.apache.org/jira/browse/GEODE-4545
> Project: Geode
>  Issue Type: Sub-task
>  Components: security
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>Priority: Major
>
> These product classes in org.apache.geode.security invoke singleton getters.
> GemFireCacheImpl.getInstance():
> * AuthInitialize



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

[jira] [Assigned] (GEODE-4633) un-deprecate peer-auth-init

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-4633:
--

Assignee: Jinmei Liao

> un-deprecate peer-auth-init
> ---
>
> Key: GEODE-4633
> URL: https://issues.apache.org/jira/browse/GEODE-4633
> Project: Geode
>  Issue Type: Task
>  Components: docs, security
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
>  `peer-auth-init` is currently deprecated but allows the user to supply a 
> class that generates credentials for peer authentication (instead of reading 
> from cmd line or properties).  This might be useful for integration with a 
> key management system like CredHub, and allow user not to save password in a 
> plain text format on file. 
> please make sure this property still works as expected. and un-deprecate it 
> in the docs.



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

[jira] [Commented] (GEODE-3967) if put hits concurrent modification exception should still notify serial gateway sender

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3967:


Commit de7c6d8b4a9b3e2c1c0ebd4ce1835aff0007f9e1 in geode's branch 
refs/heads/develop from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=de7c6d8 ]

GEODE-3967: There're following 9 problems fixed here:
1) When ConcurrentCacheModificationException happened, GatewaySenderEventImpl
 should save the status and notify gatewaysender if it hold primary queue,
because other member might have put the event into the secondary queue.
2) In AbstractUpdateOperation's doPutOrCreate's 3 tries of basicUpdate, the
3rd try should allow both create and update.
3) Let event with CME not to dispatch. The old logic does not allow CME event
to  enqueue. This is wrong, because an event without CME might have been
added into the secondary queue. So we should enqueue it, but not to dispatch.
4) Let UPDATE_VERSION_STAMP not to enqueue if not primary queue, because
the event did not fire in pair.
5) AbstractGatewaySenderEventProcessor put loop of filter in wrong place,
which caused UPDATE_VERSION_STAMP and CME events are not ignored.
However, not to fix it for now. Leave it in GEODE-4659.
6) shouldSendVersionEvents for Remote sender should return true, since
we no longer support 7.0.1 any more.
7) change version to 150
8) CME event should not retry in AUO.doPutOrCreate, because retry will end up 
with CME too.
9) CME && !originRemote: only enqueue to primary

This closes #1317


> if put hits concurrent modification exception should still notify serial 
> gateway sender
> ---
>
> Key: GEODE-3967
> URL: https://issues.apache.org/jira/browse/GEODE-3967
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In serial gateway sender, the event arrives at secondary will be put into 
> unprocessedMap and wait for event from primary queue to distribute over, then 
> remove it from the unprocessedMap.
> If the put at primary member (member with primary queue) failed with CME, the 
> event in unprocessedMap will never be removed. 



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

[jira] [Commented] (GEODE-4659) AbstractGatewaySenderEventProcessor put loop of filter in wrong place

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4659:


Commit de7c6d8b4a9b3e2c1c0ebd4ce1835aff0007f9e1 in geode's branch 
refs/heads/develop from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=de7c6d8 ]

GEODE-3967: There're following 9 problems fixed here:
1) When ConcurrentCacheModificationException happened, GatewaySenderEventImpl
 should save the status and notify gatewaysender if it hold primary queue,
because other member might have put the event into the secondary queue.
2) In AbstractUpdateOperation's doPutOrCreate's 3 tries of basicUpdate, the
3rd try should allow both create and update.
3) Let event with CME not to dispatch. The old logic does not allow CME event
to  enqueue. This is wrong, because an event without CME might have been
added into the secondary queue. So we should enqueue it, but not to dispatch.
4) Let UPDATE_VERSION_STAMP not to enqueue if not primary queue, because
the event did not fire in pair.
5) AbstractGatewaySenderEventProcessor put loop of filter in wrong place,
which caused UPDATE_VERSION_STAMP and CME events are not ignored.
However, not to fix it for now. Leave it in GEODE-4659.
6) shouldSendVersionEvents for Remote sender should return true, since
we no longer support 7.0.1 any more.
7) change version to 150
8) CME event should not retry in AUO.doPutOrCreate, because retry will end up 
with CME too.
9) CME && !originRemote: only enqueue to primary

This closes #1317


> AbstractGatewaySenderEventProcessor put loop of filter in wrong place
> -
>
> Key: GEODE-4659
> URL: https://issues.apache.org/jira/browse/GEODE-4659
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> {noformat}
> When fixing GEODE-3967, I found the loop of filter is in wrong place. 
>  
> If there's no filter defined, the processing  to ignore UPDATE_VERSION_STAMP 
> and events with CME should have nothing to do with filters. But if there's no 
> filter defined, the code will not ignore the UPDATE_VERSION_STAMP and events 
> with CME.
>  
> However, if fixed this problem. the GEODE-3967 have more race conditions to 
> be fixed. (I have fixed several of them). It looks like this bug hided other 
> race conditions from blowing out. 
>  
> GIving the time constrain, I will not fix the filter issue in GEODE_3967 and 
> log this bug for future reference. 
>  
> Here are the diff to fix or this bug:
> diff --git 
> a/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
>  
> b/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
> index 8739a8f72..a3a89fbd0 100644
> --- 
> a/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
> +++ 
> b/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
> @@ -81,40 +81,8 @@ public class RemoteParallelGatewaySenderEventProcessor 
> extends ParallelGatewaySe
>     * @param disp
>     * @return true if remote site Gemfire Version is >= 7.0.1
>     */
> -  private boolean shouldSendVersionEvents(GatewaySenderEventDispatcher disp)
> -      throws GatewaySenderException {
> -    try {
> -      GatewaySenderEventRemoteDispatcher remoteDispatcher =
> -          (GatewaySenderEventRemoteDispatcher) disp;
> -      // This will create a new connection if no batch has been sent till
> -      // now.
> -      Connection conn = remoteDispatcher.getConnection(false);
> -      if (conn != null) {
> -        short remoteSiteVersion = conn.getWanSiteVersion();
> -        if (Version.GFE_701.compareTo(remoteSiteVersion) <= 0) {
> -          return true;
> -        }
> -      }
> -    } catch (GatewaySenderException e) {
> -      Throwable cause = e.getCause();
> -      if (cause instanceof IOException || e instanceof 
> GatewaySenderConfigurationException
> -          || cause instanceof ConnectionDestroyedException) {
> -        try {
> -          int sleepInterval = GatewaySender.CONNECTION_RETRY_INTERVAL;
> -          if (logger.isDebugEnabled()) {
> -            logger.debug("Sleeping for {} milliseconds", sleepInterval);
> -          }
> -          Thread.sleep(sleepInterval);
> -        } catch (InterruptedException ie) {
> -          // log the exception
> -          if (logger.isDebugEnabled()) {
> -            logger.debug(ie.getMessage(), ie);
> -          }
> -        }
> -      }
> -      throw e;
> -    }
> -    return false;
> +  protected boolean 

[jira] [Commented] (GEODE-4655) CI Failure: DiskRegionJUnitTest.testDiskRegionOverflow

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4655:


Commit 3a2a539df95451ecf8fac1f6587a8b1d32f7e4fc in geode's branch 
refs/heads/feature/GEODE-3967 from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a2a539 ]

GEODE-4655: Use smaller eviction limit to avoid async scanning. (#1446)



> CI Failure: DiskRegionJUnitTest.testDiskRegionOverflow
> --
>
> Key: GEODE-4655
> URL: https://issues.apache.org/jira/browse/GEODE-4655
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> org.apache.geode.internal.cache.DiskRegionJUnitTest > testDiskRegionOverflow 
> FAILED
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.geode.internal.cache.DiskRegionJUnitTest.testDiskRegionOverflow(DiskRegionJUnitTest.java:219)



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

[jira] [Commented] (GEODE-4640) CI Failure: RemoveCommandDUnitTest can fail to find region

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4640:


Commit f3e37e180fe9cdcda9f54b989afbba9ea72b8f7e in geode's branch 
refs/heads/feature/GEODE-3967 from [~prhomberg]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f3e37e1 ]

GEODE-4640: Remove potential race condition from RemoveCommandDUnitTest. (#1421)



> CI Failure: RemoveCommandDUnitTest can fail to find region
> --
>
> Key: GEODE-4640
> URL: https://issues.apache.org/jira/browse/GEODE-4640
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The test has failed sporadically with
> {noformat}
> org.apache.geode.management.internal.cli.commands.RemoveCommandDUnitTest > 
> removeAllFromPartitionedRegion FAILED
> org.junit.ComparisonFailure: [Region  not found in 
> any of the members
> {noformat}
> This may be to the test waiting only for one region to be ready before 
> proceeding, resulting in a race condition between the testing VM and the 
> server VMs.
> See 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/124
> http://files.apachegeode-ci.info/builds/1.5.0-build.409/test-results/distributedTest/



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

[jira] [Commented] (GEODE-4511) Avoid creation of unnecessary default pool

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4511:


Commit 525241905050e9a192a1f36fc662735ab8e281d9 in geode's branch 
refs/heads/feature/GEODE-3967 from [~PivotalSarge]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5252419 ]

GEODE-4511: Ensure a pool is available for durable client subscription. (#1448)

* GEODE-4511: Ensure a pool is available for durable client subscription.

* GEODE-4511: Restrict default pool creation for subscription to clients.


> Avoid creation of unnecessary default pool
> --
>
> Key: GEODE-4511
> URL: https://issues.apache.org/jira/browse/GEODE-4511
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The Java API for creating a client cache automatically creates a default pool 
> although this default pool is not used for almost all real use cases. 
> Moreover, this pool periodically tries to connect to the server. This is 
> basically harmless but it wastes resources a little bit.



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

[jira] [Commented] (GEODE-3967) if put hits concurrent modification exception should still notify serial gateway sender

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3967:


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

GEODE-3967: There're following 9 problems fixed here:
1) When ConcurrentCacheModificationException happened, GatewaySenderEventImpl
 should save the status and notify gatewaysender if it hold primary queue,
because other member might have put the event into the secondary queue.
2) In AbstractUpdateOperation's doPutOrCreate's 3 tries of basicUpdate, the
3rd try should allow both create and update.
3) Let event with CME not to dispatch. The old logic does not allow CME event
to  enqueue. This is wrong, because an event without CME might have been
added into the secondary queue. So we should enqueue it, but not to dispatch.
4) Let UPDATE_VERSION_STAMP not to enqueue if not primary queue, because
the event did not fire in pair.
5) AbstractGatewaySenderEventProcessor put loop of filter in wrong place,
which caused UPDATE_VERSION_STAMP and CME events are not ignored.
However, not to fix it for now. Leave it in GEODE-4659.
6) shouldSendVersionEvents for Remote sender should return true, since
we no longer support 7.0.1 any more.
7) change version to 150
8) CME event should not retry in AUO.doPutOrCreate, because retry will end up 
with CME too.
9) CME && !originRemote: only enqueue to primary


> if put hits concurrent modification exception should still notify serial 
> gateway sender
> ---
>
> Key: GEODE-3967
> URL: https://issues.apache.org/jira/browse/GEODE-3967
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>  Labels: pull-request-available
>
> In serial gateway sender, the event arrives at secondary will be put into 
> unprocessedMap and wait for event from primary queue to distribute over, then 
> remove it from the unprocessedMap.
> If the put at primary member (member with primary queue) failed with CME, the 
> event in unprocessedMap will never be removed. 



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

[jira] [Commented] (GEODE-4511) Avoid creation of unnecessary default pool

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4511:


Commit 525241905050e9a192a1f36fc662735ab8e281d9 in geode's branch 
refs/heads/feature/GEODE-3967 from [~PivotalSarge]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5252419 ]

GEODE-4511: Ensure a pool is available for durable client subscription. (#1448)

* GEODE-4511: Ensure a pool is available for durable client subscription.

* GEODE-4511: Restrict default pool creation for subscription to clients.


> Avoid creation of unnecessary default pool
> --
>
> Key: GEODE-4511
> URL: https://issues.apache.org/jira/browse/GEODE-4511
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The Java API for creating a client cache automatically creates a default pool 
> although this default pool is not used for almost all real use cases. 
> Moreover, this pool periodically tries to connect to the server. This is 
> basically harmless but it wastes resources a little bit.



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

[jira] [Commented] (GEODE-800) Geode's classloading mechanism is unable to resolve classes found within nested jars

[ASF subversion and git services (JIRA)]

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

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

Commit 53178f8e375c05cf093723756a34f5e363e4b63d in geode's branch 
refs/heads/feature/GEODE-3967 from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=53178f8 ]

GEODE-800: Reduce test iterations to avoid timeouts


> Geode's classloading mechanism is unable to resolve classes found within 
> nested jars
> 
>
> Key: GEODE-800
> URL: https://issues.apache.org/jira/browse/GEODE-800
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Priority: Major
>  Labels: ClassLoader, DeployCommand, deploy, gfsh, 
> pull-request-available
> Fix For: 1.5.0
>
> Attachments: geode-800-testcase.zip
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This issue is particularly evident when using Geode in a Spring Boot app 
> which creates an 'über' jar containing all dependent jars.
> When Geode is launched in this context, the following errors can be seen:
> {noformat}
> [warn 2016/01/20 08:53:29.431 PST  tid=0xd] (tid=13 msgId=0) Required 
> Commands classes were not loaded. Check logs for errors.
> java.lang.IllegalStateException: Required Commands classes were not loaded. 
> Check logs for errors.
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.raiseExceptionIfEmpty(CommandManager.java:249)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.loadCommands(CommandManager.java:188)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.(CommandManager.java:86)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:278)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:258)
> at 
> com.gemstone.gemfire.management.internal.cli.remote.CommandProcessor.(CommandProcessor.java:58)
> ...
> {noformat}
> The problem here is in {{ClasspathScanLoadHelper.getClasses()}}. In this 
> method we call:
> {noformat}
> Enumeration resources = 
> ClassPathLoader.getLatest().getResources(packagePath);
> {noformat}
> However {{getResources()}} doesn't just work against the 'latest' 
> classloader, but also considers the thread context classloader. In the case 
> of a Spring Boot app, Spring does provide such a classloader and 
> {{getResources}} is able to find the necessary resources {{CommandMarker}} 
> classes. (These classes are found within a nested jar. For ex. 
> {{jar:file:/Users/jdeppe/src/woddrive/WodDrive-GF-Server/target/WodDriveGFServer.jar!/lib/gemfire-core-1.0.0-incubating-SNAPSHOT.jar!/com/gemstone/gemfire/management/internal/cli/commands}}).
>  This is all fine, but subsequent code doesn't consider classes (or packages) 
> within nested jars, and in addition, when classes actually get resolved, the 
> thread context classloader (where those resources might have come from) is 
> not considered.



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

[jira] [Commented] (GEODE-4659) AbstractGatewaySenderEventProcessor put loop of filter in wrong place

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4659:


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

GEODE-3967: There're following 9 problems fixed here:
1) When ConcurrentCacheModificationException happened, GatewaySenderEventImpl
 should save the status and notify gatewaysender if it hold primary queue,
because other member might have put the event into the secondary queue.
2) In AbstractUpdateOperation's doPutOrCreate's 3 tries of basicUpdate, the
3rd try should allow both create and update.
3) Let event with CME not to dispatch. The old logic does not allow CME event
to  enqueue. This is wrong, because an event without CME might have been
added into the secondary queue. So we should enqueue it, but not to dispatch.
4) Let UPDATE_VERSION_STAMP not to enqueue if not primary queue, because
the event did not fire in pair.
5) AbstractGatewaySenderEventProcessor put loop of filter in wrong place,
which caused UPDATE_VERSION_STAMP and CME events are not ignored.
However, not to fix it for now. Leave it in GEODE-4659.
6) shouldSendVersionEvents for Remote sender should return true, since
we no longer support 7.0.1 any more.
7) change version to 150
8) CME event should not retry in AUO.doPutOrCreate, because retry will end up 
with CME too.
9) CME && !originRemote: only enqueue to primary


> AbstractGatewaySenderEventProcessor put loop of filter in wrong place
> -
>
> Key: GEODE-4659
> URL: https://issues.apache.org/jira/browse/GEODE-4659
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> {noformat}
> When fixing GEODE-3967, I found the loop of filter is in wrong place. 
>  
> If there's no filter defined, the processing  to ignore UPDATE_VERSION_STAMP 
> and events with CME should have nothing to do with filters. But if there's no 
> filter defined, the code will not ignore the UPDATE_VERSION_STAMP and events 
> with CME.
>  
> However, if fixed this problem. the GEODE-3967 have more race conditions to 
> be fixed. (I have fixed several of them). It looks like this bug hided other 
> race conditions from blowing out. 
>  
> GIving the time constrain, I will not fix the filter issue in GEODE_3967 and 
> log this bug for future reference. 
>  
> Here are the diff to fix or this bug:
> diff --git 
> a/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
>  
> b/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
> index 8739a8f72..a3a89fbd0 100644
> --- 
> a/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
> +++ 
> b/geode-wan/src/main/java/org/apache/geode/internal/cache/wan/parallel/RemoteParallelGatewaySenderEventProcessor.java
> @@ -81,40 +81,8 @@ public class RemoteParallelGatewaySenderEventProcessor 
> extends ParallelGatewaySe
>     * @param disp
>     * @return true if remote site Gemfire Version is >= 7.0.1
>     */
> -  private boolean shouldSendVersionEvents(GatewaySenderEventDispatcher disp)
> -      throws GatewaySenderException {
> -    try {
> -      GatewaySenderEventRemoteDispatcher remoteDispatcher =
> -          (GatewaySenderEventRemoteDispatcher) disp;
> -      // This will create a new connection if no batch has been sent till
> -      // now.
> -      Connection conn = remoteDispatcher.getConnection(false);
> -      if (conn != null) {
> -        short remoteSiteVersion = conn.getWanSiteVersion();
> -        if (Version.GFE_701.compareTo(remoteSiteVersion) <= 0) {
> -          return true;
> -        }
> -      }
> -    } catch (GatewaySenderException e) {
> -      Throwable cause = e.getCause();
> -      if (cause instanceof IOException || e instanceof 
> GatewaySenderConfigurationException
> -          || cause instanceof ConnectionDestroyedException) {
> -        try {
> -          int sleepInterval = GatewaySender.CONNECTION_RETRY_INTERVAL;
> -          if (logger.isDebugEnabled()) {
> -            logger.debug("Sleeping for {} milliseconds", sleepInterval);
> -          }
> -          Thread.sleep(sleepInterval);
> -        } catch (InterruptedException ie) {
> -          // log the exception
> -          if (logger.isDebugEnabled()) {
> -            logger.debug(ie.getMessage(), ie);
> -          }
> -        }
> -      }
> -      throw e;
> -    }
> -    return false;
> +  protected boolean 

[jira] [Commented] (GEODE-4511) Avoid creation of unnecessary default pool

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4511:


Commit 525241905050e9a192a1f36fc662735ab8e281d9 in geode's branch 
refs/heads/feature/GEODE-3967 from [~PivotalSarge]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5252419 ]

GEODE-4511: Ensure a pool is available for durable client subscription. (#1448)

* GEODE-4511: Ensure a pool is available for durable client subscription.

* GEODE-4511: Restrict default pool creation for subscription to clients.


> Avoid creation of unnecessary default pool
> --
>
> Key: GEODE-4511
> URL: https://issues.apache.org/jira/browse/GEODE-4511
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The Java API for creating a client cache automatically creates a default pool 
> although this default pool is not used for almost all real use cases. 
> Moreover, this pool periodically tries to connect to the server. This is 
> basically harmless but it wastes resources a little bit.



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

[jira] [Commented] (GEODE-4403) Remove ProtocolErrorCode

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4403:


Commit 10a91241ff3fca5ba5b3edf818a0ea433879bedd in geode's branch 
refs/heads/feature/GEODE-3967 from [~gosullivan]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=10a9124 ]

GEODE-4403: Remove ProtobufErrorCode (#1432)

as it's a duplicate of BasicTypes.ErrorCode

> Remove ProtocolErrorCode
> 
>
> Key: GEODE-4403
> URL: https://issues.apache.org/jira/browse/GEODE-4403
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We currently have a class called ProtocolErrorCode, which lists the errors 
> that can happen in the Protobuf protocol, but these error codes are also 
> listed in an enum in the .proto files and corresponding generated code. 
> Remove ProtocolErrorCode to DRY it up.



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

[jira] [Resolved] (GEODE-4655) CI Failure: DiskRegionJUnitTest.testDiskRegionOverflow

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-4655.
-
   Resolution: Fixed
Fix Version/s: 1.5.0

> CI Failure: DiskRegionJUnitTest.testDiskRegionOverflow
> --
>
> Key: GEODE-4655
> URL: https://issues.apache.org/jira/browse/GEODE-4655
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> org.apache.geode.internal.cache.DiskRegionJUnitTest > testDiskRegionOverflow 
> FAILED
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.geode.internal.cache.DiskRegionJUnitTest.testDiskRegionOverflow(DiskRegionJUnitTest.java:219)



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

[jira] [Commented] (GEODE-4640) CI Failure: RemoveCommandDUnitTest can fail to find region

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4640:


Commit f3e37e180fe9cdcda9f54b989afbba9ea72b8f7e in geode's branch 
refs/heads/develop from [~prhomberg]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f3e37e1 ]

GEODE-4640: Remove potential race condition from RemoveCommandDUnitTest. (#1421)



> CI Failure: RemoveCommandDUnitTest can fail to find region
> --
>
> Key: GEODE-4640
> URL: https://issues.apache.org/jira/browse/GEODE-4640
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The test has failed sporadically with
> {noformat}
> org.apache.geode.management.internal.cli.commands.RemoveCommandDUnitTest > 
> removeAllFromPartitionedRegion FAILED
> org.junit.ComparisonFailure: [Region  not found in 
> any of the members
> {noformat}
> This may be to the test waiting only for one region to be ready before 
> proceeding, resulting in a race condition between the testing VM and the 
> server VMs.
> See 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/124
> http://files.apachegeode-ci.info/builds/1.5.0-build.409/test-results/distributedTest/



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

[jira] [Commented] (GEODE-4655) CI Failure: DiskRegionJUnitTest.testDiskRegionOverflow

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4655:


Commit 3a2a539df95451ecf8fac1f6587a8b1d32f7e4fc in geode's branch 
refs/heads/develop from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a2a539 ]

GEODE-4655: Use smaller eviction limit to avoid async scanning. (#1446)



> CI Failure: DiskRegionJUnitTest.testDiskRegionOverflow
> --
>
> Key: GEODE-4655
> URL: https://issues.apache.org/jira/browse/GEODE-4655
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> org.apache.geode.internal.cache.DiskRegionJUnitTest > testDiskRegionOverflow 
> FAILED
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.geode.internal.cache.DiskRegionJUnitTest.testDiskRegionOverflow(DiskRegionJUnitTest.java:219)



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

[jira] [Resolved] (GEODE-4511) Avoid creation of unnecessary default pool

[Michael Dodge (JIRA)]

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

Michael Dodge resolved GEODE-4511.
--
   Resolution: Fixed
Fix Version/s: 1.5.0

> Avoid creation of unnecessary default pool
> --
>
> Key: GEODE-4511
> URL: https://issues.apache.org/jira/browse/GEODE-4511
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The Java API for creating a client cache automatically creates a default pool 
> although this default pool is not used for almost all real use cases. 
> Moreover, this pool periodically tries to connect to the server. This is 
> basically harmless but it wastes resources a little bit.



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

[jira] [Commented] (GEODE-4511) Avoid creation of unnecessary default pool

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4511:


Commit 525241905050e9a192a1f36fc662735ab8e281d9 in geode's branch 
refs/heads/develop from [~PivotalSarge]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5252419 ]

GEODE-4511: Ensure a pool is available for durable client subscription. (#1448)

* GEODE-4511: Ensure a pool is available for durable client subscription.

* GEODE-4511: Restrict default pool creation for subscription to clients.


> Avoid creation of unnecessary default pool
> --
>
> Key: GEODE-4511
> URL: https://issues.apache.org/jira/browse/GEODE-4511
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The Java API for creating a client cache automatically creates a default pool 
> although this default pool is not used for almost all real use cases. 
> Moreover, this pool periodically tries to connect to the server. This is 
> basically harmless but it wastes resources a little bit.



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

[jira] [Commented] (GEODE-4511) Avoid creation of unnecessary default pool

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4511:


Commit 525241905050e9a192a1f36fc662735ab8e281d9 in geode's branch 
refs/heads/develop from [~PivotalSarge]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5252419 ]

GEODE-4511: Ensure a pool is available for durable client subscription. (#1448)

* GEODE-4511: Ensure a pool is available for durable client subscription.

* GEODE-4511: Restrict default pool creation for subscription to clients.


> Avoid creation of unnecessary default pool
> --
>
> Key: GEODE-4511
> URL: https://issues.apache.org/jira/browse/GEODE-4511
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The Java API for creating a client cache automatically creates a default pool 
> although this default pool is not used for almost all real use cases. 
> Moreover, this pool periodically tries to connect to the server. This is 
> basically harmless but it wastes resources a little bit.



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

[jira] [Commented] (GEODE-4511) Avoid creation of unnecessary default pool

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4511:


Commit 525241905050e9a192a1f36fc662735ab8e281d9 in geode's branch 
refs/heads/develop from [~PivotalSarge]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5252419 ]

GEODE-4511: Ensure a pool is available for durable client subscription. (#1448)

* GEODE-4511: Ensure a pool is available for durable client subscription.

* GEODE-4511: Restrict default pool creation for subscription to clients.


> Avoid creation of unnecessary default pool
> --
>
> Key: GEODE-4511
> URL: https://issues.apache.org/jira/browse/GEODE-4511
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The Java API for creating a client cache automatically creates a default pool 
> although this default pool is not used for almost all real use cases. 
> Moreover, this pool periodically tries to connect to the server. This is 
> basically harmless but it wastes resources a little bit.



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

[jira] [Assigned] (GEODE-4528) Remove singleton calls from product code in org.apache.geode.internal.cache.tier

[Avinash Dongre (JIRA)]

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

Avinash Dongre reassigned GEODE-4528:
-

Assignee: Avinash Dongre

> Remove singleton calls from product code in 
> org.apache.geode.internal.cache.tier
> 
>
> Key: GEODE-4528
> URL: https://issues.apache.org/jira/browse/GEODE-4528
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Kirk Lund
>Assignee: Avinash Dongre
>Priority: Major
>
> These product classes in org.apache.geode.internal.cache.tier invoke 
> singleton getters.
> CacheFactory.getAnyInstance():
> * InternalClientMembership



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

[jira] [Created] (GEODE-4673) Create new geode-example about overflow

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-4673:


 Summary: Create new geode-example about overflow
 Key: GEODE-4673
 URL: https://issues.apache.org/jira/browse/GEODE-4673
 Project: Geode
  Issue Type: New Feature
  Components: examples
Reporter: Michael Dodge


Create a new example that demonstrates overflow.



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

[jira] [Assigned] (GEODE-4673) Create new geode-example about overflow

[Michael Dodge (JIRA)]

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

Michael Dodge reassigned GEODE-4673:


Assignee: Michael Dodge

> Create new geode-example about overflow
> ---
>
> Key: GEODE-4673
> URL: https://issues.apache.org/jira/browse/GEODE-4673
> Project: Geode
>  Issue Type: New Feature
>  Components: examples
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>
> Create a new example that demonstrates overflow.



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

[jira] [Closed] (GEODE-3460) Misleading error message from gfsh create region

[Jens Deppe (JIRA)]

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

Jens Deppe closed GEODE-3460.
-
Assignee: Jens Deppe  (was: Jared Stewart)

> Misleading error message from gfsh create region
> 
>
> Key: GEODE-3460
> URL: https://issues.apache.org/jira/browse/GEODE-3460
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.4.0
>
>
> If you provide --classpath to start server but not to start locator, you will 
> get the following (misleading) error message: 
> {noformat}
> gfsh>create region --name=example-region --type=PARTITION 
> --partition-resolver=Foo
> null is an invalid Partition Resolver.
> {noformat}



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

[jira] [Resolved] (GEODE-3460) Misleading error message from gfsh create region

[Jens Deppe (JIRA)]

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

Jens Deppe resolved GEODE-3460.
---
   Resolution: Fixed
Fix Version/s: 1.4.0

> Misleading error message from gfsh create region
> 
>
> Key: GEODE-3460
> URL: https://issues.apache.org/jira/browse/GEODE-3460
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Major
> Fix For: 1.4.0
>
>
> If you provide --classpath to start server but not to start locator, you will 
> get the following (misleading) error message: 
> {noformat}
> gfsh>create region --name=example-region --type=PARTITION 
> --partition-resolver=Foo
> null is an invalid Partition Resolver.
> {noformat}



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

[jira] [Commented] (GEODE-3460) Misleading error message from gfsh create region

[Jens Deppe (JIRA)]

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

Jens Deppe commented on GEODE-3460:
---

This was fixed by GEODE-1897 - commit 7a7c2ef7d546f278fc99aa700d7e456b8d86cf24

> Misleading error message from gfsh create region
> 
>
> Key: GEODE-3460
> URL: https://issues.apache.org/jira/browse/GEODE-3460
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Major
>
> If you provide --classpath to start server but not to start locator, you will 
> get the following (misleading) error message: 
> {noformat}
> gfsh>create region --name=example-region --type=PARTITION 
> --partition-resolver=Foo
> null is an invalid Partition Resolver.
> {noformat}



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

[jira] [Commented] (GEODE-800) Geode's classloading mechanism is unable to resolve classes found within nested jars

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-800: Reduce test iterations to avoid timeouts


> Geode's classloading mechanism is unable to resolve classes found within 
> nested jars
> 
>
> Key: GEODE-800
> URL: https://issues.apache.org/jira/browse/GEODE-800
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Priority: Major
>  Labels: ClassLoader, DeployCommand, deploy, gfsh, 
> pull-request-available
> Fix For: 1.5.0
>
> Attachments: geode-800-testcase.zip
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This issue is particularly evident when using Geode in a Spring Boot app 
> which creates an 'über' jar containing all dependent jars.
> When Geode is launched in this context, the following errors can be seen:
> {noformat}
> [warn 2016/01/20 08:53:29.431 PST  tid=0xd] (tid=13 msgId=0) Required 
> Commands classes were not loaded. Check logs for errors.
> java.lang.IllegalStateException: Required Commands classes were not loaded. 
> Check logs for errors.
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.raiseExceptionIfEmpty(CommandManager.java:249)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.loadCommands(CommandManager.java:188)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.(CommandManager.java:86)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:278)
> at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:258)
> at 
> com.gemstone.gemfire.management.internal.cli.remote.CommandProcessor.(CommandProcessor.java:58)
> ...
> {noformat}
> The problem here is in {{ClasspathScanLoadHelper.getClasses()}}. In this 
> method we call:
> {noformat}
> Enumeration resources = 
> ClassPathLoader.getLatest().getResources(packagePath);
> {noformat}
> However {{getResources()}} doesn't just work against the 'latest' 
> classloader, but also considers the thread context classloader. In the case 
> of a Spring Boot app, Spring does provide such a classloader and 
> {{getResources}} is able to find the necessary resources {{CommandMarker}} 
> classes. (These classes are found within a nested jar. For ex. 
> {{jar:file:/Users/jdeppe/src/woddrive/WodDrive-GF-Server/target/WodDriveGFServer.jar!/lib/gemfire-core-1.0.0-incubating-SNAPSHOT.jar!/com/gemstone/gemfire/management/internal/cli/commands}}).
>  This is all fine, but subsequent code doesn't consider classes (or packages) 
> within nested jars, and in addition, when classes actually get resolved, the 
> thread context classloader (where those resources might have come from) is 
> not considered.



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

[jira] [Commented] (GEODE-4403) Remove ProtocolErrorCode

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4403:


Commit 10a91241ff3fca5ba5b3edf818a0ea433879bedd in geode's branch 
refs/heads/develop from [~gosullivan]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=10a9124 ]

GEODE-4403: Remove ProtobufErrorCode (#1432)

as it's a duplicate of BasicTypes.ErrorCode

> Remove ProtocolErrorCode
> 
>
> Key: GEODE-4403
> URL: https://issues.apache.org/jira/browse/GEODE-4403
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We currently have a class called ProtocolErrorCode, which lists the errors 
> that can happen in the Protobuf protocol, but these error codes are also 
> listed in an enum in the .proto files and corresponding generated code. 
> Remove ProtocolErrorCode to DRY it up.



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