Jenkins build is back to normal : Geode-nightly #710

[Apache Jenkins Server]

See 

[GitHub] geode issue #327: GEODE-2236: Remove all cache-listners using Gfsh

[deepakddixit]

Github user deepakddixit commented on the issue:

https://github.com/apache/geode/pull/327
  
@kjduling If changes are good can you please help me in merging this PR?


---
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-2236) Attempting to remove all CacheListeners from a Region using gfsh throws NullPointerException

[ASF GitHub Bot (JIRA)]

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

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

Github user deepakddixit commented on the issue:

https://github.com/apache/geode/pull/327
  
@kjduling If changes are good can you please help me in merging this PR?


> Attempting to remove all CacheListeners from a Region using gfsh throws 
> NullPointerException
> 
>
> Key: GEODE-2236
> URL: https://issues.apache.org/jira/browse/GEODE-2236
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>Assignee: Deepak Dixit
>
> The --cache-listener option to the alter region command replaces the existing 
> CacheListeners with the ones set in the option.
> What happens in RegionAlterFunction is that the existing CacheListeners not 
> included in the new list are removed, then the new ones are added.
> So, in theory, to remove all CacheListeners, an empty string could be passed 
> into the --cache-listener option like:
> {noformat}
> alter region --name=data --cache-listener=''
> Executing - alter region --name=data --cache-listener=""
> Member  | Status
> --- | 
> --
> server2 | ERROR: java.lang.NullPointerException
>   at com.gemstone.gemfire.manag..
> server1 | ERROR: java.lang.NullPointerException
>   at com.gemstone.gemfire.manag..
> {noformat}
> This actually works but it throws the NPE below.
> {noformat}
> [error 2016/09/13 09:48:59.943 PDT server1  
> tid=0x40] 
> java.lang.NullPointerException
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.newInstance(RegionAlterFunction.java:320)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.alterRegion(RegionAlterFunction.java:228)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.execute(RegionAlterFunction.java:64)
>   at 
> com.gemstone.gemfire.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:185)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:457)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:692)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1149)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> A work-around to this issue is to set a non-existent CacheListener in the 
> --cache-listener option like:
> {noformat}
> alter region --name=data --cache-listener=Fred
> Executing - alter region --name=data --cache-listener=Fred
> Member  | Status
> --- | --
> server1 | ERROR: Could not find class "Fred" specified for "cache-listener".
> server2 | ERROR: Could not find class "Fred" specified for "cache-listener".
> {noformat}
> This correctly throws the ClassNotFoundException below and also removes all 
> the existing CacheListeners.
> {noformat}
> [error 2016/09/13 09:46:40.537 PDT server1  
> tid=0x40] Could not find class "Fred" specified for "cache-listener".
> java.lang.RuntimeException: Could not find class "Fred" specified for 
> "cache-listener".
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.forName(RegionAlterFunction.java:306)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.alterRegion(RegionAlterFunction.java:227)
>   at 
> com.gemstone.gemfire.management.internal.cli.functions.RegionAlterFunction.execute(RegionAlterFunction.java:64)
>   at 
> com.gemstone.gemfire.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:185)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:457)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:692)

[jira] [Updated] (GEODE-47) GFSH can't start servers in foreground

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-47:
---
Issue Type: Improvement  (was: Bug)

> GFSH can't start servers in foreground
> --
>
> Key: GEODE-47
> URL: https://issues.apache.org/jira/browse/GEODE-47
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: William Markito Oliveira
>Priority: Minor
>  Labels: gfsh, gsoc2016
>
> There are certain cases where users may want to use gfsh and start members 
> (locator or servers) in foreground.
> In old scripts there was an alternative to have servers started in foreground 
> but that's not available anymore. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 55329: GEODE-182: Auto-generate member names if needed

[Anthony Baker]

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

Review request for geode, Jinmei Liao, John Blum, Kirk Lund, and William 
Markito.


Repository: geode


Description
---

When a user runs `start server` or `start locator` from gfsh
without specifying the member name, gfsh will automatically pick
a random member name. This is useful for automation.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 09d0a67b9f94e22fdeb3b9055a0759b5db805b1d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/ThreePhraseGenerator.java
 PRE-CREATION 
  geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java 
