[GitHub] geode issue #397: Add junit to try parsing of simple XML file w pool ...

[oshvarts]

Github user oshvarts commented on the issue:

https://github.com/apache/geode/pull/397
  
@metatype @kirklund could you move this forward please?


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

Re: One class loader vs multiple class loaders for deployed jars

[Jacob Barrett]

There are certainly many projects in the OS community that have solved this
same problem. Perhaps we can find a class loader from a project that would
suite this need.

Quick search of standalone frameworks comes up with a few popular hits:
https://github.com/kamranzafar/JCL
https://github.com/jboss-modules/jboss-modules

-Jake




On Mon, Apr 10, 2017 at 1:40 PM Kirk Lund  wrote:

> I think Jared started down this path because we had a custom classloader
> implementation that he was trying to get rid of -- that impl was pretty
> limited and forced loading of all classes up-front.
>
> Now the code uses fast classpath scanner and that old custom classloader
> can't be used. The old classloader is so simplistic and limited that trying
> to modify it looks like more work than writing a new one from scratch.
> Implementing a new custom classloader or switching our codebase to use a
> new classloader container (using an existing solution) are both possible
> directions. Until that's completed the "deploy jar" command will continue
> to force ALL classes to be loaded up-front.
>
> One major concern is that implementing a new custom classloader is
> non-trivial and could also introduce some new classloader bugs -- of
> particular interest to "deploy jar" is the fact that Java remembers TWO
> classloaders for each class [1] -- the CL that *loaded* the class AND the
> CL that *initiated* the request to load the class -- dropping the
> *initiating* CL at runtime can result in failures to load additional
> classes from the CL that directly loaded the class even though that CL is
> intact and available.
>
> [1] states: "When one class loader delegates to another class loader, the
> loader that initiates the loading is not necessarily the same loader that
> completes the loading and defines the class. If L creates C, either by
> defining it directly or by delegation, we say that L initiates loading of C
> or, equivalently, that L is an *initiating* loader of C."
>
> For better or worse, this is one of the reasons why that old custom CL was
> naively force loading all classes up-front -- ie, to avoid runtime
> classloading failures if the initiating CL was dropped or replaced and
> ultimately GC'ed. Java won't let you drop the *loading* CL but it will
> allow you to drop the *initiating* CL (or it did historically -- the
> reference seems to be down in native code, not in java.lang.Class). You'd
> have to find some way to force all initiating requests up to the parent
> application CL (or somehow prevent code in deployed jars from initiating
> requests from other CLs) and maybe that's what this old custom classloader
> was missing all along.
>
> The tradeoff mentioned by Jared is only necessary if we want a release
> (soon) that does NOT eagerly class load all deployed classes up-front.
> Otherwise, this is a feature request that users might have to wait a little
> longer for (and maybe that's ok!).
>
> [1]
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3
>
> On Mon, Apr 10, 2017 at 10:30 AM, Anthony Baker  wrote:
>
> > What about this:
> >
> > 1) Each jar is deployed into it’s own classloader.
> > 2) If the classloader for jar1 is unable to load a class, it delegates to
> > its parent which can load classes from siblings to jar1.
> >
> > The classloader hierarchy would be:
> >
> > bootstrap << system << application << (deploy jar)*
> >
> > where the application classloader manages the delegation to all deployed
> > jars.
> >
> > Anthony
> >
> >
> > > On Apr 10, 2017, at 10:20 AM, Jared Stewart 
> wrote:
> > >
> > > There is last one implementation decision for GEODE-2290 that I'm torn
> > about, namely having one classloader for all deployed jars vs having
> > separate classloaders for each deployed jar.
> > >
> > > If we have one class loader, e.g. new UrlClassLoader(jar1, jar2), then:
> > >
> > > - Jar1 will be able to load classes/resources from jar2  (this was the
> > previous behavior of deployed jars with our custom class loader)
> > > - But if we redeploy jar 1, jar 2 will also get its class loader
> > rebuilt, which may raise the likelihood of weird classloader problems
> > arising
> > >
> > > Does anyone else have thoughts about this tradeoff?
> > >
> > > Thanks,
> > > Jared
> >
> >
>

[jira] [Created] (GEODE-2770) When using the REST API it is possible for the API to be accepting requests after the system has shutdown

[Charlie Black (JIRA)]

Charlie Black created GEODE-2770:


 Summary: When using the REST API it is possible for the API to be 
accepting requests after the system has shutdown
 Key: GEODE-2770
 URL: https://issues.apache.org/jira/browse/GEODE-2770
 Project: Geode
  Issue Type: Improvement
  Components: rest (dev)
Reporter: Charlie Black


When using the REST API it is possible for the API to be accepting requests 
after the system has shutdown,



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

[jira] [Commented] (GEODE-2217) Add generic type parameter to FunctionContext interface

[ASF GitHub Bot (JIRA)]

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

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

GitHub user dalyssakim opened a pull request:

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

Feature/geode 2217

JIRA : https://issues.apache.org/jira/browse/GEODE-2217

Let me know if we want to change the parameter descriptions.

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

$ git pull https://github.com/dalyssakim/incubator-geode feature/GEODE-2217

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

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


commit d3c6b339af85d4be78f53bc092049f7849350835
Author: Alyssa Kim 
Date:   2017-04-11T03:14:12Z

GEODE=2217

Add generic type parameter to FunctionContext interface

commit d9cd09f9a983c1c820be13fbee271c2baaa9cf11
Author: Alyssa Kim 
Date:   2017-04-11T03:27:07Z

GEODE-2217

Add generic type parameter to FunctionContext interface
Minor change in comments

commit a3ef95d4a6b0fffa775cf9469e5c4e79eec89b77
Author: Alyssa Kim 
Date:   2017-04-11T03:31:23Z

GEODE-2217

Add generic type parameter to FunctionContext interface
Minor change in comments.




> Add generic type parameter to FunctionContext interface
> ---
>
> Key: GEODE-2217
> URL: https://issues.apache.org/jira/browse/GEODE-2217
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Jared Stewart
>Assignee: Alyssa Kim
>
> FunctionContext has a method getArguments() that returns Object.  It would be 
> nice to have getArguments return a known type instead.
> ```
> public interface FunctionContext  {
>   public T getArguments();
> }
> ```
> The Function interface would then allow users to bound the expected argument 
> type:
> ```
> public interface Function {
>   public void execute(FunctionContext context);
> }
> ```



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

[GitHub] geode pull request #447: Feature/geode 2217

[dalyssakim]

GitHub user dalyssakim opened a pull request:

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

Feature/geode 2217

JIRA : https://issues.apache.org/jira/browse/GEODE-2217

Let me know if we want to change the parameter descriptions.

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

$ git pull https://github.com/dalyssakim/incubator-geode feature/GEODE-2217

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

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


commit d3c6b339af85d4be78f53bc092049f7849350835
Author: Alyssa Kim 
Date:   2017-04-11T03:14:12Z

GEODE=2217

Add generic type parameter to FunctionContext interface

commit d9cd09f9a983c1c820be13fbee271c2baaa9cf11
Author: Alyssa Kim 
Date:   2017-04-11T03:27:07Z

GEODE-2217

Add generic type parameter to FunctionContext interface
Minor change in comments

commit a3ef95d4a6b0fffa775cf9469e5c4e79eec89b77
Author: Alyssa Kim 
Date:   2017-04-11T03:31:23Z

GEODE-2217

Add generic type parameter to FunctionContext interface
Minor change in comments.




---
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] [Created] (GEODE-2769) Document how to remove all cache listeners

[Joey McAllister (JIRA)]

Joey McAllister created GEODE-2769:
--

 Summary: Document how to remove all cache listeners
 Key: GEODE-2769
 URL: https://issues.apache.org/jira/browse/GEODE-2769
 Project: Geode
  Issue Type: Sub-task
  Components: docs
Reporter: Joey McAllister


GEODE-2236 describes how to remove all cache listeners using a gfsh command. 
This should be documented in the user guide.



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

