[jira] [Assigned] (GEODE-5068) Upgrade Jackson to 2.9.5

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan reassigned GEODE-5068:
---

Assignee: Galen O'Sullivan

> Upgrade Jackson to 2.9.5
> 
>
> Key: GEODE-5068
> URL: https://issues.apache.org/jira/browse/GEODE-5068
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Major
>
> We're a patch version behind, let's try to stay on the latest.



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

[jira] [Updated] (GEODE-5067) Failed dynamic_cast when visibility is set to hidden on Clang

[ASF GitHub Bot (JIRA)]

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

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

> Failed dynamic_cast when visibility is set to hidden on Clang
> -
>
> Key: GEODE-5067
> URL: https://issues.apache.org/jira/browse/GEODE-5067
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ryan McMahon
>Priority: Major
>  Labels: pull-request-available
>
> The testThinClientBigValue test is failing due to issues with Clang and the 
> cmake 'CXX_VISIBILITY_PRESET hidden' setting.  It appears Clang does not 
> propagate visibility attributes through using statements i.e.
> ```
> using CacheableBytes = CacheableArray;
> ```
> Despite CacheableArray and its base class Serializable being decorated with 
> APACHE_GEODE_EXPORT, dynamic_casts appear to fail. 



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

[jira] [Created] (GEODE-5068) Upgrade Jackson to 2.9.5

