date:20170508


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

ASF GitHub Bot commented on GEODE-2832:
---

Github user masaki-yamakawa commented on a diff in the pull request:

https://github.com/apache/geode-native/pull/95#discussion_r115204022
  
--- Diff: README.md ---
@@ -24,3 +24,33 @@ Native Client applications can be written in these 
client technologies:
 
 * [C++](https://isocpp.org)
 * [C#](https://msdn.microsoft.com/en-us/library/ms228593.aspx)
+
+## Export Control
+
+This distribution includes cryptographic software.
+The country in which you currently reside may have restrictions
+on the import, possession, use, and/or re-export to another country,
+of encryption software. BEFORE using any encryption software,
+please check your country's laws, regulations and policies
+concerning the import, possession, or use, and re-export of
+encryption software, to see if this is permitted.
+See  for more information.
+
+The U.S. Government Department of Commerce, Bureau of Industry and 
Security (BIS),
+has classified this software as Export Commodity Control Number (ECCN) 
5D002.C.1,
+which includes information security software using or performing
+cryptographic functions with asymmetric algorithms.
+The form and manner of this Apache Software Foundation distribution makes
+it eligible for export under the License Exception
+ENC Technology Software Unrestricted (TSU) exception
+(see the BIS Export Administration Regulations, Section 740.13)
+for both object code and source code.
+
+The following provides more details on the included cryptographic software:
+
+* Apache Geode is designed to be used with
+  [Java Secure Socket 
Extension](https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html)
 (JSSE) and
--- End diff --

I deleted the statements about JCE. OpenSSL does not delete statement 
because it is used.


> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #497: GEODE-2866: Removing the unused files and the corre...

2017-05-08 Thread prasi-in

GitHub user prasi-in opened a pull request:

https://github.com/apache/geode/pull/497

GEODE-2866: Removing the unused files and the corresponding test.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/prasi-in/geode feature/GEODE-2866

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/497.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #497


commit 2f3ea1aa523890d5a388210b354fb6d87ecc11b9
Author: prasind 
Date:   2017-05-08T09:23:59Z

GEODE-2866: Removing the unused files and the corresponding test.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2866) Bytes.java is not used in product, Only used in BytesJUnitTest, should be removed


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

ASF GitHub Bot commented on GEODE-2866:
---

GitHub user prasi-in opened a pull request:

https://github.com/apache/geode/pull/497

GEODE-2866: Removing the unused files and the corresponding test.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/prasi-in/geode feature/GEODE-2866

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/497.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #497


commit 2f3ea1aa523890d5a388210b354fb6d87ecc11b9
Author: prasind 
Date:   2017-05-08T09:23:59Z

GEODE-2866: Removing the unused files and the corresponding test.




> Bytes.java is not used in product, Only used in BytesJUnitTest, should be 
> removed
> -
>
> Key: GEODE-2866
> URL: https://issues.apache.org/jira/browse/GEODE-2866
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Avinash Dongre
>
> Bytes.java is not used only used in BytesJUnitTest, should be removed
> FYI [~bschuchardt]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-231) Remove deprecated AttributesMutator.setCacheListener


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

Avinash Dongre reassigned GEODE-231:


Assignee: Shankar Hundekar

> Remove deprecated AttributesMutator.setCacheListener
> 
>
> Key: GEODE-231
> URL: https://issues.apache.org/jira/browse/GEODE-231
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Shankar Hundekar
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> It looks like AttributesMutator.setCacheListener is currently only called 
> from test code. All of these calls can be replaced with 
> AttributesMutator.initCacheListeners with an array of one listener.
> It is probably not safe to use AttributesMutator.addCacheListener since it 
> leaves an original listeners in place.
> The method is called in about 25 different tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-240) Remove deprecated methods on TransactionEvent


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

Avinash Dongre reassigned GEODE-240:


Assignee: Shankar Hundekar

> Remove deprecated methods on TransactionEvent
> -
>
> Key: GEODE-240
> URL: https://issues.apache.org/jira/browse/GEODE-240
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Shankar Hundekar
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The following methods should all be deleted from TransactionEvent and callers 
> should be changed to instead use getEvents. The caller may have to do its own 
> filtering on getEvents to find the event(s) it is interested in.
> - getCreateEvents
> - getDestroyEvents
> - getPutEvents
> - getInvalidateEvents
> Some of the existing unit tests depend on the filtering done by these methods 
> so that filtering will need to move to some test util methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-254) Remove deprecated Region.keys and Region.entries


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

Avinash Dongre resolved GEODE-254.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #467: GEODE-258: Remove deprecated Cache.getLoggerI18n and getSe...

2017-05-08 Thread davinash

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/467
  
Thanks @kirklund and @upthewaterspout If I understand correctly 
getLoggerI18n should go away and replace with Log4j2. What is to be done for 
getSecurityLoggerI18n ??


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-258) Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods


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

ASF GitHub Bot commented on GEODE-258:
--

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/467
  
Thanks @kirklund and @upthewaterspout If I understand correctly 
getLoggerI18n should go away and replace with Log4j2. What is to be done for 
getSecurityLoggerI18n ??


> Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods
> ---
>
> Key: GEODE-258
> URL: https://issues.apache.org/jira/browse/GEODE-258
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods. 
> All calls can be replaced with getLogger().convertToLogWriterI18n() so this 
> should be a quick task.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2891) connect-timeout violation in C++ Native Client

2017-05-08 Thread Gregory Vortman (JIRA)

Gregory Vortman created GEODE-2891:
--

 Summary: connect-timeout violation in C++ Native Client
 Key: GEODE-2891
 URL: https://issues.apache.org/jira/browse/GEODE-2891
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Gregory Vortman
 Fix For: 1.1.1


1.  C++ native client doesn’t honour read-timeout-milli-sec in a consistent 
way while connecting to a server
2.  The lock on the connection pool has a very high granularity. Even if 
the client can’t connect to one server, all other threads which are working 
with totally different servers get affected by it




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2891) connect-timeout violation in C++ Native Client

2017-05-08 Thread Gregory Vortman (JIRA)


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

Gregory Vortman updated GEODE-2891:
---
Attachment: gemfire-connect-timeout-violation.docx

> connect-timeout violation in C++ Native Client
> --
>
> Key: GEODE-2891
> URL: https://issues.apache.org/jira/browse/GEODE-2891
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Gregory Vortman
> Fix For: 1.1.1
>
> Attachments: gemfire-connect-timeout-violation.docx
>
>
> 1.C++ native client doesn’t honour read-timeout-milli-sec in a consistent 
> way while connecting to a server
> 2.The lock on the connection pool has a very high granularity. Even if 
> the client can’t connect to one server, all other threads which are working 
> with totally different servers get affected by it



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

RE: [jira] [Updated] (GEODE-2891) connect-timeout violation in C++ Native Client

2017-05-08 Thread Dor Ben Dov

Hi,
How one can be assigned to this issue to solve it ? 
Actually who is going to switch it from backlog forward?

Regards,
Dor

-Original Message-
From: Gregory Vortman (JIRA) [mailto:j...@apache.org] 
Sent: יום ב 08 מאי 2017 14:09
To: dev@geode.apache.org
Subject: [jira] [Updated] (GEODE-2891) connect-timeout violation in C++ Native 
Client


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

Gregory Vortman updated GEODE-2891:
---
Attachment: gemfire-connect-timeout-violation.docx

> connect-timeout violation in C++ Native Client
> --
>
> Key: GEODE-2891
> URL: https://issues.apache.org/jira/browse/GEODE-2891
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Gregory Vortman
> Fix For: 1.1.1
>
> Attachments: gemfire-connect-timeout-violation.docx
>
>
> 1.C++ native client doesn’t honour read-timeout-milli-sec in a consistent 
> way while connecting to a server
> 2.The lock on the connection pool has a very high granularity. Even if 
> the client can’t connect to one server, all other threads which are working 
> with totally different servers get affected by it



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer

[jira] [Assigned] (GEODE-265) Remove deprecated methods on Execution interface

2017-05-08 Thread Deepak Dixit (JIRA)


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

Deepak Dixit reassigned GEODE-265:
--

Assignee: Deepak Dixit

> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #95: GEODE-2832: Fixing the link of README.md

2017-05-08 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/95


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2832) Fixing the link of README.md


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

ASF GitHub Bot commented on GEODE-2832:
---

Github user asfgit closed the pull request at:

https://github.com/apache/geode-native/pull/95


> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native issue #95: GEODE-2832: Fixing the link of README.md

2017-05-08 Thread pivotal-jbarrett

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/95
  
@masaki-yamakawa For future reference, please rebase your branch before 
pull requests and include the `GEODE-XX: ` prefix in your first line commit 
statement.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2832) Fixing the link of README.md


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

ASF GitHub Bot commented on GEODE-2832:
---

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode-native/pull/95
  
@masaki-yamakawa For future reference, please rebase your branch before 
pull requests and include the `GEODE-XX: ` prefix in your first line commit 
statement.



> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2832) Fixing the link of README.md

2017-05-08 Thread Jacob S. Barrett (JIRA)


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

Jacob S. Barrett reassigned GEODE-2832:
---

Assignee: Jacob S. Barrett

> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>Assignee: Jacob S. Barrett
>Priority: Minor
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2832) Fixing the link of README.md

2017-05-08 Thread Jacob S. Barrett (JIRA)


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

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

> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>Assignee: Jacob S. Barrett
>Priority: Minor
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (GEODE-2832) Fixing the link of README.md

2017-05-08 Thread Jacob S. Barrett (JIRA)


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

Jacob S. Barrett closed GEODE-2832.
---

> Fixing the link of README.md
> 
>
> Key: GEODE-2832
> URL: https://issues.apache.org/jira/browse/GEODE-2832
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Masaki Yamakawa
>Assignee: Jacob S. Barrett
>Priority: Minor
>
> Fixed an error in Markdown link notation of README.md.
> - Delete the space between the display name and the destination URL.
> - Fixed link destination of native-client-intro.html
> - Fixed link of BUILDING.md



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [gemfire-dev] New Client-Server Protocol Proposal

2017-05-08 Thread Jacob Barrett

On Fri, May 5, 2017 at 2:09 PM Hitesh Khamesra  wrote:

>
> 0. In first phase we are not doing chunking/fragmentation. And even this
> will be option for client.(
> https://cwiki.apache.org/confluence/display/GEODE/Message+Structure+and+Definition#MessageStructureandDefinition-Protocolnegotiation
> )
>

I highly suggest initial handshake be more relaxed than specific "version
number" or flags. Consider sending objects that indicate support for
features or even a list of feature IDs. At connect server can send list of
feature IDs to the client. The client can respond with a set of feature IDs
it supports as well as any metadata associated with them, say default set
of supported encodings.

> 1. Are you refereeing websocket/spdy? But I think we are talking almost
> same thing, may be push isPartialMessage flag with chunk length(Anthony's
> example below) ?
>

I am not sure what you mean here but if you are talking about layering a
channel protocol handler then I guess yes. The point is that each of these
behaviors should be encapsulated in specific layers and not intermixed with
the message.

> 2. That's the part of the problem. Even if you need to serialize the
> "String", you need to write length first and then need to write serialized
> utf bytes. We can implement chunked input stream and can de-serialize the
> object as it is coming (DataSerializable.fromData(ChunkedStream)).
>

Right, and in this case the length is never the length of the string, it is
the length of the byte encoding of the string. This is not known until the
encoding is complete. So by chunking we can write the length of smaller
buffers (from buffer pools) as the length of that sequence of bytes, the
last chunk terminated with length 0. Each of those chunks can be based to a
UTF-8 to UTF-16 transcoder to create the String.

-Jake

Re: Review Request 59035: GEODE-2883: Fix GFSH gc heap size output

2017-05-08 Thread Ken Howe


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59035/#review174171
---