[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan commented on GEODE-2746:
-

Because Thrift doesn't support server push, I think it is out. There is this 
hack, but it is too much of a hack for me:
http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html

> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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

[jira] [Updated] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

[Galen O'Sullivan (JIRA)]

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

Galen O'Sullivan updated GEODE-2746:

Description: 
There are several existing RPC frameworks for which you can define the 
structure of your protocol and the tool will generate code for talking over the 
wire, generally down to serialization of objects.

If one of those RPC frameworks does not fit all our requirements, we'll design 
our own binary protocol. This protocol would define both what kind of messages 
can be sent and how they are encoded on the wire. How we encode the objects 
that we are sending in requests, however, could still be pluggable.

A few contenders:
* [BERT|http://bert-rpc.org]
* [thrift|https://thrift.apache.org/]
* [gRPC|http://www.grpc.io/]

These are two not-entirely-common features we will need to have:
* support for SSL/TLS, ability to connect to a server with IP & port.
* support for push messages from the server without polling (this is needed for 
CQs).

This is one half of GEODE-2734.

  was:
There are several existing RPC frameworks for which you can define the 
structure of your protocol and the tool will generate code for talking over the 
wire, generally down to serialization of objects.

If one of those RPC frameworks does not fit all our requirements, we'll design 
our own binary protocol. This protocol would define both what kind of messages 
can be sent and how they are encoded on the wire. How we encode the objects 
that we are sending in requests, however, could still be pluggable.

A few contenders:
* [BERT|http://bert-rpc.org]
* [thrift|https://thrift.apache.org/]
* [gRPC|http://www.grpc.io/]

This is one half of GEODE-2734.


> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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

[GitHub] geode issue #441: Fix a repetition in the README.

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/441
  
I'm not a committer, so someone else will have to push this for me. 
@kohlmu-pivotal ?


---
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] [Updated] (GEODE-288) Remove deprecated Admin API

[Joey McAllister (JIRA)]

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

Joey McAllister updated GEODE-288:
--
Component/s: (was: docs)

> Remove deprecated Admin API
> ---
>
> Key: GEODE-288
> URL: https://issues.apache.org/jira/browse/GEODE-288
> Project: Geode
>  Issue Type: Sub-task
>  Components: jmx
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The Admin API (com.gemstone.gemfire.admin) and old JMX Agent have been 
> deprecated since GemFire 7.0. The Admin API was retired in favor of using the 
> new Management JMX API (com.gemstone.gemfire.management) and GFSH.
> #1) move some Admin classes used internally by non-Admin code:
> move com.gemstone.gemfire.admin.BackupStatus
> move com.gemstone.gemfire.admin.OperationCancelledException
> move com.gemstone.gemfire.admin.RegionNotFoundException
> move 
> com.gemstone.gemfire.admin.internal.AdminDistributedSystemImpl.backupAllMembers
> move 
> com.gemstone.gemfire.admin.internal.AdminDistributedSystemImpl.compactAllDiskStores
> move com.gemstone.gemfire.admin.internal.FinishBackupRequest
> move com.gemstone.gemfire.admin.internal.FlushToDiskRequest
> move com.gemstone.gemfire.admin.internal.InetAddressUtil
> move com.gemstone.gemfire.admin.internal.PrepareBackupRequest
> #2) move com.gemstone.gemfire.admin to 
> com.gemstone.gemfire.internal.admin.api (temporarily)
> #3) remove com.gemstone.gemfire.cache.* usage of admin
> #4) remove com.gemstone.gemfire.distributed.* usage of admin
> #5) remove com.gemstone.gemfire.internal.* usage of admin (except for 
> internal.admin.*)
> #6) remove com.gemstone.gemfire.management.* usage of admin
> #7) remove com.gemstone.gemfire.internal.admin.api if possible
> #8) remove unused classes from com.gemstone.gemfire.internal.admin.*
> Breakdown by package and class:
> com.gemstone.gemfire
>   --change DataSerializer to use moved RegionNotFoundException
> com.gemstone.gemfire.cache
> com.gemstone.gemfire.cache.persistence
> com.gemstone.gemfire.cache.util
>   --remove com.gemstone.gemfire.cache.util.UniversalMembershipListenerAdapter
> com.gemstone.gemfire.distributed
>   --remove Admin API from javadocs in Locator and DistributedSystem
> com.gemstone.gemfire.distributed.internal
>   --remove 
> com.gemstone.gemfire.distributed.internal.DistributionManager.createHealthMonitor
>   --remove remove com.gemstone.gemfire.distributed.internal.HealthMonitor
>   --remove remove com.gemstone.gemfire.distributed.internal.HealthMonitorImpl
>   --change 
> com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.hasAlertListenerFor
>  to not use AlertLevel
> com.gemstone.gemfire.internal
>   --remove DSFIDFactory support for admin messages
>   --remove com.gemstone.gemfire.admin.jmx.internal.AgentLauncher from 
> GemFireUtilLauncher
>   --change MigrationServer to use moved InetAddressUtil
>   --change SocketCreator to use moved InetAddressUtil
>   --remove SystemAdmin.backup
>   --remove SystemAdmin.compactAllDiskStores
>   --remove SystemAdmin.shutDownAll
>   --remove SystemAdmin.listMissingDiskStores
>   --remove SystemAdmin.revokeMissingDiskStores
> com.gemstone.gemfire.internal.cache
>   --replace use of com.gemstone.gemfire.admin.OperationCancelledException
>   --remove use of 
> com.gemstone.gemfire.admin.internal.SystemMemberCacheEventProcessor
> com.gemstone.gemfire.internal.cache.partitioned
>   --replace use of com.gemstone.gemfire.admin.OperationCancelledException
> com.gemstone.gemfire.internal.cache.snapshot
>   --replace use of com.gemstone.gemfire.admin.RegionNotFoundException
> com.gemstone.gemfire.internal.tools.gfsh.app.command.task
>   --reimplement PartitionedRegionAttributeTask
> com.gemstone.gemfire.internal.tools.gfsh.util
>   --reimplement RegionUtil
> com.gemstone.gemfire.management.internal.beans
>   --change DistributedSystemBridge to use moved classes
> com.gemstone.gemfire.management.internal.cli.commands
>   --change DiskStoreCommands to use moved classes
>   



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

Broken: apache/geode#2318 (develop - 344f93d)

[Travis CI]

Build Update for apache/geode
-

Build: #2318
Status: Broken

Duration: 21 minutes and 36 seconds
Commit: 344f93d (develop)
Author: Darrel Schneider
Message: GEODE-2485: fix leak in tx suspend/resume

The CCPTimer is now purged for every 1000 cancels done.
So we will now no longer have more than 1000
cancelled tasks eating up memory.
Now uses internalSuspend in two places the previously used suspend.
Since internalSuspend does not schedule a timer task
these places will have no more issues with leaking memory
and these code paths will perform better.

renamed resume(TxStateProxy) to internalResume for clarity.

internalResume no longer checks for a TimerTask to cancel
since internalSuspend does not add one.
Instead the only code that checks for a TimerTask is "resume".

View the changeset: 
https://github.com/apache/geode/compare/8183b1fdcf22...344f93dfd07e

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/220749517

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[jira] [Assigned] (GEODE-2768) Lucene Queries executed before index is fully created should be retried

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-2768:
--

Assignee: Jason Huynh

> Lucene Queries executed before index is fully created should be retried
> ---
>
> Key: GEODE-2768
> URL: https://issues.apache.org/jira/browse/GEODE-2768
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> With the feature to destroy a Lucene Index, parts of the querying function 
> were changed to handle the event where we execute a query on an index that is 
> no longer present.  However, the scenario where we execute a query on an 
> index that is defined but has not been created can also arise. 
> We want to handle the case where we have defined the index, but have yet to 
> create it due to a brief window in restart.  



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

[jira] [Created] (GEODE-2768) Lucene Queries executed before index is fully created should be retried

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2768:
--

 Summary: Lucene Queries executed before index is fully created 
should be retried
 Key: GEODE-2768
 URL: https://issues.apache.org/jira/browse/GEODE-2768
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Jason Huynh


With the feature to destroy a Lucene Index, parts of the querying function were 
changed to handle the event where we execute a query on an index that is no 
longer present.  However, the scenario where we execute a query on an index 
that is defined but has not been created can also arise. 

We want to handle the case where we have defined the index, but have yet to 
create it due to a brief window in restart.  



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

[GitHub] geode pull request #446: GEODE-1274: Migration from PulseLogWriter to Log4j ...

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

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

GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of 
associated classes.

* To avoid dependency on geode-core, the pulse loggers are instantiated 
directly from LogManager, rather than canonical LogService (which itself 
extends LogManager).

* Significant reduction of logging level state checks, relying on Log4j 
handling.
* Significant reduction of string concatenation, relying on Log4j2 string 
substitutions.
* Reduction of logging using an exception e.getMessage, favoring instead 
passing the exception itself for the stacktrace.
* Multiple identical exception blocks collapsed.

precheckin green on Test/IntegrationTest/Legacy.  Previous runs green on 
Distributed, but current still running.

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

$ git pull https://github.com/PurelyApplied/geode bugfix/GEODE-1274

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

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


commit 49f5f9f57768eaf005364149c212c20404f6d197
Author: Patrick Rhomberg 
Date:   2017-03-22T20:27:34Z

GEODE-1274: Migration from PulseLogWriter to Log4j standard and removal of 
associated classes.

To avoid dependency on geode-core, the pulse loggers are instantiated 
directly from LogManager, rather than canonical LogService (which itself 
extends LogManager).

Significant reduction of logging level state checks, relying on Log4j 
handling.
Significant reduction of string concatenation, relying on Log4j2 string 
substitutions.
Reduction of logging using an exception e.getMessage, favoring instead 
passing the exception itself for the stacktrace.
Multiple identical exception blocks collapsed.

commit dd14d6b0bdce628cc13b3237de5efa0dc18c5661
Author: Patrick Rhomberg 
Date:   2017-04-10T21:10:52Z

Corrected merge error regarding random ports.




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

Re: Shareable Filter Permission

[Kirk Lund]

There are no settings specific to Filters under Geode administration.

I think you have to change this in the settings for Filters and Dashboard
Sharing on your own Profile Preferences.

You should also be able to hit "Share" while viewing a private Filter and
then share it with specific people without changing your Profile
Preferences.

On Mon, Apr 10, 2017 at 3:40 PM, Fred Krone  wrote:

> Hi,
>
> Could I get the sharable filter permission in Geode?  Right now my filters
> are all private.
>
> I'm fkrone
>
> Thanks,
> -Fred
>

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On April 10, 2017, 9:52 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58325/
> ---
> 
> (Updated April 10, 2017, 9:52 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2737: Change Pulse UI tests to use random port for JMX connections
> 
> 
> Diffs
> -
> 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
>  af3d64bd5118ff870fadc16dcdeb3cde858611ce 
> 
> 
> Diff: https://reviews.apache.org/r/58325/diff/1/
> 
> 
> Testing
> ---
> 
> All Pulse UI tests run locally pass.
> 
> Precheckin is running
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Jinmei Liao]

> On April 10, 2017, 10:05 p.m., Kirk Lund wrote:
> > geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
> > Lines 47 (patched)
> > 
> >
> > Is there no other way to configure this other than with hidden system 
> > properties? I was hoping there would be something in 
> > ConfigurationProperties to configure the Pulse port. I suppose that 
> > LauncherLifecycleCommands#startPulse would already be configuring things 
> > but it's rather sparse for configuration.
> > 
> > Also, I notice that you're using "jmxPort" for the Pulse port. 
> > Shouldn't this be "pulsePort"? The "jmxPort" would theoretically be the RMI 
> > server port for JMX instead.
> 
> Kirk Lund wrote:
> I'm guess that "pulse.port" is actually the jmxPort now that I'm reading 
> PulseAppListener. Go ahead and disregard the jmxPort vs pulsePort question. 
> Confusing code in Pulse...
> 
> Jared Stewart wrote:
> One thing to note is that `start pulse` only opens a web browser to the 
> pulse URL.  It doesn't actually start pulse AFAIK. (In the default 
> configuration, pulse will start up when you issue `start locator`.)

When Kevin was fixing the "pulse always tries to connect to 1099" issues, used 
this hidden system properties to tell pulse what jmx port locator is running 
on, since Pulse can not used any class reference from geode-core.


- Jinmei


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


On April 10, 2017, 9:52 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58325/
> ---
> 
> (Updated April 10, 2017, 9:52 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2737: Change Pulse UI tests to use random port for JMX connections
> 
> 
> Diffs
> -
> 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
>  af3d64bd5118ff870fadc16dcdeb3cde858611ce 
> 
> 
> Diff: https://reviews.apache.org/r/58325/diff/1/
> 
> 
> Testing
> ---
> 
> All Pulse UI tests run locally pass.
> 
> Precheckin is running
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #520 was SUCCESSFUL (with 1843 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #520 was successful.
---
Scheduled
1845 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On April 10, 2017, 9:52 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58325/
> ---
> 
> (Updated April 10, 2017, 9:52 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2737: Change Pulse UI tests to use random port for JMX connections
> 
> 
> Diffs
> -
> 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
>  af3d64bd5118ff870fadc16dcdeb3cde858611ce 
> 
> 
> Diff: https://reviews.apache.org/r/58325/diff/1/
> 
> 
> Testing
> ---
> 
> All Pulse UI tests run locally pass.
> 
> Precheckin is running
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Shareable Filter Permission

[Fred Krone]

Hi,

Could I get the sharable filter permission in Geode?  Right now my filters
are all private.

I'm fkrone

Thanks,
-Fred

[jira] [Commented] (GEODE-2647) ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled fails with NullPointerException

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-2647:
--

>From Darrel Schneider , Mar 15, to dev:

The problem with this test is that is does [KL: not?] register interest. The 
first
client that calls the put method does 2 puts, then a clear, then 2 puts,
then a clear. All of those ops get sent async to the other client. So when
you call the same put method on the second client it can be receiving the
events from the first client. When you see the "null" right after client 2
did a put it is because you processed one of the clears from client1.

>From looking at this test it is unclear to me why is does puts and clears.
For the health stats it is trying to verify I would not think any of these
ops are needed. Or you could add some type of listener on client2 and wait
for it to see 2 clears before you have it execute the put task.

Hope this helps

> ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled fails 
> with NullPointerException
> 
>
> Key: GEODE-2647
> URL: https://issues.apache.org/jira/browse/GEODE-2647
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.management.ClientHealthStatsDUnitTest$$Lambda$193/1653332728.run
>  in VM 3 running on Host asf902.gq1.ygridcore.net with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
>   at 
> org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled(ClientHealthStatsDUnitTest.java:128)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at 
> org.apache.geode.management.ManagementTestRule$2.evaluate(ManagementTestRule.java:86)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at 

[jira] [Resolved] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

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

Darrel Schneider resolved GEODE-2485.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



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

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2485:


Commit 344f93dfd07e6ace79cedfb474bf524b97232281 in geode's branch 
refs/heads/develop from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=344f93d ]

GEODE-2485: fix leak in tx suspend/resume

The CCPTimer is now purged for every 1000 cancels done.
So we will now no longer have more than 1000
cancelled tasks eating up memory.
Now uses internalSuspend in two places the previously used suspend.
Since internalSuspend does not schedule a timer task
these places will have no more issues with leaking memory
and these code paths will perform better.

renamed resume(TxStateProxy) to internalResume for clarity.

internalResume no longer checks for a TimerTask to cancel
since internalSuspend does not add one.
Instead the only code that checks for a TimerTask is "resume".


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



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

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Kirk Lund]

> On April 10, 2017, 10:05 p.m., Kirk Lund wrote:
> > geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
> > Lines 47 (patched)
> > 
> >
> > Is there no other way to configure this other than with hidden system 
> > properties? I was hoping there would be something in 
> > ConfigurationProperties to configure the Pulse port. I suppose that 
> > LauncherLifecycleCommands#startPulse would already be configuring things 
> > but it's rather sparse for configuration.
> > 
> > Also, I notice that you're using "jmxPort" for the Pulse port. 
> > Shouldn't this be "pulsePort"? The "jmxPort" would theoretically be the RMI 
> > server port for JMX instead.

I'm guess that "pulse.port" is actually the jmxPort now that I'm reading 
PulseAppListener. Go ahead and disregard the jmxPort vs pulsePort question. 
Confusing code in Pulse...


- Kirk


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


On April 10, 2017, 9:52 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58325/
> ---
> 
> (Updated April 10, 2017, 9:52 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2737: Change Pulse UI tests to use random port for JMX connections
> 
> 
> Diffs
> -
> 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
>  af3d64bd5118ff870fadc16dcdeb3cde858611ce 
> 
> 
> Diff: https://reviews.apache.org/r/58325/diff/1/
> 
> 
> Testing
> ---
> 
> All Pulse UI tests run locally pass.
> 
> Precheckin is running
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[GitHub] geode pull request #445: GEODE-2767: Added DUnitTests to validate export log...

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

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

GEODE-2767: Added DUnitTests to validate export log options --group and 
--member.

Only affects test code.

precheckin running.

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

$ git pull https://github.com/PurelyApplied/geode geode-2767

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

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


commit 3a5a30cda052359c92b47373f2c9a27d9c0998e3
Author: Patrick Rhomberg 
Date:   2017-04-10T21:49:33Z

GEODE-2767: Added DUnitTests to validate export log options --group and 
--member.

commit 0686dc8f3a54ce0623e176fd3bdf8cb4dd2cdfbf
Author: Patrick Rhomberg 
Date:   2017-04-10T22:04:53Z

Spotless




---
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-2767) Extend testing coverage of export logs

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PurelyApplied opened a pull request:

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

GEODE-2767: Added DUnitTests to validate export log options --group and 
--member.

Only affects test code.

precheckin running.

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

$ git pull https://github.com/PurelyApplied/geode geode-2767

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

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


commit 3a5a30cda052359c92b47373f2c9a27d9c0998e3
Author: Patrick Rhomberg 
Date:   2017-04-10T21:49:33Z

GEODE-2767: Added DUnitTests to validate export log options --group and 
--member.

commit 0686dc8f3a54ce0623e176fd3bdf8cb4dd2cdfbf
Author: Patrick Rhomberg 
Date:   2017-04-10T22:04:53Z

Spotless




> Extend testing coverage of export logs
> --
>
> Key: GEODE-2767
> URL: https://issues.apache.org/jira/browse/GEODE-2767
> Project: Geode
>  Issue Type: Test
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> Move the hydra functional tests of "export logs" to GEODE. Currently, export 
> logs tests do not cover --group and --member options.



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

Re: Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Kirk Lund]

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




geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
Lines 47 (patched)


Is there no other way to configure this other than with hidden system 
properties? I was hoping there would be something in ConfigurationProperties to 
configure the Pulse port. I suppose that LauncherLifecycleCommands#startPulse 
would already be configuring things but it's rather sparse for configuration.

Also, I notice that you're using "jmxPort" for the Pulse port. Shouldn't 
this be "pulsePort"? The "jmxPort" would theoretically be the RMI server port 
for JMX instead.


- Kirk Lund


On April 10, 2017, 9:52 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58325/
> ---
> 
> (Updated April 10, 2017, 9:52 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2737: Change Pulse UI tests to use random port for JMX connections
> 
> 
> Diffs
> -
> 
>   
> geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
>  af3d64bd5118ff870fadc16dcdeb3cde858611ce 
> 
> 
> Diff: https://reviews.apache.org/r/58325/diff/1/
> 
> 
> Testing
> ---
> 
> All Pulse UI tests run locally pass.
> 
> Precheckin is running
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[jira] [Created] (GEODE-2767) Extend testing coverage of export logs

[Patrick Rhomberg (JIRA)]

Patrick Rhomberg created GEODE-2767:
---

 Summary: Extend testing coverage of export logs
 Key: GEODE-2767
 URL: https://issues.apache.org/jira/browse/GEODE-2767
 Project: Geode
  Issue Type: Test
  Components: gfsh
Reporter: Patrick Rhomberg


Move the hydra functional tests of "export logs" to GEODE. Currently, export 
logs tests do not cover --group and --member options.



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

[jira] [Assigned] (GEODE-2767) Extend testing coverage of export logs

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-2767:
---

Assignee: Patrick Rhomberg

> Extend testing coverage of export logs
> --
>
> Key: GEODE-2767
> URL: https://issues.apache.org/jira/browse/GEODE-2767
> Project: Geode
>  Issue Type: Test
>  Components: gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>
> Move the hydra functional tests of "export logs" to GEODE. Currently, export 
> logs tests do not cover --group and --member options.



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

Review Request 58325: GEODE-2737: Change Pulse UI tests to use random port for JMX connections

[Ken Howe]

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

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


Repository: geode


Description
---

GEODE-2737: Change Pulse UI tests to use random port for JMX connections


Diffs
-

  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/ServerRule.java
 af3d64bd5118ff870fadc16dcdeb3cde858611ce 


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


Testing
---

All Pulse UI tests run locally pass.

Precheckin is running


Thanks,

Ken Howe

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2737:


Commit e1de5dd501f08644ff4b859abdc71840eeb847da in geode's branch 
refs/heads/feature/GEODE-2737 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e1de5dd ]

GEODE-2737: Change Pulse UI tests to use random port for JMX connections


> 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}
> 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;
>  
> 

[jira] [Commented] (GEODE-2766) Only apply patches for dependencies on relevant architectures

[ASF GitHub Bot (JIRA)]

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

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

GitHub user jdeppe-pivotal opened a pull request:

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

GEODE-2766: Only apply patches on Solaris

- This avoids trying to apply patches on Windows which can break if the 
source
  wasn't actually checked out by a Windows git.

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

$ git pull https://github.com/jdeppe-pivotal/geode-native feature/GEODE-2766

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

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


commit 876067051269375b2162a953d5dd572469eef1c3
Author: Jens Deppe 
Date:   2017-04-10T21:40:34Z

GEODE-2766: Only apply patches on Solaris

- This avoids trying to apply patches on Windows which can break if the 
source
  wasn't actually checked out by a Windows git.




> Only apply patches for dependencies on relevant architectures
> -
>
> Key: GEODE-2766
> URL: https://issues.apache.org/jira/browse/GEODE-2766
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Currently the patches for openssl and ACE are only required for Solaris but 
> are still applied on all platforms. This can break on Windows if the patching 
> tool cannot correctly convert Windows/Unix line-endings.



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

[GitHub] geode-native pull request #89: GEODE-2766: Only apply patches on Solaris

[jdeppe-pivotal]

GitHub user jdeppe-pivotal opened a pull request:

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

GEODE-2766: Only apply patches on Solaris

- This avoids trying to apply patches on Windows which can break if the 
source
  wasn't actually checked out by a Windows git.

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

$ git pull https://github.com/jdeppe-pivotal/geode-native feature/GEODE-2766

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

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


commit 876067051269375b2162a953d5dd572469eef1c3
Author: Jens Deppe 
Date:   2017-04-10T21:40:34Z

GEODE-2766: Only apply patches on Solaris

- This avoids trying to apply patches on Windows which can break if the 
source
  wasn't actually checked out by a Windows git.




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

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On April 10, 2017, 9:06 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 9:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/4/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Assigned] (GEODE-2766) Only apply patches for dependencies on relevant architectures

[Jens Deppe (JIRA)]

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

Jens Deppe reassigned GEODE-2766:
-

Assignee: Jens Deppe

> Only apply patches for dependencies on relevant architectures
> -
>
> Key: GEODE-2766
> URL: https://issues.apache.org/jira/browse/GEODE-2766
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>
> Currently the patches for openssl and ACE are only required for Solaris but 
> are still applied on all platforms. This can break on Windows if the patching 
> tool cannot correctly convert Windows/Unix line-endings.



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

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

[Bruce Schuchardt]

I don't like the idea of using someone else's messaging software for 
several reasons:


* we may have needs that are beyond its capabilities
* it may impose something like a broker or endpoint IDs that we have to 
deal with
* it introduces more overhead per message and we will have no control 
over that overhead
* it can introduce backward compatibility issues that we have no control 
over

* it won't fit into our configuration and management infrastructure

However, I do like the idea of exploring the use of other serialization 
software if it has good multi-language support.


Le 4/10/2017 à 1:38 PM, Michael William Dodge a écrit :

MQTT is an interesting idea but from the wiki page it sounds like it depends on 
a broker. In that architecture, would the server be the broker as well as a 
publisher and subscriber? Would the locator be the broker? Or would we 
introduce a separate broker, either third-party or bespoke?

Sarge


On 10 Apr, 2017, at 13:21, Michael Stolz  wrote:

I am wondering why we are leaning so heavily toward RPC IDL rather than
messaging standards.

One of the big features of the client-server discussion around Geode is the
ability to register interest and run Continuous Queries.
Both of these behave more like messaging than RPCs.

Beyond that all that Geode really does is puts and gets and function calls.
A put is analogous to a publish. A get is similar to a subscribe. A
function call can be implemented as a put on a special topic that has a
callback attached to it. In fact that's how we used to do server side
functions before we added the function execution api.

The other thing we are constantly battling with is being able to push more
and more data into Geode from clients faster and faster.
That too lends itself to a messaging protocol.

In fact, I remember that last year we were already having some discussions
about maybe developing a client based on MQTT.
That would make GemFire a natural for the Internet-of-Things and for mobile
devices.
I wonder if it would be sufficient for a full-blown .Net GemFire client.

One of our goals in this thread is to be able to have clients in many
languages.
Well, there are at least 75 different language bindings for MQTT already
out in the wild.

MQTT is agnostic about what format the payload is in, so we could support
PDX if we choose to, or ProtoBufs or FlatBuffers or whatever else for
payload serialization.

Thoughts?


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Mon, Apr 10, 2017 at 2:39 PM, Galen M O'Sullivan 
wrote:


On Mon, Apr 10, 2017 at 10:47 AM, Bruce Schuchardt 

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On April 10, 2017, 9:06 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 9:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/4/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Jenkins karma (was Re: Blacklist asf904 for Geode nightly job)

[Anthony Baker]

Yea, thanks Mark!

Anthony

> On Apr 10, 2017, at 2:11 PM, Mark Bretl  wrote:
> 
> Hi Anthony,
> 
> Look at that I do have karma for adding people to Jenkins. I have added you
> to Jenkins.
> 
> Please let me know if you have any issues.
> 
> --Mark
> 
> On Mon, Apr 10, 2017 at 9:59 AM, William Markito Oliveira <
> william.mark...@gmail.com> wrote:
> 
>> Hi Anthony,
>> 
>> My karma is also limited, sorry.  I believe only Roman (or infra) can
>> change that...
>> 
>> On Mon, Apr 10, 2017 at 11:46 AM, Anthony Baker  wrote:
>> 
>>> Anyone?
>>> 
 On Apr 7, 2017, at 11:32 AM, Anthony Baker  wrote:
 
 I would like Jenkins karma so I can explore running our tests from
>>> within a docker container.  William / Mark / Roman can you help me out?
 
 Thanks,
 Anthony
 
 
> On Mar 21, 2017, at 3:14 PM, Anthony Baker  wrote:
> 
> Would be very nice to run our jenkins jobs from a docker container to
>>> avoid these environmental quirks.
> 
> Anthony
>>> 
>>> 
>> 
>> 
>> --
>> ~/William
>> 

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On April 10, 2017, 9:06 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 9:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/4/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Jinmei Liao]

> On April 10, 2017, 7:48 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
> > Line 2374 (original), 2377 (patched)
> > 
> >
> > One small oddity of this help text is that would seem to imply that 
> > `start locator --log-level=ALL` is a valid commmand.  I think `export logs` 
> > is a special case in accepting `ALL` as a log level.
> 
> Kirk Lund wrote:
> Actually, ALL and NONE are both valid values for --log-level on the start 
> commands and the alter runtime command. In fact, we would have to do 
> something additional in code to prevent it from working. Note: ALL and NONE 
> were also valid for the old GemFire LogWriter log-level. My change didn't 
> introduce this -- it just made us more aware of it.
> 
> If you think we shouldn't allow ALL and NONE, then that should be a new 
> separate ticket because changing it would involve more than the gfsh help 
> strings.
> 
> Kirk Lund wrote:
> Hmm, actually, it looks like old-GF logging used "all" and "none" but the 
> log4j levels should be ALL and OFF. I need to change all instances of NONE to 
> OFF.
> 
> Jared Stewart wrote:
> My mistake, this looks good then!

Agree we should have a separate ticket to exclude all/off from start 
locator/server commands.


- Jinmei


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


On April 10, 2017, 9:06 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 9:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/4/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[jira] [Commented] (GEODE-1274) Pulse logging does not appear in Geode log file.

[ASF GitHub Bot (JIRA)]

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

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

Github user PurelyApplied closed the pull request at:

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


> Pulse logging does not appear in Geode log file.
> 
>
> Key: GEODE-1274
> URL: https://issues.apache.org/jira/browse/GEODE-1274
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jens Deppe
>  Labels: Log4j2
>
> While trying to enable debug logging for Pulse, I found that no Pulse logging 
> appears in the Geode log. The Admin REST logging does appear though.
> I had tried to enable debug logging by starting a locator with the followiing 
> log4j config:
> {noformat}
> 
>  packages="com.gemstone.gemfire.internal.logging.log4j">
>   
> [%level{lowerCase=true} %date{/MM/dd 
> HH:mm:ss.SSS z} %thread tid=%tid] %message%n%throwable%n
>   
>   
> 
>   
> 
>   
>   
> 
> 
>onMismatch="NEUTRAL"/>
> 
> 
> 
> 
>   
> 
>   
> 
> {noformat}
> However, only the Admin REST app produced debug log output. 



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

[GitHub] geode pull request #432: GEODE-1274: Migration from PulseLogWriter to Log4j ...

[PurelyApplied]

Github user PurelyApplied closed the pull request at:

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


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

Re: Jenkins karma (was Re: Blacklist asf904 for Geode nightly job)

[Mark Bretl]

Hi Anthony,

Look at that I do have karma for adding people to Jenkins. I have added you
to Jenkins.

Please let me know if you have any issues.

--Mark

On Mon, Apr 10, 2017 at 9:59 AM, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> Hi Anthony,
>
> My karma is also limited, sorry.  I believe only Roman (or infra) can
> change that...
>
> On Mon, Apr 10, 2017 at 11:46 AM, Anthony Baker  wrote:
>
> > Anyone?
> >
> > > On Apr 7, 2017, at 11:32 AM, Anthony Baker  wrote:
> > >
> > > I would like Jenkins karma so I can explore running our tests from
> > within a docker container.  William / Mark / Roman can you help me out?
> > >
> > > Thanks,
> > > Anthony
> > >
> > >
> > >> On Mar 21, 2017, at 3:14 PM, Anthony Baker  wrote:
> > >>
> > >> Would be very nice to run our jenkins jobs from a docker container to
> > avoid these environmental quirks.
> > >>
> > >> Anthony
> >
> >
>
>
> --
> ~/William
>

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Kirk Lund]

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