2ddc810b39161e4457ee4bfd498a1fc635652280 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/ThreePhraseGeneratorTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/55329/diff/


Testing
---


Thanks,

Anthony Baker

Re: copy files to servers

[Wes Williams]

This seems dangerous to me as a client could send malicious code for
execution to all servers.
Geode requires an administrative step to do gfsh> deploy --jar=..., that
provides a control step that theoretically should check a malicious client.

As for third-party jars, they do the same as what we're discussing:

> "Our suggestion is to include all 3rd party libraries into class path of
> every node. This can be achieved by copying your JAR files into the Ignite
> libs folder."


​As for the dynamical loading and running of Spring jars, let's say that
​timeline pressures and money outweigh a small, temporary network
saturation as we distribute Spring jars to the nodes.  We then get to the
dynamic loading:

If class is not locally available, then a request will be sent to the
> originating node to provide class definition. Originating node will send
> class byte-code definition and the class will be loaded on the worker node.
> This happens only once per class - once class definition is loaded on a
> node, it will never have to be loaded again.


I think it's practical.  However, iIsn't this potentially dangerous as a
client could intentionally inject malicious code into the grid?  Whereas
gfsh> deploy --jar=... gives Operations a control check point that
theoretically can thwart such an attack.



*Wes Williams | Pivotal Advisory **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire

On Fri, Jan 6, 2017 at 8:46 PM, Roman Shaposhnik 
wrote:

> Btw, I'm sure a comparison of capabilities with Ignite will come up at
> some point. So here's what
> they do in this department (which I personally find really cool):
>http://apacheignite.gridgain.org/v1.0/docs/zero-deployment
>
> Thanks,
> Roman.
>
> On Fri, Jan 6, 2017 at 12:11 PM, Anthony Baker  wrote:
> > Hmmm, I agree with Udo.  I’d like to push a new version of my
> application with a single idempotent command.  The server should be smart
> enough to figure out what's in my bundle and understand how to deploy it
> including any dependencies (because who writes dependency-free code?).
> >
> > I do want some lifecycle hooks to alloc/free resources.  This seems
> conceptually similar to the “war” model which is pretty familiar to most
> Java devs.
> >
> > Anthony
> >
> >> On Jan 6, 2017, at 11:37 AM, Udo Kohlmeyer 
> wrote:
> >>
> >> In some ways that is a great idea but sometimes too explicit... Do
> we expect them to have fine grained jars?
> >> Also how do we handle dependencies as a single util class might be
> used by both a cache-listener and a partition listener... is the
> expectation that we update the dependent util class for one but not the
> other
> >>
> >> It's a very grey area
> >>
> >> On 1/6/17 11:19, John Blum wrote:
> >>> How about...
> >>>
> >>> * deploy function
> >>> * deploy cache-listener
> >>> * deploy cache-loader
> >>> * deploy cache-loader
> >>> * deploy resource (jar, xml, properties, etc)
> >>> * etc.
> >>>
> >>> Might as was make it explicit.  For instance, I may have a JAR file I
> just
> >>> deployed (uploaded) that contains Functions, Listeners, Loaders,
> Writers,
> >>> etc but I only want to deploy functions.
> >>>
> >>> Having 1 uber "deploy" command with many options gets cumbersome.
> >>>
> >>> It is a simple matter to introduce multiple command but have those
> commands
> >>> share similar logic.  This would also enable different workflows for
> >>> different commands in a more non-convoluted, maintainable way.
> >>>
> >>> These could be matched with corresponding `undeploy` commands.
> >>>
> >>> Food for thought,
> >>>
> >>> John
> >>>
> >>>
> >>>
> >>> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund  wrote:
> >>>
>  With appropriate constraints, a copy file type command could be
> secure.
> 
>  1) don't use Apache Geode without security AND make the command
> require
>  authorization permissions
>  2) limit the target directory to a directory under the working
> directory of
>  the remote server
>  3) rename it to "deploy resource" so people don't expect it to copy
> to an
>  arbitrary target directory on the remote machine
> 
>  Back to "deploy jar":
> 
>  The deploy command is only for deploying Apache Geode callbacks
> (Function,
>  CacheListener, etc). "deploy resource" such Spring jars or Spring xml
> files
>  or anything similar does not overlap with "deploy jar". There is
> continued
>  confusion over what "deploy jar" is or does. I propose we rename it to
>  "deploy functions" or "deploy callbacks" or something along those
> lines to
>  end the confusion.
> 
>  On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz 
> wrote:
> 
> > So maybe a generic copy command is too insecure, I agree.
> > What we should do is think about exactly what files we think we are
>  trying
> > to deploy.
> >
> >1. I believe that there is a need to deploy dependency jars into
> the
> >system classpat

