Re: [VOTE] Apache Geode release - v1.1.1 RC2

[Jared Stewart]

+1

- Built from source
- Started cluster using gfsh, inserted data and ran queries from Pulse

> On Mar 30, 2017, at 5:34 PM, Mark Bretl  wrote:
> 
> +1 (binding)
> 
> - Checked and verified all MD5 and SHA256 hashes
> - Executed GFSH from both ZIP and TAR binary distributions
> - Verified GFSH version is 1.1.1
> 
> --Mark
> 
> On Thu, Mar 30, 2017 at 4:52 PM, Anthony Baker  wrote:
> 
>> We need more reviews from the community and PMC members.  Please check out
>> the release candidate and vote.  Thanks!
>> 
>> Anthony
>> 
>>> On Mar 27, 2017, at 10:18 PM, Anthony Baker  wrote:
>>> 
>>> This is the second release candidate of the release for Apache Geode,
>>> version 1.1.1.
>>> 
>>> It fixes the following issues:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12318420=12340271
>>> 
>>> *** Please download, test and vote by Thursday, March 30, 2200 hrs US
>>> Pacific. ***
>>> 
>>> Note that we are voting upon the source (tag):
>>> rel/v1.1.1.RC2
>>> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
>> refs/tags/rel/v1.1.1.RC2
>>> 
>>> Commit ID: e2081044ea0afca1cb38d62c7f34e7363b45ad97
>>> 
>>> Source and binary files:
>>> https://dist.apache.org/repos/dist/dev/geode/1.1.1.RC2/
>>> 
>>> Maven staging repo:
>>> https://repository.apache.org/content/repositories/orgapachegeode-1018
>>> 
>>> Geode's KEYS file containing PGP keys we use to sign the release:
>>> https://github.com/apache/geode/blob/release/1.1.1/KEYS
>>> 
>>> pub  4096R/C72CFB64 2015-10-01
>>>   Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
>>> 
>>> 
>>> Thanks,
>>> Anthony
>> 
>> 

Re: [gemfire-dev] More detailed Geode Modularization proposal

[Dan Smith]

I remember one of the issues we hit with OSGI is that geode-core needs to
be able to instantiate internal classes of other modules in order to
deserialize them. Is that something that is going to be an issue with jboss
modules? All of the documentation on classloaders for jboss modules is
blank in their documentation - https://docs.jboss.org/author/
display/MODULES/Class+loaders.

Is using jboss modules going to break simple use cases of declaring a
dependency on geode in maven or gradle and starting a geode client or peer
embedded in an existing application? How are these modules actually
bundled?

-Dan


On Thu, Mar 30, 2017 at 7:55 AM, Udo Kohlmeyer 
wrote:

> Hi William,
>
> I had looked at this. I liked the idea of JDK9's modular approach. With
> it's GA data not too far off, it is a definite contender.
>
> --Udo
>
>
> On 3/29/17 17:35, William Markito Oliveira wrote:
>
> Since the modularization effort may take a significant time and one of the
>> big features of Java 9 is modularization, why not leverage the
>> infrastructure of the JDK [1] for that ?  This would not only bring the
>> modularization but also make it 100% compatible with Java 9.
>>
>> It also provide solutions around class-loaders [2].
>>
>> Food for thought... :)
>>
>> [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining-modules
>> [2] http://openjdk.java.net/projects/jigsaw/spec/sotms/#class-loaders
>>
>> On Wed, Mar 29, 2017 at 3:29 PM, Jared Stewart 
>> wrote:
>>
>> I have some questions about the ClassLoader isolation proposal. If the
>>> class loaders of different modules are truly isolated, how can any module
>>> load classes from a different module?  And conversely, if different
>>> modules
>>> can load classes from each other, how can they truly be isolated?  In
>>> something like an application server, this seems much simpler, since the
>>> wars that get deployed to an app server should never need to interact
>>> with
>>> each other.  But how can this work with Geode modules?
>>>
>>> On Mar 29, 2017, at 10:00 AM, Udo Kohlmeyer 

>>> wrote:
>>>
 Hi there Guys,

 A more detailed proposal for a more modular Geode is available. Please

>>> review and comment, either on this thread or on confluence.
>>>
 https://cwiki.apache.org/confluence/display/GEODE/

>>> Geode+Modularization+-+An+approach
>>>
 Udo


>>>
>

[jira] [Comment Edited] (GEODE-1577) Unhelpful generic types on Execution.execute

[Alyssa Kim (JIRA)]

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

Alyssa Kim edited comment on GEODE-1577 at 3/31/17 3:33 AM:


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

-Reverted the changes made before
-Added argument types.

Let me know and assign it back to me if there is any problem. It's been a while 
so I might have missed something.

Thank you for the code-review!


was (Author: dalyssakim):
https://github.com/apache/geode/pull/321

-Reverted the changes made before
-Added argument types.

Let me know if there is any problem. It's been a while so I might have missed 
something.

Thank you for the code-review!

> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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

Re: [VOTE] Apache Geode release - v1.1.1 RC2

[Mark Bretl]

+1 (binding)

- Checked and verified all MD5 and SHA256 hashes
- Executed GFSH from both ZIP and TAR binary distributions
- Verified GFSH version is 1.1.1

--Mark

On Thu, Mar 30, 2017 at 4:52 PM, Anthony Baker  wrote:

> We need more reviews from the community and PMC members.  Please check out
> the release candidate and vote.  Thanks!
>
> Anthony
>
> > On Mar 27, 2017, at 10:18 PM, Anthony Baker  wrote:
> >
> > This is the second release candidate of the release for Apache Geode,
> > version 1.1.1.
> >
> > It fixes the following issues:
> >  https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318420=12340271
> >
> > *** Please download, test and vote by Thursday, March 30, 2200 hrs US
> > Pacific. ***
> >
> > Note that we are voting upon the source (tag):
> >  rel/v1.1.1.RC2
> >  https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=
> refs/tags/rel/v1.1.1.RC2
> >
> > Commit ID: e2081044ea0afca1cb38d62c7f34e7363b45ad97
> >
> > Source and binary files:
> >  https://dist.apache.org/repos/dist/dev/geode/1.1.1.RC2/
> >
> > Maven staging repo:
> >  https://repository.apache.org/content/repositories/orgapachegeode-1018
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> >  https://github.com/apache/geode/blob/release/1.1.1/KEYS
> >
> > pub  4096R/C72CFB64 2015-10-01
> >Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
> >
> >
> > Thanks,
> > Anthony
>
>

Re: Request for edit permissions

[Brian Baynes]

Thank you!

On Mar 30, 2017 3:49 PM, "Roman Shaposhnik"  wrote:

> Done!
>
> On Thu, Mar 30, 2017 at 9:08 AM, Brian Baynes  wrote:
> > Hi, Roman.
> >
> > Sure, understood -- that info was by way of introduction, not a claim to
> > anything :)
> > Thanks for making it clear.
> >
> > Both IDs are bbaynes.
> >
> > Thanks for helping me get set up!
> >
> > Bran
> >
> > On Thu, Mar 30, 2017 at 8:50 AM, Roman Shaposhnik 
> > wrote:
> >
> >> Hi Brian!
> >>
> >> On Thu, Mar 30, 2017 at 8:32 AM, Brian Baynes 
> wrote:
> >> > Hello,
> >> >
> >> > I'm a new PM at Pivotal working with the Communications team.
> >>
> >> Quick note on the Apache way of doing things. While we appreciate
> >> knowing your relationship with Pivotal please realize that neither your
> >> title nor your affiliation with this particular employer have any
> bearings
> >> on what kind of access you get with the project. We're all contributing
> >> to Apache Geode as individual contributors and a lot of times we don't
> >> even know the employment affiliation of others.
> >>
> >> This is a good thing. This is how Apache Way works.
> >>
> >> > I'd like to request edit access for wikis and Jira tickets for Geode.
> >> For
> >> > example, I'd like to edit the description for GEODE-2580, a project
> our
> >> > team is working on.
> >>
> >> Now, for both of these -- we welcome all levels of contributions -
> giving
> >> you
> >> an access is not a problem.
> >>
> >> What's your ASF wiki and JIRA ID?
> >>
> >> Thanks,
> >> Roman.
> >>
>

Re: [VOTE] Apache Geode release - v1.1.1 RC2

[Anthony Baker]

We need more reviews from the community and PMC members.  Please check out the 
release candidate and vote.  Thanks!

Anthony

> On Mar 27, 2017, at 10:18 PM, Anthony Baker  wrote:
> 
> This is the second release candidate of the release for Apache Geode,
> version 1.1.1.
> 
> It fixes the following issues:
>  
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12340271
> 
> *** Please download, test and vote by Thursday, March 30, 2200 hrs US
> Pacific. ***
> 
> Note that we are voting upon the source (tag):
>  rel/v1.1.1.RC2
>  
> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=refs/tags/rel/v1.1.1.RC2
> 
> Commit ID: e2081044ea0afca1cb38d62c7f34e7363b45ad97
> 
> Source and binary files:
>  https://dist.apache.org/repos/dist/dev/geode/1.1.1.RC2/
> 
> Maven staging repo:
>  https://repository.apache.org/content/repositories/orgapachegeode-1018
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
>  https://github.com/apache/geode/blob/release/1.1.1/KEYS
> 
> pub  4096R/C72CFB64 2015-10-01
>Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
> 
> 
> Thanks,
> Anthony

Review Request 58090: GEODE-2738: Occurred should be spelled with two Rs.

[Patrick Rhomberg]

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

Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
Kirk Lund, and Swapnil Bawaskar.


Repository: geode


Description
---

Minor but extensive correction of "occured" to "occurred."


Diffs
-

  geode-core/src/main/java/org/apache/geode/DataSerializer.java 
627661a8ebbf5f8ffc6a5d2edff6c08f99a4035e 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteFunctionNoAckOp.java
 def738938cc10546a157111ef93c6720cefbbdf2 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteRegionFunctionNoAckOp.java
 06f02d1e6dd2250ef88cc794837905cd678052c0 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/LiveServerPinger.java
 32d0f8e62096ed714f8eebae6b16f49e0a33e32c 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/AbstractCompiledValue.java
 d635e024a9fa9cf8e3a7ae812744817ef071be13 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledSelect.java
 9b775570ce01e696dc73b8523ff088e585ddf399 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/OrderByComparator.java
 b9d6026c61209c3e32183f470de05ae41bd17285 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java 