(Updated April 10, 2017, 9:06 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


Changes
---

Regenerate and reupload diffs. Not sure what went wrong before.


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


Repository: geode


Description
---

GEODE-2765: change gfsh help to consistently use log4j levels


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 67955dc61e87b8d485eaf191ce06eecdfb65cf39 
  
geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
 af6b4bfac982cc5dd69f3d5254c6512264361e2b 


Diff: https://reviews.apache.org/r/58319/diff/4/

Changes: https://reviews.apache.org/r/58319/diff/3-4/


Testing
---

* HelpCommandsIntegrationTest updated and passes
* precheckin in progress


Thanks,

Kirk Lund

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Kirk Lund]

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

(Updated April 10, 2017, 9:04 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


Changes
---

Change from using NONE in list of log-levels to OFF (the log4j level).


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


Repository: geode


Description
---

GEODE-2765: change gfsh help to consistently use log4j levels


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
 PRE-CREATION 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Cluster.java
 432834a314f26e308c1430362355bf250dfb2264 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/JMXDataUpdater.java
 5c30501a2c07e55873b090d7c7d14efcfc48139b 
  
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
 61e967b7e81511dc2f47b6a641e938c4b31502db 
  geode-pulse/src/main/webapp/DataBrowser.html  
  geode-pulse/src/main/webapp/Login.html  
  geode-pulse/src/main/webapp/MemberDetails.html  
  geode-pulse/src/main/webapp/QueryStatistics.html  
  geode-pulse/src/main/webapp/WEB-INF/spring-security.xml 
cac6caffe500ff3b93d12b4556bde475a45401ad 
  geode-pulse/src/main/webapp/index.html 
74b895430bac774da81332b72017c619c369787d 
  geode-pulse/src/main/webapp/scripts/lib/common.js 
0c58922eb82eb760d668c3054a52fa9d654fd598 
  geode-pulse/src/main/webapp/scripts/pulsescript/MemberDetails.js 
650f30d2b26e51b24b64c43f974138bf20d30702 
  geode-pulse/src/main/webapp/scripts/pulsescript/PulseCallbacks.js 
e19ddf4779be8d5567380f19d87dcae5e7840344 
  geode-pulse/src/main/webapp/scripts/pulsescript/clusterDetail.js 
3fe49eb57c79e637c8ba4d7e8e972bd078b04212 
  geode-pulse/src/main/webapp/scripts/pulsescript/clusterRGraphMembers.js 
94b0538ede779a15269b7bf0e29803704ac1cb7e 
  geode-pulse/src/main/webapp/scripts/pulsescript/common.js 
550af7c9ab498413cfae9d988afb92f4e7886695 
  geode-pulse/src/main/webapp/scripts/pulsescript/pages/DataBrowser.js 
5bbcd7534864f6cb4d6344adfb2179d049a1f13f 
  geode-pulse/src/main/webapp/scripts/pulsescript/pages/DataBrowserQuery.js 
534f5c87baa63de5fcbff9f50593b037ea67cc46 
  
geode-pulse/src/main/webapp/scripts/pulsescript/pages/DataBrowserQueryHistory.js
 77f939e82f9557c513e41de5fcae255bf957f44b 
  geode-pulse/src/main/webapp/scripts/pulsescript/regionView.js 
5ce63007b3be2467c47bd7a936d9eaa1a3b63312 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/rules/WebDriverRule.java
 ca4646bc41921f3fccee833618bca58ae14df91a 
  
geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/ui/PulseAnonymousUserTest.java
 b37551b565da3eca97dfe92d75b9ebaf1fd2f1f8 
  gradle.properties 5979f38d03beb3a6b9e6d6087a636b84b75ed2ee 


Diff: https://reviews.apache.org/r/58319/diff/3/

Changes: https://reviews.apache.org/r/58319/diff/2-3/


Testing
---

* HelpCommandsIntegrationTest updated and passes
* precheckin in progress


Thanks,

Kirk Lund

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Jared Stewart]