Ship it!




Ship It!

- Ken Howe


On May 5, 2017, 11:19 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59035/
> ---
> 
> (Updated May 5, 2017, 11:19 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Jinmei Liao, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2883: Fix GFSH gc heap size output
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GarbageCollectionFunction.java
>  354d353 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/BytesToString.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59035/diff/3/
> 
> 
> Testing
> ---
> 
> Precheckin started (still running)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 59035: GEODE-2883: Fix GFSH gc heap size output

2017-05-08 Thread Jinmei Liao


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59035/#review174178
---


Ship it!




Ship It!

- Jinmei Liao


On May 5, 2017, 11:19 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59035/
> ---
> 
> (Updated May 5, 2017, 11:19 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Jinmei Liao, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2883: Fix GFSH gc heap size output
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GarbageCollectionFunction.java
>  354d353 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/BytesToString.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/BytesToStringTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59035/diff/3/
> 
> 
> Testing
> ---
> 
> Precheckin started (still running)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: ASF Board Report for Geode - Initial Reminder for May 2017

2017-05-08 Thread Mark Bretl

We need to submit a report by Friday and I have not seen any takers to
creating the report. If there are no volunteers, I will create a draft on
Wednesday.

--Mark

On Thu, Apr 27, 2017 at 12:48 PM, Mark Bretl  wrote:

> Hi Everyone,
>
> Amazing how three months goes by so fast! We are approaching six months
> since our TLP graduation and its time for another board report.
>
> Do we have any volunteers to create a draft? No need to be a PMC member
> either, anyone can be involved with writing the report. There is a template
> on the Geode wiki [1].
>
> Best regards,
>
> --Mark
>
> [1]: https://cwiki.apache.org/confluence/display/GEODE/ASF+
> Board+Report+Template
>
>
> -- Forwarded message --
> From: Brett Porter 
> Date: Wed, Apr 26, 2017 at 6:16 AM
> Subject: ASF Board Report for Geode - Initial Reminder for May 2017
> To: Mark Bretl 
> Cc: priv...@geode.apache.org
>
>
> This email was sent on behalf of the ASF Board.  It is an initial reminder
> to
> give you plenty of time to prepare the report.
>
> According to board records, you are listed as the chair of a committee
> that is
> due to submit a report this month. [1] [2]
>
> The meeting is scheduled for Wed, 17 May 2017 at 10:30 PDT and the
> deadline for
> submitting your report is 1 full week prior to that (Wed May 10th)!
>
> Meeting times in other time zones:
>
>   https://timeanddate.com/s/38ta
>
> Please submit your report with sufficient time to allow the board members
> to review and digest. Again, the very latest you should submit your report
> is 1 full week (7days) prior to the board meeting (Wed May 10th).
>
> If you feel that an error has been made, please consult [1] and if there
> is still an issue then contact the board directly.
>
> As always, PMC chairs are welcome to attend the board meeting.
>
> Thanks,
> The ASF Board
>
> [1] - https://svn.apache.org/repos/private/committers/board/commit
> tee-info.txt
> [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt
> [3] - https://svn.apache.org/repos/private/committers/board/templates
> [4] - https://reporter.apache.org/
>
>

[jira] [Updated] (GEODE-2880) value auto complete for member and file names does not work

2017-05-08 Thread Jinmei Liao (JIRA)


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

Jinmei Liao updated GEODE-2880:
---
Component/s: gfsh

> value auto complete for member and file names does not work
> ---
>
> Key: GEODE-2880
> URL: https://issues.apache.org/jira/browse/GEODE-2880
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
> Fix For: 1.2.0
>
>
> those command should be auto-completed with the correct values:
> connect --locator=yy
> stop server --member=xx
> start server --property-file=filename



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-1994) Change geode StringUtils to extend commons StringUtils

2017-05-08 Thread Patrick Rhomberg (JIRA)


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

Patrick Rhomberg updated GEODE-1994:

Component/s: management

> Change geode StringUtils to extend commons StringUtils
> --
>
> Key: GEODE-1994
> URL: https://issues.apache.org/jira/browse/GEODE-1994
> Project: Geode
>  Issue Type: Wish
>  Components: general, management
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>
> org.apache.geode.internal.lang.StringUtils duplicates some of the methods in 
> org.apache.commons.lang.StringUtils with some inconsistencies.
> isBlank is implemented identically
> isEmpty is inconsistent -- commons version returns true if string is null, 
> while geode version returns false if string is null



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-276) Remove deprecated RegionFactory constructors


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

Avinash Dongre reassigned GEODE-276:


Assignee: Avinash Dongre

> Remove deprecated RegionFactory constructors
> 
>
> Key: GEODE-276
> URL: https://issues.apache.org/jira/browse/GEODE-276
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The RegionFactory constructors were deprecated and should be removed. If you 
> want to create a RegionFactory the cache now has factory methods that will 
> create one.
> The old constructors are used in many tests but it should not be too hard to 
> convert them to use the new methods on the cache.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2885) Client users need an easy way to check counts on their server region


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

Fred Krone updated GEODE-2885:
--
Summary: Client users need an easy way to check counts on their server 
region  (was: Client users need an easy way to check on server)

> Client users need an easy way to check counts on their server region
> 
>
> Key: GEODE-2885
> URL: https://issues.apache.org/jira/browse/GEODE-2885
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Fred Krone
>
> When "getting" a region from the client, and putting or getting to that 
> region, certain methods can be very confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

2017-05-08 Thread Swapnil Bawaskar (JIRA)


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

Swapnil Bawaskar commented on GEODE-2874:
-

Hi [~hiteshkh25] Can you please provide a list of files in your working 
directory?

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-234) remove deprecated MirrorType class

2017-05-08 Thread Darrel Schneider (JIRA)


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

Darrel Schneider commented on GEODE-234:


What references to mirror-type did you find in the docs? I see that Karen added 
a comment that we did not have any so it would be helpful if you could describe 
the ones you found.

> remove deprecated MirrorType class
> --
>
> Key: GEODE-234
> URL: https://issues.apache.org/jira/browse/GEODE-234
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> All uses of MirrorType should be changed to use DataPolicy.REPLICATE.
> All apis that take it as a parameter or return it need to be deleted.
> The cache-9.0.xsd should also be changed to no longer have the "mirror-type" 
> region-attribute.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode issue #495: GEODE-234: Removed deprecated MirrorType class and its usa...

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/495

The xsd you are looking for is:
geode-core/build/resources/main/META-INF/schemas/geode.apache.org/schema/cache/cache-1.0.xsd

However you should not modify this one since it has already been released.
The next geode release will be 1.2 so you would want to create a new
cache-1.2.xsd and remove mirror-type from it. Introducing a new xsd involves a
bunch of busy work.
You need to add
org.apache.geode.internal.cache.xmlcache.CacheXml.VERSION_1_2,
update CacheXml.VERSION_LATEST,
add CacheXml.SCHEMA_1_2_LOCATION,
add CacheXmlVersion.GEODE_1_2,
add CacheXmlGeode12DUnitTest that extends CacheXmlGeode10DUnitTest.
I'm not sure what should be done about these dunit tests. They test the old
xsd/dtds which still do support mirror-type. If we remove support for the
mirror-type attribute from the xml parser code then all these old dtds and xsds
will no longer support mirror-type in their xml even though the old dtd/xsd
says it does. I think all the old dtds we still support also have data-policy
so even with that old dtd you could convert the mirror-type attribute to
data-policy in you existing xml.

---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-234) remove deprecated MirrorType class

2017-05-08 Thread ASF subversion and git services (JIRA)


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

ASF GitHub Bot commented on GEODE-234:
--

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/495
  
The xsd you are looking for is: 
geode-core/build/resources/main/META-INF/schemas/geode.apache.org/schema/cache/cache-1.0.xsd

However you should not modify this one since it has already been released.
The next geode release will be 1.2 so you would want to create a new 
cache-1.2.xsd and remove mirror-type from it. Introducing a new xsd involves a 
bunch of busy work.
You need to add 
org.apache.geode.internal.cache.xmlcache.CacheXml.VERSION_1_2,
update CacheXml.VERSION_LATEST,
add CacheXml.SCHEMA_1_2_LOCATION,
add CacheXmlVersion.GEODE_1_2,
add CacheXmlGeode12DUnitTest that extends CacheXmlGeode10DUnitTest.
I'm not sure what should be done about these dunit tests. They test the old 
xsd/dtds which still do support mirror-type. If we remove support for the 
mirror-type attribute from the xml parser code then all these old dtds and xsds 
will no longer support  mirror-type in their xml even though the old dtd/xsd 
says it does. I think all the old dtds we still support also have data-policy 
so even with that old dtd you could convert the mirror-type attribute to 
data-policy in you existing xml.


> remove deprecated MirrorType class
> --
>
> Key: GEODE-234
> URL: https://issues.apache.org/jira/browse/GEODE-234
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> All uses of MirrorType should be changed to use DataPolicy.REPLICATE.
> All apis that take it as a parameter or return it need to be deleted.
> The cache-9.0.xsd should also be changed to no longer have the "mirror-type" 
> region-attribute.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()


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

ASF subversion and git services commented on GEODE-2879:


Commit 288676dfed0d6d4e0b20e81b2392854fa1204cb6 in geode's branch 
refs/heads/feature/GEODE-2858 from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=288676d ]

Revert "GEODE-2879: LonerDistributionManager shutdown called from close"

This reverts commit 149e06d53a33fa7363da15bf3f9cb248d94fabf5.


> LonerDistributionManager's Shutdown not being called in close()
> ---
>
> Key: GEODE-2879
> URL: https://issues.apache.org/jira/browse/GEODE-2879
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> LonerDistributionManager shutdown was not being called from close() method 
> call.
> This resulted in the thread pool's threads to wait for 1 minute of inactivity 
> for them to be killed.
> This resulted in an extra delay while test executions.
> Solution:
> Call shutdown from close()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2858) Add test to verify successful load of configuration with pool or locator

2017-05-08 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2858:


Commit 2d33a671f6e7da8c8a7e149a551948920240dcc5 in geode's branch 
refs/heads/feature/GEODE-2858 from [~oshvarts]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2d33a67 ]

GEODE-2858: Add test for parsing of simple XML file w pool

to detect/prevent regression to parsing exceptions that
was fixed in Geode 1.0

This closes #397


> Add test to verify successful load of configuration with pool or locator
> 
>
> Key: GEODE-2858
> URL: https://issues.apache.org/jira/browse/GEODE-2858
> Project: Geode
>  Issue Type: Test
>  Components: client/server, locator
>Reporter: Oleg
>Assignee: Kirk Lund
>Priority: Minor
>
> Geode 0.9 / Gemfire 9.0 had a regression where it could not load config xml 
> file with pool or locator configuration in it.  It was fixed in 1.0 but no 
> test was added.  Add a unit test to prevent this coming back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2887) Exclude build-* output directories from rat license checking

2017-05-08 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2887:


Commit 25d02710ad9a03b516c59d4efad8834a1873786d in geode's branch 
refs/heads/feature/GEODE-2858 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=25d0271 ]

GEODE-2887: exclude build-* output directories from rat


> Exclude build-* output directories from rat license checking
> 
>
> Key: GEODE-2887
> URL: https://issues.apache.org/jira/browse/GEODE-2887
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The rat.gradle excludes "build" which is the directory that gradle writes to 
> when building geode on the command-line.
> I'd like to configure IntelliJ to write output to build-intellij and have 
> this not cause rat failures when building my checkout on the command-line.
> I've also seen others configure Eclipse to write output to build-eclipse, so 
> "build-*" would be a good pattern to add to the rat exclusions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2884) ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if called before getLatest()

2017-05-08 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on GEODE-2884:


Commit d3520eaf34cd3e5d01f85c758d8cd3ed3ef5939a in geode's branch 
refs/heads/feature/GEODE-2858 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d3520ea ]