8eaa74a5dad5b8edbed28e9798a7f325fc9bffcf 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/cq/CqAttributesImpl.java
 7aeee1d95101a95284516a45395a678283eb91b2 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/AbstractIndex.java
 96a3c833f4028cdd2e53c6fb7d74a169e8c8e465 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactRangeIndex.java
 80568f513c5fed3a03d6b6929cb2f3083ecad9aa 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/HashIndex.java
 023fbb465960f366dbe901b586602ed961047b49 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/MemoryIndexStore.java
 e9cd0709e224339ab46d2c3c17c87b3dcb96f1f8 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 987e4911272ba6c37046d8e39a1187b71556736d 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalLocator.java
 4ac2c9c705a344503fd247d39fbc980a27e2d403 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java 
eaababaf6be6041c72156a338c69fa81f10db4c5 
  geode-core/src/main/java/org/apache/geode/internal/cache/DiskStoreImpl.java 
b97f4286b6e2352a4ec5637477641d868cb05a6c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java 
b9cdfd75c19f3425dacc8f99c1bc399248230b71 
  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegionFunctionStreamingMessage.java
 1de8d3b3b97a090a549dbcd866436f8d571fe81e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
15755175fc16609e0341d8c9e97039b5b83ce5d2 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
45540eebda466805bedc6ee08fc69203ae278c8b 
  
geode-core/src/main/java/org/apache/geode/internal/cache/MemberFunctionStreamingMessage.java
 d0dd08466c0053dfd3f0b1dc58cc68c1c9ce01ad 
  geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java 
ca9468d503f5930fb20efa191335ba72d9b081ff 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PRQueryProcessor.java 
6df39713fa7986e3ecd6e4c72bd0c7819235472c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java 
173f35c73d33c2e88d5b41e7a04055c423908127 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataStore.java
 5ddf0cb66e2f2e503336a2705a57a6000edd6128 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PlaceHolderDiskRegion.java
 db01162aeeba8113c208565d683e71a41d0f6d00 
  geode-core/src/main/java/org/apache/geode/internal/cache/ProxyRegionMap.java 
92c7b6f8e90a3382e7ce00064581d69f9706fcd3 
  
geode-core/src/main/java/org/apache/geode/internal/cache/UpdateEntryVersionOperation.java
 f82f0ce5d92420f27ba8c260069221ee6605254c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/control/HeapMemoryMonitor.java
 afc9a23aafba2c1f993b30546f24cd2b5d6a0126 
  
geode-core/src/main/java/org/apache/geode/internal/cache/control/OffHeapMemoryMonitor.java
 414036747a5062ab556b60cdb58c5ce490312c78 
  
geode-core/src/main/java/org/apache/geode/internal/cache/execute/AbstractExecution.java
 505dfce711a0931ec2c52050c121b70c5cb56334 
  
geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionServiceStats.java
 09a9122c4058df477d14f03ba7e4c4024d259d6e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionStats.java
 2f04034041fafa1f79e9c3f464270d4c4ea96e70 
  

Re: Review Request 58088: GEODE-2738: There are many typos throughout the codebase.

[Dave Barnes]

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


Ship it!




Ship It!

- Dave Barnes


On March 30, 2017, 10:26 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58088/
> ---
> 
> (Updated March 30, 2017, 10:26 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
> Kirk Lund, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Various typos corrected, notably in --ignoreInterceptors (from 
> --ignoreInterCeptors), which is only referenced during command parsing.
> 
> Many other typos corrected.  Biggest offender: "occurred" has two Rs.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 627661a8ebbf5f8ffc6a5d2edff6c08f99a4035e 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/AbstractHealthEvaluator.java
>  57b42a819a340348dfffd2fc5bcd0bc036f8aa1b 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteFunctionNoAckOp.java
>  def738938cc10546a157111ef93c6720cefbbdf2 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteRegionFunctionNoAckOp.java
>  06f02d1e6dd2250ef88cc794837905cd678052c0 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/LiveServerPinger.java
>  32d0f8e62096ed714f8eebae6b16f49e0a33e32c 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/AbstractCompiledValue.java
>  d635e024a9fa9cf8e3a7ae812744817ef071be13 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/AbstractGroupOrRangeJunction.java
>  5ed4d865bdafc77817514b34735460f23d97f5d4 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledComparison.java
>  d47509fd88319ded7b7d8c223aeb72043688e5fc 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledIn.java
>  0aa1efbaadb4a2334d48fbb8fe43785cc4ff8637 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledJunction.java
>  ece8a9dd2480b3cc706b5ec981076ae597bb44a4 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledSelect.java
>  9b775570ce01e696dc73b8523ff088e585ddf399 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/CompositeGroupJunction.java
>  8f57ad6693a485ad061c93bf4732d62459a8b9e9 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/GroupJunction.java
>  84971fd314987189eb249344cdc4ebf3fb4cff2f 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/OrderByComparator.java
>  b9d6026c61209c3e32183f470de05ae41bd17285 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryObserver.java
>  2a965668fe564178a408b061a3c9623adf8040b2 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryObserverAdapter.java
>  b4a92b0070c326b761f965f165a42556c1cd29ec 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java
>  8eaa74a5dad5b8edbed28e9798a7f325fc9bffcf 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/RangeJunction.java
>  42fb30d8f041f7c8924f5b6228a03c95f088f479 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/cq/CqAttributesImpl.java
>  7aeee1d95101a95284516a45395a678283eb91b2 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/AbstractIndex.java
>  96a3c833f4028cdd2e53c6fb7d74a169e8c8e465 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactRangeIndex.java
>  80568f513c5fed3a03d6b6929cb2f3083ecad9aa 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/HashIndex.java
>  023fbb465960f366dbe901b586602ed961047b49 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexData.java
>  e5c516f5441198ca2f5a16bb6590b046f6530ff6 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/MemoryIndexStore.java
>  e9cd0709e224339ab46d2c3c17c87b3dcb96f1f8 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
>  2c6c025043282b1e64418dced01eefc8d551fd9e 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  987e4911272ba6c37046d8e39a1187b71556736d 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalLocator.java
>  4ac2c9c705a344503fd247d39fbc980a27e2d403 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractBucketRegionQueue.java
>  60f397ccb36a01720128b1b398422b988511550d 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractDiskRegion.java
>  

Re: Review Request 58050: GEODE-2725: export logs --dir now honored when not connected via HTTP[S].

[Ken Howe]

> On March 30, 2017, 10:44 p.m., Jared Stewart wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
> > Line 32 (original), 35 (patched)
> > 
> >
> > Let's change this to a `@Rule` instead of a `@ClassRule`.  This will 
> > cause the locator to be created and destroyed for every `@Test`, rather 
> > than once for the whole class.  The all of the `try{} finally{}` blocks 
> > below will be unnecessary.  The `LocatorStarterRule` uses a 
> > `TemporaryFolder` to back the locator's working dir that will automatically 
> > be deleted by the `@Rule`'s lifecycle.

Good suggestion. Also, for the absolute path test we should be able to resolve 
the TemporaryFolder to an absolute path and use that as the root of the 
subdirectory instead of arbitarily using /tmp.


- Ken


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


On March 30, 2017, 6:17 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58050/
> ---
> 
> (Updated March 30, 2017, 6:17 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
> Kirk Lund, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> export logs --dir refers to local filesystem when connected via HTTP and 
> refers to the managers filesystem when connected via JMX.  This behavior will 
> be changed in GEODE-2663.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  3f147c19a128dce78c51c31e6758e517cd2ab496 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  5b1f089c18c404f64929398f6015839eb783ccb4 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
>  268fa397db253f12c0effdbf6faa5e822730144c 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  3c56def01ad58f98ea1707f4dd6b57e643e9eab1 
> 
> 
> Diff: https://reviews.apache.org/r/58050/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin running.
> 
> Manual verification of behavior both with and without --dir option, both 
> connected via HTTP and not.
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

[jira] [Commented] (GEODE-2736) Native client thread pool get stuck sometimes during rolling restart

[ASF GitHub Bot (JIRA)]

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

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

GitHub user mhansonp opened a pull request:

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

GEODE-2736: Fixed orphaned worker threads

- Force timeouts to be handled like no connection
- Added test

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

$ git pull https://github.com/mhansonp/geode-native feature/GEODE-2736

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

https://github.com/apache/geode-native/pull/82.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 #82


commit 75c6dcb206a72f68356805e34290f0e9836533b1
Author: Mark Hanson 
Date:   2017-03-30T17:19:40Z

GEODE-2736: Fixed orphaned worker threads

- Force timeouts to be handled like no connection
- Added test




> Native client thread pool get stuck sometimes during rolling restart
> 
>
> Key: GEODE-2736
> URL: https://issues.apache.org/jira/browse/GEODE-2736
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mark Hanson
>
> Users has a function which executes on all nodes hosting the region, during 
> rolling restart of the Geode servers, occasionally all the threads in the 
> Geode native client thread pool get stuck sometimes when certain exceptions 
> are thrown.
> The user thinks it is due to possible incorrect exception handling inside the 
> Geode native client code
> This leads to application threads getting stuck as the thread pool is not 
> available



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

[GitHub] geode-native pull request #82: GEODE-2736: Fixed orphaned worker threads

[mhansonp]

GitHub user mhansonp opened a pull request:

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

GEODE-2736: Fixed orphaned worker threads

- Force timeouts to be handled like no connection
- Added test

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

$ git pull https://github.com/mhansonp/geode-native feature/GEODE-2736

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

https://github.com/apache/geode-native/pull/82.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 #82


commit 75c6dcb206a72f68356805e34290f0e9836533b1
Author: Mark Hanson 
Date:   2017-03-30T17:19:40Z

GEODE-2736: Fixed orphaned worker threads

- Force timeouts to be handled like no connection
- Added 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-2730) Refactor ServerStarterRule and LocatorStarterRule

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2730:


Commit 50f6d1e39213ed64f5cc38b0438c63bd21482e60 in geode's branch 
refs/heads/develop from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=50f6d1e ]

GEODE-2730: Refactor ServerStarterRule and LocatorStarterRule

- Introduced LocalServerStarterRule and LocalLocatorStarterRule to eventually 
replace LocatorStarterRule and ServerStarterRule.
- The new rules will *only* start a member through the rule's before() method.  
Members will *never* be started on Rule instantiation.
- The new rules are backed by Builders that use AvailablePort.Keeper to reserve 
the ports that a member will use when it eventually starts.  The Keepers are 
released just before starting the member, with the goal of minimizing test 
flakiness caused by BindExceptions when a port is already in use.


> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



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

Request For Geode Wiki Admin Karma

[Mark Bretl]

Hi,

I would like to follow Kirk's request with one of my own for Admin Karma on
the Geode Wiki. Username is mbretl.

Best Regards,

--Mark

Re: Request for edit permissions

[Roman Shaposhnik]