> On April 10, 2017, 7:48 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
> > Line 2374 (original), 2377 (patched)
> > 
> >
> > One small oddity of this help text is that would seem to imply that 
> > `start locator --log-level=ALL` is a valid commmand.  I think `export logs` 
> > is a special case in accepting `ALL` as a log level.
> 
> Kirk Lund wrote:
> Actually, ALL and NONE are both valid values for --log-level on the start 
> commands and the alter runtime command. In fact, we would have to do 
> something additional in code to prevent it from working. Note: ALL and NONE 
> were also valid for the old GemFire LogWriter log-level. My change didn't 
> introduce this -- it just made us more aware of it.
> 
> If you think we shouldn't allow ALL and NONE, then that should be a new 
> separate ticket because changing it would involve more than the gfsh help 
> strings.
> 
> Kirk Lund wrote:
> Hmm, actually, it looks like old-GF logging used "all" and "none" but the 
> log4j levels should be ALL and OFF. I need to change all instances of NONE to 
> OFF.

My mistake, this looks good then!


- Jared


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


On April 10, 2017, 7:15 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 7:15 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/2/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Kirk Lund]

> On April 10, 2017, 7:48 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
> > Line 2374 (original), 2377 (patched)
> > 
> >
> > One small oddity of this help text is that would seem to imply that 
> > `start locator --log-level=ALL` is a valid commmand.  I think `export logs` 
> > is a special case in accepting `ALL` as a log level.
> 
> Kirk Lund wrote:
> Actually, ALL and NONE are both valid values for --log-level on the start 
> commands and the alter runtime command. In fact, we would have to do 
> something additional in code to prevent it from working. Note: ALL and NONE 
> were also valid for the old GemFire LogWriter log-level. My change didn't 
> introduce this -- it just made us more aware of it.
> 
> If you think we shouldn't allow ALL and NONE, then that should be a new 
> separate ticket because changing it would involve more than the gfsh help 
> strings.

Hmm, actually, it looks like old-GF logging used "all" and "none" but the log4j 
levels should be ALL and OFF. I need to change all instances of NONE to OFF.