GEODE-2884: fix NPE when calling getLatestAsClassLoader before getLatest

Without this fix, CacheXmlParserJUnitTest.testGetDelegate() fails when
run in isolation but passes when run with all tests.


> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest()
> -
>
> Key: GEODE-2884
> URL: https://issues.apache.org/jira/browse/GEODE-2884
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> ClassPathLoader.getLatestAsClassLoader() throws NullPointerException if 
> called before getLatest(). This manifests itself if you run 
> CacheXmlParserJUnitTest in isolation.
> {noformat}
> java.lang.NullPointerException
>   at 
> org.apache.geode.internal.ClassPathLoader.getLatestAsClassLoader(ClassPathLoader.java:372)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.getDelegate(CacheXmlParser.java:2770)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest$TestCacheXmlParser.getDelegate(CacheXmlParserJUnitTest.java:174)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParserJUnitTest.testGetDelegate(CacheXmlParserJUnitTest.java:67)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.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.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2874) StringIndexOutOfBoundsException while initializing logger

2017-05-08 Thread Hitesh Khamesra (JIRA)


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

Hitesh Khamesra commented on GEODE-2874:


Here is the list of files. I think log file was set to log-file="clientLog"


-bash-4.2$ ls
bin  client-01-01.log  client.log  clientLog  failedclientLog.txt  src

> StringIndexOutOfBoundsException while initializing logger
> -
>
> Key: GEODE-2874
> URL: https://issues.apache.org/jira/browse/GEODE-2874
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String 
> index out of range: -1
>   at java.lang.String.substring(String.java:1967)
>   at 
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.calcNextChildId(MainWithChildrenRollingFileHandler.java:47)
>   at 
> org.apache.geode.internal.logging.ManagerLogWriter.getLogNameForOldMainLog(ManagerLogWriter.java:330)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.createLogWriterAppender(LogWriterAppenders.java:144)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:72)
>   at 
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.java:88)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:304)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
>   at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207)
>   at GeodeClient.GeodeClient(GeodeClient.java:22)
>   at GeodeClient.main(GeodeClient.java:10)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2885) Client users need an easy way to check counts on their server region

2017-05-08 Thread ASF subversion and git services (JIRA)


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

Fred Krone resolved GEODE-2885.
---
Resolution: Duplicate

> Client users need an easy way to check counts on their server region
> 
>
> Key: GEODE-2885
> URL: https://issues.apache.org/jira/browse/GEODE-2885
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Fred Krone
>
> When "getting" a region from the client, and putting or getting to that 
> region, certain methods can be very confusing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2776) The version tag on client event is not updated when an entry is added to server using load operation.


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

ASF subversion and git services commented on GEODE-2776:


Commit 72d0d4baaccfb90e011286cb57d97174065256ae in geode's branch 
refs/heads/develop from [~agingade]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=72d0d4b ]

GEODE-2776: Setting version tag on the client event from the current region 
entry after load. And refactoring the findObjectInSystem().


> The version tag on client event is not updated when an entry is added to 
> server using load operation.
> -
>
> Key: GEODE-2776
> URL: https://issues.apache.org/jira/browse/GEODE-2776
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
>
> When client does a get() which results in adding an entry by calling loader 
> on server side, the client event returned back is not updated with the 
> version tag that is created with the new entry on server. This results in 
> client having a different version tag than the server side entry. If client 
> has registered event, and is concurrently updating the entry (from get() call 
> and an register-event from server), it could result in data consistency 
> between client and server.
> Scenario 1:
> On Server invalidate happens, and the event is added to client queue.
> Client does get()
> On Server, the get() triggers load + put on server. And the response is sent 
> back.
> Client gets the result from get() (which is newer) and applies to its cache.
> Client gets invalid event (older than get), and it applies the event to the 
> cache (this is supposed to be conflated, but due to this bug its not 
> conflated).
> At the end server has valid entry in the cache but client has invalid entry.
> On Server: INVALID (First), Get(From Client, LOAD+PUT) (later)
> On Client: GET(), PUT using Get Response(), INVALID (old)
> Scenario 2:
> Client does get()
> On Server, the get() triggers load + put on server. And the response is sent 
> back.
> On Server invalidate happens, and the event is added to client queue.
> Client gets invalid event, and it applies the event to the cache.
> Client gets the result from get() (which is older than invalidate) and 
> applies to its cache (this is supposed to be conflated, but due to this bug 
> its not conflated).
> At the end server has invalid entry in the cache but client has valid entry 
> (old value).
> On Server: Get(From Client, LOAD+PUT), INVALID (later)
> On Client: GET() (new), INVALID (old), PUT using Get Response().



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 59057: GEODE-2193 a member is kicked out immediately after joining

2017-05-08 Thread Bruce Schuchardt


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59057/
---

Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.


Bugs: GEODE-2193
https://issues.apache.org/jira/browse/GEODE-2193


Repository: geode


Description
---

The previous fix for this ticket introduced a shutdown problem that caused 
servers to pause waiting for ShutdownMessage to be sent to another server that 
had already exited.  We reduced the pause time but this change set fixes the 
problem by transmitting the message over UDP instead of TCP/IP stream sockets.

Another change in GMSJoinLeave prepareView/sendView allows a membership 
coordinator that is shutting down to complete the sending out of a new view if 
it has already prepared the view when shutdown begins.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 df880a076739509fe48394dd224ae2ea33c60dd5 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
 e0c0ba29a5c74614d2430fb78d972e306a355845 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 8ae66d0b6839cfbd46b479d896104f54fd11a68d 
  geode-core/src/main/java/org/apache/geode/internal/util/PluckStacks.java 
357812a6ec0cb09a88fa727a4bf828f18794264d 


Diff: https://reviews.apache.org/r/59057/diff/1/


Testing
---

precheckin plus 1000 runs of the test that was hitting this issue at least 4% 
of the time


Thanks,

Bruce Schuchardt

Re: Review Request 59040: when advisor cannot found target nodes for bucket id, should double check if the member is offline

2017-05-08 Thread Dan Smith


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59040/#review174195
---


Ship it!




Ship It!

- Dan Smith


On May 7, 2017, 5:47 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59040/
> ---
> 
> (Updated May 7, 2017, 5:47 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Dan Smith.
> 
> 
> Bugs: GEODE-2824
> https://issues.apache.org/jira/browse/GEODE-2824
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a race condition. When a member is offline (in redundentcopy=0 case), 
> an earlier check will found that. But if it passed the check, the code will 
> enter a retry loop to ask advisor to give the target node. Finally the 
> advisor will return an empty list of member. Then the code will screw up and 
> throw the "No target node found" exception. 
> 
> The fix is: when the empty list is return, double check if target node is 
> offline.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionExecutionNodePruner.java
>  18700a75d 
> 
> 
> Diff: https://reviews.apache.org/r/59040/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

[jira] [Resolved] (GEODE-2802) TombstoneMessage can throw SerializationException when region is configured as persistent and non-persistent in cluster (in different nodes).

2017-05-08 Thread Anilkumar Gingade (JIRA)


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

Anilkumar Gingade resolved GEODE-2802.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> TombstoneMessage can throw SerializationException when region is configured 
> as persistent and non-persistent in cluster (in different nodes).
> -
>
> Key: GEODE-2802
> URL: https://issues.apache.org/jira/browse/GEODE-2802
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> TombstoneMessage serialization code assumes the member info in RVV to be 
> either membership-id or disk-id and uses this info while de-serializing.
> When there is a mix of persistent and non-persistent region in the cluster 
> (between nodes), the above assumption will not hold good; resulting in data 
> serialization exception.
> DistributedTombstoneOperation$TombstoneMessage
> toData() {
> -
> -
>  if (persistent) {
>   DiskStoreID id = new DiskStoreID();
>   InternalDataSerializer.invokeFromData(id, in);
>   mbr = id;
> } 
> -
> -



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2863) DiskStoreImpl close does not shutdown its thread pools


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

Fred Krone updated GEODE-2863:
--
Labels: storage_3  (was: )

> DiskStoreImpl close does not shutdown its thread pools
> --
>
> Key: GEODE-2863
> URL: https://issues.apache.org/jira/browse/GEODE-2863
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>  Labels: storage_3
>
> Closing a DiskStoreImpl does not shutdown its thread pools.
> It has two pools, "diskStoreTaskPool" and "delayedWritePool", that it does 
> not shutdown.
> However at least in some cases (see GEODE-2862) it does wait for all the 
> tasks submitted to these pools to complete. But it is not clear if additional 
> tasks could still be submitted after this wait is done.
> Some logic should be added that causes the code that would submit a task to 
> these executors to no longer do so or, if needed, to process the task inline.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2860) refactor EventTracker to be on DistributedRegion instead of LocalRegion


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

Fred Krone updated GEODE-2860:
--
Labels: storage_3  (was: )

> refactor EventTracker to be on DistributedRegion instead of LocalRegion
> ---
>
> Key: GEODE-2860
> URL: https://issues.apache.org/jira/browse/GEODE-2860
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>  Labels: storage_3
>
> Currently LocalRegion has a non-final field named "eventTracker". It is 
> initialized in a method named createEventTracker which does nothing on 
> LocalRegion but is implemented on DistributedRegion and BucketRegion to 
> initialize the eventTracker field.
> I think things would be clearer if this field was moved to DistributedRegion.
> All the code on LocalRegion that currently tests for a non-null eventTracker 
> can be changed to do nothing and overridden on DistributedRegion to use its 
> eventTracker. DistributedRegion can make this field final and always set it 
> in its constructor. Since BucketRegion extends DistributedRegion it does not 
> to do anything (it currently implements createEventTracker but that was not 
> needed since it inherits the same impl from DistributedRegion).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2862) shutdown hook does not wait for disk store async tasks to complete


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

Fred Krone updated GEODE-2862:
--
Labels: storage_3  (was: )

> shutdown hook does not wait for disk store async tasks to complete
> --
>
> Key: GEODE-2862
> URL: https://issues.apache.org/jira/browse/GEODE-2862
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>  Labels: storage_3
>
> If you do a normal cache close and are using persistence then each disk store 
> close will wait for all of its async background tasks to complete.
> But if instead the JVM shutdown hook is used (see 
> java.lang.Runtime.addShutdownHook(Thread) for a description of what causes 
> the shutdown hook to be called) then it will not wait for the async 
> persistent tasks to complete.
> Both of these types of shutdown are considered an orderly shutdown (as 
> opposed to a unorderly shutdown caused by things like a kill -9) and geode 
> should only have one type of orderly shutdown. By not waiting for the async 
> persistent tasks to complete some files may never be fully written.
> Here is the code that causes the shutdown hook to not wait in DiskStoreImpl:
> {code}
>   // don't block the shutdown hook
>   if (Thread.currentThread() != InternalDistributedSystem.shutdownHook) {
> waitForBackgroundTasks();
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2861) remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool


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

Fred Krone updated GEODE-2861:
--
Labels: storage_3  (was: )

> remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool
> ---
>
> Key: GEODE-2861
> URL: https://issues.apache.org/jira/browse/GEODE-2861
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Priority: Trivial
>  Labels: storage_3
>
> Both GemFireCacheImpl and DiskStoreImpl have deadcode related to shutting 
> down the DiskStoreTaskPool.
> On DiskStoreImpl see these methods:
>   stopDiskStoreTaskPool
>   shutdownPool
> On GemFireCacheImpl the field diskStoreTaskPool is always null.
> Note that a bug exists in this deadcode that causes it to not call 
> taskCancelled as it iterates over a list of runnables. Since this code is 
> dead it is currently doing no harm but if the code is not removed then make 
> sure and fix this loop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2829) VMRegionVersionVector allows/stores DiskStoreId as its member id


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