Done!

On Thu, Mar 30, 2017 at 9:08 AM, Brian Baynes  wrote:
> Hi, Roman.
>
> Sure, understood -- that info was by way of introduction, not a claim to
> anything :)
> Thanks for making it clear.
>
> Both IDs are bbaynes.
>
> Thanks for helping me get set up!
>
> Bran
>
> On Thu, Mar 30, 2017 at 8:50 AM, Roman Shaposhnik 
> wrote:
>
>> Hi Brian!
>>
>> On Thu, Mar 30, 2017 at 8:32 AM, Brian Baynes  wrote:
>> > Hello,
>> >
>> > I'm a new PM at Pivotal working with the Communications team.
>>
>> Quick note on the Apache way of doing things. While we appreciate
>> knowing your relationship with Pivotal please realize that neither your
>> title nor your affiliation with this particular employer have any bearings
>> on what kind of access you get with the project. We're all contributing
>> to Apache Geode as individual contributors and a lot of times we don't
>> even know the employment affiliation of others.
>>
>> This is a good thing. This is how Apache Way works.
>>
>> > I'd like to request edit access for wikis and Jira tickets for Geode.
>> For
>> > example, I'd like to edit the description for GEODE-2580, a project our
>> > team is working on.
>>
>> Now, for both of these -- we welcome all levels of contributions - giving
>> you
>> an access is not a problem.
>>
>> What's your ASF wiki and JIRA ID?
>>
>> Thanks,
>> Roman.
>>

Re: Requesting edit permissions for Geode tickets

[Roman Shaposhnik]

Kirk, I've bumped your karma to the admin.

Thanks,
Roman.

On Thu, Mar 30, 2017 at 10:20 AM, Kirk Lund  wrote:
> I gave you permissions for Jira. Someone else still needs to give you karma
> on the Wiki.
>
> -Kirk
>
> On Thu, Mar 30, 2017 at 9:22 AM, Fred Krone  wrote:
>
>> Hi,
>>
>> Could I get editing permissions for Geode tickets?  I can only edit mine
>> and I'd like to reword some descriptions etc on other tickets.  I'd also
>> like to edit some wikis if needed.
>>
>> Both ASF and JIRA IDs are fkrone.
>>
>> Thanks,
>>
>> -Fred
>>

Re: Requesting edit permissions for Geode tickets

[Roman Shaposhnik]

On Thu, Mar 30, 2017 at 9:22 AM, Fred Krone  wrote:
> Hi,
>
> Could I get editing permissions for Geode tickets?  I can only edit mine
> and I'd like to reword some descriptions etc on other tickets.  I'd also
> like to edit some wikis if needed.
>
> Both ASF and JIRA IDs are fkrone.

Here's what I'm getting from cwiki:
   User fkrone could not be found

Thanks,
Roman.

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #509 was SUCCESSFUL (with 1843 tests). Change made by John Blum.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #509 was successful.
---
Scheduled with changes by John Blum.
1845 tests in total.

https://build.spring.io/browse/SGF-NAG-509/




--
Code Changes
--
John Blum (043cc922b95b0620b7ddb76b7bb19d96498d2561):

>SGF-603 - Add ignoreIfExists attribute defaulted to true in @Region 
>annotations for @EnableEntityDefinedRegions.

John Blum (9f0a07273c1241a81c5efa9e8f5f9a239e3f5ddb):

>SGF-402 - Implement support for proper Paging with Projections in Lucene query 
>results.

John Blum (249e64586537d9be9331971b9e3b3d864b6cf694):

>SGF-402 - Add SDG Annotation configuration support for Lucene Integration.



--
This message is automatically generated by Atlassian Bamboo

[jira] [Updated] (GEODE-2738) Occurred is spelled with two Rs.

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2738:

Issue Type: Improvement  (was: Bug)

> Occurred is spelled with two Rs.
> 
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> Most frequently, "an exception occured: {}" in logging.



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

Re: Review Request 58050: GEODE-2725: export logs --dir now honored when not connected via HTTP[S].

[Jared Stewart]

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




geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
Line 32 (original), 35 (patched)


Let's change this to a `@Rule` instead of a `@ClassRule`.  This will cause 
the locator to be created and destroyed for every `@Test`, rather than once for 
the whole class.  The all of the `try{} finally{}` blocks below will be 
unnecessary.  The `LocatorStarterRule` uses a `TemporaryFolder` to back the 
locator's working dir that will automatically be deleted by the `@Rule`'s 
lifecycle.



geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
Line 38 (original), 41 (patched)


If we add the `@Before` annotation to this method, JUnit will automatically 
invoke it before every `@Test` method. Then we can delete the repetitive calls 
to `connect()` at the beginning of each `@Test` method below.



geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
Lines 81 (patched)


This way of resolving the subdirectory will not work on any OS that does 
not use "/" as a file separator (i.e. Windows).   Try this instead:

```
  Path workingDirPath = locator.getWorkingDir().toPath();
  Path subdirPath =
workingDirPath.resolve("some").resolve("test").resolve("directory");
  String relativeDir = workingDirPath.relativize(subdirPath).toString();

  gfsh.executeCommand("export logs --dir=some/test/directory");
  assertThat(FileUtils.listFiles(subdirPath.toFile(), extensions, 
false)).isNotEmpty();
  assertThat(FileUtils.listFiles(locator.getWorkingDir(), extensions, 
false)).isEmpty();
```


- Jared Stewart


On March 30, 2017, 6:17 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58050/
> ---
> 
> (Updated March 30, 2017, 6:17 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
> Kirk Lund, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> export logs --dir refers to local filesystem when connected via HTTP and 
> refers to the managers filesystem when connected via JMX.  This behavior will 
> be changed in GEODE-2663.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  3f147c19a128dce78c51c31e6758e517cd2ab496 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  5b1f089c18c404f64929398f6015839eb783ccb4 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
>  268fa397db253f12c0effdbf6faa5e822730144c 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  3c56def01ad58f98ea1707f4dd6b57e643e9eab1 
> 
> 
> Diff: https://reviews.apache.org/r/58050/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin running.
> 
> Manual verification of behavior both with and without --dir option, both 
> connected via HTTP and not.
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

Re: Review Request 58080: GEODE-2420: Add classes to estimated the size of exported logs

[Ken Howe]

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

(Updated March 30, 2017, 10:43 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Kirk Lund, 
and Patrick Rhomberg.


Repository: geode


Description
---

- New Function class added with tests
- Code to invoke new function added, but disabled, in ExportLogsCommand
- New option added, but disabled, for specifying size limit for exported
  logs
- Refactoring: extracted the interceptor from ExportLogsCommand
- Refactoring: renamed ExportLogCommand to ExportLogsCommand
- New Serializable class to return the log size estimate to the command
- Tests for the log sizing related classes

This is work-in-progress that is adds sizing estimation for exported logs, but 
the code is currently not called by ExportLogsCommand. Follow-on work will use 
the new sizing estimation to provide warnings to the user if exporting logs may 
fill up disks on servers or the locator.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 3f147c19a128dce78c51c31e6758e517cd2ab496 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 cbdf1c4bc28554a8fbec3740c566ee07c69b4ac9 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 5b1f089c18c404f64929398f6015839eb783ccb4 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogSizer.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 95edd426da8b8f39bb1486661d8c307d43f170d6 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
 268fa397db253f12c0effdbf6faa5e822730144c 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
 573701fd7f48c8c1b72c0f71993a4adea7bdbe8b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
 5a4d274a751a6e22fcfbc0c5e6bd5dff39e3b938 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LogLevelInterceptorTest.java
 41b971534fd83c87f33751fa46454e158315f6ae 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfoTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionCacheTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionFileTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsTestSuite.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogSizerTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 6ae82da58923fdf3a44217c1773a40d8ff1001bc 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedDataSerializables.txt
 2f5a5cdf8c59e90625fe01c3306462e9277ab4e1 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
 397ec14c0bbbea277d378eefcaecfdb90cc9e224 


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


Testing (updated)
---

Precheckin is running

I need to debug one test of the new class that is still failing:

org.apache.geode.management.internal.cli.functions.SizeExportLogsFunctionCacheTest
 > withFunctionError_shouldThrow FAILED
org.apache.geode.GemFireConfigException: The locators attribute can not be 
empty when the mcast-port attribute is non-zero.
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:558)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:216)
 

[jira] [Updated] (GEODE-2738) Occurred is spelled with two Rs.

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2738:

Description: Most frequently, "an exception occured: {}" in logging.  (was: 
The most pervasive that I've noticed is that "occurred" is spelled with only 
one R.)

> Occurred is spelled with two Rs.
> 
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> Most frequently, "an exception occured: {}" in logging.



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

[jira] [Commented] (GEODE-2734) Investigate/discuss message encoding

[Mark Bretl (JIRA)]

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

Mark Bretl commented on GEODE-2734:
---

This may be only a task to track the overall discussion, however, please 
remember to have the discuss discussion on the dev mailing list.

Thanks,

--Mark

> Investigate/discuss message encoding
> 
>
> Key: GEODE-2734
> URL: https://issues.apache.org/jira/browse/GEODE-2734
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Brian Baynes
>
> Out of all the great ways to encode messages (Thrift, Protobuf, etc), which 
> should we use here?  Let's discuss and come to consensus.



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

[jira] [Commented] (GEODE-2738) Occurred is spelled with two Rs.

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg commented on GEODE-2738:
-

Yeah, I have since reduced the scope, once I noticed how broad the patch I was 
building had gotten.

> Occurred is spelled with two Rs.
> 
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> The most pervasive that I've noticed is that "occurred" is spelled with only 
> one R.



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

[jira] [Updated] (GEODE-2738) Occurred is spelled with two Rs.

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2738:

Summary: Occurred is spelled with two Rs.  (was: There are many typos 
throughout the codebase.)

> Occurred is spelled with two Rs.
> 
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> The most pervasive that I've noticed is that "occurred" is spelled with only 
> one R.



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

[jira] [Commented] (GEODE-2738) There are many typos throughout the codebase.

[Mark Bretl (JIRA)]

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

Mark Bretl commented on GEODE-2738:
---

 [~prhomberg] This is a vague subject and hard to determine the scope of the 
changes. Are you able to narrow the issue?

> There are many typos throughout the codebase.
> -
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> The most pervasive that I've noticed is that "occurred" is spelled with only 
> one R.



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

Review Request 58088: GEODE-2738: There are many typos throughout the codebase.

[Patrick Rhomberg]

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

Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
Kirk Lund, and Swapnil Bawaskar.


Repository: geode


Description
---

Various typos corrected, notably in --ignoreInterceptors (from 
--ignoreInterCeptors), which is only referenced during command parsing.