- Kirk


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


On April 10, 2017, 7:15 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 7:15 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/2/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Kirk Lund]

> On April 10, 2017, 7:48 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
> > Line 2374 (original), 2377 (patched)
> > 
> >
> > One small oddity of this help text is that would seem to imply that 
> > `start locator --log-level=ALL` is a valid commmand.  I think `export logs` 
> > is a special case in accepting `ALL` as a log level.

Actually, ALL and NONE are both valid values for --log-level on the start 
commands and the alter runtime command. In fact, we would have to do something 
additional in code to prevent it from working. Note: ALL and NONE were also 
valid for the old GemFire LogWriter log-level. My change didn't introduce this 
-- it just made us more aware of it.

If you think we shouldn't allow ALL and NONE, then that should be a new 
separate ticket because changing it would involve more than the gfsh help 
strings.


- Kirk


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


On April 10, 2017, 7:15 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 7:15 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/2/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: One class loader vs multiple class loaders for deployed jars

[Kirk Lund]

I think Jared started down this path because we had a custom classloader
implementation that he was trying to get rid of -- that impl was pretty
limited and forced loading of all classes up-front.

Now the code uses fast classpath scanner and that old custom classloader
can't be used. The old classloader is so simplistic and limited that trying
to modify it looks like more work than writing a new one from scratch.
Implementing a new custom classloader or switching our codebase to use a
new classloader container (using an existing solution) are both possible
directions. Until that's completed the "deploy jar" command will continue
to force ALL classes to be loaded up-front.

One major concern is that implementing a new custom classloader is
non-trivial and could also introduce some new classloader bugs -- of
particular interest to "deploy jar" is the fact that Java remembers TWO
classloaders for each class [1] -- the CL that *loaded* the class AND the
CL that *initiated* the request to load the class -- dropping the
*initiating* CL at runtime can result in failures to load additional
classes from the CL that directly loaded the class even though that CL is
intact and available.

[1] states: "When one class loader delegates to another class loader, the
loader that initiates the loading is not necessarily the same loader that
completes the loading and defines the class. If L creates C, either by
defining it directly or by delegation, we say that L initiates loading of C
or, equivalently, that L is an *initiating* loader of C."

For better or worse, this is one of the reasons why that old custom CL was
naively force loading all classes up-front -- ie, to avoid runtime
classloading failures if the initiating CL was dropped or replaced and
ultimately GC'ed. Java won't let you drop the *loading* CL but it will
allow you to drop the *initiating* CL (or it did historically -- the
reference seems to be down in native code, not in java.lang.Class). You'd
have to find some way to force all initiating requests up to the parent
application CL (or somehow prevent code in deployed jars from initiating
requests from other CLs) and maybe that's what this old custom classloader
was missing all along.

The tradeoff mentioned by Jared is only necessary if we want a release
(soon) that does NOT eagerly class load all deployed classes up-front.
Otherwise, this is a feature request that users might have to wait a little
longer for (and maybe that's ok!).

[1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3

On Mon, Apr 10, 2017 at 10:30 AM, Anthony Baker  wrote:

> What about this:
>
> 1) Each jar is deployed into it’s own classloader.
> 2) If the classloader for jar1 is unable to load a class, it delegates to
> its parent which can load classes from siblings to jar1.
>
> The classloader hierarchy would be:
>
> bootstrap << system << application << (deploy jar)*
>
> where the application classloader manages the delegation to all deployed
> jars.
>
> Anthony
>
>
> > On Apr 10, 2017, at 10:20 AM, Jared Stewart  wrote:
> >
> > There is last one implementation decision for GEODE-2290 that I'm torn
> about, namely having one classloader for all deployed jars vs having
> separate classloaders for each deployed jar.
> >
> > If we have one class loader, e.g. new UrlClassLoader(jar1, jar2), then:
> >
> > - Jar1 will be able to load classes/resources from jar2  (this was the
> previous behavior of deployed jars with our custom class loader)
> > - But if we redeploy jar 1, jar 2 will also get its class loader
> rebuilt, which may raise the likelihood of weird classloader problems
> arising
> >
> > Does anyone else have thoughts about this tradeoff?
> >
> > Thanks,
> > Jared
>
>

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

[Michael William Dodge]

MQTT is an interesting idea but from the wiki page it sounds like it depends on 
a broker. In that architecture, would the server be the broker as well as a 
publisher and subscriber? Would the locator be the broker? Or would we 
introduce a separate broker, either third-party or bespoke?

Sarge

> On 10 Apr, 2017, at 13:21, Michael Stolz  wrote:
> 
> I am wondering why we are leaning so heavily toward RPC IDL rather than
> messaging standards.
> 
> One of the big features of the client-server discussion around Geode is the
> ability to register interest and run Continuous Queries.
> Both of these behave more like messaging than RPCs.
> 
> Beyond that all that Geode really does is puts and gets and function calls.
> A put is analogous to a publish. A get is similar to a subscribe. A
> function call can be implemented as a put on a special topic that has a
> callback attached to it. In fact that's how we used to do server side
> functions before we added the function execution api.
> 
> The other thing we are constantly battling with is being able to push more
> and more data into Geode from clients faster and faster.
> That too lends itself to a messaging protocol.
> 
> In fact, I remember that last year we were already having some discussions
> about maybe developing a client based on MQTT.
> That would make GemFire a natural for the Internet-of-Things and for mobile
> devices.
> I wonder if it would be sufficient for a full-blown .Net GemFire client.
> 
> One of our goals in this thread is to be able to have clients in many
> languages.
> Well, there are at least 75 different language bindings for MQTT already
> out in the wild.
> 
> MQTT is agnostic about what format the payload is in, so we could support
> PDX if we choose to, or ProtoBufs or FlatBuffers or whatever else for
> payload serialization.
> 
> Thoughts?
> 
> 
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
> 
> On Mon, Apr 10, 2017 at 2:39 PM, Galen M O'Sullivan 
> wrote:
> 
>> On Mon, Apr 10, 2017 at 10:47 AM, Bruce Schuchardt >> 
>> wrote:
>> 
>>> I agree that key/value serialization is a separate issue and more related
>>> to storage than communications.  The thing I'm struggling with is how to
>>> specify message metadata in an RPC IDL.  I'm thinking of things like an
>>> eventID, transaction info, security principal, etc.  The basic
>>> client/server messaging doesn't need to know the details of this
>>> information - just that it exists and maybe the ID of each piece of
>>> metadata.
>>> 
>> 
>> Is there any reason that this data couldn't be packed into, say, Thrift
>> types? It's all numbers, right?
>> 

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

[Michael Stolz]

I am wondering why we are leaning so heavily toward RPC IDL rather than
messaging standards.

One of the big features of the client-server discussion around Geode is the
ability to register interest and run Continuous Queries.
Both of these behave more like messaging than RPCs.

Beyond that all that Geode really does is puts and gets and function calls.
A put is analogous to a publish. A get is similar to a subscribe. A
function call can be implemented as a put on a special topic that has a
callback attached to it. In fact that's how we used to do server side
functions before we added the function execution api.

The other thing we are constantly battling with is being able to push more
and more data into Geode from clients faster and faster.
That too lends itself to a messaging protocol.

In fact, I remember that last year we were already having some discussions
about maybe developing a client based on MQTT.
That would make GemFire a natural for the Internet-of-Things and for mobile
devices.
I wonder if it would be sufficient for a full-blown .Net GemFire client.

One of our goals in this thread is to be able to have clients in many
languages.
Well, there are at least 75 different language bindings for MQTT already
out in the wild.

MQTT is agnostic about what format the payload is in, so we could support
PDX if we choose to, or ProtoBufs or FlatBuffers or whatever else for
payload serialization.

Thoughts?


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Mon, Apr 10, 2017 at 2:39 PM, Galen M O'Sullivan 
wrote:

> On Mon, Apr 10, 2017 at 10:47 AM, Bruce Schuchardt  >
> wrote:
>
> > I agree that key/value serialization is a separate issue and more related
> > to storage than communications.  The thing I'm struggling with is how to
> > specify message metadata in an RPC IDL.  I'm thinking of things like an
> > eventID, transaction info, security principal, etc.  The basic
> > client/server messaging doesn't need to know the details of this
> > information - just that it exists and maybe the ID of each piece of
> > metadata.
> >
>
> Is there any reason that this data couldn't be packed into, say, Thrift
> types? It's all numbers, right?
>

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
Line 2374 (original), 2377 (patched)


One small oddity of this help text is that would seem to imply that `start 
locator --log-level=ALL` is a valid commmand.  I think `export logs` is a 
special case in accepting `ALL` as a log level.


- Jared Stewart