Fred Krone updated GEODE-2829:
--
Labels: storage_3  (was: storage_2)

> VMRegionVersionVector allows/stores DiskStoreId as its member id
> 
>
> Key: GEODE-2829
> URL: https://issues.apache.org/jira/browse/GEODE-2829
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>  Labels: storage_3
>
> The VMRegionVersionVector is a region version vector for regions without 
> persistent data. This region version vector suppose to allow the 
> InternalDistributedMember as the member id, but currently it allows both 
> DiskStoreId and InternalDistributedMember as member ids.
> This is in relation to ticket# GEODE-2802
> The issue can be reproduced by having persistent and non-persistent region in 
> the cluster (same region name). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-site pull request #2: GEODE-2554 Add htaccess file for docs redirect

2017-05-08 Thread joeymcallister

GitHub user joeymcallister opened a pull request:

https://github.com/apache/geode-site/pull/2

GEODE-2554 Add htaccess file for docs redirect



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/joeymcallister/geode-site feature/GEODE-2554

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode-site/pull/2.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2


commit da2e988acb269aa4befa13236e7bbf49c5a354ba
Author: joeymcallister 
Date:   2017-05-08T17:37:18Z

GEODE-2554 Add htaccess file for docs redirect




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 58996: GEODE-2876: Add logging to diagnose CI failure

2017-05-08 Thread Patrick Rhomberg


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58996/#review174197
---


Ship it!




Ship It!

- Patrick Rhomberg


On May 5, 2017, 11:15 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58996/
> ---
> 
> (Updated May 5, 2017, 11:15 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2876: Add logging to diagnose CI failure
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  20ae022 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e14 
> 
> 
> Diff: https://reviews.apache.org/r/58996/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up


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

ASF GitHub Bot commented on GEODE-2554:
---

GitHub user joeymcallister opened a pull request:

https://github.com/apache/geode-site/pull/2

GEODE-2554 Add htaccess file for docs redirect



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/joeymcallister/geode-site feature/GEODE-2554

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode-site/pull/2.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2


commit da2e988acb269aa4befa13236e7bbf49c5a354ba
Author: joeymcallister 
Date:   2017-05-08T17:37:18Z

GEODE-2554 Add htaccess file for docs redirect




> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2859) ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.

2017-05-08 Thread Jared Stewart (JIRA)


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

Jared Stewart reassigned GEODE-2859:


Assignee: Jared Stewart

> ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction failing in CI.
> 
>
> Key: GEODE-2859
> URL: https://issues.apache.org/jira/browse/GEODE-2859
> Project: Geode
>  Issue Type: Test
>  Components: gfsh, membership, messaging, tests
>Reporter: Galen O'Sullivan
>Assignee: Jared Stewart
>
> https://builds.apache.org/job/Geode-nightly/821/
> This test is a copy of GemFireDeadlockDetectorDUnitTest.java, which was 
> recently updated (https://reviews.apache.org/r/58541/diff/1#index_header). 
> Probably it needs the same fix or related.
> ShowDeadlockDUnitTest.testNoDeadlock also fails in this test run.
> {code}
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest.testDistributedDeadlockWithFunction(ShowDeadlockDUnitTest.java:156)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:

[GitHub] geode pull request #498: GEODE-2881: Wait for waitForFlushBeforeExecuteTextS...

2017-05-08 Thread nabarunnag

GitHub user nabarunnag opened a pull request:

https://github.com/apache/geode/pull/498

GEODE-2881: Wait for waitForFlushBeforeExecuteTextSearch to complete

* Test now waits for waitForFlushBeforeExecuteTextSearch initiated by 
the test hook.
* The test hook gets called when GII is requested.
* This task may hit CacheClosedException if the test get completed 
before the flush operations of GII


Potential Reviewers
@upthewaterspout @jhuynh1 @gesterzhou @ladyVader 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2881

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/498.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #498


commit 2e7c610adefe01f81c98acf3294aacede18a5c91
Author: nabarun 
Date:   2017-05-06T00:13:20Z

GEODE-2881: Wait for waitForFlushBeforeExecuteTextSearch to complete

* Test now waits for waitForFlushBeforeExecuteTextSearch initiated by 
the test hook.
* The test hook gets called when GII is requested.
* This task may hit CacheClosedException if the test get completed 
before the flush operations of GII




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2881) waitForFlushBeforeExecuteTextSearch instance hits cache closed exception because test is completed


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

ASF GitHub Bot commented on GEODE-2881:
---

GitHub user nabarunnag opened a pull request:

https://github.com/apache/geode/pull/498

GEODE-2881: Wait for waitForFlushBeforeExecuteTextSearch to complete

* Test now waits for waitForFlushBeforeExecuteTextSearch initiated by 
the test hook.
* The test hook gets called when GII is requested.
* This task may hit CacheClosedException if the test get completed 
before the flush operations of GII


Potential Reviewers
@upthewaterspout @jhuynh1 @gesterzhou @ladyVader 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2881

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/498.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #498


commit 2e7c610adefe01f81c98acf3294aacede18a5c91
Author: nabarun 
Date:   2017-05-06T00:13:20Z

GEODE-2881: Wait for waitForFlushBeforeExecuteTextSearch to complete

* Test now waits for waitForFlushBeforeExecuteTextSearch initiated by 
the test hook.
* The test hook gets called when GII is requested.
* This task may hit CacheClosedException if the test get completed 
before the flush operations of GII




> waitForFlushBeforeExecuteTextSearch instance hits cache closed exception 
> because test is completed
> --
>
> Key: GEODE-2881
> URL: https://issues.apache.org/jira/browse/GEODE-2881
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> The returnCorrectResultsWhenIndexUpdateHappensIntheMiddleofGII tests creates 
> a test hook which calls waitForFlushBeforeExecuteTextSearch when GII is 
> requested and also the test calls waitForFlushBeforeExecuteTextSearch before 
> executing a Lucene Query. 
> Both calls occur in different threads and if the wait for flush called by the 
> test hook is still executing while the test is completed, the caches are shut 
> down and it gets a CacheClosedException
> Solution:
> Make sure the test hook's wait for flush is completed before the test is 
> terminated / before executing a query



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59057: GEODE-2193 a member is kicked out immediately after joining

2017-05-08 Thread Hitesh Khamesra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59057/#review174198
---




geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
Line 830 (original)


I think problem here is, we send shutdown message using Tcp layer. In that 
case, "receiver1" gets that shutdown message and pass that info to membership 
layer. Then "receiver1" becomes coordinator(legal coordinator) by removing 
current coordinator. Now if current coordinator sends new view then cluster 
just ignores that view, as cluster has new-view by "receiver1".


- Hitesh Khamesra


On May 8, 2017, 5:23 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59057/
> ---
> 
> (Updated May 8, 2017, 5:23 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2193
> https://issues.apache.org/jira/browse/GEODE-2193
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix for this ticket introduced a shutdown problem that caused 
> servers to pause waiting for ShutdownMessage to be sent to another server 
> that had already exited.  We reduced the pause time but this change set fixes 
> the problem by transmitting the message over UDP instead of TCP/IP stream 
> sockets.
> 
> Another change in GMSJoinLeave prepareView/sendView allows a membership 
> coordinator that is shutting down to complete the sending out of a new view 
> if it has already prepared the view when shutdown begins.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  e0c0ba29a5c74614d2430fb78d972e306a355845 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  8ae66d0b6839cfbd46b479d896104f54fd11a68d 
>   geode-core/src/main/java/org/apache/geode/internal/util/PluckStacks.java 
> 357812a6ec0cb09a88fa727a4bf828f18794264d 
> 
> 
> Diff: https://reviews.apache.org/r/59057/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin plus 1000 runs of the test that was hitting this issue at least 4% 
> of the time
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

gradle upgrade has broken IntelliJ

2017-05-08 Thread ASF subversion and git services (JIRA)

Our recent gradle upgrade seems to have broken IntelliJ. I've tried
refreshing from gradle. I've even tried deleting .idea and my IntelliJ
output directory and rebuilding my IntelliJ project in a couple different
ways.

No matter what I do, it seems to be stuck and IntelliJ refuses to work now.
I'm up-to-date with latest version of IntelliJ as well.

The only info from IntelliJ is the following:

Gradle 'geode' project refresh failed
Error:Cannot change dependencies of configuration ':geode-core:antlr' after
it has been included in dependency resolution.

Anyone else seeing this? Anyone know how to fix this? It's completely
blocking my ability to work right now.

[jira] [Reopened] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()

2017-05-08 Thread nabarun (JIRA)


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

nabarun reopened GEODE-2879:


> LonerDistributionManager's Shutdown not being called in close()
> ---
>
> Key: GEODE-2879
> URL: https://issues.apache.org/jira/browse/GEODE-2879
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> LonerDistributionManager shutdown was not being called from close() method 
> call.
> This resulted in the thread pool's threads to wait for 1 minute of inactivity 
> for them to be killed.
> This resulted in an extra delay while test executions.
> Solution:
> Call shutdown from close()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2824) FunctionException: No target node found when executing hasNext on Lucene result


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

ASF subversion and git services commented on GEODE-2824:


Commit 3f1482b689db67a764b1f6507d4482a45e4bd11f in geode's branch 
refs/heads/develop from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3f1482b ]

GEODE-2824: When advisor cannot found target nodes for bucket id, should double 
check if the member is offline.


> FunctionException: No target node found when executing hasNext on Lucene 
> result
> ---
>
> Key: GEODE-2824
> URL: https://issues.apache.org/jira/browse/GEODE-2824
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: xiaojian zhou
>
> The stack trace below is thrown during a race condition when a node is 
> closing and calling hasNext on a Lucene result.
> It looks there was a CacheClosedException, but this execution was unable to 
> find a target node to retry on.  This execution then threw a 
> FunctionException.
> We have code to unwrap CacheClosedExceptions from function exceptions, 
> however this was just an ordinary function exception.  The underlying cause 
> is that the cache is closing at this time.
> We should probably wrap all function exceptions with either a 
> LuceneQueryException or equivalent as a user would probably not expect a 
> FunctionException when calling Lucene methods.
> The stack trace:
> {noformat}
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnMultipleNodes(PartitionedRegion.java:3459)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3367)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:228)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at 
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:178)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getValues(PageableLuceneQueryResultsImpl.java:112)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getHitEntries(PageableLuceneQueryResultsImpl.java:91)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.advancePage(PageableLuceneQueryResultsImpl.java:139)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.hasNext(PageableLuceneQueryResultsImpl.java:148)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2878) If an exception occurs after retrieving an XAConnection from the ConnectionProvider but before returning it to the application, the GemFireTransactionDataSource doesn't r


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

Fred Krone updated GEODE-2878:
--
Labels: storage_3  (was: )