Many other typos corrected.  Biggest offender: "occurred" has two Rs.


Diffs
-

  geode-core/src/main/java/org/apache/geode/DataSerializer.java 
627661a8ebbf5f8ffc6a5d2edff6c08f99a4035e 
  
geode-core/src/main/java/org/apache/geode/admin/internal/AbstractHealthEvaluator.java
 57b42a819a340348dfffd2fc5bcd0bc036f8aa1b 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteFunctionNoAckOp.java
 def738938cc10546a157111ef93c6720cefbbdf2 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteRegionFunctionNoAckOp.java
 06f02d1e6dd2250ef88cc794837905cd678052c0 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/LiveServerPinger.java
 32d0f8e62096ed714f8eebae6b16f49e0a33e32c 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/AbstractCompiledValue.java
 d635e024a9fa9cf8e3a7ae812744817ef071be13 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/AbstractGroupOrRangeJunction.java
 5ed4d865bdafc77817514b34735460f23d97f5d4 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledComparison.java
 d47509fd88319ded7b7d8c223aeb72043688e5fc 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledIn.java 
0aa1efbaadb4a2334d48fbb8fe43785cc4ff8637 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledJunction.java
 ece8a9dd2480b3cc706b5ec981076ae597bb44a4 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledSelect.java
 9b775570ce01e696dc73b8523ff088e585ddf399 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/CompositeGroupJunction.java
 8f57ad6693a485ad061c93bf4732d62459a8b9e9 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/GroupJunction.java
 84971fd314987189eb249344cdc4ebf3fb4cff2f 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/OrderByComparator.java
 b9d6026c61209c3e32183f470de05ae41bd17285 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryObserver.java
 2a965668fe564178a408b061a3c9623adf8040b2 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryObserverAdapter.java
 b4a92b0070c326b761f965f165a42556c1cd29ec 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/QueryUtils.java 
8eaa74a5dad5b8edbed28e9798a7f325fc9bffcf 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/RangeJunction.java
 42fb30d8f041f7c8924f5b6228a03c95f088f479 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/cq/CqAttributesImpl.java
 7aeee1d95101a95284516a45395a678283eb91b2 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/AbstractIndex.java
 96a3c833f4028cdd2e53c6fb7d74a169e8c8e465 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactRangeIndex.java
 80568f513c5fed3a03d6b6929cb2f3083ecad9aa 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/HashIndex.java
 023fbb465960f366dbe901b586602ed961047b49 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexData.java
 e5c516f5441198ca2f5a16bb6590b046f6530ff6 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/MemoryIndexStore.java
 e9cd0709e224339ab46d2c3c17c87b3dcb96f1f8 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 2c6c025043282b1e64418dced01eefc8d551fd9e 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 987e4911272ba6c37046d8e39a1187b71556736d 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalLocator.java
 4ac2c9c705a344503fd247d39fbc980a27e2d403 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractBucketRegionQueue.java
 60f397ccb36a01720128b1b398422b988511550d 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractDiskRegion.java
 554455d9db2269a7692f1e238ba373c94393d4e5 
  
geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java 
eaababaf6be6041c72156a338c69fa81f10db4c5 
  geode-core/src/main/java/org/apache/geode/internal/cache/DiskStoreImpl.java 
b97f4286b6e2352a4ec5637477641d868cb05a6c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java 
b9cdfd75c19f3425dacc8f99c1bc399248230b71 
  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegionFunctionStreamingMessage.java
 1de8d3b3b97a090a549dbcd866436f8d571fe81e 
  

[jira] [Updated] (GEODE-2738) There are many typos throughout the codebase.

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2738:

Summary: There are many typos throughout the codebase.  (was: There are a 
lot of typos)

> There are many typos throughout the codebase.
> -
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> The most pervasive that I've noticed is that "occurred" is spelled with only 
> one R.



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

[jira] [Updated] (GEODE-2738) There are many typos throughout the codebase.

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg updated GEODE-2738:

Priority: Trivial  (was: Major)

> There are many typos throughout the codebase.
> -
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Trivial
>
> The most pervasive that I've noticed is that "occurred" is spelled with only 
> one R.



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

[jira] [Created] (GEODE-2738) There are a lot of typos

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-2738:
---

 Summary: There are a lot of typos
 Key: GEODE-2738
 URL: https://issues.apache.org/jira/browse/GEODE-2738
 Project: Geode
  Issue Type: Bug
Reporter: Patrick Rhomberg


The most pervasive that I've noticed is that "occurred" is spelled with only 
one R.



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

[jira] [Assigned] (GEODE-2738) There are a lot of typos

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-2738:
---

Assignee: Patrick Rhomberg

> There are a lot of typos
> 
>
> Key: GEODE-2738
> URL: https://issues.apache.org/jira/browse/GEODE-2738
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> The most pervasive that I've noticed is that "occurred" is spelled with only 
> one R.



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

[jira] [Updated] (GEODE-2737) PulseAuthTest failures

[Kenneth Howe (JIRA)]

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

Kenneth Howe updated GEODE-2737:

Description: 
Tests are failing in the PulseAuthTest (UITest category) with the error:

{code}
org.apache.geode.tools.pulse.tests.ui.PulseAuthTest > testTopologyPopUpData 
FAILED
org.openqa.selenium.TimeoutException: Expected condition failed: waiting 
for org.apache.geode.tools.pulse.tests.rules.WebDriverRule$1@4d7af88e (tried 
for 30 second(s) with 500 MILLISECONDS interval)
Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
09:49:13 -0700'
System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', os.name: 
'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: '1.8.0_111'
Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
Capabilities [{applicationCacheEnabled=false, rotatable=false, 
handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
acceptSslCerts=false, driverVersion=1.2.0, 
phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581

Caused by:
org.openqa.selenium.NoSuchElementException: {"errorMessage":"Unable to 
find element with id 
'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
 charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
(Java/1.8.0_111)"},"httpVersion":"1.1","method":"POST","post":"{\"using\":\"id\",\"value\":\"userName\"}","url":"/element","urlParsed":{"anchor":"","query":"","file":"element","directory":"/","path":"/element","relative":"/element","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/element","queryKey":{},"chunks":["element"]},"urlOriginal":"/session/abd2bc60-1593-11e7-922e-d790ba7a8581/element"}}
Command duration or timeout: 10.13 seconds
For documentation on this error, please visit: 
http://seleniumhq.org/exceptions/no_such_element.html
Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
09:49:13 -0700'
System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
'1.8.0_111'
Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
Capabilities [{applicationCacheEnabled=false, rotatable=false, 
handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
acceptSslCerts=false, driverVersion=1.2.0, 
phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
*** Element info: {Using=id, value=userName}

Caused by:
org.openqa.selenium.remote.ScreenshotException: Screen shot has 
been taken
Build info: version: '3.0.1', revision: '1969d75', time: 
'2016-10-18 09:49:13 -0700'
System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
'1.8.0_111'
Driver info: driver.version: RemoteWebDriver

Caused by:
org.openqa.selenium.NoSuchElementException: 
{"errorMessage":"Unable to find element with id 
'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
 charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
(Java/1.8.0_111)"},"httpVersion":"1.1","method":"POST","post":"{\"using\":\"id\",\"value\":\"userName\"}","url":"/element","urlParsed":{"anchor":"","query":"","file":"element","directory":"/","path":"/element","relative":"/element","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/element","queryKey":{},"chunks":["element"]},"urlOriginal":"/session/abd2bc60-1593-11e7-922e-d790ba7a8581/element"}}
For documentation on this error, please visit: 
http://seleniumhq.org/exceptions/no_such_element.html
Build info: version: '3.0.1', revision: '1969d75', time: 
'2016-10-18 09:49:13 -0700'
System info: host: 'Kens-MacBook-Pro-2.local', ip: 

[jira] [Updated] (GEODE-2737) PulseAuthTest failures

[Kenneth Howe (JIRA)]

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

Kenneth Howe updated GEODE-2737:

Affects Version/s: 1.1.0

> PulseAuthTest failures
> --
>
> Key: GEODE-2737
> URL: https://issues.apache.org/jira/browse/GEODE-2737
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.0
>Reporter: Kenneth Howe
>
> Tests are failing in the PulseAuthTest (UITest category) with the error:
> {code}
> java.lang.IllegalStateException: The path to the driver executable must be 
> set by the phantomjs.binary.path capability/system property/PATH variable; 
> for more information, see https://github.com/ariya/phantomjs/wiki. The latest 
> version can be downloaded from http://phantomjs.org/download.html
>   at 
> com.google.common.base.Preconditions.checkState(Preconditions.java:199)
>   at 
> org.openqa.selenium.phantomjs.PhantomJSDriverService.findPhantomJS(PhantomJSDriverService.java:236)
>   at 
> org.openqa.selenium.phantomjs.PhantomJSDriverService.createDefaultService(PhantomJSDriverService.java:181)
>   at 
> org.openqa.selenium.phantomjs.PhantomJSDriver.(PhantomJSDriver.java:105)
>   at 
> org.apache.geode.tools.pulse.tests.rules.WebDriverRule.setUpWebDriver(WebDriverRule.java:98)
>   at 
> org.apache.geode.tools.pulse.tests.rules.WebDriverRule.before(WebDriverRule.java:60)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> {code}
> Possibly caused by
> author
> Kevin J. Duling
> author_date   
> 2017-03-21 15:23:05 -0700
> commit
> 6f716278df9803da28a546b102534c8e568eef2d
> committer 
> Kevin J. Duling
> committer_date
> 2017-03-21 15:23:05 -0700
> message   
> GEODE-2704: Remove Pulse's custom StringUtils in favor of Apache Commons 
> StringUtils



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

[jira] [Created] (GEODE-2737) PulseAuthTest failures

[Kenneth Howe (JIRA)]

Kenneth Howe created GEODE-2737:
---

 Summary: PulseAuthTest failures
 Key: GEODE-2737
 URL: https://issues.apache.org/jira/browse/GEODE-2737
 Project: Geode
  Issue Type: Bug
  Components: pulse
Reporter: Kenneth Howe


Tests are failing in the PulseAuthTest (UITest category) with the error:

{code}
java.lang.IllegalStateException: The path to the driver executable must be set 
by the phantomjs.binary.path capability/system property/PATH variable; for more 
information, see https://github.com/ariya/phantomjs/wiki. The latest version 
can be downloaded from http://phantomjs.org/download.html
at 
com.google.common.base.Preconditions.checkState(Preconditions.java:199)
at 
org.openqa.selenium.phantomjs.PhantomJSDriverService.findPhantomJS(PhantomJSDriverService.java:236)
at 
org.openqa.selenium.phantomjs.PhantomJSDriverService.createDefaultService(PhantomJSDriverService.java:181)
at 
org.openqa.selenium.phantomjs.PhantomJSDriver.(PhantomJSDriver.java:105)
at 
org.apache.geode.tools.pulse.tests.rules.WebDriverRule.setUpWebDriver(WebDriverRule.java:98)
at 
org.apache.geode.tools.pulse.tests.rules.WebDriverRule.before(WebDriverRule.java:60)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
{code}

Possibly caused by

author  
Kevin J. Duling
author_date 
2017-03-21 15:23:05 -0700
commit  
6f716278df9803da28a546b102534c8e568eef2d
committer   
Kevin J. Duling
committer_date  
2017-03-21 15:23:05 -0700
message 
GEODE-2704: Remove Pulse's custom StringUtils in favor of Apache Commons 
StringUtils




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

Re: Review Request 58050: GEODE-2725: export logs --dir now honored when not connected via HTTP[S].

[Ken Howe]

> On March 29, 2017, 11:17 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
> > Line 53 (original), 53 (patched)
> > 
> >
> > I keep seeing people changing this class and my reviews keep asking for 
> > the same things: 1) rename it to ExportLogsCommand to be consistent with 
> > other code, 2) create ExportLogsCommandTest which is a UnitTest and start 
> > writing some unit tests for this class.

This rename is part of the review request I posted earlier today: 
https://reviews.apache.org/r/58080/#review170604


- Ken


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


On March 30, 2017, 6:17 p.m., Patrick Rhomberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58050/
> ---
> 
> (Updated March 30, 2017, 6:17 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
> Kirk Lund, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> export logs --dir refers to local filesystem when connected via HTTP and 
> refers to the managers filesystem when connected via JMX.  This behavior will 
> be changed in GEODE-2663.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  3f147c19a128dce78c51c31e6758e517cd2ab496 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  5b1f089c18c404f64929398f6015839eb783ccb4 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
>  268fa397db253f12c0effdbf6faa5e822730144c 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  3c56def01ad58f98ea1707f4dd6b57e643e9eab1 
> 
> 
> Diff: https://reviews.apache.org/r/58050/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin running.
> 
> Manual verification of behavior both with and without --dir option, both 
> connected via HTTP and not.
> 
> 
> Thanks,
> 
> Patrick Rhomberg
> 
>

[jira] [Commented] (GEODE-2734) Investigate/discuss message encoding

[Avinash Dongre (JIRA)]

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

Avinash Dongre commented on GEODE-2734:
---

Thoughts/Comments  on http://www.grpc.io/

> Investigate/discuss message encoding
> 
>
> Key: GEODE-2734
> URL: https://issues.apache.org/jira/browse/GEODE-2734
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Brian Baynes
>
> Out of all the great ways to encode messages (Thrift, Protobuf, etc), which 
> should we use here?  Let's discuss and come to consensus.



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

Re: Wait on macOS 10.12.4 and Xcode 8.3

[Michael William Dodge]

With Dave Barnes' help, we have determined that Xcode 8.3 is the problem. If 
you have already upgraded to Xcode 8.3, you can rollback to Xcode 8.2.1 to 
restore functionality.

Sarge

> On 29 Mar, 2017, at 15:25, Michael William Dodge  wrote:
> 
> With the recent upgrade to macOS 10.12.4 and Xcode 8.3, we're seeing a 
> SIGSEGV/EXC_BAD_ACCESS with pthread_mutex_lock() which is part of the 
> initialization of the ACE libraries. I haven't done enough debugging to know 
> whether it's caused by an incompatibility between ACE and the 10.12.4 
> runtimes (e.g., a struct has changed in size) or if it's an actual bug in the 
> runtimes. Mike Martell found a bug that has already been filed about Emacs 
> crashing with pthread-related problems after this update, so our current 
> theory is that there's a problem in the pthreads library from Apple.
> 
> Sarge

[jira] [Commented] (GEODE-2733) Crash during initialization using Xcode 8.3

[Michael Dodge (JIRA)]

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

Michael Dodge commented on GEODE-2733:
--

I have independently verified that rolling back to Xcode 8.2.1 fixes the 
problem.

> Crash during initialization using Xcode 8.3
> ---
>
> Key: GEODE-2733
> URL: https://issues.apache.org/jira/browse/GEODE-2733
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> Circa 27 March 2017, Apple released the macOS 10.12.4 and Xcode 8.3 updates. 
> After applying those updates, all native client executables (e.g., unit 
> tests, integration tests, quickstarts) crashes with a SIGSEGV/EXC_BAD_ACCESS 
> with pthread_mutex_lock() which is part of the initialization of the ACE 
> libraries. We don't know whether it's caused by an incompatibility between 
> ACE and the 10.12.4 runtimes (e.g., a struct has changed in size) or if it's 
> an actual bug in the runtimes. Mike Martell found a bug that has already been 
> filed with Apple about Emacs crashing with pthread-related problems after 
> this update, so our current theory is that there's a problem in the pthreads 
> library from Apple.
> UPDATE: Dave Barnes installed just macOS 10.12.4 and has had no problems. 
> Thus, it appears that Xcode 8.3 is the culprit. Anecdotal evidence suggests 
> that Xcode 8.3 has other problems, too, which may or may not be related to 
> the crashes.



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

Re: Review Request 58010: GEODE-2716: export logs default behavior changed from filtering at log level INFO to ALL.

[Patrick Rhomberg]

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

(Updated March 30, 2017, 7:19 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
Kirk Lund, and Swapnil Bawaskar.


Changes
---

Added simpler class unit tests, updated variable name and location.


Repository: geode


Description (updated)
---

Added relevant unit and dUnit tests.  Moved default value variable to 
ExportLogsCommand and deleted the now-unused LogService.DEFAULT_LOG_LEVEL


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/internal/logging/LogService.java 
1f8a564 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 3f147c1 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 cbdf1c4 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 95edd42 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionTest.java
 PRE-CREATION 


Diff: https://reviews.apache.org/r/58010/diff/2/

Changes: https://reviews.apache.org/r/58010/diff/1-2/


Testing (updated)
---

precheckin running.


Thanks,

Patrick Rhomberg

[jira] [Assigned] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2730:


Assignee: Jared Stewart

> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



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

[jira] [Updated] (GEODE-2733) Crash during initialization using Xcode 8.3

[Michael Dodge (JIRA)]

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

Michael Dodge updated GEODE-2733:
-
Description: 
Circa 27 March 2017, Apple released the macOS 10.12.4 and Xcode 8.3 updates. 
After applying those updates, all native client executables (e.g., unit tests, 
integration tests, quickstarts) crashes with a SIGSEGV/EXC_BAD_ACCESS with 
pthread_mutex_lock() which is part of the initialization of the ACE libraries. 
We don't know whether it's caused by an incompatibility between ACE and the 
10.12.4 runtimes (e.g., a struct has changed in size) or if it's an actual bug 
in the runtimes. Mike Martell found a bug that has already been filed with 
Apple about Emacs crashing with pthread-related problems after this update, so 
our current theory is that there's a problem in the pthreads library from Apple.

UPDATE: Dave Barnes installed just macOS 10.12.4 and has had no problems. Thus, 
it appears that Xcode 8.3 is the culprit. Anecdotal evidence suggests that 
Xcode 8.3 has other problems, too, which may or may not be related to the 
crashes.

  was:Circa 27 March 2017, Apple released the macOS 10.12.4 and Xcode 8.3 
updates. After applying those updates, all native client executables (e.g., 
unit tests, integration tests, quickstarts) crashes with a 
SIGSEGV/EXC_BAD_ACCESS with pthread_mutex_lock() which is part of the 
initialization of the ACE libraries. We don't know whether it's caused by an 
incompatibility between ACE and the 10.12.4 runtimes (e.g., a struct has 
changed in size) or if it's an actual bug in the runtimes. Mike Martell found a 
bug that has already been filed with Apple about Emacs crashing with 
pthread-related problems after this update, so our current theory is that 
there's a problem in the pthreads library from Apple.

Summary: Crash during initialization using Xcode 8.3  (was: Crash 
during initialization using macOS 10.12.4 and Xcode 8.3)

> Crash during initialization using Xcode 8.3
> ---
>
> Key: GEODE-2733
> URL: https://issues.apache.org/jira/browse/GEODE-2733
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>
> Circa 27 March 2017, Apple released the macOS 10.12.4 and Xcode 8.3 updates. 
> After applying those updates, all native client executables (e.g., unit 
> tests, integration tests, quickstarts) crashes with a SIGSEGV/EXC_BAD_ACCESS 
> with pthread_mutex_lock() which is part of the initialization of the ACE 
> libraries. We don't know whether it's caused by an incompatibility between 
> ACE and the 10.12.4 runtimes (e.g., a struct has changed in size) or if it's 
> an actual bug in the runtimes. Mike Martell found a bug that has already been 
> filed with Apple about Emacs crashing with pthread-related problems after 
> this update, so our current theory is that there's a problem in the pthreads 
> library from Apple.
> UPDATE: Dave Barnes installed just macOS 10.12.4 and has had no problems. 
> Thus, it appears that Xcode 8.3 is the culprit. Anecdotal evidence suggests 
> that Xcode 8.3 has other problems, too, which may or may not be related to 
> the crashes.



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

Re: Review Request 58080: GEODE-2420: Add classes to estimated the size of exported logs

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
Lines 265 (patched)


I think you probably intended to reference the constants declared below 
here.



geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
Lines 24 (patched)


Is there a reason you chose to use DataSerializable instead the Java 
built-in Serializable?  Just curious as I'm not too familiar with 
DataSerializable.



geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
Lines 60 (patched)


Might want to make this class final if using getClass() in the equals 
implementation.  (Effective Java has a big discussion about this if you're 
interested)



geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
Lines 77 (patched)


I think this might be simpler implementation: 
```
public int hashCode(){
return Objects.hash(logsSize, diskAvailable, diskSize);
}
```


- Jared Stewart


On March 30, 2017, 2:43 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58080/
> ---
> 
> (Updated March 30, 2017, 2:43 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Kirk 
> Lund, and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - New Function class added with tests
> - Code to invoke new function added, but disabled, in ExportLogsCommand
> - New option added, but disabled, for specifying size limit for exported
>   logs
> - Refactoring: extracted the interceptor from ExportLogsCommand
> - Refactoring: renamed ExportLogCommand to ExportLogsCommand
> - New Serializable class to return the log size estimate to the command
> - Tests for the log sizing related classes
> 
> This is work-in-progress that is adds sizing estimation for exported logs, 
> but the code is currently not called by ExportLogsCommand. Follow-on work 
> will use the new sizing estimation to provide warnings to the user if 
> exporting logs may fill up disks on servers or the locator.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  3f147c19a128dce78c51c31e6758e517cd2ab496 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
>  cbdf1c4bc28554a8fbec3740c566ee07c69b4ac9 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  5b1f089c18c404f64929398f6015839eb783ccb4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogSizer.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  95edd426da8b8f39bb1486661d8c307d43f170d6 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
>  268fa397db253f12c0effdbf6faa5e822730144c 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
>  573701fd7f48c8c1b72c0f71993a4adea7bdbe8b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
>  5a4d274a751a6e22fcfbc0c5e6bd5dff39e3b938 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LogLevelInterceptorTest.java
>  41b971534fd83c87f33751fa46454e158315f6ae 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfoTest.java
>  PRE-CREATION 

Re: Review Request 58050: GEODE-2725: export logs --dir now honored when not connected via HTTP[S].

[Patrick Rhomberg]

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

(Updated March 30, 2017, 6:17 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Ken Howe, 
Kirk Lund, and Swapnil Bawaskar.


Changes
---

Added appropriate unittests, reverted collapse of exceptions in files otherwise 
untouched, corrected --dir behavior to not also address GEODE-2663.


Repository: geode


Description (updated)
---

export logs --dir refers to local filesystem when connected via HTTP and refers 
to the managers filesystem when connected via JMX.  This behavior will be 
changed in GEODE-2663.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 3f147c19a128dce78c51c31e6758e517cd2ab496 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
 268fa397db253f12c0effdbf6faa5e822730144c 


Diff: https://reviews.apache.org/r/58050/diff/2/

Changes: https://reviews.apache.org/r/58050/diff/1-2/


Testing (updated)
---

precheckin running.

Manual verification of behavior both with and without --dir option, both 
connected via HTTP and not.


Thanks,

Patrick Rhomberg

Re: Client Commands and SecurityService

[Kirk Lund]

PS: I'll be writing and using JMH benchmarks to drive these changes. I'll
also create new unit tests for each of these classes that don't currently
have unit tests.

On Thu, Mar 30, 2017 at 10:58 AM, Kirk Lund  wrote:

> The client Commands now check with SecurityService even when security is
> not configured. This has introduced a negative performance impact.
>
> The best way to fix something like this is to tell the Command instance
> when it's being constructed that is does or does not need to perform
> security checks.
>
> Unfortunately, Commands are all implemented as singletons which are very
> eagerly instantiated during class loading of CommandInitializer (who
> thought that was a good idea?!).
>
> In order to fix this performance problem, I would need to get rid of these
> problematic static initializer blocks that so eagerly construct the
> Commands so that I can put off constructing them until AFTER the Cache is
> initializing and specifically AFTER the Cache has determined if it is using
> security or not.
>
> This means I'm going to have to do some refactoring of CommandInitializer,
> the Command classes, ServerConnection, AcceptorImpl, etc.
>
> Any other approach is going to have such minimal impact on performance
> that I'm not even interested in doing less than this.
>
> From a very high level, I would change the code so that the Cache owns the
> Server which owns the Command instances. In this way, the configuring of
> use of security can trickle down from Cache to each Command. I would
> primarily be altering static singletons, static initializers and adding
> constructors.
>
> Does anyone have a problem with me changing the above classes and
> especially getting rid of the static initializers and singleton instances?
>
>

Client Commands and SecurityService

[Kirk Lund]

The client Commands now check with SecurityService even when security is
not configured. This has introduced a negative performance impact.

The best way to fix something like this is to tell the Command instance
when it's being constructed that is does or does not need to perform
security checks.

Unfortunately, Commands are all implemented as singletons which are very
eagerly instantiated during class loading of CommandInitializer (who
thought that was a good idea?!).

In order to fix this performance problem, I would need to get rid of these
problematic static initializer blocks that so eagerly construct the
Commands so that I can put off constructing them until AFTER the Cache is
initializing and specifically AFTER the Cache has determined if it is using
security or not.

This means I'm going to have to do some refactoring of CommandInitializer,
the Command classes, ServerConnection, AcceptorImpl, etc.

Any other approach is going to have such minimal impact on performance that
I'm not even interested in doing less than this.

>From a very high level, I would change the code so that the Cache owns the
Server which owns the Command instances. In this way, the configuring of
use of security can trickle down from Cache to each Command. I would
primarily be altering static singletons, static initializers and adding
constructors.

Does anyone have a problem with me changing the above classes and
especially getting rid of the static initializers and singleton instances?

[jira] [Updated] (GEODE-2727) optimize new 1.8 ConcurrentMap default methods on Region

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2727:
--
Description: 
I can now edit this!

In JDK 1.8 ConcurrentMap added the following default methods to the interface:
  getOrDefault
  computeIfAbsent
  computeIfPresent
  compute
  merge
  foreach
  replaceAll

All of the default implementations of these methods have issues with get 
returning null when the key actually exists. So they do not support invalid 
region entries.
The other problem with all of them (except getOrDefault) is that they will make 
multiple round trips when done from a proxy. In a distributed environment we 
should implement these to send the lambda to the primary so that the entire 
operation can be done with one message and while the RegionEntry is locked.
This would require that the lambda parameter by serializable which would be 
consistent with what we do for other parameters to Region methods (for example 
"put").
>From a performance point of view "foreach" and "replaceAll" are the worst 
>since they bring back to whoever is executing the method all the keys and 
>values from the entire cluster.
It is also worth considering how the operations behave in a geode transaction.

  was:
In JDK 1.8 ConcurrentMap added the following default methods to the interface:
  getOrDefault
  computeIfAbsent
  computeIfPresent
  compute
  merge
  foreach
  replaceAll

All of the default implementations of these methods have issues with get 
returning null when the key actually exists. So they do not support invalid 
region entries.
The other problem with all of them (except getOrDefault) is that they will make 
multiple round trips when done from a proxy. In a distributed environment we 
should implement these to send the lambda to the primary so that the entire 
operation can be done with one message and while the RegionEntry is locked.
This would require that the lambda parameter by serializable which would be 
consistent with what we do for other parameters to Region methods (for example 
"put").
>From a performance point of view "foreach" and "replaceAll" are the worst 
>since they bring back to whoever is executing the method all the keys and 
>values from the entire cluster.
It is also worth considering how the operations behave in a geode transaction.


> optimize new 1.8 ConcurrentMap default methods on Region
> 
>
> Key: GEODE-2727
> URL: https://issues.apache.org/jira/browse/GEODE-2727
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>
> I can now edit this!
> In JDK 1.8 ConcurrentMap added the following default methods to the interface:
>   getOrDefault
>   computeIfAbsent
>   computeIfPresent
>   compute
>   merge
>   foreach
>   replaceAll
> All of the default implementations of these methods have issues with get 
> returning null when the key actually exists. So they do not support invalid 
> region entries.
> The other problem with all of them (except getOrDefault) is that they will 
> make multiple round trips when done from a proxy. In a distributed 
> environment we should implement these to send the lambda to the primary so 
> that the entire operation can be done with one message and while the 
> RegionEntry is locked.
> This would require that the lambda parameter by serializable which would be 
> consistent with what we do for other parameters to Region methods (for 
> example "put").
> From a performance point of view "foreach" and "replaceAll" are the worst 
> since they bring back to whoever is executing the method all the keys and 
> values from the entire cluster.
> It is also worth considering how the operations behave in a geode transaction.



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

Re: Requesting edit permissions for Geode tickets

[Kirk Lund]

I gave you permissions for Jira. Someone else still needs to give you karma
on the Wiki.

-Kirk

On Thu, Mar 30, 2017 at 9:22 AM, Fred Krone  wrote:

> Hi,
>
> Could I get editing permissions for Geode tickets?  I can only edit mine
> and I'd like to reword some descriptions etc on other tickets.  I'd also
> like to edit some wikis if needed.
>
> Both ASF and JIRA IDs are fkrone.
>
> Thanks,
>
> -Fred
>

[jira] [Created] (GEODE-2736) Native client thread pool get stuck sometimes during rolling restart

[Mark Hanson (JIRA)]

Mark Hanson created GEODE-2736:
--

 Summary: Native client thread pool get stuck sometimes during 
rolling restart
 Key: GEODE-2736
 URL: https://issues.apache.org/jira/browse/GEODE-2736
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Mark Hanson


Users has a function which executes on all nodes hosting the region, during 
rolling restart of the Geode servers, occasionally all the threads in the Geode 
native client thread pool get stuck sometimes when certain exceptions are 
thrown.
The user thinks it is due to possible incorrect exception handling inside the 
Geode native client code

This leads to application threads getting stuck as the thread pool is not 
available



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

Re: Request for edit permissions

[Kirk Lund]

I gave you access in Jira.

I'm not sure how to give you access in Wiki though. Roman, if you want to
give me permissions to give Wiki karma, I'll be happy to help Brian there
as well.

-Kirk

On Thu, Mar 30, 2017 at 9:08 AM, Brian Baynes  wrote:

> Hi, Roman.
>
> Sure, understood -- that info was by way of introduction, not a claim to
> anything :)
> Thanks for making it clear.
>
> Both IDs are bbaynes.
>
> Thanks for helping me get set up!
>
> Bran
>
> On Thu, Mar 30, 2017 at 8:50 AM, Roman Shaposhnik 
> wrote:
>
> > Hi Brian!
> >
> > On Thu, Mar 30, 2017 at 8:32 AM, Brian Baynes 
> wrote:
> > > Hello,
> > >
> > > I'm a new PM at Pivotal working with the Communications team.
> >
> > Quick note on the Apache way of doing things. While we appreciate
> > knowing your relationship with Pivotal please realize that neither your
> > title nor your affiliation with this particular employer have any
> bearings
> > on what kind of access you get with the project. We're all contributing
> > to Apache Geode as individual contributors and a lot of times we don't
> > even know the employment affiliation of others.
> >
> > This is a good thing. This is how Apache Way works.
> >
> > > I'd like to request edit access for wikis and Jira tickets for Geode.
> > For
> > > example, I'd like to edit the description for GEODE-2580, a project our
> > > team is working on.
> >
> > Now, for both of these -- we welcome all levels of contributions - giving
> > you
> > an access is not a problem.
> >
> > What's your ASF wiki and JIRA ID?
> >
> > Thanks,
> > Roman.
> >
>

Requesting edit permissions for Geode tickets

[Fred Krone]

Hi,

Could I get editing permissions for Geode tickets?  I can only edit mine
and I'd like to reword some descriptions etc on other tickets.  I'd also
like to edit some wikis if needed.

Both ASF and JIRA IDs are fkrone.

Thanks,

-Fred

[jira] [Closed] (GEODE-2731) Specifying in cache.xml file causing server error on start up.

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-2731.


> Specifying   in cache.xml file causing server error on 
> start up. 
> -
>
> Key: GEODE-2731
> URL: https://issues.apache.org/jira/browse/GEODE-2731
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Andrei Biketov
>
> Configure region as following:
> 
> data-policy="partition" statistics-enabled="true">
>   total-num-buckets="12"/>
>  
>  action="overflow-to-disk"/>
>
>  
>  
>  
>  
>   
> Run server:
> gfsh>start server --name=s1 --cache-xml-file=site_a.xml
> Starting a Geode Server in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1 for full 
> details.
> Exception in thread "main" org.apache.geode.cache.CacheXmlException: While 
> reading Cache XML file:/C:/sandbox/pivotal-gemfire-9.0.1/bin/site_a.xml. 
> Error while parsing XML, caused by org.xml.sax.SAXParseException; lineNumber: 
> 61; columnNumber: 26; cvc-complex-type.2.4.d: Invalid content was found 
> starting with element 'entry-time-to-live'. No child element is expected at 
> this point.
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXml.error(CacheXml.java:890)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.error(CacheXmlParser.java:3409)
> at 
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:137)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284)
> at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452)



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

[jira] [Resolved] (GEODE-2731) Specifying in cache.xml file causing server error on start up.

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2731.
--
Resolution: Not A Problem

> Specifying   in cache.xml file causing server error on 
> start up. 
> -
>
> Key: GEODE-2731
> URL: https://issues.apache.org/jira/browse/GEODE-2731
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Andrei Biketov
>
> Configure region as following:
> 
> data-policy="partition" statistics-enabled="true">
>   total-num-buckets="12"/>
>  
>  action="overflow-to-disk"/>
>
>  
>  
>  
>  
>   
> Run server:
> gfsh>start server --name=s1 --cache-xml-file=site_a.xml
> Starting a Geode Server in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1 for full 
> details.
> Exception in thread "main" org.apache.geode.cache.CacheXmlException: While 
> reading Cache XML file:/C:/sandbox/pivotal-gemfire-9.0.1/bin/site_a.xml. 
> Error while parsing XML, caused by org.xml.sax.SAXParseException; lineNumber: 
> 61; columnNumber: 26; cvc-complex-type.2.4.d: Invalid content was found 
> starting with element 'entry-time-to-live'. No child element is expected at 
> this point.
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXml.error(CacheXml.java:890)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.error(CacheXmlParser.java:3409)
> at 
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:137)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284)
> at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452)



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