[Galen O'Sullivan (JIRA)]

Galen O'Sullivan created GEODE-5068:
---

 Summary: Upgrade Jackson to 2.9.5
 Key: GEODE-5068
 URL: https://issues.apache.org/jira/browse/GEODE-5068
 Project: Geode
  Issue Type: Improvement
  Components: serialization
Reporter: Galen O'Sullivan


We're a patch version behind, let's try to stay on the latest.



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

[jira] [Comment Edited] (GEODE-629) Replace use of org.json with Jackson JSON library

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan edited comment on GEODE-629 at 4/13/18 1:40 AM:
-

[~jens.deppe] / [~amb] can we close this? It looks like we've rewritten some of 
the org.json classes but no longer include the package.

EDIT: I think I misread, and we want to remove what's still included entirely.


was (Author: gosullivan):
[~jens.deppe] / [~amb] can we close this? It looks like we've rewritten some of 
the org.json classes but no longer include the package.

> Replace use of org.json with Jackson JSON library
> -
>
> Key: GEODE-629
> URL: https://issues.apache.org/jira/browse/GEODE-629
> Project: Geode
>  Issue Type: Improvement
>  Components: configuration, gfsh, serialization
>Reporter: Jens Deppe
>Priority: Major
>  Labels: json
> Attachments: json.patch
>
>
> Currently we're using two different JSON libraries; org.json and jackson. We 
> have customized org.json in the module gemfire-json.
> We should try and consolidate on a single JSON library - namely jackson as it 
> is much more capable than org.json.



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

[jira] [Commented] (GEODE-629) Replace use of org.json with Jackson JSON library

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan commented on GEODE-629:


[~jens.deppe] / [~amb] can we close this? It looks like we've rewritten some of 
the org.json classes but no longer include the package.

> Replace use of org.json with Jackson JSON library
> -
>
> Key: GEODE-629
> URL: https://issues.apache.org/jira/browse/GEODE-629
> Project: Geode
>  Issue Type: Improvement
>  Components: configuration, gfsh, serialization
>Reporter: Jens Deppe
>Priority: Major
>  Labels: json
> Attachments: json.patch
>
>
> Currently we're using two different JSON libraries; org.json and jackson. We 
> have customized org.json in the module gemfire-json.
> We should try and consolidate on a single JSON library - namely jackson as it 
> is much more capable than org.json.



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

[jira] [Commented] (GEODE-5056) ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2 intermittently fail

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5056:


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

GEODE-5056: when found the dropped events at primary sender, send
QueueRemovalMessage for it


> ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
>  intermittently fail 
> ---
>
> Key: GEODE-5056
> URL: https://issues.apache.org/jira/browse/GEODE-5056
> 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
>
> After fixe GEODE-4942, I found there's at least one race condition is not 
> covered. 
>  
> [vm6] [debug 2018/04/11 16:47:35.189 PDT  Processor2> tid=110] WAN: On primary bucket 57, setting the seq number as 1357
>  
> [vm7] [info 2018/04/11 16:47:35.150 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
>  
> [vm7] [debug 2018/04/11 16:47:35.189 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] WAN: 
> On secondary bucket 57, setting the seq number as 1357
> [vm7] [debug 2018/04/11 16:47:35.190 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] Key : 
> > 1357
> [vm6] [debug 2018/04/11 16:47:35.190 PDT  Processor2> tid=110] register dropped event for primary queue. BucketId is 
> 57, shadowKey is 1357, prQ is /ln_PARALLEL_GATEWAY_SENDER_QUEUE
>  
> - Note: vm6's sender is restarted and cleanup the map, before the
> QueueRemvalMessage is sent out for the map.
> [vm6] [info 2018/04/11 16:47:35.249 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
> [vm6] [debug 2018/04/11 16:47:35.437 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map \{/ln_PARALLEL_GATEWAY_SENDER_QUEUE={96=[1396], 2=[1402], 
> 83=[1383], 6=[1406], 71=[1371], 87=[1387], 73=[1373], 90=[1390], 77=[1377], 
> 94=[1394]}}
> [vm6] [debug 2018/04/11 16:47:35.753 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map {/ln_PARALLEL_GATEWAY_SENDER_QUEUE={49=[1449], 65=[1465], 
> 83=[1483], 53=[1453], 71=[1471], 87=[1487], *57=[1457]*, 73=[1473], 
> 77=[1477], 62=[1462]}}
>  shadowKey 1457 was created after the sender is restarted
>  
> [vm6] [debug 2018/04/11 16:47:35.438 PDT  GatewaySender_ln_0> tid=118] Sending (ParallelQueueRemovalMessage@2344969b 
> processorId=0 sender=10.118.19.25(27489):32781) to 3 peers 
> ([10.118.19.25(27492):32783@4(GEODE 1.6.0), 
> 10.118.19.25(27485):32779@1(GEODE 1.6.0), 
> 10.118.19.25(27482):32778@2(GEODE 1.6.0)]) via tcp/ip
> [vm7] [debug 2018/04/11 16:47:35.439 PDT  10.118.19.25(27489):32781 shared unordered uid=4 port=59119> tid=52] 
> Received message 'ParallelQueueRemovalMessage@11583f5b processorId=0 
> sender=10.118.19.25(27489):32781' from <10.118.19.25(27489):32781>
>  
> i.e. the dropped key was in the map, but before sending a QueueRemovalMessage 
> the sender is closed and cleared the map. 



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

[jira] [Updated] (GEODE-5056) ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2 intermittently fail

[ASF GitHub Bot (JIRA)]

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

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

> ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
>  intermittently fail 
> ---
>
> Key: GEODE-5056
> URL: https://issues.apache.org/jira/browse/GEODE-5056
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>  Labels: pull-request-available
>
> After fixe GEODE-4942, I found there's at least one race condition is not 
> covered. 
>  
> [vm6] [debug 2018/04/11 16:47:35.189 PDT  Processor2> tid=110] WAN: On primary bucket 57, setting the seq number as 1357
>  
> [vm7] [info 2018/04/11 16:47:35.150 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
>  
> [vm7] [debug 2018/04/11 16:47:35.189 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] WAN: 
> On secondary bucket 57, setting the seq number as 1357
> [vm7] [debug 2018/04/11 16:47:35.190 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] Key : 
> > 1357
> [vm6] [debug 2018/04/11 16:47:35.190 PDT  Processor2> tid=110] register dropped event for primary queue. BucketId is 
> 57, shadowKey is 1357, prQ is /ln_PARALLEL_GATEWAY_SENDER_QUEUE
>  
> - Note: vm6's sender is restarted and cleanup the map, before the
> QueueRemvalMessage is sent out for the map.
> [vm6] [info 2018/04/11 16:47:35.249 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
> [vm6] [debug 2018/04/11 16:47:35.437 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map \{/ln_PARALLEL_GATEWAY_SENDER_QUEUE={96=[1396], 2=[1402], 
> 83=[1383], 6=[1406], 71=[1371], 87=[1387], 73=[1373], 90=[1390], 77=[1377], 
> 94=[1394]}}
> [vm6] [debug 2018/04/11 16:47:35.753 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map {/ln_PARALLEL_GATEWAY_SENDER_QUEUE={49=[1449], 65=[1465], 
> 83=[1483], 53=[1453], 71=[1471], 87=[1487], *57=[1457]*, 73=[1473], 
> 77=[1477], 62=[1462]}}
>  shadowKey 1457 was created after the sender is restarted
>  
> [vm6] [debug 2018/04/11 16:47:35.438 PDT  GatewaySender_ln_0> tid=118] Sending (ParallelQueueRemovalMessage@2344969b 
> processorId=0 sender=10.118.19.25(27489):32781) to 3 peers 
> ([10.118.19.25(27492):32783@4(GEODE 1.6.0), 
> 10.118.19.25(27485):32779@1(GEODE 1.6.0), 
> 10.118.19.25(27482):32778@2(GEODE 1.6.0)]) via tcp/ip
> [vm7] [debug 2018/04/11 16:47:35.439 PDT  10.118.19.25(27489):32781 shared unordered uid=4 port=59119> tid=52] 
> Received message 'ParallelQueueRemovalMessage@11583f5b processorId=0 
> sender=10.118.19.25(27489):32781' from <10.118.19.25(27489):32781>
>  
> i.e. the dropped key was in the map, but before sending a QueueRemovalMessage 
> the sender is closed and cleared the map. 



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

[jira] [Commented] (GEODE-5044) Protobuf server does not log full stacktrace of failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5044:


Commit 757e8f915b4fc7c6c3d637426c7015b9ade486f2 in geode's branch 
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=757e8f9 ]

GEODE-5044: Correctly log stack trace on the protobuf server

We were just logging the exception message, not the stack trace.


> Protobuf server does not log full stacktrace of failures
> 
>
> Key: GEODE-5044
> URL: https://issues.apache.org/jira/browse/GEODE-5044
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Dan Smith
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> While doing some testing, we noticed that the protobuf server was not logging 
> the stacktrace of some failures, which makes debugging difficult.
> Looking at the code, it looks like we were trying to log the exception as a 
> separate log line. But in this case the exception just gets turned into a 
> string
> {code:java}
> logger.error("Invalid execution context found for operation {}", requestType);
> logger.error(exception); //This just prints the toString of the exception
> {code}
> Instead, we should be logging the exception and message as a single line
> {code:java}
> logger.error("Invalid execution context found for operation {}", requestType, 
> exception);
> {code}



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

[jira] [Resolved] (GEODE-5044) Protobuf server does not log full stacktrace of failures

[Dan Smith (JIRA)]

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

Dan Smith resolved GEODE-5044.
--
   Resolution: Fixed
Fix Version/s: 1.7.0

> Protobuf server does not log full stacktrace of failures
> 
>
> Key: GEODE-5044
> URL: https://issues.apache.org/jira/browse/GEODE-5044
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Dan Smith
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While doing some testing, we noticed that the protobuf server was not logging 
> the stacktrace of some failures, which makes debugging difficult.
> Looking at the code, it looks like we were trying to log the exception as a 
> separate log line. But in this case the exception just gets turned into a 
> string
> {code:java}
> logger.error("Invalid execution context found for operation {}", requestType);
> logger.error(exception); //This just prints the toString of the exception
> {code}
> Instead, we should be logging the exception and message as a single line
> {code:java}
> logger.error("Invalid execution context found for operation {}", requestType, 
> exception);
> {code}



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

[jira] [Commented] (GEODE-4962) Fix typo and output format from 'list gateways' gfsh command

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4962:


Commit 3468fb5e5041bfd2a9aaa44de14873ba76b508f5 in geode's branch 
refs/heads/feature/GEODE-5057 from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3468fb5 ]

GEODE-4962: Fix typo and output format from 'list gateways' gfsh command (#1778)



> Fix typo and output format from 'list gateways' gfsh command
> 
>
> Key: GEODE-4962
> URL: https://issues.apache.org/jira/browse/GEODE-4962
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, wan
>Reporter: Diane Hardman
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The output printed from `list gateways` command needs some TLC:
> Sample output:
> {noformat}
> Cluster-2 gfsh>list gateways
> Gateways
> GatewaySender
> GatewaySender Id |                  Member                  | Remote Cluster 
> Id |   Type   | Status  | Queued Events | Receiver Location
>  |  | 
> - |  | --- | - | -
> ny               | 10.118.19.46(server-ln-1:31527):1026 | 1               
>   | Parallel | Running | 0             | 10.118.19.46:5248
> ny               | 10.118.19.46(server-ln-2:31545):1027 | 1               
>   | Parallel | Running | 0             | 10.118.19.46:5269
> GatewayReceiver
>                   Member                  | Port | Sender Count | Sender's 
> Connected
>  |  |  | 
> 
> 10.118.19.46(server-ln-1:31527):1026 | 5407 | 7            | 
> [Ljava.lang.String;@7deec2d6
> 10.118.19.46(server-ln-2:31545):1027 | 5071 | 7            | 
> [Ljava.lang.String;@6baa580f
> {noformat}
> Note: 'Sender's Connected' should instead be 'Senders Connected'
> Also, need to pretty-print the String[] for Senders Connected.



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

[jira] [Commented] (GEODE-4952) Improve spotless -- automatically remove unused imports.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4952:


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

GEODE-4952: Remove usused imports from non-geode-core files. (#1724)



> Improve spotless -- automatically remove unused imports.
> 
>
> Key: GEODE-4952
> URL: https://issues.apache.org/jira/browse/GEODE-4952
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 3h
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (GEODE-4952) Improve spotless -- automatically remove unused imports.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4952:


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

GEODE-4952: Remove unused imports from geode-core, excluding 
geode-core:internal. (#1726)



> Improve spotless -- automatically remove unused imports.
> 
>
> Key: GEODE-4952
> URL: https://issues.apache.org/jira/browse/GEODE-4952
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 3h
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (GEODE-4952) Improve spotless -- automatically remove unused imports.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4952:


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

GEODE-4952: Remove unused imports from geode-core:internal. (#1725)



> Improve spotless -- automatically remove unused imports.
> 
>
> Key: GEODE-4952
> URL: https://issues.apache.org/jira/browse/GEODE-4952
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 3h
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (GEODE-5065) DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5065:


Commit 46ee1c8939e4874cd34f75352eb359074c6587d7 in geode's branch 
refs/heads/feature/GEODE-5057 from [~WireBaron]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=46ee1c8 ]

GEODE-5065: Add awaitability to testServerUpFirstClientLater (#1792)



> DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky
> 
>
> Key: GEODE-5065
> URL: https://issues.apache.org/jira/browse/GEODE-5065
> Project: Geode
>  Issue Type: Bug
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Test tests that value set on server is propagated to client, but doesn't wait 
> for queue to be processed.



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

[jira] [Commented] (GEODE-5051) Improve gfsh destroy jndi-binding help prose

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5051:


Commit e6c712691fc6ef5a11a3dda3e15d6335ae41bfd3 in geode's branch 
refs/heads/feature/GEODE-5057 from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e6c7126 ]

GEODE-5051: Improve gfsh destroy jndi-binding help prose (#1775)



> Improve gfsh destroy jndi-binding help prose
> 
>
> Key: GEODE-5051
> URL: https://issues.apache.org/jira/browse/GEODE-5051
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Karen Smoler Miller
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The current help text output for gfsh destroy jndi-binding contains some 
> errors:
>  gfsh>help destroy jndi-binding
> NAME
> destroy jndi-binding
> IS AVAILABLE
> false
> SYNOPSIS
> Destroy a jndi binding that holds the configuration for the XA datasource.
> SYNTAX
> destroy jndi-binding --name=value [--if-exists(=value)?]
> PARAMETERS
> name
> Name of the binding to be destroyed.
> Required: true
> if-exists
> Skip the destroy operation when a jndi binding with the same name does
> not exists. Without specifying this option, this command execution
> results into an error.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
> We can improve this text by changing the underlined prose to:
> gfsh>help destroy jndi-binding
> NAME
> destroy jndi-binding
> IS AVAILABLE
> false
> SYNOPSIS
> Destroy a +JNDI+ binding that holds the configuration for +an+ XA 
> datasource.
> SYNTAX
> destroy jndi-binding --name=value [--if-exists(=value)?]
> PARAMETERS
> name
> Name of the binding to be destroyed.
> Required: true
> if-exists
> +Skip the destroy operation when the specified JNDI binding does+
> +not exist. Without this option, an error results from the 
> specification+
> +of a JNDI binding that does not exist.+
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
>  



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

[jira] [Commented] (GEODE-5051) Improve gfsh destroy jndi-binding help prose

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5051:


Commit e6c712691fc6ef5a11a3dda3e15d6335ae41bfd3 in geode's branch 
refs/heads/develop from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e6c7126 ]

GEODE-5051: Improve gfsh destroy jndi-binding help prose (#1775)



> Improve gfsh destroy jndi-binding help prose
> 
>
> Key: GEODE-5051
> URL: https://issues.apache.org/jira/browse/GEODE-5051
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Karen Smoler Miller
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The current help text output for gfsh destroy jndi-binding contains some 
> errors:
>  gfsh>help destroy jndi-binding
> NAME
> destroy jndi-binding
> IS AVAILABLE
> false
> SYNOPSIS
> Destroy a jndi binding that holds the configuration for the XA datasource.
> SYNTAX
> destroy jndi-binding --name=value [--if-exists(=value)?]
> PARAMETERS
> name
> Name of the binding to be destroyed.
> Required: true
> if-exists
> Skip the destroy operation when a jndi binding with the same name does
> not exists. Without specifying this option, this command execution
> results into an error.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
> We can improve this text by changing the underlined prose to:
> gfsh>help destroy jndi-binding
> NAME
> destroy jndi-binding
> IS AVAILABLE
> false
> SYNOPSIS
> Destroy a +JNDI+ binding that holds the configuration for +an+ XA 
> datasource.
> SYNTAX
> destroy jndi-binding --name=value [--if-exists(=value)?]
> PARAMETERS
> name
> Name of the binding to be destroyed.
> Required: true
> if-exists
> +Skip the destroy operation when the specified JNDI binding does+
> +not exist. Without this option, an error results from the 
> specification+
> +of a JNDI binding that does not exist.+
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
>  



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

[jira] [Created] (GEODE-5066) Race condition between stats init and cache close causes memory access exception

[Ryan McMahon (JIRA)]

Ryan McMahon created GEODE-5066:
---

 Summary: Race condition between stats init and cache close causes 
memory access exception
 Key: GEODE-5066
 URL: https://issues.apache.org/jira/browse/GEODE-5066
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Ryan McMahon


The cache can be accessed by the statistics manager thread after the cache has 
been destroyed, which results in a memory access exception.  A quick fix is to 
directly use the cacheImpl in the stats manager initialization logic, though 
this object may be partially destroyed and potentially run into a similar issue.



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

[jira] [Commented] (GEODE-4952) Improve spotless -- automatically remove unused imports.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4952:


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

GEODE-4952: Remove unused imports from geode-core, excluding 
geode-core:internal. (#1726)



> Improve spotless -- automatically remove unused imports.
> 
>
> Key: GEODE-4952
> URL: https://issues.apache.org/jira/browse/GEODE-4952
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (GEODE-4952) Improve spotless -- automatically remove unused imports.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4952:


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

GEODE-4952: Remove unused imports from geode-core:internal. (#1725)



> Improve spotless -- automatically remove unused imports.
> 
>
> Key: GEODE-4952
> URL: https://issues.apache.org/jira/browse/GEODE-4952
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (GEODE-4952) Improve spotless -- automatically remove unused imports.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4952:


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

GEODE-4952: Remove usused imports from non-geode-core files. (#1724)



> Improve spotless -- automatically remove unused imports.
> 
>
> Key: GEODE-4952
> URL: https://issues.apache.org/jira/browse/GEODE-4952
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>




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

[jira] [Resolved] (GEODE-5065) DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky

[Brian Rowe (JIRA)]

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

Brian Rowe resolved GEODE-5065.
---
   Resolution: Fixed
Fix Version/s: 1.5.0

> DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky
> 
>
> Key: GEODE-5065
> URL: https://issues.apache.org/jira/browse/GEODE-5065
> Project: Geode
>  Issue Type: Bug
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.5.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Test tests that value set on server is propagated to client, but doesn't wait 
> for queue to be processed.



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

[jira] [Commented] (GEODE-5065) DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5065:


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

GEODE-5065: Add awaitability to testServerUpFirstClientLater (#1792)



> DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky
> 
>
> Key: GEODE-5065
> URL: https://issues.apache.org/jira/browse/GEODE-5065
> Project: Geode
>  Issue Type: Bug
>Reporter: Brian Rowe
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Test tests that value set on server is propagated to client, but doesn't wait 
> for queue to be processed.



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

[jira] [Assigned] (GEODE-5065) DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky

[Brian Rowe (JIRA)]

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

Brian Rowe reassigned GEODE-5065:
-

Assignee: Brian Rowe

> DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky
> 
>
> Key: GEODE-5065
> URL: https://issues.apache.org/jira/browse/GEODE-5065
> Project: Geode
>  Issue Type: Bug
>Reporter: Brian Rowe
>Assignee: Brian Rowe
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Test tests that value set on server is propagated to client, but doesn't wait 
> for queue to be processed.



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

[jira] [Updated] (GEODE-5065) DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky

[ASF GitHub Bot (JIRA)]

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

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

> DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky
> 
>
> Key: GEODE-5065
> URL: https://issues.apache.org/jira/browse/GEODE-5065
> Project: Geode
>  Issue Type: Bug
>Reporter: Brian Rowe
>Priority: Major
>  Labels: pull-request-available
>
> Test tests that value set on server is propagated to client, but doesn't wait 
> for queue to be processed.



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

[jira] [Commented] (GEODE-4874) Inconsistency in gfsh help for create jndi-binding

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4874:


Commit 34fdc32099d9c449bf67a37067158777847d0d8f in geode's branch 
refs/heads/develop from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=34fdc32 ]

GEODE-4874: Inconsistency in gfsh help for create jndi-binding (#1777)



> Inconsistency in gfsh help for create jndi-binding 
> ---
>
> Key: GEODE-4874
> URL: https://issues.apache.org/jira/browse/GEODE-4874
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.5.0
>Reporter: Karen Smoler Miller
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I see an error and an inconsistency when trying to use the gfsh help 
> functionality for create jndi-binding.
> Tab completion of
> create jndi-binding
> outputs
>  gfsh>create jndi-binding –
>  create jndi-binding --connection-url
>  create jndi-binding --jdbc-driver-class
>  create jndi-binding --name
>  create jndi-binding --type
> This is inconsistent with the output of other tab completions, which just 
> give the options, and do not repeat the "create jndi-binding" portion of the 
> command.
>  



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

[jira] [Commented] (GEODE-4962) Fix typo and output format from 'list gateways' gfsh command

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4962:


Commit 3468fb5e5041bfd2a9aaa44de14873ba76b508f5 in geode's branch 
refs/heads/develop from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3468fb5 ]

GEODE-4962: Fix typo and output format from 'list gateways' gfsh command (#1778)



> Fix typo and output format from 'list gateways' gfsh command
> 
>
> Key: GEODE-4962
> URL: https://issues.apache.org/jira/browse/GEODE-4962
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, wan
>Reporter: Diane Hardman
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The output printed from `list gateways` command needs some TLC:
> Sample output:
> {noformat}
> Cluster-2 gfsh>list gateways
> Gateways
> GatewaySender
> GatewaySender Id |                  Member                  | Remote Cluster 
> Id |   Type   | Status  | Queued Events | Receiver Location
>  |  | 
> - |  | --- | - | -
> ny               | 10.118.19.46(server-ln-1:31527):1026 | 1               
>   | Parallel | Running | 0             | 10.118.19.46:5248
> ny               | 10.118.19.46(server-ln-2:31545):1027 | 1               
>   | Parallel | Running | 0             | 10.118.19.46:5269
> GatewayReceiver
>                   Member                  | Port | Sender Count | Sender's 
> Connected
>  |  |  | 
> 
> 10.118.19.46(server-ln-1:31527):1026 | 5407 | 7            | 
> [Ljava.lang.String;@7deec2d6
> 10.118.19.46(server-ln-2:31545):1027 | 5071 | 7            | 
> [Ljava.lang.String;@6baa580f
> {noformat}
> Note: 'Sender's Connected' should instead be 'Senders Connected'
> Also, need to pretty-print the String[] for Senders Connected.



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

[jira] [Created] (GEODE-5065) DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky

[Brian Rowe (JIRA)]

Brian Rowe created GEODE-5065:
-

 Summary: 
DataSerializerPropagationDUnitTest.testServerUpFirstClientLater is flaky
 Key: GEODE-5065
 URL: https://issues.apache.org/jira/browse/GEODE-5065
 Project: Geode
  Issue Type: Bug
Reporter: Brian Rowe


Test tests that value set on server is propagated to client, but doesn't wait 
for queue to be processed.



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

[jira] [Commented] (GEODE-5055) CI failure: LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion

[Jason Huynh (JIRA)]

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

Jason Huynh commented on GEODE-5055:


As part of this fix, we need a set of rolling upgrade tests that enable the 
reindex feature.  This exception only occurs now when the feature flag is 
enabled

> CI failure: 
> LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion
> -
>
> Key: GEODE-5055
> URL: https://issues.apache.org/jira/browse/GEODE-5055
> Project: Geode
>  Issue Type: Sub-task
>  Components: lucene
>Reporter: Jason Huynh
>Priority: Major
>
> This is related to changes for GEODE-3926.  The roll is occuring but because 
> we added the new complete file, the new server is probably "reindexing" at 
> the moment. 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit > 
> luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion[from_v140]
>  FAILED
>  org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit$$Lambda$27/1996438298.run
>  in VM 0 running on Host eada542bc38a with 4 VMs
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResultInEachVM(LuceneSearchWithRollingUpgradeDUnit.java:678)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.executeLuceneQueryWithServerRollOvers(LuceneSearchWithRollingUpgradeDUnit.java:572)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion(LuceneSearchWithRollingUpgradeDUnit.java:134)
> Caused by:
>  java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:661)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.lambda$verifyLuceneQueryResultInEachVM$b83f705c$2(LuceneSearchWithRollingUpgradeDUnit.java:678)
> Caused by:
>  
> org.apache.geode.cache.lucene.internal.LuceneIndexCreationInProgressException:
>  Lucene Index creation in progress for bucket: 1



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

[jira] [Updated] (GEODE-4856) Public API for retrieving/persisting Cluster Configuration

[ASF GitHub Bot (JIRA)]

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

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

> Public API for retrieving/persisting Cluster Configuration
> --
>
> Key: GEODE-4856
> URL: https://issues.apache.org/jira/browse/GEODE-4856
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available
>
> Public API for Cluster Configuration Service: 
> https://cwiki.apache.org/confluence/display/GEODE/Public+API+for+Cluster+Configuration
>  Add @experimental to all the public apis we exposed for this story.
>  



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

[jira] [Updated] (GEODE-5055) CI failure: LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-5055:
---
Issue Type: Sub-task  (was: Bug)
Parent: GEODE-3924

> CI failure: 
> LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion
> -
>
> Key: GEODE-5055
> URL: https://issues.apache.org/jira/browse/GEODE-5055
> Project: Geode
>  Issue Type: Sub-task
>  Components: lucene
>Reporter: Jason Huynh
>Priority: Major
>
> This is related to changes for GEODE-3926.  The roll is occuring but because 
> we added the new complete file, the new server is probably "reindexing" at 
> the moment. 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit > 
> luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion[from_v140]
>  FAILED
>  org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit$$Lambda$27/1996438298.run
>  in VM 0 running on Host eada542bc38a with 4 VMs
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResultInEachVM(LuceneSearchWithRollingUpgradeDUnit.java:678)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.executeLuceneQueryWithServerRollOvers(LuceneSearchWithRollingUpgradeDUnit.java:572)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion(LuceneSearchWithRollingUpgradeDUnit.java:134)
> Caused by:
>  java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:661)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.lambda$verifyLuceneQueryResultInEachVM$b83f705c$2(LuceneSearchWithRollingUpgradeDUnit.java:678)
> Caused by:
>  
> org.apache.geode.cache.lucene.internal.LuceneIndexCreationInProgressException:
>  Lucene Index creation in progress for bucket: 1



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

[jira] [Resolved] (GEODE-3926) Lucene Query should throw an exception while lucene index is being built on existing region

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-3926.

Resolution: Fixed

> Lucene Query should throw an exception while lucene index is being built on 
> existing region
> ---
>
> Key: GEODE-3926
> URL: https://issues.apache.org/jira/browse/GEODE-3926
> Project: Geode
>  Issue Type: Sub-task
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Udo Kohlmeyer
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> When GEODE-3928 is complete, we will have a process to index existing data in 
> a region when a lucene index is added. That process may take some time. While 
> indexing is going on queries should not block for a long period of time or 
> return incorrect results. Instead the query should throw an exception 
> indicating that the index does not exist/is not built yet.
> Acceptance:
> Queries executed while indexing is going on throw an exception, rather than 
> blocking or returning incorrect results.
> Implementation Details:
> GEODE-3928 is about modifying computeRepository to actually do the indexing. 
> Queries also call compute repository, so they will block until 
> computeRepository is done.
> To avoid blocking, we can make  computeRepo to return an IndexRepository in 
> an "building" state. That index repo could contain an asynchronous task that 
> is actually indexing the data. Until the asynchronous task is complete, the 
> IndexRepostory could throw exceptions from query operations. This has the 
> advantage of making sure that whenever computeRepository is called, we always 
> at least start or make sure there is a task running to index the data.



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

[jira] [Updated] (GEODE-5064) Remove unused code and if clause that does not get thrown

[ASF GitHub Bot (JIRA)]

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

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

> Remove unused code and if clause that does not get thrown
> -
>
> Key: GEODE-5064
> URL: https://issues.apache.org/jira/browse/GEODE-5064
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>Priority: Major
>  Labels: pull-request-available
>
> There appears to be an exception that should be thrown, but upon futher 
> inspection, this clause can never be hit because the boolean it checks is 
> never set to true;
>  
> In LocalRegion:
> logger.info("Failed to create index {} on region {} with exception: {}",
>  icd.getIndexName(), this.getFullPath(), ex);
> // Check if the region index creation is from cache.xml, in that case throw 
> exception.
> // Other case is when bucket regions are created dynamically, in that case 
> ignore the
> // exception.
> if (internalRegionArgs.getDeclarativeIndexCreation()) {
>  throw new 
> InternalGemFireError(LocalizedStrings.GemFireCache_INDEX_CREATION_EXCEPTION_1
>  .toLocalizedString(icd.getIndexName(), this.getFullPath()), ex);
> }



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

[jira] [Updated] (GEODE-5064) Remove unused code and if clause that does not get thrown

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-5064:
---
Description: 
There appears to be an exception that should be thrown, but upon futher 
inspection, this clause can never be hit because the boolean it checks is never 
set to true;

 

In LocalRegion:

logger.info("Failed to create index {} on region {} with exception: {}",
 icd.getIndexName(), this.getFullPath(), ex);

// Check if the region index creation is from cache.xml, in that case throw 
exception.
// Other case is when bucket regions are created dynamically, in that case 
ignore the
// exception.
if (internalRegionArgs.getDeclarativeIndexCreation()) {
 throw new 
InternalGemFireError(LocalizedStrings.GemFireCache_INDEX_CREATION_EXCEPTION_1
 .toLocalizedString(icd.getIndexName(), this.getFullPath()), ex);
}

  was:There appears to be an exception that should be thrown, but upon futher 
inspection, this clause can never be hit because the boolean it checks is never 
set to true;


> Remove unused code and if clause that does not get thrown
> -
>
> Key: GEODE-5064
> URL: https://issues.apache.org/jira/browse/GEODE-5064
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>Priority: Major
>
> There appears to be an exception that should be thrown, but upon futher 
> inspection, this clause can never be hit because the boolean it checks is 
> never set to true;
>  
> In LocalRegion:
> logger.info("Failed to create index {} on region {} with exception: {}",
>  icd.getIndexName(), this.getFullPath(), ex);
> // Check if the region index creation is from cache.xml, in that case throw 
> exception.
> // Other case is when bucket regions are created dynamically, in that case 
> ignore the
> // exception.
> if (internalRegionArgs.getDeclarativeIndexCreation()) {
>  throw new 
> InternalGemFireError(LocalizedStrings.GemFireCache_INDEX_CREATION_EXCEPTION_1
>  .toLocalizedString(icd.getIndexName(), this.getFullPath()), ex);
> }



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

[jira] [Created] (GEODE-5064) Remove unused code and if clause that does not get thrown

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-5064:
--

 Summary: Remove unused code and if clause that does not get thrown
 Key: GEODE-5064
 URL: https://issues.apache.org/jira/browse/GEODE-5064
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: Jason Huynh


There appears to be an exception that should be thrown, but upon futher 
inspection, this clause can never be hit because the boolean it checks is never 
set to true;



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

[jira] [Assigned] (GEODE-5064) Remove unused code and if clause that does not get thrown

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-5064:
--

Assignee: Jason Huynh

> Remove unused code and if clause that does not get thrown
> -
>
> Key: GEODE-5064
> URL: https://issues.apache.org/jira/browse/GEODE-5064
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>Priority: Major
>
> There appears to be an exception that should be thrown, but upon futher 
> inspection, this clause can never be hit because the boolean it checks is 
> never set to true;



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

[jira] [Created] (GEODE-5063) AbstractRegionMap.basicPut may get old value more than once

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-5063:
---

 Summary: AbstractRegionMap.basicPut may get old value more than 
once
 Key: GEODE-5063
 URL: https://issues.apache.org/jira/browse/GEODE-5063
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


AbstractRegionMap.doPutOnRegionEntry calls both of the following:

      setOldValueForDelta(putInfo);

      setOldValueInEvent(putInfo);

I think the logic in setOldValueForDelta can be moved into setOldValueInEvent.

As it is now we might fetch the old value twice when using delta.

 



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

[jira] [Created] (GEODE-5062) AbstractRegionMap.basicPut does not use lastModified parameter

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-5062:
---

 Summary: AbstractRegionMap.basicPut does not use lastModified 
parameter
 Key: GEODE-5062
 URL: https://issues.apache.org/jira/browse/GEODE-5062
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


The callers of AbstractRegionMap.basicPut do lots of work to pass the 
lastModifiedTime to it.

Most, if not all callers, seems to set the lastModifiedTime parameter to zero. 
If none of them ever set it to a non-zero value then the parameter should be 
removed.

basicPut itself does not pass the parameter on to LocalRegion.basicPutPart2. So 
it never uses the parameter. If we do have callers with non-zero then basicPut 
needs to pass the parameter to basicPutPart2. If we don't then we should 
simplify the code by removing the parameter.

 



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

[jira] [Commented] (GEODE-5053) Import and export should be supported with full cluster running

[Barbara Pruijn (JIRA)]

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

Barbara Pruijn commented on GEODE-5053:
---

The precondition of the use of this -force option is that you have exported 
your configuration and data (the configuration matches the data that you have 
exported). And then when you do a force import, the configuration and data that 
you import are in synch.

This is an advanced option, not meant for the beginner.

Maybe we should add a reaffirming question: "Are you sure? Your configuration 
needs to be consistent with the data that you will import. Y/n".

When this option is run in a script, you should know what you are doing.

> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have 
> the ability to just run locators and not servers as we use BOSH to manage 
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like 
> to ensure I can back it up. Use cases range from ensuring your data doesnt 
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full 
> cluster would be running before import is called. We can do rolling restart, 
> if that is needed.
>  
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893



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

[jira] [Commented] (GEODE-5053) Import and export should be supported with full cluster running

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-5053:
--

If you override an existing configuration, what happens to the data structures 
associated with the overwritten configuration (eg regions, gateway sender, etc)?

> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have 
> the ability to just run locators and not servers as we use BOSH to manage 
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like 
> to ensure I can back it up. Use cases range from ensuring your data doesnt 
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full 
> cluster would be running before import is called. We can do rolling restart, 
> if that is needed.
>  
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893



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

[jira] [Comment Edited] (GEODE-5053) Import and export should be supported with full cluster running

[Barbara Pruijn (JIRA)]

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

Barbara Pruijn edited comment on GEODE-5053 at 4/12/18 9:09 PM:


Since there is a use case where specific configuration gets added to the 
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration 
when importing a preferred configuration.

The proposal is to add the option -force: 
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster 
will be replaced with the configuration provided in the import command.

--force is not provided by default (and is false) and the default value if 
provided is true.


was (Author: bpruijn):
Since there is a use case where specific configuration gets added to the 
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration 
when importing a preferred configuration.

The proposal is to add the option -force: 
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster 
will be replaced with the configuration provided in the import command.

--force is not provided by default and the default value if provided is false.

> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have 
> the ability to just run locators and not servers as we use BOSH to manage 
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like 
> to ensure I can back it up. Use cases range from ensuring your data doesnt 
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full 
> cluster would be running before import is called. We can do rolling restart, 
> if that is needed.
>  
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893



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

[jira] [Comment Edited] (GEODE-5053) Import and export should be supported with full cluster running

[Barbara Pruijn (JIRA)]

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

Barbara Pruijn edited comment on GEODE-5053 at 4/12/18 9:07 PM:


Since there is a use case where specific configuration gets added to the 
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration 
when importing a preferred configuration.

The proposal is to add the option -force: 
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster 
will be replaced with the configuration provided in the import command.

--force is not provided by default and the default value if provided is false.


was (Author: bpruijn):
Since there is a use case where specific configuration gets added to the 
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration 
when importing a preferred configuration.

The proposal is to add the option -force: 
{code:java}
import cluster-configuration --force{code}

The behavior of the -force is that any existing configuration on the cluster 
will be replaced with the configuration provided in the import command.

> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have 
> the ability to just run locators and not servers as we use BOSH to manage 
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like 
> to ensure I can back it up. Use cases range from ensuring your data doesnt 
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full 
> cluster would be running before import is called. We can do rolling restart, 
> if that is needed.
>  
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893



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

[jira] [Commented] (GEODE-5053) Import and export should be supported with full cluster running

[Barbara Pruijn (JIRA)]

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

Barbara Pruijn commented on GEODE-5053:
---

Since there is a use case where specific configuration gets added to the 
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration 
when importing a preferred configuration.

The proposal is to add the option -force: 
{code:java}
import cluster-configuration --force{code}

The behavior of the -force is that any existing configuration on the cluster 
will be replaced with the configuration provided in the import command.

> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have 
> the ability to just run locators and not servers as we use BOSH to manage 
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like 
> to ensure I can back it up. Use cases range from ensuring your data doesnt 
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full 
> cluster would be running before import is called. We can do rolling restart, 
> if that is needed.
>  
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893



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

[jira] [Updated] (GEODE-5057) Remove 'experimental' from JDBC Connector code

[ASF GitHub Bot (JIRA)]

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

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

> Remove 'experimental' from JDBC Connector code
> --
>
> Key: GEODE-5057
> URL: https://issues.apache.org/jira/browse/GEODE-5057
> Project: Geode
>  Issue Type: Task
>  Components: extensions, regions
>Affects Versions: 1.6.0
>Reporter: Anilkumar Gingade
>Priority: Major
>  Labels: pull-request-available
>
> Remove 'experimental' from JDBC Connector code.



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

[jira] [Updated] (GEODE-5061) Lucene queries can be executed on an accessor which causes the system to go into stack overflow

[nabarun (JIRA)]

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

nabarun updated GEODE-5061:
---
Summary: Lucene queries can be executed on an accessor which causes the 
system to go into stack overflow  (was: Lucene queries cannot be executed on an 
accessor)

> Lucene queries can be executed on an accessor which causes the system to go 
> into stack overflow
> ---
>
> Key: GEODE-5061
> URL: https://issues.apache.org/jira/browse/GEODE-5061
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Priority: Major
>
> h2. Current:
> An Apache Geode user can execute a Lucene query on an accessor without ever 
> creating a Lucene index. This should not be allowed but it is and it causes a 
> stack overflow when we execute a Lucene query from the accessor. This can be 
> observed in the below test case.
>  
> {code:java}
> public void asynchronousLuceneIndexCreationWithDifferentFieldsMustFail(
>  RegionTestableType regionTestType) throws Exception {
>  SerializableRunnableIF createIndex = () -> {
>  LuceneService luceneService = LuceneServiceProvider.get(getCache());
>  luceneService.createIndexFactory().addField("text").create(INDEX_NAME, 
> REGION_NAME);
>  };
>  dataStore1.invoke(() -> initDataStore(createIndex, regionTestType));
>  dataStore2.invoke(() -> initDataStore(createIndex, regionTestType));
>  accessor.invoke(() -> initAccessor(createIndex, regionTestType));
>  putDataInRegion(accessor);
>  assertTrue(waitForFlushBeforeExecuteTextSearch(accessor, 6));
>  assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));
>  executeTextSearch(accessor);
>  dataStore1.invoke(() -> destroyIndex());
>  // re-index stored data
>  AsyncInvocation ai1 = dataStore1.invokeAsync(() -> {
>  recreateIndex();
>  });
>  
>  dataStore2.invoke(() -> closeCache());
>  ai1.join();
>  aia.join();
>  assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));
>  ai1.checkException();
>  putAllDataIntoRegion(accessor);
>  executeTextSearch(accessor);
> }{code}
>  
> However we can see that the issue is resolved when the accessor creates the 
> Lucene Index. 
> This can be seen in the below test case.
>  
> {code:java}
> public void asynchronousLuceneIndexCreationWithDifferentFieldsMustFail(
>  RegionTestableType regionTestType) throws Exception {
>  SerializableRunnableIF createIndex = () -> {
>  LuceneService luceneService = LuceneServiceProvider.get(getCache());
>  luceneService.createIndexFactory().addField("text").create(INDEX_NAME, 
> REGION_NAME);
>  };
>  dataStore1.invoke(() -> initDataStore(createIndex, regionTestType));
>  dataStore2.invoke(() -> initDataStore(createIndex, regionTestType));
>  accessor.invoke(() -> initAccessor(createIndex, regionTestType));
>  putDataInRegion(accessor);
>  assertTrue(waitForFlushBeforeExecuteTextSearch(accessor, 6));
>  assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));
>  executeTextSearch(accessor);
>  dataStore1.invoke(() -> destroyIndex());
>  // re-index stored data
>  AsyncInvocation ai1 = dataStore1.invokeAsync(() -> {
>  recreateIndex();
>  });
>  AsyncInvocation aia = accessor.invokeAsync(() -> {
>  recreateIndex();
>  });
>  dataStore2.invoke(() -> closeCache());
>  ai1.join();
>  aia.join();
>  assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));
>  ai1.checkException();
>  putAllDataIntoRegion(accessor);
>  executeTextSearch(accessor);
> }{code}
>  
>  
> h2. Solution:
>  
> Make sure that Lucene queries cannot be executed in the accessor if the 
> accessor has not created the Lucene index used in the query.
>  



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

[jira] [Created] (GEODE-5061) Lucene queries cannot be executed on an accessor

[nabarun (JIRA)]

nabarun created GEODE-5061:
--

 Summary: Lucene queries cannot be executed on an accessor
 Key: GEODE-5061
 URL: https://issues.apache.org/jira/browse/GEODE-5061
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: nabarun


h2. Current:

An Apache Geode user can execute a Lucene query on an accessor without ever 
creating a Lucene index. This should not be allowed but it is and it causes a 
stack overflow when we execute a Lucene query from the accessor. This can be 
observed in the below test case.

 
{code:java}
public void asynchronousLuceneIndexCreationWithDifferentFieldsMustFail(
 RegionTestableType regionTestType) throws Exception {
 SerializableRunnableIF createIndex = () -> {
 LuceneService luceneService = LuceneServiceProvider.get(getCache());
 luceneService.createIndexFactory().addField("text").create(INDEX_NAME, 
REGION_NAME);
 };
 dataStore1.invoke(() -> initDataStore(createIndex, regionTestType));
 dataStore2.invoke(() -> initDataStore(createIndex, regionTestType));
 accessor.invoke(() -> initAccessor(createIndex, regionTestType));

 putDataInRegion(accessor);
 assertTrue(waitForFlushBeforeExecuteTextSearch(accessor, 6));
 assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));
 executeTextSearch(accessor);

 dataStore1.invoke(() -> destroyIndex());

 // re-index stored data
 AsyncInvocation ai1 = dataStore1.invokeAsync(() -> {
 recreateIndex();
 });
 
 dataStore2.invoke(() -> closeCache());
 ai1.join();
 aia.join();
 assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));

 ai1.checkException();

 putAllDataIntoRegion(accessor);

 executeTextSearch(accessor);
}{code}
 

However we can see that the issue is resolved when the accessor creates the 
Lucene Index. 

This can be seen in the below test case.

 
{code:java}
public void asynchronousLuceneIndexCreationWithDifferentFieldsMustFail(
 RegionTestableType regionTestType) throws Exception {
 SerializableRunnableIF createIndex = () -> {
 LuceneService luceneService = LuceneServiceProvider.get(getCache());
 luceneService.createIndexFactory().addField("text").create(INDEX_NAME, 
REGION_NAME);
 };
 dataStore1.invoke(() -> initDataStore(createIndex, regionTestType));
 dataStore2.invoke(() -> initDataStore(createIndex, regionTestType));
 accessor.invoke(() -> initAccessor(createIndex, regionTestType));

 putDataInRegion(accessor);
 assertTrue(waitForFlushBeforeExecuteTextSearch(accessor, 6));
 assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));
 executeTextSearch(accessor);

 dataStore1.invoke(() -> destroyIndex());

 // re-index stored data
 AsyncInvocation ai1 = dataStore1.invokeAsync(() -> {
 recreateIndex();
 });
 AsyncInvocation aia = accessor.invokeAsync(() -> {
 recreateIndex();
 });

 dataStore2.invoke(() -> closeCache());
 ai1.join();
 aia.join();
 assertTrue(waitForFlushBeforeExecuteTextSearch(dataStore1, 6));

 ai1.checkException();

 putAllDataIntoRegion(accessor);

 executeTextSearch(accessor);
}{code}
 

 
h2. Solution:

 

Make sure that Lucene queries cannot be executed in the accessor if the 
accessor has not created the Lucene index used in the query.

 



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

[jira] [Updated] (GEODE-4954) Improve spotless -- remove trivial javadoc stubs

[ASF GitHub Bot (JIRA)]

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

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

> Improve spotless -- remove trivial javadoc stubs
> 
>
> Key: GEODE-4954
> URL: https://issues.apache.org/jira/browse/GEODE-4954
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
>  Labels: pull-request-available
>
> For instance, the block
> {noformat}
> @param myparam
> @param secondParam
> @throws Exception
> {noformat}
> is entirely implicit by the method's signature, which is included in the 
> javadoc itself.  Javadoc stubs that do not include description of a given 
> term is trivial, redundant, and should be removed.



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

[jira] [Resolved] (GEODE-4881) handle concurrent lucene indexing (after region created) with rebalance

[nabarun (JIRA)]

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

nabarun resolved GEODE-4881.

   Resolution: Fixed
Fix Version/s: 1.7.0

> handle concurrent lucene indexing (after region created) with rebalance
> ---
>
> Key: GEODE-4881
> URL: https://issues.apache.org/jira/browse/GEODE-4881
> Project: Geode
>  Issue Type: New Feature
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {noformat}
> While adding a Lucene index to a region with data, if a rebalance is 
> triggered during re-indexing, the index should complete successfully and 
> match the region data.
> If I add a Lucene index while a rebalance is in progress, the index should 
> successfully complete and match the region data. (*)
> (*) Note: It may be acceptable to detect a rebalance in progress before 
> starting and wait for it to finish before adding the Lucene index.
> {noformat}



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

[jira] [Closed] (GEODE-4881) handle concurrent lucene indexing (after region created) with rebalance

[nabarun (JIRA)]

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

nabarun closed GEODE-4881.
--

> handle concurrent lucene indexing (after region created) with rebalance
> ---
>
> Key: GEODE-4881
> URL: https://issues.apache.org/jira/browse/GEODE-4881
> Project: Geode
>  Issue Type: New Feature
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {noformat}
> While adding a Lucene index to a region with data, if a rebalance is 
> triggered during re-indexing, the index should complete successfully and 
> match the region data.
> If I add a Lucene index while a rebalance is in progress, the index should 
> successfully complete and match the region data. (*)
> (*) Note: It may be acceptable to detect a rebalance in progress before 
> starting and wait for it to finish before adding the Lucene index.
> {noformat}



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

[jira] [Reopened] (GEODE-4876) Add static VM APIs from Host to VM

[Kirk Lund (JIRA)]

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

Kirk Lund reopened GEODE-4876:
--

I missed one API on Host that needs to be added to VM:
{noformat}
public VM getVM(String version, int n);
{noformat}
This API is used by the backwards compatibility tests.

> Add static VM APIs from Host to VM
> --
>
> Key: GEODE-4876
> URL: https://issues.apache.org/jira/browse/GEODE-4876
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Trivial
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add getVM(int), getAllVMs(), getVMCount(), getLocator(), getHostName() to VM.
> Change tests that use DistributedTestRule to invoke methods on VM instead of 
> Host.



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

[jira] [Resolved] (GEODE-4919) Alter regions must update PRconfig

[nabarun (JIRA)]

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

nabarun resolved GEODE-4919.

   Resolution: Fixed
Fix Version/s: 1.7.0

> Alter regions must update PRconfig
> --
>
> Key: GEODE-4919
> URL: https://issues.apache.org/jira/browse/GEODE-4919
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Altering the region to add parallel gateway sender to non colocated regions 
> must fail.
> The check is done using the PartitionRegionConfig but we never update it 
> after altering the region to add the gateway sender.



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

[jira] [Closed] (GEODE-4919) Alter regions must update PRconfig

[nabarun (JIRA)]

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

nabarun closed GEODE-4919.
--

> Alter regions must update PRconfig
> --
>
> Key: GEODE-4919
> URL: https://issues.apache.org/jira/browse/GEODE-4919
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Altering the region to add parallel gateway sender to non colocated regions 
> must fail.
> The check is done using the PartitionRegionConfig but we never update it 
> after altering the region to add the gateway sender.



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

[jira] [Created] (GEODE-5060) DistributedDisconnectRule is redundant after improving DistributedTestRule TearDown

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-5060:


 Summary: DistributedDisconnectRule is redundant after improving 
DistributedTestRule TearDown
 Key: GEODE-5060
 URL: https://issues.apache.org/jira/browse/GEODE-5060
 Project: Geode
  Issue Type: Improvement
  Components: tests
Reporter: Kirk Lund


DistributedDisconnectRule is redundant after improving DistributedTestRule 
TearDown. Just delete DistributedDisconnectRule.



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

[jira] [Assigned] (GEODE-5060) DistributedDisconnectRule is redundant after improving DistributedTestRule TearDown

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-5060:


Assignee: Kirk Lund

> DistributedDisconnectRule is redundant after improving DistributedTestRule 
> TearDown
> ---
>
> Key: GEODE-5060
> URL: https://issues.apache.org/jira/browse/GEODE-5060
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> DistributedDisconnectRule is redundant after improving DistributedTestRule 
> TearDown. Just delete DistributedDisconnectRule.



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

[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'

[Barbara Pruijn (JIRA)]

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

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

> Re-instate Management REST API endpoints for 'create index' and 'create 
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.3.0, 1.4.0
>Reporter: John Blum
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: 1.5.0
>
> Attachments: ClusterConfigurationExampleIntegrationTests.java, 
> Customer.java, CustomerRepository.java
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper 
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in 
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache 
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC 
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache 
> Geode community refactored and [reduced the 
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
>  and by extension, the Web service endpoints to, mostly, a [single Web 
> service 
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
>  which essentially just accepts a _Gfsh_ command string, such as `{{create 
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with 
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as 
> measured against [Richardson Maturity 
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did 
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources 
> (e.g. Regions, Indexes, etc).  Additionally, it also used property Verbs to 
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the 
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia 
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for 
> _Gfsh_.  The initial purpose was to enable _Gfsh_ to connect to the Manager 
> via HTTP in order to transcend firewalls when a devops team wanted to manage 
> a remote cluster deployed in a cloud environment, such as AWS or GCP.  By 
> using HTTP over JMX/RMI, a user would not need to punch additional holes in 
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to 
> become a true REST API that can be consumed by any client (not just _Gfsh_): 
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#, 
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of 
> this design and actually took a step backwards.  The HTTP Verbs are not 
> properly used.  The Web service API endpoints are not resourceful, and 
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically, 
> speaking, guarding classes by putting them in an "internal" package is no 
> safe-guard or guarantee that could have been properly enforced using Java 
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only 
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an 
> "alternative" solution was properly introduced.



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

[jira] [Resolved] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'

[Barbara Pruijn (JIRA)]

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

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

> Re-instate Management REST API endpoints for 'create index' and 'create 
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.3.0, 1.4.0
>Reporter: John Blum
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: 1.5.0
>
> Attachments: ClusterConfigurationExampleIntegrationTests.java, 
> Customer.java, CustomerRepository.java
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper 
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in 
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache 
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC 
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache 
> Geode community refactored and [reduced the 
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
>  and by extension, the Web service endpoints to, mostly, a [single Web 
> service 
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
>  which essentially just accepts a _Gfsh_ command string, such as `{{create 
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with 
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as 
> measured against [Richardson Maturity 
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did 
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources 
> (e.g. Regions, Indexes, etc).  Additionally, it also used property Verbs to 
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the 
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia 
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for 
> _Gfsh_.  The initial purpose was to enable _Gfsh_ to connect to the Manager 
> via HTTP in order to transcend firewalls when a devops team wanted to manage 
> a remote cluster deployed in a cloud environment, such as AWS or GCP.  By 
> using HTTP over JMX/RMI, a user would not need to punch additional holes in 
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to 
> become a true REST API that can be consumed by any client (not just _Gfsh_): 
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#, 
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of 
> this design and actually took a step backwards.  The HTTP Verbs are not 
> properly used.  The Web service API endpoints are not resourceful, and 
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically, 
> speaking, guarding classes by putting them in an "internal" package is no 
> safe-guard or guarantee that could have been properly enforced using Java 
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only 
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an 
> "alternative" solution was properly introduced.



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

[jira] [Comment Edited] (GEODE-1422) CI Failure: ParallelGatewaySenderOperationsOffHeapDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda edited comment on GEODE-1422 at 4/12/18 7:47 PM:
-

Saw a failure similar to this on a precheckin.

 
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$81/79403770.run
 in VM 5 running on Host 37959746403d with 8 VMs
 at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
 at 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.validateParallelSenderQueueAllBucketsDrained(ParallelGatewaySenderOperationsDUnitTest.java:709)
 at 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2(ParallelGatewaySenderOperationsDUnitTest.java:443)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
 at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
 at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
 at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
 at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
 at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
 at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
 at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
 at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
 at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
 at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
 at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
 at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
 at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
 at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
 at 
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147)
 at 
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:129)
 at 

[jira] [Comment Edited] (GEODE-1422) CI Failure: ParallelGatewaySenderOperationsOffHeapDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda edited comment on GEODE-1422 at 4/12/18 7:47 PM:
-

Saw a failure similar to this on a precheckin in develop.

 
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$81/79403770.run
 in VM 5 running on Host 37959746403d with 8 VMs
 at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
 at 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.validateParallelSenderQueueAllBucketsDrained(ParallelGatewaySenderOperationsDUnitTest.java:709)
 at 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2(ParallelGatewaySenderOperationsDUnitTest.java:443)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
 at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
 at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
 at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
 at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
 at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
 at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
 at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
 at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
 at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
 at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
 at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
 at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
 at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
 at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
 at 
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147)
 at 
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:129)
 at 

[jira] [Commented] (GEODE-1422) CI Failure: ParallelGatewaySenderOperationsOffHeapDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda commented on GEODE-1422:


Saw a failure similar to this on a precheckin.

 
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$81/79403770.run
 in VM 5 running on Host 37959746403d with 8 VMs
 at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
 at 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.validateParallelSenderQueueAllBucketsDrained(ParallelGatewaySenderOperationsDUnitTest.java:709)
 at 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2(ParallelGatewaySenderOperationsDUnitTest.java:443)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
 at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
 at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
 at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
 at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
 at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
 at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
 at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
 at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
 at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
 at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
 at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
 at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
 at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
 at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
 at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
 at 
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147)
 at 
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:129)
 at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
 at 

[jira] [Resolved] (GEODE-4908) Environment variable $GFCPP is still used

[Michael Oleske (JIRA)]

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

Michael Oleske resolved GEODE-4908.
---
Resolution: Fixed

> Environment variable $GFCPP is still used
> -
>
> Key: GEODE-4908
> URL: https://issues.apache.org/jira/browse/GEODE-4908
> Project: Geode
>  Issue Type: Task
>  Components: docs, native client
>Reporter: Ryan McMahon
>Assignee: Michael Oleske
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> We need to change $GFCPP to $GEODE_NATIVE or something without reference to 
> GemFire (GF) since it is now part of Apache Geode Native.  This will also 
> include changing references in the doc from $GFCPP to $GEODE_NATIVE.  
> **Specifically "Installing the Native Client" section and possibly others 
> (search GFCPP).



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

[jira] [Commented] (GEODE-4874) Inconsistency in gfsh help for create jndi-binding

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4874:


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

GEODE-4874: Inconsistency in gfsh help for create jndi-binding (doc update)


> Inconsistency in gfsh help for create jndi-binding 
> ---
>
> Key: GEODE-4874
> URL: https://issues.apache.org/jira/browse/GEODE-4874
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.5.0
>Reporter: Karen Smoler Miller
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I see an error and an inconsistency when trying to use the gfsh help 
> functionality for create jndi-binding.
> Tab completion of
> create jndi-binding
> outputs
>  gfsh>create jndi-binding –
>  create jndi-binding --connection-url
>  create jndi-binding --jdbc-driver-class
>  create jndi-binding --name
>  create jndi-binding --type
> This is inconsistent with the output of other tab completions, which just 
> give the options, and do not repeat the "create jndi-binding" portion of the 
> command.
>  



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

[jira] [Updated] (GEODE-4874) Inconsistency in gfsh help for create jndi-binding

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-4874:
---
Component/s: (was: docs)

> Inconsistency in gfsh help for create jndi-binding 
> ---
>
> Key: GEODE-4874
> URL: https://issues.apache.org/jira/browse/GEODE-4874
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.5.0
>Reporter: Karen Smoler Miller
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I see an error and an inconsistency when trying to use the gfsh help 
> functionality for create jndi-binding.
> Tab completion of
> create jndi-binding
> outputs
>  gfsh>create jndi-binding –
>  create jndi-binding --connection-url
>  create jndi-binding --jdbc-driver-class
>  create jndi-binding --name
>  create jndi-binding --type
> This is inconsistent with the output of other tab completions, which just 
> give the options, and do not repeat the "create jndi-binding" portion of the 
> command.
>  



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

[jira] [Commented] (GEODE-4908) Environment variable $GFCPP is still used

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4908:


Commit edd2989a2f7731ae53668733e39778af45307d58 in geode-native's branch 
refs/heads/develop from M. Oleske
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=edd2989 ]

GEODE-4908 - Rename GFCPP (#270)

* GEODE-4908: Rename GFCPP

* Clang format and readibility improvements

* Use GEODE_NATIVE_HOME instead of GEODE_NATIVE to better match java server


> Environment variable $GFCPP is still used
> -
>
> Key: GEODE-4908
> URL: https://issues.apache.org/jira/browse/GEODE-4908
> Project: Geode
>  Issue Type: Task
>  Components: docs, native client
>Reporter: Ryan McMahon
>Assignee: Michael Oleske
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> We need to change $GFCPP to $GEODE_NATIVE or something without reference to 
> GemFire (GF) since it is now part of Apache Geode Native.  This will also 
> include changing references in the doc from $GFCPP to $GEODE_NATIVE.  
> **Specifically "Installing the Native Client" section and possibly others 
> (search GFCPP).



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

[jira] [Commented] (GEODE-4908) Environment variable $GFCPP is still used

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4908:


Commit edd2989a2f7731ae53668733e39778af45307d58 in geode-native's branch 
refs/heads/develop from M. Oleske
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=edd2989 ]

GEODE-4908 - Rename GFCPP (#270)

* GEODE-4908: Rename GFCPP

* Clang format and readibility improvements

* Use GEODE_NATIVE_HOME instead of GEODE_NATIVE to better match java server


> Environment variable $GFCPP is still used
> -
>
> Key: GEODE-4908
> URL: https://issues.apache.org/jira/browse/GEODE-4908
> Project: Geode
>  Issue Type: Task
>  Components: docs, native client
>Reporter: Ryan McMahon
>Assignee: Michael Oleske
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> We need to change $GFCPP to $GEODE_NATIVE or something without reference to 
> GemFire (GF) since it is now part of Apache Geode Native.  This will also 
> include changing references in the doc from $GFCPP to $GEODE_NATIVE.  
> **Specifically "Installing the Native Client" section and possibly others 
> (search GFCPP).



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

[jira] [Created] (GEODE-5059) AbstractRegionMap.basicPut should be refactored

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-5059:
---

 Summary: AbstractRegionMap.basicPut should be refactored
 Key: GEODE-5059
 URL: https://issues.apache.org/jira/browse/GEODE-5059
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


Recently the AbstractRegionMap.basicPut method was refactored into many smaller 
methods that all take an instance of RegionMapPutContext.

These methods should be moved to another class (it could be named RegionMapPut) 
and the RegionMapPutContext could go away since the RegionMapPut instance could 
keep all the state of the put operation.

 



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

[jira] [Updated] (GEODE-4874) Inconsistency in gfsh help for create jndi-binding

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-4874:
---
Component/s: docs

> Inconsistency in gfsh help for create jndi-binding 
> ---
>
> Key: GEODE-4874
> URL: https://issues.apache.org/jira/browse/GEODE-4874
> Project: Geode
>  Issue Type: Bug
>  Components: docs, gfsh
>Affects Versions: 1.5.0
>Reporter: Karen Smoler Miller
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I see an error and an inconsistency when trying to use the gfsh help 
> functionality for create jndi-binding.
> Tab completion of
> create jndi-binding
> outputs
>  gfsh>create jndi-binding –
>  create jndi-binding --connection-url
>  create jndi-binding --jdbc-driver-class
>  create jndi-binding --name
>  create jndi-binding --type
> This is inconsistent with the output of other tab completions, which just 
> give the options, and do not repeat the "create jndi-binding" portion of the 
> command.
>  



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

[jira] [Created] (GEODE-5058) Delete redundant DUnit tests with JUnit4 prefix

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-5058:


 Summary: Delete redundant DUnit tests with JUnit4 prefix
 Key: GEODE-5058
 URL: https://issues.apache.org/jira/browse/GEODE-5058
 Project: Geode
  Issue Type: Wish
  Components: tests
Reporter: Kirk Lund


Delete redundant DUnit tests with JUnit4 prefix:
* JUnit4BasicDUnitTest
* JUnit4GetDefaultDiskStoreNameDUnitTest
* JUnit4GetTestMethodNameDUnitTest
* JUnit4OverridingGetPropertiesDisconnectsAllDUnitTest
* JUnit4VMDUnitTest

These are duplicates of tests without the JUnit4* prefix.



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

[jira] [Assigned] (GEODE-5058) Delete redundant DUnit tests with JUnit4 prefix

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-5058:


Assignee: Kirk Lund

> Delete redundant DUnit tests with JUnit4 prefix
> ---
>
> Key: GEODE-5058
> URL: https://issues.apache.org/jira/browse/GEODE-5058
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Delete redundant DUnit tests with JUnit4 prefix:
> * JUnit4BasicDUnitTest
> * JUnit4GetDefaultDiskStoreNameDUnitTest
> * JUnit4GetTestMethodNameDUnitTest
> * JUnit4OverridingGetPropertiesDisconnectsAllDUnitTest
> * JUnit4VMDUnitTest
> These are duplicates of tests without the JUnit4* prefix.



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

[jira] [Commented] (GEODE-5056) ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2 intermittently fail

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5056:


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

GEODE-5056: set testParallelPropagationSenderStartAfterStop_Scenario2 to be 
flaky


> ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
>  intermittently fail 
> ---
>
> Key: GEODE-5056
> URL: https://issues.apache.org/jira/browse/GEODE-5056
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> After fixe GEODE-4942, I found there's at least one race condition is not 
> covered. 
>  
> [vm6] [debug 2018/04/11 16:47:35.189 PDT  Processor2> tid=110] WAN: On primary bucket 57, setting the seq number as 1357
>  
> [vm7] [info 2018/04/11 16:47:35.150 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
>  
> [vm7] [debug 2018/04/11 16:47:35.189 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] WAN: 
> On secondary bucket 57, setting the seq number as 1357
> [vm7] [debug 2018/04/11 16:47:35.190 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] Key : 
> > 1357
> [vm6] [debug 2018/04/11 16:47:35.190 PDT  Processor2> tid=110] register dropped event for primary queue. BucketId is 
> 57, shadowKey is 1357, prQ is /ln_PARALLEL_GATEWAY_SENDER_QUEUE
>  
> - Note: vm6's sender is restarted and cleanup the map, before the
> QueueRemvalMessage is sent out for the map.
> [vm6] [info 2018/04/11 16:47:35.249 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
> [vm6] [debug 2018/04/11 16:47:35.437 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map \{/ln_PARALLEL_GATEWAY_SENDER_QUEUE={96=[1396], 2=[1402], 
> 83=[1383], 6=[1406], 71=[1371], 87=[1387], 73=[1373], 90=[1390], 77=[1377], 
> 94=[1394]}}
> [vm6] [debug 2018/04/11 16:47:35.753 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map {/ln_PARALLEL_GATEWAY_SENDER_QUEUE={49=[1449], 65=[1465], 
> 83=[1483], 53=[1453], 71=[1471], 87=[1487], *57=[1457]*, 73=[1473], 
> 77=[1477], 62=[1462]}}
>  shadowKey 1457 was created after the sender is restarted
>  
> [vm6] [debug 2018/04/11 16:47:35.438 PDT  GatewaySender_ln_0> tid=118] Sending (ParallelQueueRemovalMessage@2344969b 
> processorId=0 sender=10.118.19.25(27489):32781) to 3 peers 
> ([10.118.19.25(27492):32783@4(GEODE 1.6.0), 
> 10.118.19.25(27485):32779@1(GEODE 1.6.0), 
> 10.118.19.25(27482):32778@2(GEODE 1.6.0)]) via tcp/ip
> [vm7] [debug 2018/04/11 16:47:35.439 PDT  10.118.19.25(27489):32781 shared unordered uid=4 port=59119> tid=52] 
> Received message 'ParallelQueueRemovalMessage@11583f5b processorId=0 
> sender=10.118.19.25(27489):32781' from <10.118.19.25(27489):32781>
>  
> i.e. the dropped key was in the map, but before sending a QueueRemovalMessage 
> the sender is closed and cleared the map. 



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

[jira] [Resolved] (GEODE-4957) The key used in a putIfAbsent call that returns null may not be the one in the RegionEntry

[Darrel Schneider (JIRA)]

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

Darrel Schneider resolved GEODE-4957.
-
   Resolution: Fixed
Fix Version/s: 1.6.0

> The key used in a putIfAbsent call that returns null may not be the one in 
> the RegionEntry
> --
>
> Key: GEODE-4957
> URL: https://issues.apache.org/jira/browse/GEODE-4957
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barry Oglesby
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> With simultaneous putIfAbsent calls, sometimes the thread that returns null 
> is not the thread that actually creates the RegionEntry.
> Below is some logging that shows this behavior.
> Thread-77 returns null from the putIfAbsent call (which means there was no 
> previous value). 1 ms before Thread-77's putEntryIfAbsent call, Thread-9 
> creates the RegionEntry. You can see that because not only is oldRe=null for 
> Thread-9, but also the event's key (eventKey) and entry's key (reKey) are 
> identical. But Thread-9 returns a non-null old value.
> {noformat}
> Thread-77 at 1522187267493: AbstractRegionMap.putEntryIfAbsent 
> regionEntry=VersionedStatsDiskLRURegionEntryHeapObjectKey@6a8119a0 
> (key=ComplexKey[identity=1682369152; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null); 
> oldRe=VersionedStatsDiskLRURegionEntryHeapObjectKey@1aac7604 
> (key=ComplexKey[identity=342592289; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null)
> Thread-77 at 1522187267493: AbstractRegionMap.basicPut 
> eventKey=ComplexKey[identity=1682369152; key=key]; 
> reKey=ComplexKey[identity=342592289; key=key]
> Thread-77 at 1522187267500: LocalRegion.putIfAbsent returning null
> {noformat}
> {noformat}
> Thread-9 at 1522187267492: AbstractRegionMap.putEntryIfAbsent 
> regionEntry=VersionedStatsDiskLRURegionEntryHeapObjectKey@1aac7604 
> (key=ComplexKey[identity=342592289; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null); oldRe=null
> Thread-9 at 1522187267495: AbstractRegionMap.basicPut 
> eventKey=ComplexKey[identity=342592289; key=key]; 
> reKey=ComplexKey[identity=342592289; key=key]
> Thread-9 at 1522187267504: LocalRegion.putIfAbsent returning v1
> {noformat}



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

[jira] [Assigned] (GEODE-4957) The key used in a putIfAbsent call that returns null may not be the one in the RegionEntry

[Darrel Schneider (JIRA)]

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

Darrel Schneider reassigned GEODE-4957:
---

Assignee: Darrel Schneider

> The key used in a putIfAbsent call that returns null may not be the one in 
> the RegionEntry
> --
>
> Key: GEODE-4957
> URL: https://issues.apache.org/jira/browse/GEODE-4957
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barry Oglesby
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> With simultaneous putIfAbsent calls, sometimes the thread that returns null 
> is not the thread that actually creates the RegionEntry.
> Below is some logging that shows this behavior.
> Thread-77 returns null from the putIfAbsent call (which means there was no 
> previous value). 1 ms before Thread-77's putEntryIfAbsent call, Thread-9 
> creates the RegionEntry. You can see that because not only is oldRe=null for 
> Thread-9, but also the event's key (eventKey) and entry's key (reKey) are 
> identical. But Thread-9 returns a non-null old value.
> {noformat}
> Thread-77 at 1522187267493: AbstractRegionMap.putEntryIfAbsent 
> regionEntry=VersionedStatsDiskLRURegionEntryHeapObjectKey@6a8119a0 
> (key=ComplexKey[identity=1682369152; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null); 
> oldRe=VersionedStatsDiskLRURegionEntryHeapObjectKey@1aac7604 
> (key=ComplexKey[identity=342592289; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null)
> Thread-77 at 1522187267493: AbstractRegionMap.basicPut 
> eventKey=ComplexKey[identity=1682369152; key=key]; 
> reKey=ComplexKey[identity=342592289; key=key]
> Thread-77 at 1522187267500: LocalRegion.putIfAbsent returning null
> {noformat}
> {noformat}
> Thread-9 at 1522187267492: AbstractRegionMap.putEntryIfAbsent 
> regionEntry=VersionedStatsDiskLRURegionEntryHeapObjectKey@1aac7604 
> (key=ComplexKey[identity=342592289; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null); oldRe=null
> Thread-9 at 1522187267495: AbstractRegionMap.basicPut 
> eventKey=ComplexKey[identity=342592289; key=key]; 
> reKey=ComplexKey[identity=342592289; key=key]
> Thread-9 at 1522187267504: LocalRegion.putIfAbsent returning v1
> {noformat}



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

[jira] [Commented] (GEODE-4957) The key used in a putIfAbsent call that returns null may not be the one in the RegionEntry

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4957:


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

GEODE-4957: fix race in concurrent create on region (#1750)

Refactored basicPut so that a RegionEntry with REMOVE_PHASE1
is added to the map, it will already be synchronized.
This prevents a second concurrent threads from "stealing" it and
creating a region entry with a key that is the same but has a different
identity.


> The key used in a putIfAbsent call that returns null may not be the one in 
> the RegionEntry
> --
>
> Key: GEODE-4957
> URL: https://issues.apache.org/jira/browse/GEODE-4957
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barry Oglesby
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> With simultaneous putIfAbsent calls, sometimes the thread that returns null 
> is not the thread that actually creates the RegionEntry.
> Below is some logging that shows this behavior.
> Thread-77 returns null from the putIfAbsent call (which means there was no 
> previous value). 1 ms before Thread-77's putEntryIfAbsent call, Thread-9 
> creates the RegionEntry. You can see that because not only is oldRe=null for 
> Thread-9, but also the event's key (eventKey) and entry's key (reKey) are 
> identical. But Thread-9 returns a non-null old value.
> {noformat}
> Thread-77 at 1522187267493: AbstractRegionMap.putEntryIfAbsent 
> regionEntry=VersionedStatsDiskLRURegionEntryHeapObjectKey@6a8119a0 
> (key=ComplexKey[identity=1682369152; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null); 
> oldRe=VersionedStatsDiskLRURegionEntryHeapObjectKey@1aac7604 
> (key=ComplexKey[identity=342592289; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null)
> Thread-77 at 1522187267493: AbstractRegionMap.basicPut 
> eventKey=ComplexKey[identity=1682369152; key=key]; 
> reKey=ComplexKey[identity=342592289; key=key]
> Thread-77 at 1522187267500: LocalRegion.putIfAbsent returning null
> {noformat}
> {noformat}
> Thread-9 at 1522187267492: AbstractRegionMap.putEntryIfAbsent 
> regionEntry=VersionedStatsDiskLRURegionEntryHeapObjectKey@1aac7604 
> (key=ComplexKey[identity=342592289; key=key]; rawValue=REMOVED_PHASE1; 
> version=\{v0; rv0; ds=0; time=0};member=null); oldRe=null
> Thread-9 at 1522187267495: AbstractRegionMap.basicPut 
> eventKey=ComplexKey[identity=342592289; key=key]; 
> reKey=ComplexKey[identity=342592289; key=key]
> Thread-9 at 1522187267504: LocalRegion.putIfAbsent returning v1
> {noformat}



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

[jira] [Updated] (GEODE-5035) Some tests use incorrect temp directory

[ASF GitHub Bot (JIRA)]

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

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

> Some tests use incorrect temp directory
> ---
>
> Key: GEODE-5035
> URL: https://issues.apache.org/jira/browse/GEODE-5035
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Some tests that use {{JUnit}}'s {{TemporaryFolder}} rule (e.g., 
> {{DiskSpaceLimitIntegrationTest}} {{FileProcessControllerIntegrationTest}}) 
> do not specify the temp directory to use as the parent folder for the 
> temporary folder. This can result in the default location being used, which 
> is different from what is specified by the pipeline. This can result in 
> strange behavior, such as a test writing contents to a temporary file without 
> exception but then failing an existence test on the same file.
> The {{TemporaryFolder}} rule should be synchronized with the 
> {{java.io.tmpdir}} system property.



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

[jira] [Updated] (GEODE-5057) Remove 'experimental' from JDBC Connector code

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade updated GEODE-5057:
-
Affects Version/s: 1.6.0

> Remove 'experimental' from JDBC Connector code
> --
>
> Key: GEODE-5057
> URL: https://issues.apache.org/jira/browse/GEODE-5057
> Project: Geode
>  Issue Type: Task
>  Components: extensions, regions
>Affects Versions: 1.6.0
>Reporter: Anilkumar Gingade
>Priority: Major
>
> Remove 'experimental' from JDBC Connector code.



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

[jira] [Created] (GEODE-5057) Remove 'experimental' from JDBC Connector code

[Anilkumar Gingade (JIRA)]

Anilkumar Gingade created GEODE-5057:


 Summary: Remove 'experimental' from JDBC Connector code
 Key: GEODE-5057
 URL: https://issues.apache.org/jira/browse/GEODE-5057
 Project: Geode
  Issue Type: Task
  Components: extensions, regions
Reporter: Anilkumar Gingade


Remove 'experimental' from JDBC Connector code.



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

[jira] [Created] (GEODE-5056) ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2 intermittently fail

[xiaojian zhou (JIRA)]

xiaojian zhou created GEODE-5056:


 Summary: 
ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
 intermittently fail 
 Key: GEODE-5056
 URL: https://issues.apache.org/jira/browse/GEODE-5056
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: xiaojian zhou


After fixe GEODE-4942, I found there's at least one race condition is not 
covered. 

 

[vm6] [debug 2018/04/11 16:47:35.189 PDT  
tid=110] WAN: On primary bucket 57, setting the seq number as 1357

 

[vm7] [info 2018/04/11 16:47:35.150 PDT  
tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}

 

[vm7] [debug 2018/04/11 16:47:35.189 PDT :32781 shared ordered uid=7 port=59148> tid=95] WAN: On 
secondary bucket 57, setting the seq number as 1357

[vm7] [debug 2018/04/11 16:47:35.190 PDT :32781 shared ordered uid=7 port=59148> tid=95] Key : 
> 1357

[vm6] [debug 2018/04/11 16:47:35.190 PDT  
tid=110] register dropped event for primary queue. BucketId is 57, shadowKey is 
1357, prQ is /ln_PARALLEL_GATEWAY_SENDER_QUEUE

 

- Note: vm6's sender is restarted and cleanup the map, before the

QueueRemvalMessage is sent out for the map.

[vm6] [info 2018/04/11 16:47:35.249 PDT  
tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}

[vm6] [debug 2018/04/11 16:47:35.437 PDT  tid=118] BatchRemovalThread about to query the batch 
removal map \{/ln_PARALLEL_GATEWAY_SENDER_QUEUE={96=[1396], 2=[1402], 
83=[1383], 6=[1406], 71=[1371], 87=[1387], 73=[1373], 90=[1390], 77=[1377], 
94=[1394]}}

[vm6] [debug 2018/04/11 16:47:35.753 PDT  tid=118] BatchRemovalThread about to query the batch 
removal map {/ln_PARALLEL_GATEWAY_SENDER_QUEUE={49=[1449], 65=[1465], 
83=[1483], 53=[1453], 71=[1471], 87=[1487], *57=[1457]*, 73=[1473], 77=[1477], 
62=[1462]}}

 shadowKey 1457 was created after the sender is restarted

 

[vm6] [debug 2018/04/11 16:47:35.438 PDT  tid=118] Sending (ParallelQueueRemovalMessage@2344969b 
processorId=0 sender=10.118.19.25(27489):32781) to 3 peers 
([10.118.19.25(27492):32783@4(GEODE 1.6.0), 
10.118.19.25(27485):32779@1(GEODE 1.6.0), 
10.118.19.25(27482):32778@2(GEODE 1.6.0)]) via tcp/ip

[vm7] [debug 2018/04/11 16:47:35.439 PDT :32781 shared unordered uid=4 port=59119> tid=52] 
Received message 'ParallelQueueRemovalMessage@11583f5b processorId=0 
sender=10.118.19.25(27489):32781' from <10.118.19.25(27489):32781>

 

i.e. the dropped key was in the map, but before sending a QueueRemovalMessage 
the sender is closed and cleared the map. 



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

[jira] [Assigned] (GEODE-5056) ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2 intermittently fail

[xiaojian zhou (JIRA)]

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

xiaojian zhou reassigned GEODE-5056:


Assignee: xiaojian zhou

> ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
>  intermittently fail 
> ---
>
> Key: GEODE-5056
> URL: https://issues.apache.org/jira/browse/GEODE-5056
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
>
> After fixe GEODE-4942, I found there's at least one race condition is not 
> covered. 
>  
> [vm6] [debug 2018/04/11 16:47:35.189 PDT  Processor2> tid=110] WAN: On primary bucket 57, setting the seq number as 1357
>  
> [vm7] [info 2018/04/11 16:47:35.150 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
>  
> [vm7] [debug 2018/04/11 16:47:35.189 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] WAN: 
> On secondary bucket 57, setting the seq number as 1357
> [vm7] [debug 2018/04/11 16:47:35.190 PDT  10.118.19.25(27489):32781 shared ordered uid=7 port=59148> tid=95] Key : 
> > 1357
> [vm6] [debug 2018/04/11 16:47:35.190 PDT  Processor2> tid=110] register dropped event for primary queue. BucketId is 
> 57, shadowKey is 1357, prQ is /ln_PARALLEL_GATEWAY_SENDER_QUEUE
>  
> - Note: vm6's sender is restarted and cleanup the map, before the
> QueueRemvalMessage is sent out for the map.
> [vm6] [info 2018/04/11 16:47:35.249 PDT  
> tid=19] Started  ParallelGatewaySender\{id=ln,remoteDsId=2,isRunning =true}
> [vm6] [debug 2018/04/11 16:47:35.437 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map \{/ln_PARALLEL_GATEWAY_SENDER_QUEUE={96=[1396], 2=[1402], 
> 83=[1383], 6=[1406], 71=[1371], 87=[1387], 73=[1373], 90=[1390], 77=[1377], 
> 94=[1394]}}
> [vm6] [debug 2018/04/11 16:47:35.753 PDT  GatewaySender_ln_0> tid=118] BatchRemovalThread about to query the batch 
> removal map {/ln_PARALLEL_GATEWAY_SENDER_QUEUE={49=[1449], 65=[1465], 
> 83=[1483], 53=[1453], 71=[1471], 87=[1487], *57=[1457]*, 73=[1473], 
> 77=[1477], 62=[1462]}}
>  shadowKey 1457 was created after the sender is restarted
>  
> [vm6] [debug 2018/04/11 16:47:35.438 PDT  GatewaySender_ln_0> tid=118] Sending (ParallelQueueRemovalMessage@2344969b 
> processorId=0 sender=10.118.19.25(27489):32781) to 3 peers 
> ([10.118.19.25(27492):32783@4(GEODE 1.6.0), 
> 10.118.19.25(27485):32779@1(GEODE 1.6.0), 
> 10.118.19.25(27482):32778@2(GEODE 1.6.0)]) via tcp/ip
> [vm7] [debug 2018/04/11 16:47:35.439 PDT  10.118.19.25(27489):32781 shared unordered uid=4 port=59119> tid=52] 
> Received message 'ParallelQueueRemovalMessage@11583f5b processorId=0 
> sender=10.118.19.25(27489):32781' from <10.118.19.25(27489):32781>
>  
> i.e. the dropped key was in the map, but before sending a QueueRemovalMessage 
> the sender is closed and cleared the map. 



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

[jira] [Commented] (GEODE-5053) Import and export should be supported with full cluster running

[Barbara Pruijn (JIRA)]

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

Barbara Pruijn commented on GEODE-5053:
---

[~pchandra] Here is the flow: if you start a cluster with brand new locators 
and servers (with no configuration on them), you can import the cluster 
configuration when the full cluster is up and running (locators and servers are 
running). If the locators already have configuration and/or the servers have 
configuration, the import command will fail. 

Once you have imported the configuration on the running cluster, then you can 
import the data. If the data that you import does not match the configuration, 
this command will fail. (e.g. load data in a region that is not defined in the 
configuration).

In the above scenario, you can import cluster config on running servers. But if 
there is any configuration on any server or locator, you cannot import the 
configuration.

https://issues.apache.org/jira/browse/GEODE-4893 fixed a bug related to this 
and should be released in geode 1.6.0.

 

> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have 
> the ability to just run locators and not servers as we use BOSH to manage 
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like 
> to ensure I can back it up. Use cases range from ensuring your data doesnt 
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full 
> cluster would be running before import is called. We can do rolling restart, 
> if that is needed.
>  
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893



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

[jira] [Resolved] (GEODE-4830) Modify list jndi-binding gfsh command

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-4830.

Resolution: Fixed

Resolving without a commit for documentation, as the initial documentation of 
the gfsh list jndi-binding was done (in GEODE-4385) after this code change went 
in.

> Modify list jndi-binding gfsh command 
> --
>
> Key: GEODE-4830
> URL: https://issues.apache.org/jira/browse/GEODE-4830
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Barbara Pruijn
>Assignee: Joey McAllister
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The list jndi-binding command currently displays jndi-bindings that are 
> active.
> We need to modify the output of this command to list all jndi-bindings that 
> are listed in the cluster config and indicate in the output of this command 
> whether the binding is active or configured.
> We should update the help text to reflect this change. A suggested help text 
> is:
> {code:java}
> List all jndi bindings, active and configured. An active binding is one that 
> is bound to the server's jndi context (and also listed in the cluster 
> config). A configured binding is one that is listed in the cluster config, 
> but is not active.{code}
>  



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

[jira] [Commented] (GEODE-5055) CI failure: LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion

[Jason Huynh (JIRA)]

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

Jason Huynh commented on GEODE-5055:


There are two conditions I think we will need to handle:

1.) The test will need to wait until the index has been reindexed on the new 
server.

2.) Old servers will not know what a LuceneIndexCreationInProgressException is, 
and it's LuceneQueryImpl does not know how to handle one of those.

> CI failure: 
> LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion
> -
>
> Key: GEODE-5055
> URL: https://issues.apache.org/jira/browse/GEODE-5055
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Priority: Major
>
> This is related to changes for GEODE-3926.  The roll is occuring but because 
> we added the new complete file, the new server is probably "reindexing" at 
> the moment. 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit > 
> luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion[from_v140]
>  FAILED
>  org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit$$Lambda$27/1996438298.run
>  in VM 0 running on Host eada542bc38a with 4 VMs
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResultInEachVM(LuceneSearchWithRollingUpgradeDUnit.java:678)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.executeLuceneQueryWithServerRollOvers(LuceneSearchWithRollingUpgradeDUnit.java:572)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion(LuceneSearchWithRollingUpgradeDUnit.java:134)
> Caused by:
>  java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:661)
>  at 
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.lambda$verifyLuceneQueryResultInEachVM$b83f705c$2(LuceneSearchWithRollingUpgradeDUnit.java:678)
> Caused by:
>  
> org.apache.geode.cache.lucene.internal.LuceneIndexCreationInProgressException:
>  Lucene Index creation in progress for bucket: 1



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

[jira] [Resolved] (GEODE-4385) gfsh command to list jndi binding

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-4385.

Resolution: Fixed

> gfsh command to list jndi binding
> -
>
> Key: GEODE-4385
> URL: https://issues.apache.org/jira/browse/GEODE-4385
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Barbara Pruijn
>Assignee: Karen Smoler Miller
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>   
>  jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
>   password="changeme" 
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>   
>   
> {code}
> A user should be able to list a datasource using the gfsh command {{list 
> jndi-binding}}
>  Then all jndi-binding names will be displayed.
> Please look at Geode's schema for a list of attributes that can be set: 
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]



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

[jira] [Created] (GEODE-5055) CI failure: LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-5055:
--

 Summary: CI failure: 
LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion
 Key: GEODE-5055
 URL: https://issues.apache.org/jira/browse/GEODE-5055
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Jason Huynh


This is related to changes for GEODE-3926.  The roll is occuring but because we 
added the new complete file, the new server is probably "reindexing" at the 
moment. 
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit > 
luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion[from_v140]
 FAILED
 org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit$$Lambda$27/1996438298.run
 in VM 0 running on Host eada542bc38a with 4 VMs
 at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
 at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
 at 
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResultInEachVM(LuceneSearchWithRollingUpgradeDUnit.java:678)
 at 
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.executeLuceneQueryWithServerRollOvers(LuceneSearchWithRollingUpgradeDUnit.java:572)
 at 
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion(LuceneSearchWithRollingUpgradeDUnit.java:134)

Caused by:
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:661)
 at 
org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.lambda$verifyLuceneQueryResultInEachVM$b83f705c$2(LuceneSearchWithRollingUpgradeDUnit.java:678)

Caused by:
 org.apache.geode.cache.lucene.internal.LuceneIndexCreationInProgressException: 
Lucene Index creation in progress for bucket: 1



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

[jira] [Assigned] (GEODE-4953) Improve spotless -- prohibit wildcard imports

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-4953:
---

Assignee: Patrick Rhomberg

> Improve spotless -- prohibit wildcard imports
> -
>
> Key: GEODE-4953
> URL: https://issues.apache.org/jira/browse/GEODE-4953
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>




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

[jira] [Updated] (GEODE-5022) Transactions do not support propagating deltas

[Eric Shu (JIRA)]

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

Eric Shu updated GEODE-5022:

Summary: Transactions do not support propagating deltas  (was: Transactions 
are not propagating deltas)

> Transactions do not support propagating deltas
> --
>
> Key: GEODE-5022
> URL: https://issues.apache.org/jira/browse/GEODE-5022
> Project: Geode
>  Issue Type: New Feature
>  Components: transactions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0
>Reporter: Bruce Schuchardt
>Priority: Minor
> Attachments: TransactionsWithDeltaDUnitTest.java
>
>
> Client to server transactions propagate a delta from the client to the 
> server.  The server then applies the delta to its cache and forgets about it. 
>  It transmits the full object to other servers and to clients.
> Server-initiated transactions also ignore delta values.
> I'm attaching a client/server test that demonstrates the problem.



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

[jira] [Updated] (GEODE-5022) Transactions are not propagating deltas

[Eric Shu (JIRA)]

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

Eric Shu updated GEODE-5022:

Priority: Minor  (was: Major)

> Transactions are not propagating deltas
> ---
>
> Key: GEODE-5022
> URL: https://issues.apache.org/jira/browse/GEODE-5022
> Project: Geode
>  Issue Type: New Feature
>  Components: transactions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0
>Reporter: Bruce Schuchardt
>Priority: Minor
> Attachments: TransactionsWithDeltaDUnitTest.java
>
>
> Client to server transactions propagate a delta from the client to the 
> server.  The server then applies the delta to its cache and forgets about it. 
>  It transmits the full object to other servers and to clients.
> Server-initiated transactions also ignore delta values.
> I'm attaching a client/server test that demonstrates the problem.



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

[jira] [Commented] (GEODE-5022) Transactions are not propagating deltas

[Eric Shu (JIRA)]

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

Eric Shu commented on GEODE-5022:
-

Currently transaction implementation does not support delta propagation. We 
should document this behavior and then prioritize implementing if needed.

> Transactions are not propagating deltas
> ---
>
> Key: GEODE-5022
> URL: https://issues.apache.org/jira/browse/GEODE-5022
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0
>Reporter: Bruce Schuchardt
>Priority: Major
> Attachments: TransactionsWithDeltaDUnitTest.java
>
>
> Client to server transactions propagate a delta from the client to the 
> server.  The server then applies the delta to its cache and forgets about it. 
>  It transmits the full object to other servers and to clients.
> Server-initiated transactions also ignore delta values.
> I'm attaching a client/server test that demonstrates the problem.



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

[jira] [Updated] (GEODE-5022) Transactions are not propagating deltas

[Eric Shu (JIRA)]

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

Eric Shu updated GEODE-5022:

Issue Type: New Feature  (was: Bug)

> Transactions are not propagating deltas
> ---
>
> Key: GEODE-5022
> URL: https://issues.apache.org/jira/browse/GEODE-5022
> Project: Geode
>  Issue Type: New Feature
>  Components: transactions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0
>Reporter: Bruce Schuchardt
>Priority: Major
> Attachments: TransactionsWithDeltaDUnitTest.java
>
>
> Client to server transactions propagate a delta from the client to the 
> server.  The server then applies the delta to its cache and forgets about it. 
>  It transmits the full object to other servers and to clients.
> Server-initiated transactions also ignore delta values.
> I'm attaching a client/server test that demonstrates the problem.



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

[jira] [Created] (GEODE-5054) As a SDG user I want to be able to list and describe for my JDBC settings in gfsh

[Fred Krone (JIRA)]

Fred Krone created GEODE-5054:
-

 Summary: As a SDG user I want to be able to list and describe for 
my JDBC settings in gfsh
 Key: GEODE-5054
 URL: https://issues.apache.org/jira/browse/GEODE-5054
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Fred Krone


GIVEN

I am using SDG 

WHEN

Creating or updating JDBC mappings or connections

THEN

I should be able to list and describe these mappings or connections

 

Background

JDBC gfsh create, alter and destroy will work as expected in SDG, but not 
describe and list since they are only looking into CC for that information. If 
we still want list and desc to work when cluster config service is disabled, 
can we require that the command would have a "--member" option, i.e. which 
member you want this information from.

 



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

[jira] [Updated] (GEODE-5054) As a SDG user I want to be able to list and describe for my JDBC settings in gfsh

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-5054:
--
Issue Type: Bug  (was: Improvement)

> As a SDG user I want to be able to list and describe for my JDBC settings in 
> gfsh
> -
>
> Key: GEODE-5054
> URL: https://issues.apache.org/jira/browse/GEODE-5054
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Fred Krone
>Priority: Major
>
> GIVEN
> I am using SDG 
> WHEN
> Creating or updating JDBC mappings or connections
> THEN
> I should be able to list and describe these mappings or connections
>  
> Background
> JDBC gfsh create, alter and destroy will work as expected in SDG, but not 
> describe and list since they are only looking into CC for that information. 
> If we still want list and desc to work when cluster config service is 
> disabled, can we require that the command would have a "--member" option, 
> i.e. which member you want this information from.
>  



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

[jira] [Updated] (GEODE-4962) Fix typo and output format from 'list gateways' gfsh command

[ASF GitHub Bot (JIRA)]

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

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

> Fix typo and output format from 'list gateways' gfsh command
> 
>
> Key: GEODE-4962
> URL: https://issues.apache.org/jira/browse/GEODE-4962
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, wan
>Reporter: Diane Hardman
>Priority: Major
>  Labels: pull-request-available
>
> The output printed from `list gateways` command needs some TLC:
> Sample output:
> {noformat}
> Cluster-2 gfsh>list gateways
> Gateways
> GatewaySender
> GatewaySender Id |                  Member                  | Remote Cluster 
> Id |   Type   | Status  | Queued Events | Receiver Location
>  |  | 
> - |  | --- | - | -
> ny               | 10.118.19.46(server-ln-1:31527):1026 | 1               
>   | Parallel | Running | 0             | 10.118.19.46:5248
> ny               | 10.118.19.46(server-ln-2:31545):1027 | 1               
>   | Parallel | Running | 0             | 10.118.19.46:5269
> GatewayReceiver
>                   Member                  | Port | Sender Count | Sender's 
> Connected
>  |  |  | 
> 
> 10.118.19.46(server-ln-1:31527):1026 | 5407 | 7            | 
> [Ljava.lang.String;@7deec2d6
> 10.118.19.46(server-ln-2:31545):1027 | 5071 | 7            | 
> [Ljava.lang.String;@6baa580f
> {noformat}
> Note: 'Sender's Connected' should instead be 'Senders Connected'
> Also, need to pretty-print the String[] for Senders Connected.



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

[jira] [Resolved] (GEODE-5039) EvictionAttributesMutator.setMaximum does not work

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-5039.
-
   Resolution: Fixed
Fix Version/s: 1.6.0

> EvictionAttributesMutator.setMaximum does not work
> --
>
> Key: GEODE-5039
> URL: https://issues.apache.org/jira/browse/GEODE-5039
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Affects Versions: 1.5.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> EvictionAttributesMutator.setMaximum does not change the lru count.
>  
> Given I am configuring eviction
> When setting EvictionAttributesMutator.setMaximum
> Then the lru count should update accordingly



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

[jira] [Resolved] (GEODE-5046) RemotePutMessage.distribute should handle RegionDestoryedException

[Eric Shu (JIRA)]

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

Eric Shu resolved GEODE-5046.
-
   Resolution: Fixed
Fix Version/s: 1.6.0

> RemotePutMessage.distribute should handle RegionDestoryedException
> --
>
> Key: GEODE-5046
> URL: https://issues.apache.org/jira/browse/GEODE-5046
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.5.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> RemotePutMessage.distribute() tries to get a version tag from a remote member 
> in a loop. It tries another member if one member failed. 
> It is possible that a region is destroyed on a member, and the method should 
> handle it and retry to another member instead of failing the operation.



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

[jira] [Commented] (GEODE-5046) RemotePutMessage.distribute should handle RegionDestoryedException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5046:


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

GEODE-5046: Handle RegionDestroyedException in RemotePutMessage to re… (#1773)

* GEODE-5046: Handle RegionDestroyedException in RemotePutMessage to retry 
another member.


> RemotePutMessage.distribute should handle RegionDestoryedException
> --
>
> Key: GEODE-5046
> URL: https://issues.apache.org/jira/browse/GEODE-5046
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.5.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> RemotePutMessage.distribute() tries to get a version tag from a remote member 
> in a loop. It tries another member if one member failed. 
> It is possible that a region is destroyed on a member, and the method should 
> handle it and retry to another member instead of failing the operation.



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

[jira] [Commented] (GEODE-5046) RemotePutMessage.distribute should handle RegionDestoryedException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5046:


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

GEODE-5046: Handle RegionDestroyedException in RemotePutMessage to re… (#1773)

* GEODE-5046: Handle RegionDestroyedException in RemotePutMessage to retry 
another member.


> RemotePutMessage.distribute should handle RegionDestoryedException
> --
>
> Key: GEODE-5046
> URL: https://issues.apache.org/jira/browse/GEODE-5046
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.5.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> RemotePutMessage.distribute() tries to get a version tag from a remote member 
> in a loop. It tries another member if one member failed. 
> It is possible that a region is destroyed on a member, and the method should 
> handle it and retry to another member instead of failing the operation.



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

[jira] [Commented] (GEODE-4385) gfsh command to list jndi binding

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4385:


Commit 51660e6e69056fe3471784aa4b3d3bc579a60545 in geode's branch 
refs/heads/develop from Karen Miller
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=51660e6 ]

GEODE-4385 Add documentation of gfsh list jndi-binding command (#1772)

* GEODE-4385 Add documentation of gfsh list jndi-binding command

* GEODE-4385 Capitalize JNDI appropriately


> gfsh command to list jndi binding
> -
>
> Key: GEODE-4385
> URL: https://issues.apache.org/jira/browse/GEODE-4385
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Barbara Pruijn
>Assignee: Karen Smoler Miller
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>   
>  jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
>   password="changeme" 
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>   
>   
> {code}
> A user should be able to list a datasource using the gfsh command {{list 
> jndi-binding}}
>  Then all jndi-binding names will be displayed.
> Please look at Geode's schema for a list of attributes that can be set: 
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]



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

[jira] [Commented] (GEODE-4385) gfsh command to list jndi binding

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4385:


Commit 51660e6e69056fe3471784aa4b3d3bc579a60545 in geode's branch 
refs/heads/develop from Karen Miller
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=51660e6 ]

GEODE-4385 Add documentation of gfsh list jndi-binding command (#1772)

* GEODE-4385 Add documentation of gfsh list jndi-binding command

* GEODE-4385 Capitalize JNDI appropriately


> gfsh command to list jndi binding
> -
>
> Key: GEODE-4385
> URL: https://issues.apache.org/jira/browse/GEODE-4385
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Barbara Pruijn
>Assignee: Karen Smoler Miller
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>   
>  jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
>   password="changeme" 
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>   
>   
> {code}
> A user should be able to list a datasource using the gfsh command {{list 
> jndi-binding}}
>  Then all jndi-binding names will be displayed.
> Please look at Geode's schema for a list of attributes that can be set: 
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]



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

[jira] [Commented] (GEODE-4385) gfsh command to list jndi binding

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4385:


Commit 51660e6e69056fe3471784aa4b3d3bc579a60545 in geode's branch 
refs/heads/develop from Karen Miller
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=51660e6 ]

GEODE-4385 Add documentation of gfsh list jndi-binding command (#1772)

* GEODE-4385 Add documentation of gfsh list jndi-binding command

* GEODE-4385 Capitalize JNDI appropriately


> gfsh command to list jndi binding
> -
>
> Key: GEODE-4385
> URL: https://issues.apache.org/jira/browse/GEODE-4385
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Barbara Pruijn
>Assignee: Karen Smoler Miller
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.6.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>   
>  jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
>   password="changeme" 
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>   
>   
> {code}
> A user should be able to list a datasource using the gfsh command {{list 
> jndi-binding}}
>  Then all jndi-binding names will be displayed.
> Please look at Geode's schema for a list of attributes that can be set: 
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]



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

[jira] [Commented] (GEODE-5039) EvictionAttributesMutator.setMaximum does not work

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-5039:


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

GEODE-5039: Change AbstractRegion to correctly construct 
EvictionAttributesMutator (#1766)



> EvictionAttributesMutator.setMaximum does not work
> --
>
> Key: GEODE-5039
> URL: https://issues.apache.org/jira/browse/GEODE-5039
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Affects Versions: 1.5.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> EvictionAttributesMutator.setMaximum does not change the lru count.
>  
> Given I am configuring eviction
> When setting EvictionAttributesMutator.setMaximum
> Then the lru count should update accordingly



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

[jira] [Resolved] (GEODE-5023) Exception not producing stack traces.

[Jacob S. Barrett (JIRA)]

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

Jacob S. Barrett resolved GEODE-5023.
-
Resolution: Fixed

> Exception not producing stack traces.
> -
>
> Key: GEODE-5023
> URL: https://issues.apache.org/jira/browse/GEODE-5023
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
>
> Somewhere in refactoring the constructor to {{StackTrace}} was dropped form 
> {{Exception}} so no stack traces are being produced.



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

[jira] [Commented] (GEODE-4919) Alter regions must update PRconfig

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-4919:


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

GEODE-4919: Update the PRConfig (#1666)

* Before adding any gateway sender or AEQ now do the following
* Assign buckets to the partition region
* Update the PartitionRegionConfig for the region with the updated set 
of gateway senders
* For Lucene reindex AEQs will be created at this point.
* Mutators then add the gateway senders to the internal region 
attributes.

> Alter regions must update PRconfig
> --
>
> Key: GEODE-4919
> URL: https://issues.apache.org/jira/browse/GEODE-4919
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Altering the region to add parallel gateway sender to non colocated regions 
> must fail.
> The check is done using the PartitionRegionConfig but we never update it 
> after altering the region to add the gateway sender.



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

[jira] [Updated] (GEODE-4874) Inconsistency in gfsh help for create jndi-binding

[ASF GitHub Bot (JIRA)]

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

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

> Inconsistency in gfsh help for create jndi-binding 
> ---
>
> Key: GEODE-4874
> URL: https://issues.apache.org/jira/browse/GEODE-4874
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.5.0
>Reporter: Karen Smoler Miller
>Priority: Minor
>  Labels: pull-request-available
>
> I see an error and an inconsistency when trying to use the gfsh help 
> functionality for create jndi-binding.
> Tab completion of
> create jndi-binding
> outputs
>  gfsh>create jndi-binding –
>  create jndi-binding --connection-url
>  create jndi-binding --jdbc-driver-class
>  create jndi-binding --name
>  create jndi-binding --type
> This is inconsistent with the output of other tab completions, which just 
> give the options, and do not repeat the "create jndi-binding" portion of the 
> command.
>  



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