> If an exception occurs after retrieving an XAConnection from the 
> ConnectionProvider but before returning it to the application, the 
> GemFireTransactionDataSource doesn't return it to the pool
> --
>
> Key: GEODE-2878
> URL: https://issues.apache.org/jira/browse/GEODE-2878
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Barry Oglesby
>  Labels: storage_3
>
> In my test, I have 5 threads inserting rows into a derby database.
> At first, as connections are being used and returned, the 
> {{activeConnections}} is updated correctly:
> {noformat}
> Thread-16: AbstractPoolCache.getPooledConnectionFromPool activeConnections=1
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=2
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=3
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=4
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=5
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=4
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=3
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=2
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=1
> Thread-15: AbstractPoolCache.returnPooledConnectionToPool activeConnections=0
> {noformat}
> But, then if an exception occurs after retrieving the {{XAConnection}}, it is 
> not return to the {{ConnectionProvider}}.
> In my test, the exception occurs in 
> {{GemFireTransactionDataSource.registerTranxConnection}}:
> {noformat}
> java.lang.Exception: GemFireTransactionDataSource-registerTranxConnection(). 
> Exception in registering the XAResource with the Transaction.Exception 
> occurred= javax.transaction.SystemException: 
> GlobalTransaction::enlistResource::error while enlisting XAResource 
> org.apache.derby.client.am.XaException: XAER_RMFAIL : An error occurred 
> during a deferred connect reset and the connection has been terminated.
>   at 
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.registerTranxConnection(GemFireTransactionDataSource.java:218)
>   at 
> org.apache.geode.internal.datasource.GemFireTransactionDataSource.getConnection(GemFireTransactionDataSource.java:127)
>   at TestServer.saveToDB(TestServer.java:177)
>   at TestServer.save(TestServer.java:154)
>   at TestServer.loadEntriesIntoDerby(TestServer.java:127)
>   at TestServer$1.run(TestServer.java:112)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is after the {{XAConnection}} has been retrieved from the 
> {{ConnectionProvider}} and the {{activeConnections}} incremented, but before 
> it has been returned to the application. Neither the 
> {{registerTranxConnection}} method nor its caller ({{getConnection}}) does 
> anything other than to throw the exception. The {{XAConnection}} is not 
> returned to the pool nor is the {{activeConnections}} decremented.
> Finally, if enough of these exceptions occur, the test stops because all 30 
> (default max) connections are in use. They aren't really in use, its just 
> that the activeConnections counter hasn't been properly maintained.
> {noformat}
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
> Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
> Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
> Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
> {noformat}
> It doesn't really matter what the exception is. If one occurs after 
> retrieving the {{XAConnection}}, it needs to be returned to the 
> {{ConnectionProvider}} or at the very least, the {{activeConnections}} must 
> be decremented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #499: GEODE-2879: Shutdown() called from close() in Loner...

2017-05-08 Thread nabarunnag

GitHub user nabarunnag opened a pull request:

https://github.com/apache/geode/pull/499

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method

Potential reviewers
@upthewaterspout @jhuynh1 @gesterzhou @ladyVader @boglesby 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2879

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/499.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #499


commit 57ff93335a01d8ae49fb087a0cd299dbb426485a
Author: nabarun 
Date:   2017-05-05T23:28:17Z

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()


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

ASF GitHub Bot commented on GEODE-2879:
---

GitHub user nabarunnag opened a pull request:

https://github.com/apache/geode/pull/499

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method

Potential reviewers
@upthewaterspout @jhuynh1 @gesterzhou @ladyVader @boglesby 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-2879

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/499.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #499


commit 57ff93335a01d8ae49fb087a0cd299dbb426485a
Author: nabarun 
Date:   2017-05-05T23:28:17Z

GEODE-2879: Shutdown() called from close() in LonerDistributionManager

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method




> LonerDistributionManager's Shutdown not being called in close()
> ---
>
> Key: GEODE-2879
> URL: https://issues.apache.org/jira/browse/GEODE-2879
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> LonerDistributionManager shutdown was not being called from close() method 
> call.
> This resulted in the thread pool's threads to wait for 1 minute of inactivity 
> for them to be killed.
> This resulted in an extra delay while test executions.
> Solution:
> Call shutdown from close()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2824) FunctionException: No target node found when executing hasNext on Lucene result

2017-05-08 Thread xiaojian zhou (JIRA)


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

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

> FunctionException: No target node found when executing hasNext on Lucene 
> result
> ---
>
> Key: GEODE-2824
> URL: https://issues.apache.org/jira/browse/GEODE-2824
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: xiaojian zhou
>
> The stack trace below is thrown during a race condition when a node is 
> closing and calling hasNext on a Lucene result.
> It looks there was a CacheClosedException, but this execution was unable to 
> find a target node to retry on.  This execution then threw a 
> FunctionException.
> We have code to unwrap CacheClosedExceptions from function exceptions, 
> however this was just an ordinary function exception.  The underlying cause 
> is that the cache is closing at this time.
> We should probably wrap all function exceptions with either a 
> LuceneQueryException or equivalent as a user would probably not expect a 
> FunctionException when calling Lucene methods.
> The stack trace:
> {noformat}
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnMultipleNodes(PartitionedRegion.java:3459)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3367)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:228)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at 
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:178)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getValues(PageableLuceneQueryResultsImpl.java:112)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getHitEntries(PageableLuceneQueryResultsImpl.java:91)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.advancePage(PageableLuceneQueryResultsImpl.java:139)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.hasNext(PageableLuceneQueryResultsImpl.java:148)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: gradle upgrade has broken IntelliJ

2017-05-08 Thread ASF subversion and git services (JIRA)

Even the "idea" task in gradle fails:

$ ./gradlew idea
...
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-core:ideaModule'.
> Cannot change dependencies of configuration ':geode-core:antlr' after it
has been included in dependency resolution.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 6.515 secs

I think we should roll back the commit that upgraded gradle until someone
with more gradle+intellij knowledge can fix this for the rest of us.

On Mon, May 8, 2017 at 10:46 AM, Kirk Lund  wrote:

> Our recent gradle upgrade seems to have broken IntelliJ. I've tried
> refreshing from gradle. I've even tried deleting .idea and my IntelliJ
> output directory and rebuilding my IntelliJ project in a couple different
> ways.
>
> No matter what I do, it seems to be stuck and IntelliJ refuses to work
> now. I'm up-to-date with latest version of IntelliJ as well.
>
> The only info from IntelliJ is the following:
>
> Gradle 'geode' project refresh failed
> Error:Cannot change dependencies of configuration ':geode-core:antlr'
> after it has been included in dependency resolution.
>
> Anyone else seeing this? Anyone know how to fix this? It's completely
> blocking my ability to work right now.
>
>

[jira] [Updated] (GEODE-2824) FunctionException: No target node found when executing hasNext on Lucene result

2017-05-08 Thread xiaojian zhou (JIRA)


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

xiaojian zhou updated GEODE-2824:
-
Fix Version/s: 1.2.0

> FunctionException: No target node found when executing hasNext on Lucene 
> result
> ---
>
> Key: GEODE-2824
> URL: https://issues.apache.org/jira/browse/GEODE-2824
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: xiaojian zhou
> Fix For: 1.2.0
>
>
> The stack trace below is thrown during a race condition when a node is 
> closing and calling hasNext on a Lucene result.
> It looks there was a CacheClosedException, but this execution was unable to 
> find a target node to retry on.  This execution then threw a 
> FunctionException.
> We have code to unwrap CacheClosedExceptions from function exceptions, 
> however this was just an ordinary function exception.  The underlying cause 
> is that the cache is closing at this time.
> We should probably wrap all function exceptions with either a 
> LuceneQueryException or equivalent as a user would probably not expect a 
> FunctionException when calling Lucene methods.
> The stack trace:
> {noformat}
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnMultipleNodes(PartitionedRegion.java:3459)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3367)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:228)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at 
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:178)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getValues(PageableLuceneQueryResultsImpl.java:112)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.getHitEntries(PageableLuceneQueryResultsImpl.java:91)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.advancePage(PageableLuceneQueryResultsImpl.java:139)
> at 
> org.apache.geode.cache.lucene.internal.PageableLuceneQueryResultsImpl.hasNext(PageableLuceneQueryResultsImpl.java:148)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59057: GEODE-2193 a member is kicked out immediately after joining

2017-05-08 Thread Hitesh Khamesra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59057/#review174199
---




geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
Line 1865 (original), 1865 (patched)


I am not sure this will also helps as it is similar to real 
proplem(describe earlier), where receiver will become new coordinator. And that 
will create new view by removing current coordinator.


- Hitesh Khamesra


On May 8, 2017, 5:23 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59057/
> ---
> 
> (Updated May 8, 2017, 5:23 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2193
> https://issues.apache.org/jira/browse/GEODE-2193
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix for this ticket introduced a shutdown problem that caused 
> servers to pause waiting for ShutdownMessage to be sent to another server 
> that had already exited.  We reduced the pause time but this change set fixes 
> the problem by transmitting the message over UDP instead of TCP/IP stream 
> sockets.
> 
> Another change in GMSJoinLeave prepareView/sendView allows a membership 
> coordinator that is shutting down to complete the sending out of a new view 
> if it has already prepared the view when shutdown begins.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  e0c0ba29a5c74614d2430fb78d972e306a355845 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  8ae66d0b6839cfbd46b479d896104f54fd11a68d 
>   geode-core/src/main/java/org/apache/geode/internal/util/PluckStacks.java 
> 357812a6ec0cb09a88fa727a4bf828f18794264d 
> 
> 
> Diff: https://reviews.apache.org/r/59057/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin plus 1000 runs of the test that was hitting this issue at least 4% 
> of the time
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 58996: GEODE-2876: Add logging to diagnose CI failure

2017-05-08 Thread Jinmei Liao


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58996/#review174200
---


Ship it!




Ship It!

- Jinmei Liao


On May 5, 2017, 11:15 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58996/
> ---
> 
> (Updated May 5, 2017, 11:15 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2876: Add logging to diagnose CI failure
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  20ae022 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e14 
> 
> 
> Diff: https://reviews.apache.org/r/58996/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2881) waitForFlushBeforeExecuteTextSearch instance hits cache closed exception because test is completed


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

ASF subversion and git services commented on GEODE-2881:


Commit 7030dcdec5be21e2ae3bb1500020e2ec6700a35b in geode's branch 
refs/heads/develop from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7030dcd ]

GEODE-2881: Wait for waitForFlushBeforeExecuteTextSearch to complete

* Test now waits for waitForFlushBeforeExecuteTextSearch initiated by 
the test hook.
* The test hook gets called when GII is requested.
* This task may hit CacheClosedException if the test get completed 
before the flush operations of GII


> waitForFlushBeforeExecuteTextSearch instance hits cache closed exception 
> because test is completed
> --
>
> Key: GEODE-2881
> URL: https://issues.apache.org/jira/browse/GEODE-2881
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> The returnCorrectResultsWhenIndexUpdateHappensIntheMiddleofGII tests creates 
> a test hook which calls waitForFlushBeforeExecuteTextSearch when GII is 
> requested and also the test calls waitForFlushBeforeExecuteTextSearch before 
> executing a Lucene Query. 
> Both calls occur in different threads and if the wait for flush called by the 
> test hook is still executing while the test is completed, the caches are shut 
> down and it gets a CacheClosedException
> Solution:
> Make sure the test hook's wait for flush is completed before the test is 
> terminated / before executing a query



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Build failed in Jenkins: Geode-nightly #829

2017-05-08 Thread Apache Jenkins Server

See 

--
[...truncated 120.69 KB...]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.geode.cache.execute.FunctionException: 
org.apache.geode.cache.CacheClosedException: The cache is closed.
at 
org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.setException(LocalResultCollectorImpl.java:187)
at 
org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultSender.setException(PartitionedRegionFunctionResultSender.java:381)
at 
org.apache.geode.internal.cache.execute.AbstractExecution.handleException(AbstractExecution.java:587)
at 
org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:358)
at 
org.apache.geode.internal.cache.execute.AbstractExecution$1.run(AbstractExecution.java:275)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
at 
org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1071)
... 1 more
Caused by: org.apache.geode.cache.CacheClosedException: The cache is closed.
at 
org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1519)
at 
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at 
org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7656)
at 
org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2788)
at 
org.apache.geode.internal.cache.BucketRegion.checkReadiness(BucketRegion.java:1371)
at 
org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:9140)
at 
org.apache.geode.internal.cache.LocalRegion.isEmpty(LocalRegion.java:9176)
at 
org.apache.geode.internal.cache.BucketRegionQueue.waitUntilFlushed(BucketRegionQueue.java:485)
at 
org.apache.geode.internal.cache.wan.parallel.WaitUntilParallelGatewaySenderFlushedCoordinator$WaitUntilBucketRegionQueueFlushedCallable.call(WaitUntilParallelGatewaySenderFlushedCoordinator.java:131)
at 
org.apache.geode.internal.cache.wan.parallel.WaitUntilParallelGatewaySenderFlushedCoordinator$WaitUntilBucketRegionQueueFlushedCallable.call(WaitUntilParallelGatewaySenderFlushedCoordinator.java:111)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
at 
org.apache.geode.distributed.internal.DistributionManager$6$1.run(DistributionManager.java:952)
... 1 more