[jira] [Updated] (GEODE-2731) Specifying in cache.xml file causing server error on start up.

[Andrei Biketov (JIRA)]

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

Andrei Biketov updated GEODE-2731:
--

Hi Anthony,

I figured out this one. It was actually the matter of ordering of this xml
element. After I moved it up error is disappeared. It can be closed.


 * *
*   *
*   *
  
  

  
   *
  


Thanks,

Andrei

On Thu, Mar 30, 2017 at 11:45 AM, Anthony Baker (JIRA) 



> Specifying   in cache.xml file causing server error on 
> start up. 
> -
>
> Key: GEODE-2731
> URL: https://issues.apache.org/jira/browse/GEODE-2731
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Andrei Biketov
>
> Configure region as following:
> 
> data-policy="partition" statistics-enabled="true">
>   total-num-buckets="12"/>
>  
>  action="overflow-to-disk"/>
>
>  
>  
>  
>  
>   
> Run server:
> gfsh>start server --name=s1 --cache-xml-file=site_a.xml
> Starting a Geode Server in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1 for full 
> details.
> Exception in thread "main" org.apache.geode.cache.CacheXmlException: While 
> reading Cache XML file:/C:/sandbox/pivotal-gemfire-9.0.1/bin/site_a.xml. 
> Error while parsing XML, caused by org.xml.sax.SAXParseException; lineNumber: 
> 61; columnNumber: 26; cvc-complex-type.2.4.d: Invalid content was found 
> starting with element 'entry-time-to-live'. No child element is expected at 
> this point.
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXml.error(CacheXml.java:890)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.error(CacheXmlParser.java:3409)
> at 
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:137)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284)
> at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452)



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