On April 10, 2017, 7:15 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58319/
> ---
> 
> (Updated April 10, 2017, 7:15 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2267
> https://issues.apache.org/jira/browse/GEODE-2267
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2765: change gfsh help to consistently use log4j levels
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  67955dc61e87b8d485eaf191ce06eecdfb65cf39 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
>  af6b4bfac982cc5dd69f3d5254c6512264361e2b 
> 
> 
> Diff: https://reviews.apache.org/r/58319/diff/2/
> 
> 
> Testing
> ---
> 
> * HelpCommandsIntegrationTest updated and passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58315: fix memory leak in transaction suspend/resume

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 10, 2017, 6:59 p.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58315/
> ---
> 
> (Updated April 10, 2017, 6:59 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.
> 
> 
> Bugs: GEODE-2485
> https://issues.apache.org/jira/browse/GEODE-2485
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The CCPTimer is now purged for every 1000 cancels done. So we will now no 
> longer have more than 1000
> cancelled tasks eating up memory.
> Now uses internalSuspend in two places the previously used suspend. 
> Since internalSuspend does not schedule a timer task these places will have 
> no more issues with leaking memory
> and these code paths will perform better.
> 
> renamed resume(TxStateProxy) to internalResume for clarity.
> 
> internalResume no longer checks for TimerTask to cancel since internalSuspend 
> does not add one.
> Instead the only code that checks for TimerTask is "resume".
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
>  a7210916ed77e7e628a9d858fdad70a8276dbbe2 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexManager.java
>  6cf9a3f1068c5c69bd755b82f120ca719a7cb7c8 
>   geode-core/src/main/java/org/apache/geode/internal/SystemTimer.java 
> bddd06288161c2e6ba30b97c1c20915e0514438d 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java
>  fa0257432aa149e70142e35d7432a5727ba035fd 
>   
> 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 
> 957038c8a173c7f0d1f5d3c7301673fd44add965 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataView.java
>  263df0f86b7c18504704506a1162cfebff394468 
>   geode-core/src/main/java/org/apache/geode/internal/cache/TXManagerImpl.java 
> 14fdf991b13661e5702b48480624ad1142a129b7 
>   geode-core/src/main/java/org/apache/geode/internal/cache/TXState.java 
> d577f3925c2087c204a9f43b46b26d421ed51be4 
>   geode-core/src/main/java/org/apache/geode/internal/cache/TXStateProxy.java 
> c5e7cf6aef6134008f49716ff995a7e3772dd07e 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/TXStateProxyImpl.java
>  a89cdc4a59c656cc3a2081c8aaa46d36b359c161 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CacheClientProxy.java
>  d7b923c55bfca019956a2bffb613e310310ebedd 
>   
> geode-core/src/main/java/org/apache/geode/pdx/internal/PeerTypeRegistration.java
>  653cafbdd4c8c93beafaa3dd9c97ff60750ce7ab 
>   geode-core/src/test/java/org/apache/geode/TXExpiryJUnitTest.java 
> f55926ad7006375010fa37af2772d190a31a77aa 
>   geode-core/src/test/java/org/apache/geode/TXJUnitTest.java 
> 5166a160ad71bc21d61c0c6199722abf113d7878 
>   
> geode-core/src/test/java/org/apache/geode/cache30/MultiVMRegionTestCase.java 
> c51c9cc6da130b13480c68d93a6294f1c7bd4e3b 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
>  3771fa87fa81bd752000f4291a9472f2b898e496 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
>  288a3e1b9a5a17d1e4802626e17c7d74f308f468 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/RemoteTransactionDUnitTest.java
>  751bcd11fa7357f2d51be9d0bee732e3f9af395e 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/TransactionsWithDeltaDUnitTest.java
>  c6aa376f868995b9335552abcded3fe62dd19bcc 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/MyTransactionFunction.java
>  9a0f3e66d2d05c889bd3e9020551fa4bad3f17f9 
> 
> 
> Diff: https://reviews.apache.org/r/58315/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

Re: Review Request 58319: GEODE-2765: change gfsh help to use log4j levels

[Kirk Lund]

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

(Updated April 10, 2017, 7:15 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


Changes
---

Change gfsh help to use UPPERCASE for log levels because auto-completion 
specifies UPPERCASE. Make help for export logs more consistent with other 
commands.


Summary (updated)
-

GEODE-2765: change gfsh help to use log4j levels


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


Repository: geode


Description (updated)
---

GEODE-2765: change gfsh help to consistently use log4j levels


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 67955dc61e87b8d485eaf191ce06eecdfb65cf39 
  
geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
 af6b4bfac982cc5dd69f3d5254c6512264361e2b 


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

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


Testing
---

* HelpCommandsIntegrationTest updated and passes
* precheckin in progress


Thanks,

Kirk Lund

[jira] [Updated] (GEODE-2765) gfsh help should consistently use log4j log levels

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2765:
-
Summary: gfsh help should consistently use log4j log levels  (was: gfsh 
help should reference log4j2 log levels)

> gfsh help should consistently use log4j log levels
> --
>
> Key: GEODE-2765
> URL: https://issues.apache.org/jira/browse/GEODE-2765
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The fix for GEODE-2634 changed the gfsh commands that use --log-level option 
> to use log4j2 log levels. The gfsh help text needs to also change.



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

Review Request 58315: fix memory leak in transaction suspend/resume

[Darrel Schneider]

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

Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.


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


Repository: geode


Description
---

The CCPTimer is now purged for every 1000 cancels done. So we will now no 
longer have more than 1000
cancelled tasks eating up memory.
Now uses internalSuspend in two places the previously used suspend. 
Since internalSuspend does not schedule a timer task these places will have no 
more issues with leaking memory
and these code paths will perform better.

renamed resume(TxStateProxy) to internalResume for clarity.

internalResume no longer checks for TimerTask to cancel since internalSuspend 
does not add one.
Instead the only code that checks for TimerTask is "resume".


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
 a7210916ed77e7e628a9d858fdad70a8276dbbe2 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexManager.java
 6cf9a3f1068c5c69bd755b82f120ca719a7cb7c8 
  geode-core/src/main/java/org/apache/geode/internal/SystemTimer.java 
bddd06288161c2e6ba30b97c1c20915e0514438d 
  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java 
fa0257432aa149e70142e35d7432a5727ba035fd 
  
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 
957038c8a173c7f0d1f5d3c7301673fd44add965 
  
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataView.java
 263df0f86b7c18504704506a1162cfebff394468 
  geode-core/src/main/java/org/apache/geode/internal/cache/TXManagerImpl.java 
14fdf991b13661e5702b48480624ad1142a129b7 
  geode-core/src/main/java/org/apache/geode/internal/cache/TXState.java 
d577f3925c2087c204a9f43b46b26d421ed51be4 
  geode-core/src/main/java/org/apache/geode/internal/cache/TXStateProxy.java 
c5e7cf6aef6134008f49716ff995a7e3772dd07e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/TXStateProxyImpl.java 
a89cdc4a59c656cc3a2081c8aaa46d36b359c161 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CacheClientProxy.java
 d7b923c55bfca019956a2bffb613e310310ebedd 
  
geode-core/src/main/java/org/apache/geode/pdx/internal/PeerTypeRegistration.java
 653cafbdd4c8c93beafaa3dd9c97ff60750ce7ab 
  geode-core/src/test/java/org/apache/geode/TXExpiryJUnitTest.java 
f55926ad7006375010fa37af2772d190a31a77aa 
  geode-core/src/test/java/org/apache/geode/TXJUnitTest.java 
5166a160ad71bc21d61c0c6199722abf113d7878 
  geode-core/src/test/java/org/apache/geode/cache30/MultiVMRegionTestCase.java 
c51c9cc6da130b13480c68d93a6294f1c7bd4e3b 
  
geode-core/src/test/java/org/apache/geode/internal/cache/ClientServerTransactionDUnitTest.java
 3771fa87fa81bd752000f4291a9472f2b898e496 
  
geode-core/src/test/java/org/apache/geode/internal/cache/GemFireCacheImplTest.java
 288a3e1b9a5a17d1e4802626e17c7d74f308f468 
  
geode-core/src/test/java/org/apache/geode/internal/cache/RemoteTransactionDUnitTest.java
 751bcd11fa7357f2d51be9d0bee732e3f9af395e 
  
geode-core/src/test/java/org/apache/geode/internal/cache/TransactionsWithDeltaDUnitTest.java
 c6aa376f868995b9335552abcded3fe62dd19bcc 
  
geode-core/src/test/java/org/apache/geode/internal/cache/execute/MyTransactionFunction.java
 9a0f3e66d2d05c889bd3e9020551fa4bad3f17f9 


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


Testing
---

precheckin


Thanks,

Darrel Schneider

Review Request 58319: GEODE-2267: change gfsh help to use log4j levels

[Kirk Lund]

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

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


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


Repository: geode


Description
---

GEODE-2267: change gfsh help to use log4j levels


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 67955dc61e87b8d485eaf191ce06eecdfb65cf39 
  
geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/golden-help-offline.properties
 af6b4bfac982cc5dd69f3d5254c6512264361e2b 


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


Testing
---

* HelpCommandsIntegrationTest updated and passes
* precheckin in progress


Thanks,

Kirk Lund

[jira] [Updated] (GEODE-2764) Index entry not entered into cluster config xml if region name contains a function call like entrySet()

[nabarun (JIRA)]

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

nabarun updated GEODE-2764:
---
Summary: Index entry not entered into cluster config xml if region name 
contains a function call like entrySet()  (was: Index entry not entered into 
cluster config xml if region name contains a function call like entry set)

> Index entry not entered into cluster config xml if region name contains a 
> function call like entrySet()
> ---
>
> Key: GEODE-2764
> URL: https://issues.apache.org/jira/browse/GEODE-2764
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> Steps to recreate the issue type the following in a gfsh instance:
> 1. start locator --name=locator
> 2. start server --name=server
> 3. create region --name=regionName --type=REPLICATE_PERSISTENT 
> 4. create index --name=regionIndex --region="regionName.entrySet() r" 
> --expression=r.key
> -- this will result in an error message 
> {noformat}
> Failed to create index "regionIndex" due to following reasons
> null
> {noformat}
> Cause:
> The index is created but while putting the entry into the clusterconfig it 
> tries to put the region name as regionName.entrySet() which does not exist. 
> cache.getRegion(regionName.entrySet()) will result in null and no xml entry 
> is added to the clusterconfig. So when the server is restarted, there is no 
> index entry in the cluster config xml hence the index is not re-created.
> Solution:
> If the region name contains the character '(' and ')' spilt the region name 
> at the index of '.' and check if the region exists. 
> If the check returns successful only then enter the entry into the cluster 
> config.



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

[jira] [Created] (GEODE-2765) gfsh help should reference log4j2 log levels

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2765:


 Summary: gfsh help should reference log4j2 log levels
 Key: GEODE-2765
 URL: https://issues.apache.org/jira/browse/GEODE-2765
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Kirk Lund


The fix for GEODE-2634 changed the gfsh commands that use --log-level option to 
use log4j2 log levels. The gfsh help text needs to also change.



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

[jira] [Assigned] (GEODE-2765) gfsh help should reference log4j2 log levels

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2765:


Assignee: Kirk Lund

> gfsh help should reference log4j2 log levels
> 
>
> Key: GEODE-2765
> URL: https://issues.apache.org/jira/browse/GEODE-2765
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> The fix for GEODE-2634 changed the gfsh commands that use --log-level option 
> to use log4j2 log levels. The gfsh help text needs to also change.



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

[jira] [Created] (GEODE-2764) Index entry not entered into cluster config xml if region name contains a function call like entry set

[nabarun (JIRA)]

nabarun created GEODE-2764:
--

 Summary: Index entry not entered into cluster config xml if region 
name contains a function call like entry set
 Key: GEODE-2764
 URL: https://issues.apache.org/jira/browse/GEODE-2764
 Project: Geode
  Issue Type: Bug
Reporter: nabarun


Steps to recreate the issue type the following in a gfsh instance:
1. start locator --name=locator
2. start server --name=server
3. create region --name=regionName --type=REPLICATE_PERSISTENT 
4. create index --name=regionIndex --region="regionName.entrySet() r" 
--expression=r.key

-- this will result in an error message 
{noformat}
Failed to create index "regionIndex" due to following reasons
null
{noformat}

Cause:
The index is created but while putting the entry into the clusterconfig it 
tries to put the region name as regionName.entrySet() which does not exist. 

cache.getRegion(regionName.entrySet()) will result in null and no xml entry is 
added to the clusterconfig. So when the server is restarted, there is no index 
entry in the cluster config xml hence the index is not re-created.

Solution:
If the region name contains the character '(' and ')' spilt the region name at 
the index of '.' and check if the region exists. 
If the check returns successful only then enter the entry into the cluster 
config.




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

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

[Galen M O'Sullivan]

On Mon, Apr 10, 2017 at 10:47 AM, Bruce Schuchardt 
wrote:

> I agree that key/value serialization is a separate issue and more related
> to storage than communications.  The thing I'm struggling with is how to
> specify message metadata in an RPC IDL.  I'm thinking of things like an
> eventID, transaction info, security principal, etc.  The basic
> client/server messaging doesn't need to know the details of this
> information - just that it exists and maybe the ID of each piece of
> metadata.
>

Is there any reason that this data couldn't be packed into, say, Thrift
types? It's all numbers, right?

[jira] [Resolved] (GEODE-2761) Docs: un-brand client cache plugin diagram

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2761.

Resolution: Fixed

> Docs: un-brand client cache plugin diagram
> --
>
> Key: GEODE-2761
> URL: https://issues.apache.org/jira/browse/GEODE-2761
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> For the native client, the figure referenced from within file 
> client-cache/application-plugins.html has labels that say "Native Client".  
> They should probably be redrawn to just say "Client".
> The image is file `common/images/client-cache-plugins-run.gif`
> The diagram is fairly simple.



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

[GitHub] geode-native issue #87: Docs: un-brand client cache plugin diagram

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode-native/pull/87
  
Approved and merged.


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

[GitHub] geode-native pull request #87: Docs: un-brand client cache plugin diagram

[davebarnes97]

Github user davebarnes97 closed the pull request at:

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


---
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] [Resolved] (GEODE-2537) Docs: redraw image to remove GemFire label

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2537.

Resolution: Fixed

> Docs: redraw image to remove GemFire label
> --
>
> Key: GEODE-2537
> URL: https://issues.apache.org/jira/browse/GEODE-2537
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Dave Barnes
>
> The image referenced within the How Delta Propagation Works subsection of 
> *both* the Geode and the Geode Native manuals has labels that say 'GemFire.' 
> There do not appear to be any source files available, so this gif diagram 
> will need to be redrawn, and made available to both repos: geode and 
> geode-native.
> The gif for the image is 
> - geode-native/docs/geode-native-docs/common/images/delta-propagation.gif
> - geode/geode-docs/images/DeltaPropagation-1.gif



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

[GitHub] geode-native pull request #88: Feature/geode 2537 Docs: redraw delta propaga...

[davebarnes97]

Github user davebarnes97 closed the pull request at:

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


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

[GitHub] geode-native issue #88: Feature/geode 2537 Docs: redraw delta propagation im...

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode-native/pull/88
  
Change accepted & merged.


---
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] [Assigned] (GEODE-2662) Gfsh displays field value on wrong line!

[Patrick Rhomberg (JIRA)]

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

Patrick Rhomberg reassigned GEODE-2662:
---

Assignee: Patrick Rhomberg

> Gfsh displays field value on wrong line!
> 
>
> Key: GEODE-2662
> URL: https://issues.apache.org/jira/browse/GEODE-2662
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Eitan Suez
>Assignee: Patrick Rhomberg
>
> scenario:
> start a locator, a server
> write a client that stores several records of a given type, using pdx 
> serialization
> modify the type in question by adding a field
> write one more record to gemfire, populating all fields, including the new 
> field
> invoke a gfsh query command "select * from /"
> the new field value will display always on the first line of the result set, 
> not on the line associated with the object it actually belongs to.
> example:
> Customer
>  firstName, lastName
> write a customer object:
>  John Doe
> now modify Customer, add telephoneNumber
>  write another customer object:
> Sam Smith, 512.333.
> now run:
> query --query="select c from /Customer c"
> will print:
> firstName | lastName | telephoneNumber
> - |  | ---
> John  | Doe  | 512.333.
> Sam   | Smith| null
> even though the query "select c from /Customer c where c.firstName = 'Sam'" 
> clearly shows the phone number is associated with sam.
> this bug has existed in gemfire at least since v8 and verified to still exist 
> in latest version 9.0.1



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

[GitHub] geode pull request #444: Feature/gem 1353

[jhuynh1]

Github user jhuynh1 commented on a diff in the pull request:

https://github.com/apache/geode/pull/444#discussion_r110718931
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java ---
@@ -1261,7 +1333,14 @@ void basicUpdateEntryVersion(EntryEventImpl event) 
throws EntryNotFoundException
   }
 
   protected void distributeUpdateEntryVersionOperation(EntryEventImpl 
event) {
-new UpdateEntryVersionOperation(event).distribute();
+UpdateEntryVersionOperation op = new 
UpdateEntryVersionOperation(event);
+long viewVersion = -1;
+try {
+  viewVersion = op.startOperation();
--- End diff --

Out of curiosity, what happens if the startOperation() method returns a -1 
(I think that may be possible based on how it's currently written or if an 
exception is thrown before token is assigned.  What is the expected way to 
handle endOperation with an invalid/-1 token?


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

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

[Bruce Schuchardt]

I agree that key/value serialization is a separate issue and more 
related to storage than communications.  The thing I'm struggling with 
is how to specify message metadata in an RPC IDL.  I'm thinking of 
things like an eventID, transaction info, security principal, etc.  The 
basic client/server messaging doesn't need to know the details of this 
information - just that it exists and maybe the ID of each piece of 
metadata.


Le 4/7/2017 à 5:23 PM, Jacob Barrett a écrit :

You are confusing message protocol with user data serialization. The two
are not related. Look at HTTP, the message protocol is pretty simple, PUT,
GET, etc., but it does nothing with the data being PUT/GET. On a GET the
message protocol has a field that specifies the Content-Type and
Content-Encoding and some other metadata. So the GET could get HTML, JPEG,
etc. but the protocol doesn't care and doesn't know anything special about
that type of the data it puts. The structure for JPEG is not defined in the
HTTP protocol at all.

So relate that to what we want to do. Our message protocol defines a PUT
and a GET operation, some metadata perhaps and a section for the data. It
should have no restriction or care on how that data was serialized. The
protocol does not define in any way the structure of the data being PUT or
GET.

Separating that concern then, does your argument still stand that PRC
frameworks do not work for the new Geode protocol?

On Fri, Apr 7, 2017 at 3:11 PM Galen M O'Sullivan 
wrote:


I think the main selling point of an RPC framework/IDL is ease-of-use for
defined remote communications that look like function calls. If you have
calls you're making to remote servers asking them to do work, you can
fairly trivially define the interface and then call through. You can then
use native types in function calls and they transparently get transformed
and sent across the wire.

The RPC protocols I've seen are based on the idea that the types that can
be sent will be predefined -- otherwise it's hard to describe with an IDL.

However, we want to support storing unstructured data, or at least data
structures that are defined (from the cluster's point of view) at runtime
-- one of the main selling points of Geode is PDX serialization, which lets
us store arbitrary object structures in the cache. If we were to use an RPC
framework we have all the commands accept byte arrays and include some
meta-information. This loses us the ease-of-use.

What's left in the protocol then is the calls and the number of arguments
they accept, and what order we put those (and the serialized arguments) in
on the wire. I don't think we gain much by using a preexisting RPC
language, and we lose control over the wire format and message structure.
If we want to be able to make the protocol really fast, and customized to
our use case; if we want to implement asynchronous requests, futures, etc.
then we have to write wrappers for a given language anyways, and packing
those things through an RPC framework like Thrift or gRPC will be an extra
layer of confusing complexity.

Best,
Galen

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

[Jacob Barrett]

I have used plenty of RPC protocols that pass raw binary as input/output
values because the types are not pre defined. All the frameworks mentioned
support byte arrays.

-Jake

On Mon, Apr 10, 2017 at 10:36 AM Galen M O'Sullivan 
wrote:

> Hi Jacob,
>
> The message protocol is conflated with user data serialization in pretty
> much all of these frameworks I've seen. If we define some RPC in Thrift, we
> have to specify the type of data that gets passed to the call. The type of
> that data is specified using the Thrift IDL, meaning it's a
> Thrift-serialized object. We could have all the remote procedure calls take
> and return byte arrays, but then I'm not sure what the benefit of using
> Thrift is.
>
> The nice thing about HTTP is that it's specified what it looks like on the
> wire and there's a defined mechanism for negotiating content type. The RPC
> frameworks I've seen aren't as clearly specified[1]. We would also have to
> write our own mechanism for negotiating encoding. It seems to me like we
> would be doing more work than we would be gaining.
>
> Another factor that will also constrain our serialization choices as well
> as RPC frameworks is that a lot of serialization libraries expect all the
> types to be known as runtime. We currently allow users to serialize POJOs
> or anything that will fit in PDX, and we want to keep that capability.
>
> [1]: I think I could reconstruct BERT based on the Erlang docs, but Thrift
> is harder. gRPC is basically Protobuf-encoded data over HTTP/2. We could
> put binary data in protobufs, but I'd rather not.
>
> On Fri, Apr 7, 2017 at 5:23 PM, Jacob Barrett  wrote:
>
> > You are confusing message protocol with user data serialization. The two
> > are not related. Look at HTTP, the message protocol is pretty simple,
> PUT,
> > GET, etc., but it does nothing with the data being PUT/GET. On a GET the
> > message protocol has a field that specifies the Content-Type and
> > Content-Encoding and some other metadata. So the GET could get HTML,
> JPEG,
> > etc. but the protocol doesn't care and doesn't know anything special
> about
> > that type of the data it puts. The structure for JPEG is not defined in
> the
> > HTTP protocol at all.
> >
> > So relate that to what we want to do. Our message protocol defines a PUT
> > and a GET operation, some metadata perhaps and a section for the data. It
> > should have no restriction or care on how that data was serialized. The
> > protocol does not define in any way the structure of the data being PUT
> or
> > GET.
> >
> > Separating that concern then, does your argument still stand that PRC
> > frameworks do not work for the new Geode protocol?
> >
> > On Fri, Apr 7, 2017 at 3:11 PM Galen M O'Sullivan  >
> > wrote:
> >
> > > I think the main selling point of an RPC framework/IDL is ease-of-use
> for
> > > defined remote communications that look like function calls. If you
> have
> > > calls you're making to remote servers asking them to do work, you can
> > > fairly trivially define the interface and then call through. You can
> then
> > > use native types in function calls and they transparently get
> transformed
> > > and sent across the wire.
> > >
> > > The RPC protocols I've seen are based on the idea that the types that
> can
> > > be sent will be predefined -- otherwise it's hard to describe with an
> > IDL.
> > >
> > > However, we want to support storing unstructured data, or at least data
> > > structures that are defined (from the cluster's point of view) at
> runtime
> > > -- one of the main selling points of Geode is PDX serialization, which
> > lets
> > > us store arbitrary object structures in the cache. If we were to use an
> > RPC
> > > framework we have all the commands accept byte arrays and include some
> > > meta-information. This loses us the ease-of-use.
> > >
> > > What's left in the protocol then is the calls and the number of
> arguments
> > > they accept, and what order we put those (and the serialized arguments)
> > in
> > > on the wire. I don't think we gain much by using a preexisting RPC
> > > language, and we lose control over the wire format and message
> structure.
> > > If we want to be able to make the protocol really fast, and customized
> to
> > > our use case; if we want to implement asynchronous requests, futures,
> > etc.
> > > then we have to write wrappers for a given language anyways, and
> packing
> > > those things through an RPC framework like Thrift or gRPC will be an
> > extra
> > > layer of confusing complexity.
> > >
> > > Best,
> > > Galen
> > >
> >
>

Re: One class loader vs multiple class loaders for deployed jars

[Jared Stewart]

I think this would be a viable approach in principle, but it would require
us to write a custom classloader implementation for what you have described
as the application classloader, rather than simply using an implementation
from the jdk.

On Apr 10, 2017 10:30 AM, "Anthony Baker"  wrote:

What about this:

1) Each jar is deployed into it’s own classloader.
2) If the classloader for jar1 is unable to load a class, it delegates to
its parent which can load classes from siblings to jar1.

The classloader hierarchy would be:

bootstrap << system << application << (deploy jar)*

where the application classloader manages the delegation to all deployed
jars.

Anthony


> On Apr 10, 2017, at 10:20 AM, Jared Stewart  wrote:
>
> There is last one implementation decision for GEODE-2290 that I'm torn
about, namely having one classloader for all deployed jars vs having
separate classloaders for each deployed jar.
>
> If we have one class loader, e.g. new UrlClassLoader(jar1, jar2), then:
>
> - Jar1 will be able to load classes/resources from jar2  (this was the
previous behavior of deployed jars with our custom class loader)
> - But if we redeploy jar 1, jar 2 will also get its class loader rebuilt,
which may raise the likelihood of weird classloader problems arising
>
> Does anyone else have thoughts about this tradeoff?
>
> Thanks,
> Jared

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

[Galen M O'Sullivan]

Hi Jacob,

The message protocol is conflated with user data serialization in pretty
much all of these frameworks I've seen. If we define some RPC in Thrift, we
have to specify the type of data that gets passed to the call. The type of
that data is specified using the Thrift IDL, meaning it's a
Thrift-serialized object. We could have all the remote procedure calls take
and return byte arrays, but then I'm not sure what the benefit of using
Thrift is.

The nice thing about HTTP is that it's specified what it looks like on the
wire and there's a defined mechanism for negotiating content type. The RPC
frameworks I've seen aren't as clearly specified[1]. We would also have to
write our own mechanism for negotiating encoding. It seems to me like we
would be doing more work than we would be gaining.

Another factor that will also constrain our serialization choices as well
as RPC frameworks is that a lot of serialization libraries expect all the
types to be known as runtime. We currently allow users to serialize POJOs
or anything that will fit in PDX, and we want to keep that capability.

[1]: I think I could reconstruct BERT based on the Erlang docs, but Thrift
is harder. gRPC is basically Protobuf-encoded data over HTTP/2. We could
put binary data in protobufs, but I'd rather not.

On Fri, Apr 7, 2017 at 5:23 PM, Jacob Barrett  wrote:

> You are confusing message protocol with user data serialization. The two
> are not related. Look at HTTP, the message protocol is pretty simple, PUT,
> GET, etc., but it does nothing with the data being PUT/GET. On a GET the
> message protocol has a field that specifies the Content-Type and
> Content-Encoding and some other metadata. So the GET could get HTML, JPEG,
> etc. but the protocol doesn't care and doesn't know anything special about
> that type of the data it puts. The structure for JPEG is not defined in the
> HTTP protocol at all.
>
> So relate that to what we want to do. Our message protocol defines a PUT
> and a GET operation, some metadata perhaps and a section for the data. It
> should have no restriction or care on how that data was serialized. The
> protocol does not define in any way the structure of the data being PUT or
> GET.
>
> Separating that concern then, does your argument still stand that PRC
> frameworks do not work for the new Geode protocol?
>
> On Fri, Apr 7, 2017 at 3:11 PM Galen M O'Sullivan 
> wrote:
>
> > I think the main selling point of an RPC framework/IDL is ease-of-use for
> > defined remote communications that look like function calls. If you have
> > calls you're making to remote servers asking them to do work, you can
> > fairly trivially define the interface and then call through. You can then
> > use native types in function calls and they transparently get transformed
> > and sent across the wire.
> >
> > The RPC protocols I've seen are based on the idea that the types that can
> > be sent will be predefined -- otherwise it's hard to describe with an
> IDL.
> >
> > However, we want to support storing unstructured data, or at least data
> > structures that are defined (from the cluster's point of view) at runtime
> > -- one of the main selling points of Geode is PDX serialization, which
> lets
> > us store arbitrary object structures in the cache. If we were to use an
> RPC
> > framework we have all the commands accept byte arrays and include some
> > meta-information. This loses us the ease-of-use.
> >
> > What's left in the protocol then is the calls and the number of arguments
> > they accept, and what order we put those (and the serialized arguments)
> in
> > on the wire. I don't think we gain much by using a preexisting RPC
> > language, and we lose control over the wire format and message structure.
> > If we want to be able to make the protocol really fast, and customized to
> > our use case; if we want to implement asynchronous requests, futures,
> etc.
> > then we have to write wrappers for a given language anyways, and packing
> > those things through an RPC framework like Thrift or gRPC will be an
> extra
> > layer of confusing complexity.
> >
> > Best,
> > Galen
> >
>

Re: One class loader vs multiple class loaders for deployed jars

[Anthony Baker]

What about this:

1) Each jar is deployed into it’s own classloader.
2) If the classloader for jar1 is unable to load a class, it delegates to its 
parent which can load classes from siblings to jar1.

The classloader hierarchy would be:

bootstrap << system << application << (deploy jar)*

where the application classloader manages the delegation to all deployed jars.

Anthony


> On Apr 10, 2017, at 10:20 AM, Jared Stewart  wrote:
> 
> There is last one implementation decision for GEODE-2290 that I'm torn about, 
> namely having one classloader for all deployed jars vs having separate 
> classloaders for each deployed jar.
> 
> If we have one class loader, e.g. new UrlClassLoader(jar1, jar2), then:
> 
> - Jar1 will be able to load classes/resources from jar2  (this was the 
> previous behavior of deployed jars with our custom class loader)
> - But if we redeploy jar 1, jar 2 will also get its class loader rebuilt, 
> which may raise the likelihood of weird classloader problems arising
> 
> Does anyone else have thoughts about this tradeoff?
> 
> Thanks,
> Jared

One class loader vs multiple class loaders for deployed jars

[Jared Stewart]

There is last one implementation decision for GEODE-2290 that I'm torn about, 
namely having one classloader for all deployed jars vs having separate 
classloaders for each deployed jar.

If we have one class loader, e.g. new UrlClassLoader(jar1, jar2), then:

- Jar1 will be able to load classes/resources from jar2  (this was the previous 
behavior of deployed jars with our custom class loader)
- But if we redeploy jar 1, jar 2 will also get its class loader rebuilt, which 
may raise the likelihood of weird classloader problems arising

Does anyone else have thoughts about this tradeoff?

Thanks,
Jared

[GitHub] geode pull request #444: Feature/gem 1353

[bschuchardt]

Github user bschuchardt commented on a diff in the pull request:

https://github.com/apache/geode/pull/444#discussion_r110697384
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedCacheOperation.java
 ---
@@ -240,12 +240,37 @@ public boolean containsRegionContentChange() {
 return true;
   }
 
+  public long startOperation() {
+DistributedRegion region = getRegion();
+long viewVersion = -1;
+if (this.containsRegionContentChange()) {
+  viewVersion = region.getDistributionAdvisor().startOperation();
+}
+if (logger.isTraceEnabled(LogMarker.STATE_FLUSH_OP)) {
+  logger.trace(LogMarker.STATE_FLUSH_OP, "dispatching operation in 
view version {}",
+  viewVersion);
+}
+return viewVersion;
+  }
+
+  public void endOperation(long viewVersion) {
+DistributedRegion region = getRegion();
+if (viewVersion != -1) {
+  region.getDistributionAdvisor().endOperation(viewVersion);
+  if (logger.isDebugEnabled()) {
+logger.trace(LogMarker.STATE_FLUSH_OP, "done dispatching operation 
in view version {}",
+viewVersion);
+  }
+}
+  }
+
   /**
* Distribute a cache operation to other members of the distributed 
system. This method determines
* who the recipients are and handles careful delivery of the operation 
to those members.
*/
   public void distribute() {
--- End diff --

Decentralizing the start/end of the op seems fragile to me.  Could you at 
least change the javadocs to state that startOperation must be invoked before 
distribute() and have the distribute() method throw an exception if 
startOperation has not been invoked?  Or maybe it would be even better to make 
distribute() private and have startOperation invoke it.


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

[GitHub] geode pull request #444: Feature/gem 1353

[bschuchardt]

Github user bschuchardt commented on a diff in the pull request:

https://github.com/apache/geode/pull/444#discussion_r110699099
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedCacheOperation.java
 ---
@@ -240,12 +240,37 @@ public boolean containsRegionContentChange() {
 return true;
   }
 
+  public long startOperation() {
--- End diff --

This and endOperation are missing javadocs, which I think are essential in 
this case.

I don't think the callers of startOperation care that the return value is a 
"viewVersion".  I think you should change all of the methods invoking 
startOperation to use "operationToken" instead of "viewVersion" so as not to 
make that code confusing.


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

[GitHub] geode pull request #444: Feature/gem 1353

[bschuchardt]

Github user bschuchardt commented on a diff in the pull request:

https://github.com/apache/geode/pull/444#discussion_r110708948
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java ---
@@ -1261,7 +1333,14 @@ void basicUpdateEntryVersion(EntryEventImpl event) 
throws EntryNotFoundException
   }
 
   protected void distributeUpdateEntryVersionOperation(EntryEventImpl 
event) {
-new UpdateEntryVersionOperation(event).distribute();
+UpdateEntryVersionOperation op = new 
UpdateEntryVersionOperation(event);
+long viewVersion = -1;
+try {
+  viewVersion = op.startOperation();
--- End diff --

For cases like this one it would be nice to move the try/finally to a new 
method in DistributedCacheOperation and just invoke that method.  Maybe call it 
distribute()???

```
public void distributed() {
  long token;
  try {
token = startOperation();
_distribute(); // private method
  } finally {
endOperation(token);
  }
}
```
If you do this you can revert the changes you've made to a lot of classes.


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

[GitHub] geode issue #404: Geode 2469

[ggreen]

Github user ggreen commented on the issue:

https://github.com/apache/geode/pull/404
  
@galen-pivotal and @metatype, are there any suggestions on how to move this 
pull request forward?


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

[GitHub] geode issue #404: Geode 2469

[ggreen]

Github user ggreen commented on the issue:

https://github.com/apache/geode/pull/404
  
@galen-pivotal and @metatype, are there any suggestions on how to move this 
pull request forward?


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

Re: Jenkins karma (was Re: Blacklist asf904 for Geode nightly job)

[William Markito Oliveira]

Hi Anthony,

My karma is also limited, sorry.  I believe only Roman (or infra) can
change that...

On Mon, Apr 10, 2017 at 11:46 AM, Anthony Baker  wrote:

> Anyone?
>
> > On Apr 7, 2017, at 11:32 AM, Anthony Baker  wrote:
> >
> > I would like Jenkins karma so I can explore running our tests from
> within a docker container.  William / Mark / Roman can you help me out?
> >
> > Thanks,
> > Anthony
> >
> >
> >> On Mar 21, 2017, at 3:14 PM, Anthony Baker  wrote:
> >>
> >> Would be very nice to run our jenkins jobs from a docker container to
> avoid these environmental quirks.
> >>
> >> Anthony
>
>


-- 
~/William

Re: Jenkins karma (was Re: Blacklist asf904 for Geode nightly job)

[Roman Shaposhnik]

On Mon, Apr 10, 2017 at 9:46 AM, Anthony Baker  wrote:
> Anyone?

This should be done by Mark (current Chair).

Mark, can you add Anthony to the Jenkins LDAP group?

Thanks,
Roman.

Jenkins karma (was Re: Blacklist asf904 for Geode nightly job)

[Anthony Baker]

Anyone?

> On Apr 7, 2017, at 11:32 AM, Anthony Baker  wrote:
> 
> I would like Jenkins karma so I can explore running our tests from within a 
> docker container.  William / Mark / Roman can you help me out?
> 
> Thanks,
> Anthony
> 
> 
>> On Mar 21, 2017, at 3:14 PM, Anthony Baker  wrote:
>> 
>> Would be very nice to run our jenkins jobs from a docker container to avoid 
>> these environmental quirks.
>> 
>> Anthony