[jira] [Assigned] (GEODE-2160) gfsh stop server/locator exits with code 0 before server/locator actually stops

[Anthony Baker (JIRA)]

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

Anthony Baker reassigned GEODE-2160:


Assignee: Anthony Baker

> gfsh stop server/locator exits with code 0 before server/locator actually 
> stops
> ---
>
> Key: GEODE-2160
> URL: https://issues.apache.org/jira/browse/GEODE-2160
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.0.0-incubating
>Reporter: Jacob S. Barrett
>Assignee: Anthony Baker
>
> Executing
> {code}
> gfsh stop server --name=server1
> {code}
> {{gfsh}} exits, with code 0, prior to the server actually being stopped.
> This behavior isn't documented and makes scripting with gfsh difficult. One 
> can't assume that the server has stopped after gfsh exits. To verify you must 
> parse the server pid and check the status of the proc. 
> Simple test:
> {code}
> gfsh start server --name=s2 && sleep 10 && gfsh stop server --dir=s2; echo 
> $?; while (kill -0 `cat s2/vf.gf.server.pid`); do date +%s.%N; done
> {code}
> Starts server, waits 10s, stops server, prints exit code, loops until process 
> is gone while printing the time since epoch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 55286: GEODE-2280: Allow accessors to create a lucene index

[xiaojian zhou]

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




geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 (line 63)


You will create file region and chunk region with PARTITION_PROXY too? 

That's much easier than my original idea (i.e. not to create them)


- xiaojian zhou


On Jan. 6, 2017, 11:47 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55286/
> ---
> 
> (Updated Jan. 6, 2017, 11:47 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and Jason Huynh.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Allow peer accessors to create a lucene index and fixing the dunit tests
> to actually use an accessor.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  f8bbc418955b7fb6102312325f0304cd385a0a7c 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPRBase.java
>  8e62c85896da8bef5684c71cda8dc13624feede4 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerPRDUnitTest.java
>  ffab354f1c1ea030267fa21f4efd477004b622c8 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerPROverflowDUnitTest.java
>  b9aa0b781522e58ae6650e704e7ba4f9325ed99e 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/LuceneQueriesPeerPRRedundancyDUnitTest.java
>  d645d5e357b3312c5501ca24abff40ceeaf93682 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegionTest.java
>  cec37343fe1b249cc767839a708229a6c9011881 
> 
> Diff: https://reviews.apache.org/r/55286/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

[jira] [Commented] (GEODE-2160) gfsh stop server/locator exits with code 0 before server/locator actually stops

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2160:


Commit 488850bd7f43d25abe31f00aec832b3c147f8fbd in geode's branch 
refs/heads/feature/GEODE-2160 from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=488850b ]

GEODE-2160: gfsh waits for process exit before reporting success

gfsh stop server/locator now waits for the process to exit before
returning a result code. Adds a member mbean operation to support
synchronous shutdown.


> gfsh stop server/locator exits with code 0 before server/locator actually 
> stops
> ---
>
> Key: GEODE-2160
> URL: https://issues.apache.org/jira/browse/GEODE-2160
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.0.0-incubating
>Reporter: Jacob S. Barrett
>Assignee: Anthony Baker
>
> Executing
> {code}
> gfsh stop server --name=server1
> {code}
> {{gfsh}} exits, with code 0, prior to the server actually being stopped.
> This behavior isn't documented and makes scripting with gfsh difficult. One 
> can't assume that the server has stopped after gfsh exits. To verify you must 
> parse the server pid and check the status of the proc. 
> Simple test:
> {code}
> gfsh start server --name=s2 && sleep 10 && gfsh stop server --dir=s2; echo 
> $?; while (kill -0 `cat s2/vf.gf.server.pid`); do date +%s.%N; done
> {code}
> Starts server, waits 10s, stops server, prints exit code, loops until process 
> is gone while printing the time since epoch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)