Re: Request for edit permissions

[Brian Baynes]

Hi, Roman.

Sure, understood -- that info was by way of introduction, not a claim to
anything :)
Thanks for making it clear.

Both IDs are bbaynes.

Thanks for helping me get set up!

Bran

On Thu, Mar 30, 2017 at 8:50 AM, Roman Shaposhnik 
wrote:

> Hi Brian!
>
> On Thu, Mar 30, 2017 at 8:32 AM, Brian Baynes  wrote:
> > Hello,
> >
> > I'm a new PM at Pivotal working with the Communications team.
>
> Quick note on the Apache way of doing things. While we appreciate
> knowing your relationship with Pivotal please realize that neither your
> title nor your affiliation with this particular employer have any bearings
> on what kind of access you get with the project. We're all contributing
> to Apache Geode as individual contributors and a lot of times we don't
> even know the employment affiliation of others.
>
> This is a good thing. This is how Apache Way works.
>
> > I'd like to request edit access for wikis and Jira tickets for Geode.
> For
> > example, I'd like to edit the description for GEODE-2580, a project our
> > team is working on.
>
> Now, for both of these -- we welcome all levels of contributions - giving
> you
> an access is not a problem.
>
> What's your ASF wiki and JIRA ID?
>
> Thanks,
> Roman.
>

[jira] [Updated] (GEODE-2735) CliUtil.isGfshVM is not thread-safe and unnecessary

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2735:
-
Issue Type: Wish  (was: Bug)

> CliUtil.isGfshVM is not thread-safe and unnecessary
> ---
>
> Key: GEODE-2735
> URL: https://issues.apache.org/jira/browse/GEODE-2735
> Project: Geode
>  Issue Type: Wish
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The top of CliUtil defines:
> {noformat}
> public static final String GFSHVM_IDENTIFIER = "gfsh";
> public static boolean isGfshVM = Boolean.getBoolean(GFSHVM_IDENTIFIER);
> {noformat}
> Tests then set isGfshVM and unset that in setup/teardown. Various GFSH 
> commands check the state of this boolean.
> It would be thread-safe if it were volatile, but I'd prefer to just get rid 
> of this static variable.



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

[jira] [Assigned] (GEODE-2735) CliUtil.isGfshVM is not thread-safe and unnecessary

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2735:


Assignee: Kirk Lund

> CliUtil.isGfshVM is not thread-safe and unnecessary
> ---
>
> Key: GEODE-2735
> URL: https://issues.apache.org/jira/browse/GEODE-2735
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The top of CliUtil defines:
> {noformat}
> public static final String GFSHVM_IDENTIFIER = "gfsh";
> public static boolean isGfshVM = Boolean.getBoolean(GFSHVM_IDENTIFIER);
> {noformat}
> Tests then set isGfshVM and unset that in setup/teardown. Various GFSH 
> commands check the state of this boolean.
> It would be thread-safe if it were volatile, but I'd prefer to just get rid 
> of this static variable.



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

[jira] [Created] (GEODE-2735) CliUtil.isGfshVM is not thread-safe and unnecessary

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2735:


 Summary: CliUtil.isGfshVM is not thread-safe and unnecessary
 Key: GEODE-2735
 URL: https://issues.apache.org/jira/browse/GEODE-2735
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Kirk Lund


The top of CliUtil defines:
{noformat}
public static final String GFSHVM_IDENTIFIER = "gfsh";
public static boolean isGfshVM = Boolean.getBoolean(GFSHVM_IDENTIFIER);
{noformat}
Tests then set isGfshVM and unset that in setup/teardown. Various GFSH commands 
check the state of this boolean.

It would be thread-safe if it were volatile, but I'd prefer to just get rid of 
this static variable.



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

Re: Request for edit permissions

[Roman Shaposhnik]

Hi Brian!

On Thu, Mar 30, 2017 at 8:32 AM, Brian Baynes  wrote:
> Hello,
>
> I'm a new PM at Pivotal working with the Communications team.

Quick note on the Apache way of doing things. While we appreciate
knowing your relationship with Pivotal please realize that neither your
title nor your affiliation with this particular employer have any bearings
on what kind of access you get with the project. We're all contributing
to Apache Geode as individual contributors and a lot of times we don't
even know the employment affiliation of others.

This is a good thing. This is how Apache Way works.

> I'd like to request edit access for wikis and Jira tickets for Geode.  For
> example, I'd like to edit the description for GEODE-2580, a project our
> team is working on.

Now, for both of these -- we welcome all levels of contributions - giving you
an access is not a problem.

What's your ASF wiki and JIRA ID?

Thanks,
Roman.

[jira] [Commented] (GEODE-2731) Specifying in cache.xml file causing server error on start up.

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-2731:
--

Is your {{cache.xml}} file valid according to the schema at 
http://geode.apache.org/schema/cache/cache-1.0.xsd?


> Specifying   in cache.xml file causing server error on 
> start up. 
> -
>
> Key: GEODE-2731
> URL: https://issues.apache.org/jira/browse/GEODE-2731
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Andrei Biketov
>
> Configure region as following:
> 
> data-policy="partition" statistics-enabled="true">
>   total-num-buckets="12"/>
>  
>  action="overflow-to-disk"/>
>
>  
>  
>  
>  
>   
> Run server:
> gfsh>start server --name=s1 --cache-xml-file=site_a.xml
> Starting a Geode Server in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1 for full 
> details.
> Exception in thread "main" org.apache.geode.cache.CacheXmlException: While 
> reading Cache XML file:/C:/sandbox/pivotal-gemfire-9.0.1/bin/site_a.xml. 
> Error while parsing XML, caused by org.xml.sax.SAXParseException; lineNumber: 
> 61; columnNumber: 26; cvc-complex-type.2.4.d: Invalid content was found 
> starting with element 'entry-time-to-live'. No child element is expected at 
> this point.
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXml.error(CacheXml.java:890)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.error(CacheXmlParser.java:3409)
> at 
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:137)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284)
> at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452)



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

Request for edit permissions

[Brian Baynes]

Hello,

I'm a new PM at Pivotal working with the Communications team.
I'd like to request edit access for wikis and Jira tickets for Geode.  For
example, I'd like to edit the description for GEODE-2580, a project our
team is working on.

Thanks,
Brian Baynes

[jira] [Created] (GEODE-2734) Investigate/discuss message encoding

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2734:
---

 Summary: Investigate/discuss message encoding
 Key: GEODE-2734
 URL: https://issues.apache.org/jira/browse/GEODE-2734
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Brian Baynes