300 tests completed, 1 failed
:geode-lucene:distributedTest FAILED
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources NO-SOURCE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc NO-SOURCE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava NO-SOURCE
:geode-old-versions:processTestResources NO-SOURCE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests NO-SOURCE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test NO-SOURCE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest NO-SOURCE
:geode-old-versions:flakyTest NO-SOURCE
:geode-old-versions:integrationTest NO-SOURCE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note:

Re: Review Request 58996: GEODE-2876: Add logging to diagnose CI failure

2017-05-08 Thread Ken Howe


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58996/#review174201
---


Ship it!




Ship It!

- Ken Howe


On May 5, 2017, 11:15 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58996/
> ---
> 
> (Updated May 5, 2017, 11:15 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2876: Add logging to diagnose CI failure
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  20ae022 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e14 
> 
> 
> Diff: https://reviews.apache.org/r/58996/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2881) waitForFlushBeforeExecuteTextSearch instance hits cache closed exception because test is completed


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

ASF GitHub Bot commented on GEODE-2881:
---

Github user nabarunnag closed the pull request at:

https://github.com/apache/geode/pull/498


> waitForFlushBeforeExecuteTextSearch instance hits cache closed exception 
> because test is completed
> --
>
> Key: GEODE-2881
> URL: https://issues.apache.org/jira/browse/GEODE-2881
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> The returnCorrectResultsWhenIndexUpdateHappensIntheMiddleofGII tests creates 
> a test hook which calls waitForFlushBeforeExecuteTextSearch when GII is 
> requested and also the test calls waitForFlushBeforeExecuteTextSearch before 
> executing a Lucene Query. 
> Both calls occur in different threads and if the wait for flush called by the 
> test hook is still executing while the test is completed, the caches are shut 
> down and it gets a CacheClosedException
> Solution:
> Make sure the test hook's wait for flush is completed before the test is 
> terminated / before executing a query



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #498: GEODE-2881: Wait for waitForFlushBeforeExecuteTextS...

2017-05-08 Thread nabarunnag

Github user nabarunnag closed the pull request at:

https://github.com/apache/geode/pull/498


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: gradle upgrade has broken IntelliJ

Looks like it's geode-core:antlr dependency in both CLI gradlew and within
IntelliJ. Here's the full stack trace in gradlew:

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task
':geode-core:ideaModule'.
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:84)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:55)
at
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
at
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at
org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:46)
at
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
at
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at
org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at
org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
at
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
at
org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at
org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at
org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:61)
at
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
at
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
at
org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:32)
at
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:113)
at
org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at
org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
at
org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
at
org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
at
org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:256)
at
org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:253)
at
org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at
org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at
org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
at
org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:175)
at
org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:119)
at
org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:102)
at
org.gradle.launcher.exec.GradleBuildController.run(GradleBuildController.java:71)
at
org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
at
org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at
org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75)
at
org.gradle.tooling.internal.provid

[jira] [Resolved] (GEODE-2881) waitForFlushBeforeExecuteTextSearch instance hits cache closed exception because test is completed

2017-05-08 Thread nabarun (JIRA)


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

nabarun resolved GEODE-2881.

   Resolution: Fixed
Fix Version/s: 1.2.0

> waitForFlushBeforeExecuteTextSearch instance hits cache closed exception 
> because test is completed
> --
>
> Key: GEODE-2881
> URL: https://issues.apache.org/jira/browse/GEODE-2881
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> The returnCorrectResultsWhenIndexUpdateHappensIntheMiddleofGII tests creates 
> a test hook which calls waitForFlushBeforeExecuteTextSearch when GII is 
> requested and also the test calls waitForFlushBeforeExecuteTextSearch before 
> executing a Lucene Query. 
> Both calls occur in different threads and if the wait for flush called by the 
> test hook is still executing while the test is completed, the caches are shut 
> down and it gets a CacheClosedException
> Solution:
> Make sure the test hook's wait for flush is completed before the test is 
> terminated / before executing a query



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: gradle upgrade has broken IntelliJ

Looks like other projects are seeing this or something similar. Anyone with
more gradle expertise want to try and fix this?

There's some mention of a workaround here:
https://github.com/akhikhl/gretty/issues/306

On Mon, May 8, 2017 at 11:00 AM, Kirk Lund  wrote:

> Looks like it's geode-core:antlr dependency in both CLI gradlew and within
> IntelliJ. Here's the full stack trace in gradlew:
>
> * Exception is:
> org.gradle.api.tasks.TaskExecutionException: Execution failed for task
> ':geode-core:ideaModule'.
> at org.gradle.api.internal.tasks.execution.
> ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.
> java:84)
> at org.gradle.api.internal.tasks.execution.
> ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:55)
> at org.gradle.api.internal.tasks.execution.
> SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
> at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.
> execute(ValidatingTaskExecuter.java:58)
> at org.gradle.api.internal.tasks.execution.
> SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecut
> er.java:88)
> at org.gradle.api.internal.tasks.execution.
> ResolveTaskArtifactStateTaskExecuter.execute(
> ResolveTaskArtifactStateTaskExecuter.java:46)
> at org.gradle.api.internal.tasks.execution.
> SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.
> java:51)
> at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.
> execute(SkipOnlyIfTaskExecuter.java:54)
> at org.gradle.api.internal.tasks.execution.
> ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.
> java:43)
> at org.gradle.api.internal.tasks.execution.
> CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
> at org.gradle.internal.Transformers$4.transform(
> Transformers.java:169)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:106)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:61)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$
> EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$
> TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$
> TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
> at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(
> DefaultTaskPlanExecutor.java:32)
> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.
> execute(DefaultTaskGraphExecuter.java:113)
> at org.gradle.execution.SelectedTaskExecutionAction.execute(
> SelectedTaskExecutionAction.java:37)
> at org.gradle.execution.DefaultBuildExecuter.execute(
> DefaultBuildExecuter.java:37)
> at org.gradle.execution.DefaultBuildExecuter.access$
> 000(DefaultBuildExecuter.java:23)
> at org.gradle.execution.DefaultBuildExecuter$1.
> proceed(DefaultBuildExecuter.java:43)
> at org.gradle.execution.DryRunBuildExecutionAction.execute(
> DryRunBuildExecutionAction.java:32)
> at org.gradle.execution.DefaultBuildExecuter.execute(
> DefaultBuildExecuter.java:37)
> at org.gradle.execution.DefaultBuildExecuter.execute(
> DefaultBuildExecuter.java:30)
> at org.gradle.initialization.DefaultGradleLauncher$
> RunTasksAction.execute(DefaultGradleLauncher.java:256)
> at org.gradle.initialization.DefaultGradleLauncher$
> RunTasksAction.execute(DefaultGradleLauncher.java:253)
> at org.gradle.internal.Transformers$4.transform(
> Transformers.java:169)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:106)
> at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(
> DefaultBuildOperationExecutor.java:56)
> at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(
> DefaultGradleLauncher.java:175)
> at org.gradle.initialization.DefaultGradleLauncher.doBuild(
> DefaultGradleLauncher.java:119)
> at org.gradle.initialization.DefaultGradleLauncher.run(
> DefaultGradleLauncher.java:102)
> at org.gradle.launcher.exec.GradleBuildController.run(
> GradleBuildController.java:71)
> at org.gradle.tooling.internal.provider.
> ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
> a

Re: Build failed in Jenkins: Geode-nightly #829

2017-05-08 Thread Avinash Dongre

It looks like
org.apache.geode.distributed.internal.ConsoleDistributionManagerDUnitTest >
testApplications FAILED
because of my changes in GEODE-254.

Since it is marked as Flaky I just ignore it but after replacing

assertEquals(2, root.keySet().size());

with

assertEquals(2, ((AdminRegion)root).keys().size());

Test is passing again.

I am failing to understand why there is special impl for keys in AdminRegion ?

and If this is correct fix.


Thanks

Avinash



On Mon, May 8, 2017 at 11:26 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> --
> [...truncated 120.69 KB...]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.CacheClosedException: The cache is closed.
> at org.apache.geode.internal.cache.execute.
> LocalResultCollectorImpl.setException(LocalResultCollectorImpl.java:187)
> at org.apache.geode.internal.cache.execute.
> PartitionedRegionFunctionResultSender.setException(
> PartitionedRegionFunctionResultSender.java:381)
> at org.apache.geode.internal.cache.execute.AbstractExecution.
> handleException(AbstractExecution.java:587)
> at org.apache.geode.internal.cache.execute.AbstractExecution.
> executeFunctionLocally(AbstractExecution.java:358)
> at org.apache.geode.internal.cache.execute.
> AbstractExecution$1.run(AbstractExecution.java:275)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at org.apache.geode.distributed.internal.DistributionManager.
> runUntilShutdown(DistributionManager.java:625)
> at org.apache.geode.distributed.internal.DistributionManager$
> 9$1.run(DistributionManager.java:1071)
> ... 1 more
> Caused by: org.apache.geode.cache.CacheClosedException: The cache is
> closed.
> at org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.
> generateCancelledException(GemFireCacheImpl.java:1519)
> at org.apache.geode.CancelCriterion.checkCancelInProgress(
> CancelCriterion.java:83)
> at org.apache.geode.internal.cache.LocalRegion.
> checkRegionDestroyed(LocalRegion.java:7656)
> at org.apache.geode.internal.cache.LocalRegion.
> checkReadiness(LocalRegion.java:2788)
> at org.apache.geode.internal.cache.BucketRegion.
> checkReadiness(BucketRegion.java:1371)
> at org.apache.geode.internal.cache.LocalRegion.size(
> LocalRegion.java:9140)
> at org.apache.geode.internal.cache.LocalRegion.isEmpty(
> LocalRegion.java:9176)
> at org.apache.geode.internal.cache.BucketRegionQueue.
> waitUntilFlushed(BucketRegionQueue.java:485)
> at org.apache.geode.internal.cache.wan.parallel.
> WaitUntilParallelGatewaySenderFlushedCoordinator$
> WaitUntilBucketRegionQueueFlushedCallable.call(
> WaitUntilParallelGatewaySenderFlushedCoordinator.java:131)
> at org.apache.geode.internal.cache.wan.parallel.
> WaitUntilParallelGatewaySenderFlushedCoordinator$
> WaitUntilBucketRegionQueueFlushedCallable.call(
> WaitUntilParallelGatewaySenderFlushedCoordinator.java:111)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at org.apache.geode.distributed.internal.DistributionManager.
> runUntilShutdown(DistributionManager.java:625)
> at org.apache.geode.distributed.internal.DistributionManager$
> 6$1.run(DistributionManager.java:952)
> ... 1 more
>
> 300 tests completed, 1 failed
> :geode-lucene:distributedTest FAILED
> :geode-lucene:flakyTest
> :geode-lucene:integrationTest
> :geode-old-client-support:assemble
> :geode-old-client-support:compileTestJava
> :geode-old-client-support:processTestResources NO-SOURCE
> :geode-old-client-support:testClasses
> :geode-old-client-support:checkMissedTests
> :geode-old-client-support:spotlessJavaCheck
> :geode-old-client-support:spotlessCheck
> :geode-old-client-support:test
> :geode-old-client-support:check
> :geode-old-client-support:build
> :geode-old-client-support:distributedTest
> :geode-old-client-support:flakyTest
> :geode-old-client-support:integrationTest
> :geode-old-versions:javadoc NO-SOURCE
> :geode-old-versions:javadocJar
> :geode-old-versions:sourcesJar
> :geode-old-versions:signArchives SKIPPED
> :geode-old-versions:assemble
> :geode-old-versions:compileTestJava NO-SOURCE
> :geode-old-versions:processTestResources NO-SOURCE
> :geode-old