Out of all the great ways to encode messages (Thrift, Protobuf, etc), which 
should we use here?  Let's discuss and come to consensus.



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

[jira] [Created] (GEODE-2733) Crash during initialization using macOS 10.12.4 and Xcode 8.3

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2733:


 Summary: Crash during initialization using macOS 10.12.4 and Xcode 
8.3
 Key: GEODE-2733
 URL: https://issues.apache.org/jira/browse/GEODE-2733
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Michael Dodge


Circa 27 March 2017, Apple released the macOS 10.12.4 and Xcode 8.3 updates. 
After applying those updates, all native client executables (e.g., unit tests, 
integration tests, quickstarts) crashes with a SIGSEGV/EXC_BAD_ACCESS with 
pthread_mutex_lock() which is part of the initialization of the ACE libraries. 
We don't know whether it's caused by an incompatibility between ACE and the 
10.12.4 runtimes (e.g., a struct has changed in size) or if it's an actual bug 
in the runtimes. Mike Martell found a bug that has already been filed with 
Apple about Emacs crashing with pthread-related problems after this update, so 
our current theory is that there's a problem in the pthreads library from Apple.



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

Re: Wait on macOS 10.12.4 and Xcode 8.3

[Michael William Dodge]

GEODE-2733

> On 29 Mar, 2017, at 19:44, Jacob Barrett  wrote:
> 
> Can you please open a JIRA so we can track this issue, should it require an
> update to ACE or our own sources.
> 
> Thanks,
> Jake
> 
> On Wed, Mar 29, 2017 at 3:25 PM Michael William Dodge 
> wrote:
> 
>> With the recent upgrade to macOS 10.12.4 and Xcode 8.3, we're seeing a
>> SIGSEGV/EXC_BAD_ACCESS with pthread_mutex_lock() which is part of the
>> initialization of the ACE libraries. I haven't done enough debugging to
>> know whether it's caused by an incompatibility between ACE and the 10.12.4
>> runtimes (e.g., a struct has changed in size) or if it's an actual bug in
>> the runtimes. Mike Martell found a bug that has already been filed about
>> Emacs crashing with pthread-related problems after this update, so our
>> current theory is that there's a problem in the pthreads library from Apple.
>> 
>> Sarge

[jira] [Created] (GEODE-2732) after auto-reconnect a server is restarted on the default port of 40404

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2732:
---

 Summary: after auto-reconnect a server is restarted on the default 
port of 40404
 Key: GEODE-2732
 URL: https://issues.apache.org/jira/browse/GEODE-2732
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Bruce Schuchardt


If you start a server using gfsh with the server defined in a cache.xml and you 
specify the server's port Geode will ignore this setting in the event of an 
auto-reconnect.  I observed this in a GemFire deployment and the code in this 
area hasn't changed in Apache Geode.  By chance port 40404 was already in use 
when the auto-reconnect occurred and an exception was thrown.

{noformat}
com.gemstone.gemfire.GemFireIOException: While starting bridge server  
CacheServer on port=40404 client subscription config policy=none client 
subscription config capacity=1 client subscription config overflow directory=.
at 
com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:611)
at 
com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:340)
at 
com.gemstone.gemfire.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4263)
at 
com.gemstone.gemfire.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1178)
at 
com.gemstone.gemfire.internal.cache.GemFireCacheImpl.init(GemFireCacheImpl.java:1020)
at 
com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:684)
at 
com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2909)
at 
com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2655)
at 
com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1058)
at 
com.gemstone.gemfire.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4822)
at 
com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.uncleanShutdown(JGroupMembershipManager.java:2733)
at 
com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager$Puller.channelClosing(JGroupMembershipManager.java:1213)
at 
com.gemstone.org.jgroups.JChannel$CloserThread.run(JChannel.java:1617)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:463)
at sun.nio.ch.Net.bind(Net.java:455)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:432)
at 
com.gemstone.gemfire.internal.cache.BridgeServerImpl.start(BridgeServerImpl.java:342)
at 
com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:607)
... 12 more
{noformat}

I think the fix is to get rid of the ThreadLocal storage of the port and bind 
address in CacheServerLauncher.  These variables are used by the XML parser to 
configure a server.  Gfsh sets them in its thread but they aren't available in 
the auto-reconnect thread that rebuilds the cache.



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

Re: [gemfire-dev] More detailed Geode Modularization proposal

[Udo Kohlmeyer]

Hi William,

I had looked at this. I liked the idea of JDK9's modular approach. With 
it's GA data not too far off, it is a definite contender.


--Udo

On 3/29/17 17:35, William Markito Oliveira wrote:


Since the modularization effort may take a significant time and one of the
big features of Java 9 is modularization, why not leverage the
infrastructure of the JDK [1] for that ?  This would not only bring the
modularization but also make it 100% compatible with Java 9.

It also provide solutions around class-loaders [2].

Food for thought... :)

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining-modules
[2] http://openjdk.java.net/projects/jigsaw/spec/sotms/#class-loaders

On Wed, Mar 29, 2017 at 3:29 PM, Jared Stewart  wrote:


I have some questions about the ClassLoader isolation proposal. If the
class loaders of different modules are truly isolated, how can any module
load classes from a different module?  And conversely, if different modules
can load classes from each other, how can they truly be isolated?  In
something like an application server, this seems much simpler, since the
wars that get deployed to an app server should never need to interact with
each other.  But how can this work with Geode modules?


On Mar 29, 2017, at 10:00 AM, Udo Kohlmeyer 

wrote:

Hi there Guys,

A more detailed proposal for a more modular Geode is available. Please

review and comment, either on this thread or on confluence.

https://cwiki.apache.org/confluence/display/GEODE/

Geode+Modularization+-+An+approach

Udo

[jira] [Updated] (GEODE-2718) inconsistent reads during network partition

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-2718:

Component/s: (was: membership)

> inconsistent reads during network partition
> ---
>
> Key: GEODE-2718
> URL: https://issues.apache.org/jira/browse/GEODE-2718
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>
> non-persistent partitioned regions exhibit the following behavior:
>  In the event of a network partition where all copies of a bucket end up on 
> the losing side, a get() operation returns a null. A null can signify that 
> the key did not exist, so we should be more explicit about the network 
> partition and throw an error like PartitionOfflineException (which is thrown 
> if the region was persistent).



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

[jira] [Commented] (GEODE-2718) inconsistent reads during network partition

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-2718:
-

I was talking with [~dschneider] about this ticket and he pointed out that the 
bucket advisors don't really need to see the view change.  They just need to 
notice that data has been lost .

I think the correct thing to do is take advantage of the redundancy zone (rack 
aware) feature of Geode to make sure you don't lose data in the event of a 
network partition.  That will cause buckets to be backed up on a different rack.

> inconsistent reads during network partition
> ---
>
> Key: GEODE-2718
> URL: https://issues.apache.org/jira/browse/GEODE-2718
> Project: Geode
>  Issue Type: Bug
>  Components: membership, regions
>Reporter: Swapnil Bawaskar
>
> non-persistent partitioned regions exhibit the following behavior:
>  In the event of a network partition where all copies of a bucket end up on 
> the losing side, a get() operation returns a null. A null can signify that 
> the key did not exist, so we should be more explicit about the network 
> partition and throw an error like PartitionOfflineException (which is thrown 
> if the region was persistent).



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

[jira] [Created] (GEODE-2731) Specifying in cache.xml file causing server error on start up.

[Andrei Biketov (JIRA)]

Andrei Biketov created GEODE-2731:
-

 Summary: Specifying   in cache.xml file 
causing server error on start up. 
 Key: GEODE-2731
 URL: https://issues.apache.org/jira/browse/GEODE-2731
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Andrei Biketov


Configure region as following:


   
   
 
 
   
   
   
   

Run server:
gfsh>start server --name=s1 --cache-xml-file=site_a.xml
Starting a Geode Server in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1...
The Cache Server process terminated unexpectedly with exit status 1. Please 
refer to the log file in C:\sandbox\pivotal-gemfire-9.0.1\bin\s1 for full 
details.

Exception in thread "main" org.apache.geode.cache.CacheXmlException: While 
reading Cache XML file:/C:/sandbox/pivotal-gemfire-9.0.1/bin/site_a.xml. Error 
while parsing XML, caused by org.xml.sax.SAXParseException; lineNumber: 61; 
columnNumber: 26; cvc-complex-type.2.4.d: Invalid content was found starting 
with element 'entry-time-to-live'. No child element is expected at this point.
at 
org.apache.geode.internal.cache.xmlcache.CacheXml.error(CacheXml.java:890)
at 
org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.error(CacheXmlParser.java:3409)
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:137)
at 
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
at 
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
at 
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:452)



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

Review Request 58080: GEODE-2420: Add classes to estimated the size of exported logs

[Ken Howe]

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

Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, Kirk Lund, 
and Patrick Rhomberg.


Repository: geode


Description
---

- New Function class added with tests
- Code to invoke new function added, but disabled, in ExportLogsCommand
- New option added, but disabled, for specifying size limit for exported
  logs
- Refactoring: extracted the interceptor from ExportLogsCommand
- Refactoring: renamed ExportLogCommand to ExportLogsCommand
- New Serializable class to return the log size estimate to the command
- Tests for the log sizing related classes

This is work-in-progress that is adds sizing estimation for exported logs, but 
the code is currently not called by ExportLogsCommand. Follow-on work will use 
the new sizing estimation to provide warnings to the user if exporting logs may 
fill up disks on servers or the locator.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 3f147c19a128dce78c51c31e6758e517cd2ab496 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 cbdf1c4bc28554a8fbec3740c566ee07c69b4ac9 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 5b1f089c18c404f64929398f6015839eb783ccb4 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogSizer.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 95edd426da8b8f39bb1486661d8c307d43f170d6 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
 268fa397db253f12c0effdbf6faa5e822730144c 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
 573701fd7f48c8c1b72c0f71993a4adea7bdbe8b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
 5a4d274a751a6e22fcfbc0c5e6bd5dff39e3b938 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LogLevelInterceptorTest.java
 41b971534fd83c87f33751fa46454e158315f6ae 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfoTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionCacheTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionFileTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsTestSuite.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogSizerTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 6ae82da58923fdf3a44217c1773a40d8ff1001bc 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedDataSerializables.txt
 2f5a5cdf8c59e90625fe01c3306462e9277ab4e1 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/sanctionedSerializables.txt
 397ec14c0bbbea277d378eefcaecfdb90cc9e224 


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


Testing
---

Precheckin is running


Thanks,

Ken Howe