[jira] [Updated] (GEODE-2839) Enhance OQL portions of REST API developer documentation

2017-05-08 Thread Hitesh Khamesra (JIRA)


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

Hitesh Khamesra updated GEODE-2839:
---
Component/s: rest (dev)

> Enhance OQL portions of REST API developer documentation
> 
>
> Key: GEODE-2839
> URL: https://issues.apache.org/jira/browse/GEODE-2839
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, rest (dev)
>Reporter: Michael Dodge
>
> The documentation for querying has excellent coverage of OQL 
> (developing/query_additional/query_language_features.html) however it is 
> difficult to get to that coverage from the REST API developer documentation, 
> e.g., rest_apps/rest_queries.html, rest_apps/post_create_query.html.
> * Some functionality differs between ad hoc ("unnamed") queries and created 
> ("named") queries, in particular whether the "LIKE 'foo%'" construct is 
> supported, and those differences are not obvious.
> * Whilst OQL syntax is discussed in the REST API documentation, there are no 
> hyperlinks to the OQL documentation.
> * The REST API documentation contains a few example of OQL use yet the OQL 
> documentation has more complete examples.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Build failed in Jenkins: Geode-nightly #829

Looks like AdminRegion isn't "a Region" -- it's some sort of snapshot of a
Region. I don't know anything more than you unfortunately.

On Mon, May 8, 2017 at 11:05 AM, Avinash Dongre  wrote:

> It looks like
> org.apache.geode.distributed.internal.ConsoleDistributionManagerDUnitTest
> >
> testApplications FAILED
> because of my changes in GEODE-254.
>
> Since it is marked as Flaky I just ignore it but after replacing
>
> assertEquals(2, root.keySet().size());
>
> with
>
> assertEquals(2, ((AdminRegion)root).keys().size());
>
> Test is passing again.
>
> I am failing to understand why there is special impl for keys in
> AdminRegion ?
>
> and If this is correct fix.
>
>
> Thanks
>
> Avinash
>
>
>
> On Mon, May 8, 2017 at 11:26 PM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> > See 
> >
> > --
> > [...truncated 120.69 KB...]
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at java.lang.Thread.run(Thread.java:745)
> > Caused by: org.apache.geode.cache.execute.FunctionException:
> > org.apache.geode.cache.CacheClosedException: The cache is closed.
> > at org.apache.geode.internal.cache.execute.
> > LocalResultCollectorImpl.setException(LocalResultCollectorImpl.java:187)
> > at org.apache.geode.internal.cache.execute.
> > PartitionedRegionFunctionResultSender.setException(
> > PartitionedRegionFunctionResultSender.java:381)
> > at org.apache.geode.internal.cache.execute.AbstractExecution.
> > handleException(AbstractExecution.java:587)
> > at org.apache.geode.internal.cache.execute.AbstractExecution.
> > executeFunctionLocally(AbstractExecution.java:358)
> > at org.apache.geode.internal.cache.execute.
> > AbstractExecution$1.run(AbstractExecution.java:275)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at org.apache.geode.distributed.internal.DistributionManager.
> > runUntilShutdown(DistributionManager.java:625)
> > at org.apache.geode.distributed.internal.DistributionManager$
> > 9$1.run(DistributionManager.java:1071)
> > ... 1 more
> > Caused by: org.apache.geode.cache.CacheClosedException: The cache is
> > closed.
> > at org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.
> > generateCancelledException(GemFireCacheImpl.java:1519)
> > at org.apache.geode.CancelCriterion.checkCancelInProgress(
> > CancelCriterion.java:83)
> > at org.apache.geode.internal.cache.LocalRegion.
> > checkRegionDestroyed(LocalRegion.java:7656)
> > at org.apache.geode.internal.cache.LocalRegion.
> > checkReadiness(LocalRegion.java:2788)
> > at org.apache.geode.internal.cache.BucketRegion.
> > checkReadiness(BucketRegion.java:1371)
> > at org.apache.geode.internal.cache.LocalRegion.size(
> > LocalRegion.java:9140)
> > at org.apache.geode.internal.cache.LocalRegion.isEmpty(
> > LocalRegion.java:9176)
> > at org.apache.geode.internal.cache.BucketRegionQueue.
> > waitUntilFlushed(BucketRegionQueue.java:485)
> > at org.apache.geode.internal.cache.wan.parallel.
> > WaitUntilParallelGatewaySenderFlushedCoordinator$
> > WaitUntilBucketRegionQueueFlushedCallable.call(
> > WaitUntilParallelGatewaySenderFlushedCoordinator.java:131)
> > at org.apache.geode.internal.cache.wan.parallel.
> > WaitUntilParallelGatewaySenderFlushedCoordinator$
> > WaitUntilBucketRegionQueueFlushedCallable.call(
> > WaitUntilParallelGatewaySenderFlushedCoordinator.java:111)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at org.apache.geode.distributed.internal.DistributionManager.
> > runUntilShutdown(DistributionManager.java:625)
> > at org.apache.geode.distributed.internal.DistributionManager$
> > 6$1.run(DistributionManager.java:952)
> > ... 1 more
> >
> > 300 tests completed, 1 failed
> > :geode-lucene:distributedTest FAILED
> > :geode-lucene:flakyTest
> > :geode-lucene:integrationTest
> > :geode-old-client-support:assemble
> > :geode-old-client-support:compileTestJava
> > :geode-old-client-support:processTestResources NO-SOURCE
> > :geode-old-client-support:testClasses
> > :geode-old-client-support:checkMissedTests
> > :geode-old-client-support:spotlessJavaCheck
> > :geode-old-client-support:spotlessCheck
> > :geode-old-client-support:test
> > :geode-old-client-support:check
> > :geode-old-client-support:build
> > :geode-old-

Re: gradle upgrade has broken IntelliJ

In order to get "./gradlew idea" to work I have to revert both of these
commits. After reverting them, the idea gradle task works.

commit 21d4ab2cf1c897bded41c0426a32531e926b689c
Author: Mark Bretl 
Date:   Mon May 1 09:57:53 2017 -0700

GEODE-2708: Update Minimum Gradle Version To 3.4.1

commit 9ed9e329f89f09ff2d91e1de48f17c9bbbf54512
Author: Mark Bretl 
Date:   Sat Apr 8 12:11:19 2017 -0700

GEODE-2708: Update Gradle Wrapper To 3.4.1

Tested and Verified By: ./gradlew precheckin

On Mon, May 8, 2017 at 11:05 AM, Kirk Lund  wrote:

> Looks like other projects are seeing this or something similar. Anyone
> with more gradle expertise want to try and fix this?
>
> There's some mention of a workaround here: https://github.com/akhikhl/
> gretty/issues/306
>
> On Mon, May 8, 2017 at 11:00 AM, Kirk Lund  wrote:
>
>> Looks like it's geode-core:antlr dependency in both CLI gradlew and
>> within IntelliJ. Here's the full stack trace in gradlew:
>>
>> * Exception is:
>> org.gradle.api.tasks.TaskExecutionException: Execution failed for task
>> ':geode-core:ideaModule'.
>> at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskEx
>> ecuter.executeActions(ExecuteActionsTaskExecuter.java:84)
>> at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskEx
>> ecuter.execute(ExecuteActionsTaskExecuter.java:55)
>> at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExec
>> uter.execute(SkipUpToDateTaskExecuter.java:62)
>> at org.gradle.api.internal.tasks.execution.ValidatingTaskExecut
>> er.execute(ValidatingTaskExecuter.java:58)
>> at org.gradle.api.internal.tasks.execution.SkipEmptySourceFiles
>> TaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
>> at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactS
>> tateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:46)
>> at org.gradle.api.internal.tasks.execution.SkipTaskWithNoAction
>> sExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
>> at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecut
>> er.execute(SkipOnlyIfTaskExecuter.java:54)
>> at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTas
>> kExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
>> at org.gradle.api.internal.tasks.execution.CatchExceptionTaskEx
>> ecuter.execute(CatchExceptionTaskExecuter.java:34)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
>> at org.gradle.internal.Transformers$4.transform(Transformers.
>> java:169)
>> at org.gradle.internal.progress.DefaultBuildOperationExecutor.r
>> un(DefaultBuildOperationExecutor.java:106)
>> at org.gradle.internal.progress.DefaultBuildOperationExecutor.r
>> un(DefaultBuildOperationExecutor.java:61)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$Even
>> tFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
>> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$Task
>> ExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
>> at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$Task
>> ExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
>> at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.proce
>> ss(DefaultTaskPlanExecutor.java:32)
>> at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.exec
>> ute(DefaultTaskGraphExecuter.java:113)
>> at org.gradle.execution.SelectedTaskExecutionAction.execute(Sel
>> ectedTaskExecutionAction.java:37)
>> at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBui
>> ldExecuter.java:37)
>> at org.gradle.execution.DefaultBuildExecuter.access$000(
>> DefaultBuildExecuter.java:23)
>> at org.gradle.execution.DefaultBuildExecuter$1.proceed(
>> DefaultBuildExecuter.java:43)
>> at org.gradle.execution.DryRunBuildExecutionAction.execute(DryR
>> unBuildExecutionAction.java:32)
>> at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBui
>> ldExecuter.java:37)
>> at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBui
>> ldExecuter.java:30)
>> at org.gradle.initialization.DefaultGradleLauncher$RunTasksActi
>> on.execute(DefaultGradleLauncher.java:256)
>> at org.gradle.initialization.DefaultGradleLauncher$RunTasksActi
>> on.execute(DefaultGradleLauncher.java:253)
>> at org.gradle.internal.Transformers$4.transform(Transformers.
>> java:169)
>> at org.gradle.internal.progress.DefaultBuildOperationExecutor.r
>> un(DefaultBuildOperationExecutor.java:106)
>> at org.gradle.internal.pr

[jira] [Commented] (GEODE-234) remove deprecated MirrorType class


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

Avinash Dongre commented on GEODE-234:
--

[~dschneider] 
I found following files have reference of 'mirror-type'

geode-docs/reference/topics/cache_xml.html.md.erb
geode-docs/reference/topics/client-cache.html.md.erb
geode-docs/reference/topics/gfe_cache_xml.html.md.erb

I am not sure how docs are generated, this may be safe to ignore.


> remove deprecated MirrorType class
> --
>
> Key: GEODE-234
> URL: https://issues.apache.org/jira/browse/GEODE-234
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> All uses of MirrorType should be changed to use DataPolicy.REPLICATE.
> All apis that take it as a parameter or return it need to be deleted.
> The cache-9.0.xsd should also be changed to no longer have the "mirror-type" 
> region-attribute.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

GMSMembershipManagerJUnitTest failing consistently in precheckin

I don't see this test failing in the nightly build but it seems to fail
consistently for me in precheckin (last 6 precheckins). Any ideas what's
wrong? Is anyone already looking into this failure?

:geode-core:test

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendFailureDueToForcedDisconnect FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect(GMSMembershipManagerJUnitTest.java:343)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testStartupEvents FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testStartupEvents(GMSMembershipManagerJUnitTest.java:219)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testSendToEmptyListIsRejected FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testSendToEmptyListIsRejected(GMSMembershipManagerJUnitTest.java:177)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendAllRecipients FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients(GMSMembershipManagerJUnitTest.java:331)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSend FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSend(GMSMembershipManagerJUnitTest.java:281)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendFailureToOneRecipient FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient(GMSMembershipManagerJUnitTest.java:294)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testDirectChannelSendFailureToAll FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToAll(GMSMembershipManagerJUnitTest.java:313)

org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> testSendMessage FAILED
java.lang.ClassCastException:
org.apache.geode.distributed.internal.LonerDistributionManager cannot be
cast to org.apache.geode.distributed.internal.DistributionManager
at
org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testSendMessage(GMSMembershipManagerJUnitTest.java:148)

3013 tests completed, 8 failed, 11 skipped
:geode-core:test FAILED

Re: Review Request 59040: when advisor cannot found target nodes for bucket id, should double check if the member is offline

2017-05-08 Thread Barry Oglesby


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59040/#review174209
---




geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionExecutionNodePruner.java
Lines 63 (patched)


What happens in the persistent case? Does it throw a 
PartitionOfflineException?


- Barry Oglesby


On May 7, 2017, 5:47 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59040/
> ---
> 
> (Updated May 7, 2017, 5:47 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Dan Smith.
> 
> 
> Bugs: GEODE-2824
> https://issues.apache.org/jira/browse/GEODE-2824
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a race condition. When a member is offline (in redundentcopy=0 case), 
> an earlier check will found that. But if it passed the check, the code will 
> enter a retry loop to ask advisor to give the target node. Finally the 
> advisor will return an empty list of member. Then the code will screw up and 
> throw the "No target node found" exception. 
> 
> The fix is: when the empty list is return, double check if target node is 
> offline.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionExecutionNodePruner.java
>  18700a75d 
> 
> 
> Diff: https://reviews.apache.org/r/59040/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

[jira] [Updated] (GEODE-2851) REST API can not execute functions with dot in the function ID

2017-05-08 Thread Michael Dodge (JIRA)


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

Michael Dodge updated GEODE-2851:
-
Description: 
Following the examples at 
(.../developing/function_exec/function_execution.html) we created a function 
that returned the class name as the function ID. After deploying the JAR 
containing that function using gfsh, we could successfully execute that 
function via gfsh:
{code}
gfsh>execute function --id=cheezypizza.DeleteFunction
Execution summary

Member ID/Name  | Function Execution Result
--- | -
10.32.104.55(rest-server:1878):1025 | Hello, world!
{code}

However, executing that function via a POST to 
http://35.165.170.9:8080/gemfire-api/v1/functions/cheezypizza.DeleteFunction 
fails, apparently because it stops reading the function ID at the '.' given 
{color:red}Caused by: org.apache.geode.cache.execute.FunctionException: 
Function named cheezypizza is not registered to FunctionService{color}:
{code}
org.apache.geode.rest.internal.web.exception.GemfireRestException: Server has 
encountered error while executing the function!
at 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController.execute(FunctionAccessController.java:223)
at 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController$$FastClassBySpringCGLIB$$b1783d32.invoke()
at 
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at 
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at 
org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:69)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at 
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
at 
org.apache.geode.rest.internal.web.controllers.FunctionAccessController$$EnhancerBySpringCGLIB$$225e498c.execute()
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.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
at 
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
at 
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
at 
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at 
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:821)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1685)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
at 
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
at 
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilt

Re: Review Request 59057: GEODE-2193 a member is kicked out immediately after joining

2017-05-08 Thread Hitesh Khamesra



> On May 8, 2017, 5:44 p.m., Hitesh Khamesra wrote:
> >

How about sending pending joinRequest(new member) with shutdown message. And 
let new coordinator take care of it.


- Hitesh


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59057/#review174198
---


On May 8, 2017, 5:23 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59057/
> ---
> 
> (Updated May 8, 2017, 5:23 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-2193
> https://issues.apache.org/jira/browse/GEODE-2193
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The previous fix for this ticket introduced a shutdown problem that caused 
> servers to pause waiting for ShutdownMessage to be sent to another server 
> that had already exited.  We reduced the pause time but this change set fixes 
> the problem by transmitting the message over UDP instead of TCP/IP stream 
> sockets.
> 
> Another change in GMSJoinLeave prepareView/sendView allows a membership 
> coordinator that is shutting down to complete the sending out of a new view 
> if it has already prepared the view when shutdown begins.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
>  e0c0ba29a5c74614d2430fb78d972e306a355845 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
>  8ae66d0b6839cfbd46b479d896104f54fd11a68d 
>   geode-core/src/main/java/org/apache/geode/internal/util/PluckStacks.java 
> 357812a6ec0cb09a88fa727a4bf828f18794264d 
> 
> 
> Diff: https://reviews.apache.org/r/59057/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin plus 1000 runs of the test that was hitting this issue at least 4% 
> of the time
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[GitHub] geode-site issue #2: GEODE-2554 Add htaccess file for docs redirect

2017-05-08 Thread metatype

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
Not sure why travis is unhappy.  Perhaps we need to override the `install` 
directive to prevent it from trying to run `gradlew assemble`.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up


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

ASF GitHub Bot commented on GEODE-2554:
---

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
Not sure why travis is unhappy.  Perhaps we need to override the `install` 
directive to prevent it from trying to run `gradlew assemble`.



> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #488: GEODE-254: Removed deprecated Region.keys and Regio...

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331983
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegion.java ---
@@ -1702,6 +1702,8 @@ public Set entrySet(boolean recursive) {
 return entries(recursive);
   }
 
+  public abstract Set entries(boolean recursive);
--- End diff --

Why add this abstract method when you are getting rid of entries(boolean)?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #488: GEODE-254: Removed deprecated Region.keys and Regio...

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331671
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/query/internal/QRegion.java ---
@@ -321,7 +321,7 @@ public void destroyRegion(Object aCallbackArgument)
   }
 
   public Set entries(boolean recursive) {
--- End diff --

Another example of a method that should no longer exist since it is no 
longer on Region


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #488: GEODE-254: Removed deprecated Region.keys and Regio...

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331529
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -388,7 +388,7 @@ public Set keySetOnServer() {
   public Set keys() {
--- End diff --

I think you want this old "keys()" implementation to now be "keySet()". The 
old "keySet" did not properly call preOp/postOp.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #488: GEODE-254: Removed deprecated Region.keys and Regio...

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115332259
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -187,7 +187,7 @@ public void destroyRegion(Object callbackArgument) 
throws CacheWriterException,
   public Set entries(boolean recursive) {
--- End diff --

AdminRegion was another class that implements Region that should be updated 
to no longer impl the methods you are removing. You should look at all the 
classes that implement Region.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #488: GEODE-254: Removed deprecated Region.keys and Regio...

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331339
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -187,7 +187,7 @@ public void destroyRegion(Object callbackArgument) 
throws CacheWriterException,
   public Set entries(boolean recursive) {
--- End diff --

I think it is wrong to keep these methods your are removing from Region on 
classes that implement the Region interface. It is too bad that these impls did 
not have @Override on them because that would have caused compilation failures.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries


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

ASF GitHub Bot commented on GEODE-254:
--

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331339
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -187,7 +187,7 @@ public void destroyRegion(Object callbackArgument) 
throws CacheWriterException,
   public Set entries(boolean recursive) {
--- End diff --

I think it is wrong to keep these methods your are removing from Region on 
classes that implement the Region interface. It is too bad that these impls did 
not have @Override on them because that would have caused compilation failures.


> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-site issue #2: GEODE-2554 Add htaccess file for docs redirect

2017-05-08 Thread metatype

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
I think the rules should be:

```
RewriteRule /guide/latest/(.*)$ /guide/11/$1 [R=303,NC,L]
RewriteRule /guide/(.*)$ /guide/11/$1 [R=303,NC,L]
```

You can check this at a site like http://htaccess.mwl.be on 
```

https://geode.apache.org/docs/guide/configuring/running/running_the_cacheserver.html

https://geode.apache.org/docs/guide/latest/configuring/running/running_the_cacheserver.html
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries


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

ASF GitHub Bot commented on GEODE-254:
--

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331671
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/query/internal/QRegion.java ---
@@ -321,7 +321,7 @@ public void destroyRegion(Object aCallbackArgument)
   }
 
   public Set entries(boolean recursive) {
--- End diff --

Another example of a method that should no longer exist since it is no 
longer on Region


> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries


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

ASF GitHub Bot commented on GEODE-254:
--

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115332259
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -187,7 +187,7 @@ public void destroyRegion(Object callbackArgument) 
throws CacheWriterException,
   public Set entries(boolean recursive) {
--- End diff --

AdminRegion was another class that implements Region that should be updated 
to no longer impl the methods you are removing. You should look at all the 
classes that implement Region.



> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries


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

ASF GitHub Bot commented on GEODE-254:
--

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331983
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegion.java ---
@@ -1702,6 +1702,8 @@ public Set entrySet(boolean recursive) {
 return entries(recursive);
   }
 
+  public abstract Set entries(boolean recursive);
--- End diff --

Why add this abstract method when you are getting rid of entries(boolean)?


> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-254) Remove deprecated Region.keys and Region.entries


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

ASF GitHub Bot commented on GEODE-254:
--

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/488#discussion_r115331529
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 ---
@@ -388,7 +388,7 @@ public Set keySetOnServer() {
   public Set keys() {
--- End diff --

I think you want this old "keys()" implementation to now be "keySet()". The 
old "keySet" did not properly call preOp/postOp.


> Remove deprecated Region.keys and Region.entries
> 
>
> Key: GEODE-254
> URL: https://issues.apache.org/jira/browse/GEODE-254
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Region.keys and Region.entries. Any calls can be simply 
> changed to Region.keySet and Region.entrySet so this should be an easy change.
> A large number of tests call the deprecated methods.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2554) Geode incubator docs are still up


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

ASF GitHub Bot commented on GEODE-2554:
---

Github user metatype commented on the issue:

https://github.com/apache/geode-site/pull/2
  
I think the rules should be:

```
RewriteRule /guide/latest/(.*)$ /guide/11/$1 [R=303,NC,L]
RewriteRule /guide/(.*)$ /guide/11/$1 [R=303,NC,L]
```

You can check this at a site like http://htaccess.mwl.be on 
```

https://geode.apache.org/docs/guide/configuring/running/running_the_cacheserver.html

https://geode.apache.org/docs/guide/latest/configuring/running/running_the_cacheserver.html
```


> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
>Priority: Minor
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2892) Add on sizeOnServer and emptyOnServer to Region

Fred Krone created GEODE-2892:
-

 Summary: Add on sizeOnServer and emptyOnServer to Region
 Key: GEODE-2892
 URL: https://issues.apache.org/jira/browse/GEODE-2892
 Project: Geode
  Issue Type: Sub-task
  Components: regions
Reporter: Fred Krone


To lower confusion while also not breaking backwards compatibility Region needs 
explicit "onServer" methods.

sizeOnServer 
emptyOnServer 

These could also be named something like size(boolean localSize) to keep the 
API a less wordy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2893) Add containsKeyOnServer and containsValueOnServer to Region

Fred Krone created GEODE-2893:
-

 Summary: Add containsKeyOnServer and containsValueOnServer to 
Region
 Key: GEODE-2893
 URL: https://issues.apache.org/jira/browse/GEODE-2893
 Project: Geode
  Issue Type: Sub-task
  Components: regions
Reporter: Fred Krone






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2892) Add sizeOnServer and emptyOnServer to Region


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

Fred Krone updated GEODE-2892:
--
Summary: Add sizeOnServer and emptyOnServer to Region  (was: Add on 
sizeOnServer and emptyOnServer to Region)

> Add sizeOnServer and emptyOnServer to Region
> 
>
> Key: GEODE-2892
> URL: https://issues.apache.org/jira/browse/GEODE-2892
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> To lower confusion while also not breaking backwards compatibility Region 
> needs explicit "onServer" methods.
> sizeOnServer 
> emptyOnServer 
> These could also be named something like size(boolean localSize) to keep the 
> API a less wordy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2893) Add containsKeyOnServer and containsValueOnServer to Region