RE: Geode Exception: cluster configuration service not available

[Aravind Musigumpula]

Hi,
Currently I am using the following configuration :

locator-specific-props:(used by both locators)
--J=-Dgemfire.jmx-manager=true
--J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=(portno.)
--J=-Dgemfire.jmx-manager-http-port=(portno.)
locator-common-props:( used by both locators)
--initial-heap=256M --max-heap=256M
--mcast-port=0
--locators=address(port), address(port)
--dir=.
--J=-XX:+UseParNewGC --J=-XX:+UseConcMarkSweepGC 
--J=-XX:CMSInitiatingOccupancyFraction=60 
--J=-XX:+UseCMSInitiatingOccupancyOnly --J=-XX:+CMSParallelRemarkEnabled --  
J=XX:+DisableExplicitGC --J=-XX:+CMSClassUnloadingEnabled --J=-verbose:gc 
--J=-Xloggc:locator-gc.log --J=-XX:+PrintGCDateStamps --J=-XX:+PrintGCDetails 
--J=-XX:+PrintTenuringDistribution -J=-XX:+PrintGCApplicationConcurrentTime 
--J=-XX:+PrintGCApplicationStoppedTime
server-common-props(used by both servers)
locators= address(port), address(port)
cache-xml-file=./Server.xml
-J-Dgemfire.ALLOW_PERSISTENT_TRANSACTIONS=true
enable-network-partition-detection=true
disable-auto-reconnect=true
statistic-archive-file=statistics.log
server-specific-props-1(used by both servers)
jmx-manager=false
jmx-manager-start=false
server-jvm-props(used by both servers)
-J-Xmx256M -J-Xms256M
-J-XX:+UseParNewGC -J-XX:+UseConcMarkSweepGC 
-J-XX:CMSInitiatingOccupancyFraction=60 -J-XX:+UseCMSInitiatingOccupancyOnly 
-J-XX:+CMSParallelRemarkEnabled -J-   
XX:+DisableExplicitGC -J-XX:+CMSClassUnloadingEnabled -J-verbose:gc 
-J-Xloggc:server-gc.log -J-XX:+PrintGCDateStamps -J-XX:+PrintGCDetails 
-J-XX:+PrintTenuringDistribution -J- 
XX:+PrintGCApplicationConcurrentTime -J-XX:+PrintGCApplicationStoppedTime

Initially it was set to true as it was not working I set it to false and tried, 
but it also didn’t work.



Thanks,
Aravind Musigumpula 

-Original Message-
From: Jinmei Liao [mailto:jil...@pivotal.io] 
Sent: Wednesday, May 24, 2017 8:58 PM
To: dev@geode.apache.org
Subject: Re: Geode Exception: cluster configuration service not available

Aravind, can you provide us with your startup script and the relevant 
locator/server properties file? Is there any reason you want to set the 
server's "disable-auto-reconnect" to false?

On Wed, May 24, 2017 at 4:41 AM, Aravind Musigumpula < 
aravind.musigump...@amdocs.com> wrote:

>
> Hi,
>
> I am using a cluster configuration in geode 1.1.1 . I am starting two 
> locators on different hosts and one server for each locator. When I 
> stop them and restart the cluster, I can see that in one of the 
> locator view , it is receiving only one locator. In gfsh list members, 
> I can see only one locator of that host but no server and no other locator 
> and its server.
>
> I tried enabling the following parameters:
> In locator-specific-props: I have set "enable-cluster-configuration=true"
> In sever-common-props: I have set "disable-auto-reconnect=false" , 
> "use-cluster-configuration=true"
>
> In Server cache log, I am getting an exception :
> Cache server error
> org.apache.geode.GemFireConfigException: cluster configuration service 
> not available
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> requestSharedConfiguration(GemFireCacheImpl.java:1067)
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> initialize(GemFireCacheImpl.java:1200)
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> basicCreate(GemFireCacheImpl.java:798)
> at org.apache.geode.internal.cache.GemFireCacheImpl.create(
> GemFireCacheImpl.java:783)
> at org.apache.geode.cache.CacheFactory.create(
> CacheFactory.java:178)
> at org.apache.geode.cache.CacheFactory.create(
> CacheFactory.java:171)
> at org.apache.geode.internal.cache.CacheServerLauncher.
> createCache(CacheServerLauncher.java:813)
> at org.apache.geode.internal.cache.CacheServerLauncher.
> server(CacheServerLauncher.java:657)
> at org.apache.geode.internal.cache.CacheServerLauncher.
> main(CacheServerLauncher.java:201)
> Caused by: org.apache.geode.internal.process.
> ClusterConfigurationNotAvailableException: Unable to retrieve cluster 
> configuration from the locator.
> at org.apache.geode.internal.cache.ClusterConfigurationLoader.
> requestConfigurationFromLocators(ClusterConfigurationLoader.java:245)
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> requestSharedConfiguration(GemFireCacheImpl.java:1029)
> ... 8 more
> VM is exiting - shutting down distributed system In one of the locator 
> log, I can see this:
> Region /_ConfigurationRegion has potentially stale data. It is waiting 
> for another member to recover the latest data.
> .
> .
> .
>
>  tid=0x39] View Creator is processing 2 
> requests for the next membership view
>
> received new view: View ...  members: ..  

RE: Geode Exception: cluster configuration service not available

[Anton Mironenko]

Hi Aravind,
Why did you miss the locator property

  --enable-cluster-configuration=true \
?

Anton Mironenko
Software Architect
Amdocs ASP team

-Original Message-
From: Aravind Musigumpula 
Sent: Thursday, May 25, 2017 10:54
To: dev@geode.apache.org
Subject: RE: Geode Exception: cluster configuration service not available

Hi,
Currently I am using the following configuration :

locator-specific-props:(used by both locators)
--J=-Dgemfire.jmx-manager=true
--J=-Dgemfire.jmx-manager-start=true
--J=-Dgemfire.jmx-manager-port=(portno.)
--J=-Dgemfire.jmx-manager-http-port=(portno.)
locator-common-props:( used by both locators)
--initial-heap=256M --max-heap=256M
--mcast-port=0
--locators=address(port), address(port)
--dir=.
--J=-XX:+UseParNewGC --J=-XX:+UseConcMarkSweepGC 
--J=-XX:CMSInitiatingOccupancyFraction=60 
--J=-XX:+UseCMSInitiatingOccupancyOnly --J=-XX:+CMSParallelRemarkEnabled --  
J=XX:+DisableExplicitGC --J=-XX:+CMSClassUnloadingEnabled --J=-verbose:gc 
--J=-Xloggc:locator-gc.log --J=-XX:+PrintGCDateStamps --J=-XX:+PrintGCDetails 
--J=-XX:+PrintTenuringDistribution -J=-XX:+PrintGCApplicationConcurrentTime 
--J=-XX:+PrintGCApplicationStoppedTime
server-common-props(used by both servers)
locators= address(port), address(port)
cache-xml-file=./Server.xml
-J-Dgemfire.ALLOW_PERSISTENT_TRANSACTIONS=true
enable-network-partition-detection=true
disable-auto-reconnect=true
statistic-archive-file=statistics.log
server-specific-props-1(used by both servers)
jmx-manager=false
jmx-manager-start=false
server-jvm-props(used by both servers)
-J-Xmx256M -J-Xms256M
-J-XX:+UseParNewGC -J-XX:+UseConcMarkSweepGC 
-J-XX:CMSInitiatingOccupancyFraction=60 -J-XX:+UseCMSInitiatingOccupancyOnly 
-J-XX:+CMSParallelRemarkEnabled -J-   
XX:+DisableExplicitGC -J-XX:+CMSClassUnloadingEnabled -J-verbose:gc 
-J-Xloggc:server-gc.log -J-XX:+PrintGCDateStamps -J-XX:+PrintGCDetails 
-J-XX:+PrintTenuringDistribution -J- 
XX:+PrintGCApplicationConcurrentTime -J-XX:+PrintGCApplicationStoppedTime

Initially it was set to true as it was not working I set it to false and tried, 
but it also didn’t work.



Thanks,
Aravind Musigumpula 

-Original Message-
From: Jinmei Liao [mailto:jil...@pivotal.io]
Sent: Wednesday, May 24, 2017 8:58 PM
To: dev@geode.apache.org
Subject: Re: Geode Exception: cluster configuration service not available

Aravind, can you provide us with your startup script and the relevant 
locator/server properties file? Is there any reason you want to set the 
server's "disable-auto-reconnect" to false?

On Wed, May 24, 2017 at 4:41 AM, Aravind Musigumpula < 
aravind.musigump...@amdocs.com> wrote:

>
> Hi,
>
> I am using a cluster configuration in geode 1.1.1 . I am starting two 
> locators on different hosts and one server for each locator. When I 
> stop them and restart the cluster, I can see that in one of the 
> locator view , it is receiving only one locator. In gfsh list members, 
> I can see only one locator of that host but no server and no other locator 
> and its server.
>
> I tried enabling the following parameters:
> In locator-specific-props: I have set "enable-cluster-configuration=true"
> In sever-common-props: I have set "disable-auto-reconnect=false" , 
> "use-cluster-configuration=true"
>
> In Server cache log, I am getting an exception :
> Cache server error
> org.apache.geode.GemFireConfigException: cluster configuration service 
> not available
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> requestSharedConfiguration(GemFireCacheImpl.java:1067)
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> initialize(GemFireCacheImpl.java:1200)
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> basicCreate(GemFireCacheImpl.java:798)
> at org.apache.geode.internal.cache.GemFireCacheImpl.create(
> GemFireCacheImpl.java:783)
> at org.apache.geode.cache.CacheFactory.create(
> CacheFactory.java:178)
> at org.apache.geode.cache.CacheFactory.create(
> CacheFactory.java:171)
> at org.apache.geode.internal.cache.CacheServerLauncher.
> createCache(CacheServerLauncher.java:813)
> at org.apache.geode.internal.cache.CacheServerLauncher.
> server(CacheServerLauncher.java:657)
> at org.apache.geode.internal.cache.CacheServerLauncher.
> main(CacheServerLauncher.java:201)
> Caused by: org.apache.geode.internal.process.
> ClusterConfigurationNotAvailableException: Unable to retrieve cluster 
> configuration from the locator.
> at org.apache.geode.internal.cache.ClusterConfigurationLoader.
> requestConfigurationFromLocators(ClusterConfigurationLoader.java:245)
> at org.apache.geode.internal.cache.GemFireCacheImpl.
> requestSharedConfiguration(GemFireCacheImpl.java:1029)
> ... 8 more
> VM is exiting - shutting do

Re: What to do with Singletons

[Wes Williams]

+1 to utility functions

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

On Wed, May 24, 2017 at 4:59 PM, John Blum  wrote:

> On a side but related note, it would be nice if Geode had the notion of
> useful, "canned" Functions provided OOTB.  Some of the *Gfsh* functions
> would be quite useful for applications in fact, or particularly for
> framework/tools to use as well.  Sometime ago I sent a list of Functions I
> thought would be nice to have.
>
> Food for thought.
>
> On Wed, May 24, 2017 at 1:41 PM, Kirk Lund  wrote:
>
> > Thanks for pointing out that DistributionManager is internal -- I forgot
> > about that. I'm primarily concerned with internal Functions, such as
> those
> > for GFSH commands, so maybe an internal version of FunctionContext which
> > exposes more would be good for those.
> >
> > On Wed, May 24, 2017 at 11:39 AM, Darrel Schneider <
> dschnei...@pivotal.io>
> > wrote:
> >
> > > FunctionContext is an external interface so it can not expose internal
> > > interfaces like DistributionManager.
> > > But it could expose Cache. DistributedSystem is external so you could
> > have
> > > it exposed from FunctionContext but it is already exposed from Cache.
> > > SecurityService is also internal.
> > > Are you thinking that for internal Functions you would cast
> > FunctionContext
> > > to an internal that would then expose these internal classes?
> > >
> > >
> > >
> > > On Thu, May 18, 2017 at 5:13 PM, Kirk Lund  wrote:
> > >
> > > > I've been digging through our code with close attention to the
> > > singletons.
> > > > I believe the majority of singletons in Geode exist for two main
> > reasons:
> > > >
> > > > 1) Insufficient context or lack of service lookup for Function,
> > > > DistributionMessage and (Client)Command implementations.
> > > >
> > > > 2) Poor OO design. This is where you see code in one class invoking
> > > > concrete methods on another class outside of its concerns. Many of
> > these
> > > > need to be teased apart and replaced with some sort of Observer that
> > > > isolates the reaction from the source of the originating event.
> > > >
> > > > Right now my focus is on #1 because that's the area that's currently
> an
> > > > obstacle for me.
> > > >
> > > > Function, DistributionMessage and (Client)Command classes need to
> have
> > > more
> > > > context provided to them (Cache, Security, etc) or they need a better
> > > > mechanism to look up these services. Currently these classes reach
> out
> > to
> > > > singletons in order to "get" what they need.
> > > >
> > > > *A) Function*
> > > >
> > > > The main entry-point which injects services into the Function is:
> > > >
> > > > public void execute(FunctionContext context);
> > > >
> > > > The FunctionContext needs to provide the service(s) that any Function
> > > might
> > > > require. This could include Cache, DistributionManager and maybe
> > > > SecurityService (anything else?).
> > > >
> > > > *B) (Peer-to-peer) DistributionMessage*
> > > >
> > > > The main entry-point which injects services into the
> > DistributionMessage
> > > > is:
> > > >
> > > > protected abstract void process(DistributionManager dm);
> > > >
> > > > We could provide multiple arguments or a single new
> DistributionContext
> > > > which then provides DistributionManager and Cache (anything else?).
> > > >
> > > > *C) (Client) Command*
> > > >
> > > > The main entry-point which injects services into the Command is:
> > > >
> > > > public void execute(Message msg, ServerConnection servConn);
> > > >
> > > > ServerConnection is huge but it does already expose Cache.
> BaseCommand
> > is
> > > > the only Command that implements "execute" and it defines a new
> > > entry-point
> > > > for injection:
> > > >
> > > > abstract public void cmdExecute(Message msg, ServerConnection
> servConn,
> > > > long start) throws IOException, ClassNotFoundException,
> > > > InterruptedException;
> > > >
> > > > We might want to clean that up and define a new CommandContext which
> > > > provides the Cache or anything else that the Command may need.
> > > >
> > > > Thoughts or additional ideas?
> > > >
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

[jira] [Commented] (GEODE-2954) Old client gets null memberID in cache listener

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2954:


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

GEODE-2954 Old client gets null memberID in cache listener

I've added a new test that demonstrates that a new-version server sends
an EventID to a client that the client is unable to deserialize
completely.  It gets an error when deserializing its member ID,
causing cache listeners to get a null when requesting the ID of
the member that effected the change.

The fix is to reserialize the member ID in EventID.toData if the
destination stream is for an older version, such as a 1.1.0 client.
This ensures the proper on-wire format is used for that version of Geode.

I've also bumped up the version ordinal for 1.2 since version 59 is
marked as unusable in Version.java.

I've changed the Banner to show the version ordinal because the other
version information in the banner isn't completely trustworthy.  It
looks for a GemFireVersion.properties file on the classpath to get
this information and so it may not get it from the Geode jar file
as expected.


> Old client gets null memberID in cache listener
> ---
>
> Key: GEODE-2954
> URL: https://issues.apache.org/jira/browse/GEODE-2954
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> I was doing backward compatibility testing and found a 1.0 client was getting 
> a null memberID in a cache listener
> {noformat}
> [info 2017/05/18 16:27:38.957 PDT  trout(bridgegemfire5_trout_2254:2254):1030 port 21051> tid=0x2f] 
> Invoked util.SilenceListener for key Object_7399: afterDestroy in edge1, pid 
> 2267, vmID 5, operation DESTROY
>  whereIWasRegistered: 2267
>  event.getKey(): Object_7399
>  event.getOldValue():  (contains 6 levels, aPrimitiveLong=6409636308677575978)>
>  event.getNewValue(): null
>  event.getOperation().isLoad(): false
>  event.getOperation().isLocalLoad(): false
>  event.getOperation().isNetLoad(): false
>  event.getOperation().isNetSearch(): false
>  event.isConcurrencyConflict(): false
>  event.getDistributedMember(): null
>  event.getCallbackArgument(): null
>  event.getRegion(): /testRegion
>  event.getOperation().isDistributed(): true
>  event.getOperation().isExpiration(): false
>  event.isOriginRemote(): true
> {noformat}
> This was in an old test suite whose testing infrastructure isn't in the Geode 
> repo.  I'm writing a unit test to reproduce the problem.
> If you look at EventID.java you can see that it catches IOExceptions in 
> deserializing the memberID of the event and returns null without logging the 
> problem.
> {code}
> try {
>   result = InternalDistributedMember.readEssentialData(dis);
> } catch (IOException e) {
>   // nothing can be done about this
> } catch (ClassNotFoundException e) {
>   // ditto
> }
> {code}



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

Re: What to do with Singletons

[Udo Kohlmeyer]

@Kirk, I think your approach to reduce the number of singleton access is 
good. I agree and believe that any operational invocation 
(Function,Command, DistributionMessage,etc...) should provide a 
mechanism to be able to access all relevant all contextual information 
required to execute the task (Function,Command, DistributionMessage,etc...)



On 5/24/17 13:41, Kirk Lund wrote:

Thanks for pointing out that DistributionManager is internal -- I forgot
about that. I'm primarily concerned with internal Functions, such as those
for GFSH commands, so maybe an internal version of FunctionContext which
exposes more would be good for those.

On Wed, May 24, 2017 at 11:39 AM, Darrel Schneider 
wrote:


FunctionContext is an external interface so it can not expose internal
interfaces like DistributionManager.
But it could expose Cache. DistributedSystem is external so you could have
it exposed from FunctionContext but it is already exposed from Cache.
SecurityService is also internal.
Are you thinking that for internal Functions you would cast FunctionContext
to an internal that would then expose these internal classes?



On Thu, May 18, 2017 at 5:13 PM, Kirk Lund  wrote:


I've been digging through our code with close attention to the

singletons.

I believe the majority of singletons in Geode exist for two main reasons:

1) Insufficient context or lack of service lookup for Function,
DistributionMessage and (Client)Command implementations.

2) Poor OO design. This is where you see code in one class invoking
concrete methods on another class outside of its concerns. Many of these
need to be teased apart and replaced with some sort of Observer that
isolates the reaction from the source of the originating event.

Right now my focus is on #1 because that's the area that's currently an
obstacle for me.

Function, DistributionMessage and (Client)Command classes need to have

more

context provided to them (Cache, Security, etc) or they need a better
mechanism to look up these services. Currently these classes reach out to
singletons in order to "get" what they need.

*A) Function*

The main entry-point which injects services into the Function is:

public void execute(FunctionContext context);

The FunctionContext needs to provide the service(s) that any Function

might

require. This could include Cache, DistributionManager and maybe
SecurityService (anything else?).

*B) (Peer-to-peer) DistributionMessage*

The main entry-point which injects services into the DistributionMessage
is:

protected abstract void process(DistributionManager dm);

We could provide multiple arguments or a single new DistributionContext
which then provides DistributionManager and Cache (anything else?).

*C) (Client) Command*

The main entry-point which injects services into the Command is:

public void execute(Message msg, ServerConnection servConn);

ServerConnection is huge but it does already expose Cache. BaseCommand is
the only Command that implements "execute" and it defines a new

entry-point

for injection:

abstract public void cmdExecute(Message msg, ServerConnection servConn,
long start) throws IOException, ClassNotFoundException,
InterruptedException;

We might want to clean that up and define a new CommandContext which
provides the Cache or anything else that the Command may need.

Thoughts or additional ideas?

Re: What to do with the geode-spark-connector

[Anthony Baker]

I agree with Anil that the spark-connector is woefully behind.  The spark 
community is moving fast and the connector is based on a 2yo release.  That 
code hasn’t seen much activity outside of rebranding.  If we split it out into 
a different repo it just moves the problem—is anyone volunteering to not only 
fix the issues but advance the code base?

I vote for putting it on a feature branch and removing it from /develop.

Anthony

> On May 24, 2017, at 5:45 PM, Anilkumar Gingade  wrote:
> 
> The spark has come a long way after 1.3...The connector needs to be
> upgraded to be meaningful
> +1 for A
> The existing code could be used as a reference in the future...
> 
> -Anil.
> 
> 
> On Wed, May 24, 2017 at 5:17 PM, Dan Smith  wrote:
> 
>> Our geode-spark-connector needs some work. It's currently building against
>> geode 1.0.0-incubating, because it has it's own separate build process.
>> It's also somewhat out of date, we're building against spark 1.3. Is anyone
>> actually using the spark connector?
>> 
>> I think we need to get the spark connector out of the main geode repo since
>> people are currently modifying code in the connector without even compiling
>> it, since it's not linked into the gradle build.
>> 
>> What do the geode devs think we should do with the geode-spark-connector?
>> 
>> A) Move it into it's own repository, with it's own release cycle
>> B) Delete it
>> C) Other??
>> 
>> -Dan
>> 

Re: What to do with Singletons

[Anthony Baker]

> On May 25, 2017, at 7:55 AM, Udo Kohlmeyer  wrote:
> 
> @Kirk, I think your approach to reduce the number of singleton access is 
> good. I agree and believe that any operational invocation (Function,Command, 
> DistributionMessage,etc...) should provide a mechanism to be able to access 
> all relevant all contextual information required to execute the task 
> (Function,Command, DistributionMessage,etc...)
> 

How far can we go down the path of cleaning up Singletons without having a DI 
framework in the mix?

Anthony

Re: What to do with the geode-spark-connector

[Udo Kohlmeyer]

+1 to moving it from develop to it's own repo and gradle build. The 
spark-connector is another quintessential project that should be treated 
as an external module to geode.



On 5/25/17 07:58, Anthony Baker wrote:

I agree with Anil that the spark-connector is woefully behind.  The spark 
community is moving fast and the connector is based on a 2yo release.  That 
code hasn’t seen much activity outside of rebranding.  If we split it out into 
a different repo it just moves the problem—is anyone volunteering to not only 
fix the issues but advance the code base?

I vote for putting it on a feature branch and removing it from /develop.

Anthony


On May 24, 2017, at 5:45 PM, Anilkumar Gingade  wrote:

The spark has come a long way after 1.3...The connector needs to be
upgraded to be meaningful
+1 for A
The existing code could be used as a reference in the future...

-Anil.


On Wed, May 24, 2017 at 5:17 PM, Dan Smith  wrote:


Our geode-spark-connector needs some work. It's currently building against
geode 1.0.0-incubating, because it has it's own separate build process.
It's also somewhat out of date, we're building against spark 1.3. Is anyone
actually using the spark connector?

I think we need to get the spark connector out of the main geode repo since
people are currently modifying code in the connector without even compiling
it, since it's not linked into the gradle build.

What do the geode devs think we should do with the geode-spark-connector?

A) Move it into it's own repository, with it's own release cycle
B) Delete it
C) Other??

-Dan

Re: What to do with the geode-spark-connector

[Michael William Dodge]

+1 for A

> On 24 May, 2017, at 21:30, Jared Stewart  wrote:
> 
> +1 for A
> 
> On May 24, 2017 6:48 PM, "Kirk Lund"  wrote:
> 
>> +1 for A
>> 
>> On Wed, May 24, 2017 at 5:50 PM, Jianxia Chen  wrote:
>> 
>>> I prefer option A: Move it into it's own repository, with it's own
>> release
>>> cycle.
>>> 
>>> On Wed, May 24, 2017 at 5:17 PM, Dan Smith  wrote:
>>> 
 Our geode-spark-connector needs some work. It's currently building
>>> against
 geode 1.0.0-incubating, because it has it's own separate build process.
 It's also somewhat out of date, we're building against spark 1.3. Is
>>> anyone
 actually using the spark connector?
 
 I think we need to get the spark connector out of the main geode repo
>>> since
 people are currently modifying code in the connector without even
>>> compiling
 it, since it's not linked into the gradle build.
 
 What do the geode devs think we should do with the
>> geode-spark-connector?
 
 A) Move it into it's own repository, with it's own release cycle
 B) Delete it
 C) Other??
 
 -Dan
 
>>> 
>> 

Re: Review Request 59562: GEODE-2941 Pulse documentation is outdated

[Joey McAllister]

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


Ship it!




Ship It!

- Joey McAllister


On May 25, 2017, 12:45 a.m., Dave Barnes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59562/
> ---
> 
> (Updated May 25, 2017, 12:45 a.m.)
> 
> 
> Review request for geode, Jinmei Liao and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2941 Pulse documentation is outdated
> 
> 
> Diffs
> -
> 
>   geode-book/master_middleman/source/subnavs/geode-subnav.erb 
> c97e5ec3ee961c500d0f006f9cb04ec5d569224d 
>   geode-docs/configuring/cluster_config/gfsh_persist.html.md.erb 
> 45f73f9f3ffbb569c554f2c89ad86713af1695e6 
>   geode-docs/getting_started/15_minute_quickstart_gfsh.html.md.erb 
> 894b9985a24ff9e0775b2fc755ee0b6d1ba15984 
>   geode-docs/managing/management/jmx_manager_node.html.md.erb 
> 97ca066ca581689c87da5fe1d93e38ff4d13f64d 
>   geode-docs/managing/management/management_system_overview.html.md.erb 
> ecf69f5fb104850a54a57eaf69ce6f6a7d78e3bb 
>   geode-docs/managing/management/mm_overview.html.md.erb 
> 89a8df5c2957f23d9cdacffc8a6062ed40cccb47 
>   geode-docs/tools_modules/book_intro.html.md.erb 
> e7390c5d00f6ade80fe3fd01ad9e729bbdd75f11 
>   geode-docs/tools_modules/gfsh/command-pages/start.html.md.erb 
> e2a4edccddb7fa63b060002c243d955a7182ed7d 
>   geode-docs/tools_modules/lucene_integration.html.md.erb 
> e97ce061838228d46568fb80b5799cc361f74148 
>   geode-docs/tools_modules/pulse/chapter_overview.html.md.erb 
> 19de8f1d28f84402d46cb4efdf71bedb720f14a1 
>   geode-docs/tools_modules/pulse/pulse-auth.html.md.erb PRE-CREATION 
>   geode-docs/tools_modules/pulse/pulse-embedded.html.md.erb PRE-CREATION 
>   geode-docs/tools_modules/pulse/pulse-hosted.html.md.erb PRE-CREATION 
>   geode-docs/tools_modules/pulse/pulse-views.html.md.erb PRE-CREATION 
>   geode-docs/tools_modules/pulse/quickstart.html.md.erb 
> 6bcf1dc1d7c3b23c5d70a6c542103faf3970152e 
>   geode-docs/tools_modules/pulse/system_requirements.html.md.erb 
> 05dffe65a1ea67d66040c5ac1f3cde3788a5e10d 
>   geode-docs/tools_modules/redis_adapter.html.md.erb 
> 47da3fcf211e41a374da58f369ac20e346002bb6 
> 
> 
> Diff: https://reviews.apache.org/r/59562/diff/1/
> 
> 
> Testing
> ---
> 
> Compiled user guide (with bookbinder) - no broken links. Selected sections 
> reviewed by developers while in draft form.
> 
> 
> Thanks,
> 
> Dave Barnes
> 
>

Re: What to do with the geode-spark-connector

[Bruce Schuchardt]

+1

On Thu, May 25, 2017 at 8:15 AM, Udo Kohlmeyer  wrote:

> +1 to moving it from develop to it's own repo and gradle build. The
> spark-connector is another quintessential project that should be treated as
> an external module to geode.
>
>
> On 5/25/17 07:58, Anthony Baker wrote:
>
>> I agree with Anil that the spark-connector is woefully behind.  The spark
>> community is moving fast and the connector is based on a 2yo release.  That
>> code hasn’t seen much activity outside of rebranding.  If we split it out
>> into a different repo it just moves the problem—is anyone volunteering to
>> not only fix the issues but advance the code base?
>>
>> I vote for putting it on a feature branch and removing it from /develop.
>>
>> Anthony
>>
>> On May 24, 2017, at 5:45 PM, Anilkumar Gingade 
>>> wrote:
>>>
>>> The spark has come a long way after 1.3...The connector needs to be
>>> upgraded to be meaningful
>>> +1 for A
>>> The existing code could be used as a reference in the future...
>>>
>>> -Anil.
>>>
>>>
>>> On Wed, May 24, 2017 at 5:17 PM, Dan Smith  wrote:
>>>
>>> Our geode-spark-connector needs some work. It's currently building
 against
 geode 1.0.0-incubating, because it has it's own separate build process.
 It's also somewhat out of date, we're building against spark 1.3. Is
 anyone
 actually using the spark connector?

 I think we need to get the spark connector out of the main geode repo
 since
 people are currently modifying code in the connector without even
 compiling
 it, since it's not linked into the gradle build.

 What do the geode devs think we should do with the
 geode-spark-connector?

 A) Move it into it's own repository, with it's own release cycle
 B) Delete it
 C) Other??

 -Dan


>

Re: What to do with the geode-spark-connector

[Ernest Burghardt]

+1 on A

On Thu, May 25, 2017 at 8:21 AM, Michael William Dodge 
wrote:

> +1 for A
>
> > On 24 May, 2017, at 21:30, Jared Stewart  wrote:
> >
> > +1 for A
> >
> > On May 24, 2017 6:48 PM, "Kirk Lund"  wrote:
> >
> >> +1 for A
> >>
> >> On Wed, May 24, 2017 at 5:50 PM, Jianxia Chen  wrote:
> >>
> >>> I prefer option A: Move it into it's own repository, with it's own
> >> release
> >>> cycle.
> >>>
> >>> On Wed, May 24, 2017 at 5:17 PM, Dan Smith  wrote:
> >>>
>  Our geode-spark-connector needs some work. It's currently building
> >>> against
>  geode 1.0.0-incubating, because it has it's own separate build
> process.
>  It's also somewhat out of date, we're building against spark 1.3. Is
> >>> anyone
>  actually using the spark connector?
> 
>  I think we need to get the spark connector out of the main geode repo
> >>> since
>  people are currently modifying code in the connector without even
> >>> compiling
>  it, since it's not linked into the gradle build.
> 
>  What do the geode devs think we should do with the
> >> geode-spark-connector?
> 
>  A) Move it into it's own repository, with it's own release cycle
>  B) Delete it
>  C) Other??
> 
>  -Dan
> 
> >>>
> >>
>
>

Re: What to do with the geode-spark-connector

[Mark Bretl]

I have similar thoughts as Anthony on this issue. No matter if it is a
separate repo or branch I think it will be left behind.

I think the bigger question is does this community want to continue to
support the connector?

--Mark


On Thu, May 25, 2017 at 8:34 AM Ernest Burghardt 
wrote:

> +1 on A
>
> On Thu, May 25, 2017 at 8:21 AM, Michael William Dodge 
> wrote:
>
> > +1 for A
> >
> > > On 24 May, 2017, at 21:30, Jared Stewart  wrote:
> > >
> > > +1 for A
> > >
> > > On May 24, 2017 6:48 PM, "Kirk Lund"  wrote:
> > >
> > >> +1 for A
> > >>
> > >> On Wed, May 24, 2017 at 5:50 PM, Jianxia Chen 
> wrote:
> > >>
> > >>> I prefer option A: Move it into it's own repository, with it's own
> > >> release
> > >>> cycle.
> > >>>
> > >>> On Wed, May 24, 2017 at 5:17 PM, Dan Smith 
> wrote:
> > >>>
> >  Our geode-spark-connector needs some work. It's currently building
> > >>> against
> >  geode 1.0.0-incubating, because it has it's own separate build
> > process.
> >  It's also somewhat out of date, we're building against spark 1.3. Is
> > >>> anyone
> >  actually using the spark connector?
> > 
> >  I think we need to get the spark connector out of the main geode
> repo
> > >>> since
> >  people are currently modifying code in the connector without even
> > >>> compiling
> >  it, since it's not linked into the gradle build.
> > 
> >  What do the geode devs think we should do with the
> > >> geode-spark-connector?
> > 
> >  A) Move it into it's own repository, with it's own release cycle
> >  B) Delete it
> >  C) Other??
> > 
> >  -Dan
> > 
> > >>>
> > >>
> >
> >
>

Re: Review Request 59542: GEODE-2974: rename ResultBuilder methods: GemFire -> Geode

[Patrick Rhomberg]

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


Ship it!




Ship It!

- Patrick Rhomberg


On May 24, 2017, 10:20 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59542/
> ---
> 
> (Updated May 24, 2017, 10:20 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Change GemFire to Geode in method names and message string
> 
> This is change to simply correct the Gfsh command error strings where 
> "GemFire" appears. With additional work on Gfsh command error handling 
> pending (see GEODE-2984), no attempt has been made within the scope of this 
> issue to reorganize or otherwise improve Gfsh command error messages.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ClientCommands.java
>  18940fc0c6c0f36a7dd5cab5723d426d80df3cb9 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  6d3f50ff2bcdf9d0450dd40a8defb83c2f2f6e04 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  b8ebc4917d88ce089ec2a19d606e004c1e5c6b33 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  a38e54504e949905f222d9891f624e373219364b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  4018beb8dfbd4bb639aec559991452226f15c908 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  4232d91edc9a74db144d49542d79f7cfd9f4a98b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DurableClientCommands.java
>  bcbfcf0ca72876dbfb3d41613159aa051726870e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  ea101826493bfbc9211b4c673c596d7514a7f431 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  b824bc915d453defe1c665eb7811a782f2c72fdf 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptor.java
>  5f2184889d28f441eb639d7ddf4ec2b7abfa293b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  2007e4af516274ac815cc3b06b9928f1aaed313f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  a4ba64c608f184fb130eb5ca3a05822f6cf82818 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  74acfd6e03613ac4d0c62fcdd4ea859d1c74d2f2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MemberCommands.java
>  415dd691cc6ed14bc67626881eecf65d5e446c99 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
>  0d714f4c295e2aded0c0fd28bbf4f72ffcdd14a7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  0ce8ec272eee9f07a05aa0ac478e136163ee41e6 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  6208adb63cc29f213c035849c78c3809f61b3f16 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/RegionCommands.java
>  561d4b8514c5b4500bf870e0b9d0ef3bcdbaf40d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
>  ad344ff598db5474846d1b6b334d377e01c5fbd7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  feeb3533e84fafbf22e5f9283690fe2ef0edf27e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DataCommandResult.java
>  fe88fc98d397fa748f8f54b900b1511eb114c0b6 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/ResultBuilder.java
>  6332540aa4ff6d210ed7f3ba167057de9a0a5023 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
>  2b39bedd1bcceef50e3f4933e17581048142a29b 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  5e17f6e55e6726f22cc39ddaba1ec608ca5cab9d 
> 
> 
> Diff: https://reviews.apache.org/r/59542/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin is runn

Re: Geode Nightly build is consistently RED

[Anthony Baker]

This is topic is very relevant given that we are working towards a 1.2.0 
release.  In order to release we need—at the very minimum--a clean pass through 
distributedTest.

Recently we’ve had some instability that has contributed to failing tests.  

Anthony

> On May 24, 2017, at 4:54 PM, Kirk Lund  wrote:
> 
> If other people are ignoring the results of the flakyTest target and that's
> the reason that people do not want to add FlakyTest category to tests that
> aren't currently marked with FlakyTest then here's my proposal... we delete
> FlakyTest category (well actually just rename it) and replace it with
> TestsThatFailMoreFrequentlyAndNeedToRunInFreshJVM category and we educate
> all geode developers to NOT ignore the results. If the test keeps failing
> when run in isolation under
> "TestsThatFailMoreFrequentlyAndNeedToRunInFreshJVM" then that means it
> needs to be fixed asap and not ignored. Thoughts?
> 
> On Wed, May 24, 2017 at 4:50 PM, Kirk Lund  wrote:
> 
>> Geode Nightly build is staying consistently RED... each night the tests
>> that fail vary some. Do we still want to not add FlakyTest category to
>> these tests and just live with a RED nightly build?
>> 
>> What do you all want to do? Any ideas what to do to get it consistently
>> GREEN?
>> 
>> The only way I know to get it GREEN is either a) we drop everything we're
>> working on and fix flaky tests or b) we add FlakyTest category to flaky
>> tests. The flakyTest target still runs the FlakyTest tests but it does so
>> with a fresh JVM. In my opinion we should NOT ignore the results of
>> flakyTest (and I personally do not ignore these results). I think it's a
>> useful way to run DUnit tests that have special needs.
>> 

Re: What to do with the geode-spark-connector

[John Blum]

Perhaps the bigger question is, is anyone even using the connector?  No
sense in supporting something that isn't used by anyone when those efforts
could be utilized elsewhere (e.g. Redis Protocol Adapter/Data Structures).

On Thu, May 25, 2017 at 8:52 AM, Mark Bretl  wrote:

> I have similar thoughts as Anthony on this issue. No matter if it is a
> separate repo or branch I think it will be left behind.
>
> I think the bigger question is does this community want to continue to
> support the connector?
>
> --Mark
>
>
> On Thu, May 25, 2017 at 8:34 AM Ernest Burghardt 
> wrote:
>
> > +1 on A
> >
> > On Thu, May 25, 2017 at 8:21 AM, Michael William Dodge <
> mdo...@pivotal.io>
> > wrote:
> >
> > > +1 for A
> > >
> > > > On 24 May, 2017, at 21:30, Jared Stewart 
> wrote:
> > > >
> > > > +1 for A
> > > >
> > > > On May 24, 2017 6:48 PM, "Kirk Lund"  wrote:
> > > >
> > > >> +1 for A
> > > >>
> > > >> On Wed, May 24, 2017 at 5:50 PM, Jianxia Chen 
> > wrote:
> > > >>
> > > >>> I prefer option A: Move it into it's own repository, with it's own
> > > >> release
> > > >>> cycle.
> > > >>>
> > > >>> On Wed, May 24, 2017 at 5:17 PM, Dan Smith 
> > wrote:
> > > >>>
> > >  Our geode-spark-connector needs some work. It's currently building
> > > >>> against
> > >  geode 1.0.0-incubating, because it has it's own separate build
> > > process.
> > >  It's also somewhat out of date, we're building against spark 1.3.
> Is
> > > >>> anyone
> > >  actually using the spark connector?
> > > 
> > >  I think we need to get the spark connector out of the main geode
> > repo
> > > >>> since
> > >  people are currently modifying code in the connector without even
> > > >>> compiling
> > >  it, since it's not linked into the gradle build.
> > > 
> > >  What do the geode devs think we should do with the
> > > >> geode-spark-connector?
> > > 
> > >  A) Move it into it's own repository, with it's own release cycle
> > >  B) Delete it
> > >  C) Other??
> > > 
> > >  -Dan
> > > 
> > > >>>
> > > >>
> > >
> > >
> >
>



-- 
-John
john.blum10101 (skype)

Re: What to do with Singletons

[William Markito Oliveira]

+1 for Geode functions as well.

Back on the day, I've talked with Barry about it and we got a few basic
ones into this repository.

https://github.com/markito/geode-functions

But we should probably create another thread to talk about it to keep this
one focused on the singletons discussion.

On Thu, May 25, 2017 at 8:45 AM, Wes Williams  wrote:

> +1 to utility functions
>
> *Wes Williams | Pivotal Advisory **Data Engineer*
> 781.606.0325
> http://pivotal.io/big-data/pivotal-gemfire
>
> On Wed, May 24, 2017 at 4:59 PM, John Blum  wrote:
>
> > On a side but related note, it would be nice if Geode had the notion of
> > useful, "canned" Functions provided OOTB.  Some of the *Gfsh* functions
> > would be quite useful for applications in fact, or particularly for
> > framework/tools to use as well.  Sometime ago I sent a list of Functions
> I
> > thought would be nice to have.
> >
> > Food for thought.
> >
> > On Wed, May 24, 2017 at 1:41 PM, Kirk Lund  wrote:
> >
> > > Thanks for pointing out that DistributionManager is internal -- I
> forgot
> > > about that. I'm primarily concerned with internal Functions, such as
> > those
> > > for GFSH commands, so maybe an internal version of FunctionContext
> which
> > > exposes more would be good for those.
> > >
> > > On Wed, May 24, 2017 at 11:39 AM, Darrel Schneider <
> > dschnei...@pivotal.io>
> > > wrote:
> > >
> > > > FunctionContext is an external interface so it can not expose
> internal
> > > > interfaces like DistributionManager.
> > > > But it could expose Cache. DistributedSystem is external so you could
> > > have
> > > > it exposed from FunctionContext but it is already exposed from Cache.
> > > > SecurityService is also internal.
> > > > Are you thinking that for internal Functions you would cast
> > > FunctionContext
> > > > to an internal that would then expose these internal classes?
> > > >
> > > >
> > > >
> > > > On Thu, May 18, 2017 at 5:13 PM, Kirk Lund  wrote:
> > > >
> > > > > I've been digging through our code with close attention to the
> > > > singletons.
> > > > > I believe the majority of singletons in Geode exist for two main
> > > reasons:
> > > > >
> > > > > 1) Insufficient context or lack of service lookup for Function,
> > > > > DistributionMessage and (Client)Command implementations.
> > > > >
> > > > > 2) Poor OO design. This is where you see code in one class invoking
> > > > > concrete methods on another class outside of its concerns. Many of
> > > these
> > > > > need to be teased apart and replaced with some sort of Observer
> that
> > > > > isolates the reaction from the source of the originating event.
> > > > >
> > > > > Right now my focus is on #1 because that's the area that's
> currently
> > an
> > > > > obstacle for me.
> > > > >
> > > > > Function, DistributionMessage and (Client)Command classes need to
> > have
> > > > more
> > > > > context provided to them (Cache, Security, etc) or they need a
> better
> > > > > mechanism to look up these services. Currently these classes reach
> > out
> > > to
> > > > > singletons in order to "get" what they need.
> > > > >
> > > > > *A) Function*
> > > > >
> > > > > The main entry-point which injects services into the Function is:
> > > > >
> > > > > public void execute(FunctionContext context);
> > > > >
> > > > > The FunctionContext needs to provide the service(s) that any
> Function
> > > > might
> > > > > require. This could include Cache, DistributionManager and maybe
> > > > > SecurityService (anything else?).
> > > > >
> > > > > *B) (Peer-to-peer) DistributionMessage*
> > > > >
> > > > > The main entry-point which injects services into the
> > > DistributionMessage
> > > > > is:
> > > > >
> > > > > protected abstract void process(DistributionManager dm);
> > > > >
> > > > > We could provide multiple arguments or a single new
> > DistributionContext
> > > > > which then provides DistributionManager and Cache (anything else?).
> > > > >
> > > > > *C) (Client) Command*
> > > > >
> > > > > The main entry-point which injects services into the Command is:
> > > > >
> > > > > public void execute(Message msg, ServerConnection servConn);
> > > > >
> > > > > ServerConnection is huge but it does already expose Cache.
> > BaseCommand
> > > is
> > > > > the only Command that implements "execute" and it defines a new
> > > > entry-point
> > > > > for injection:
> > > > >
> > > > > abstract public void cmdExecute(Message msg, ServerConnection
> > servConn,
> > > > > long start) throws IOException, ClassNotFoundException,
> > > > > InterruptedException;
> > > > >
> > > > > We might want to clean that up and define a new CommandContext
> which
> > > > > provides the Cache or anything else that the Command may need.
> > > > >
> > > > > Thoughts or additional ideas?
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>



-- 
~/William

Re: What to do with the geode-spark-connector

[Lynn Hughes-Godfrey]

I agree with Mark and Anthony ...
+1 to deleting this altogether.

On Thu, May 25, 2017 at 9:12 AM, John Blum  wrote:

> Perhaps the bigger question is, is anyone even using the connector?  No
> sense in supporting something that isn't used by anyone when those efforts
> could be utilized elsewhere (e.g. Redis Protocol Adapter/Data Structures).
>
> On Thu, May 25, 2017 at 8:52 AM, Mark Bretl  wrote:
>
> > I have similar thoughts as Anthony on this issue. No matter if it is a
> > separate repo or branch I think it will be left behind.
> >
> > I think the bigger question is does this community want to continue to
> > support the connector?
> >
> > --Mark
> >
> >
> > On Thu, May 25, 2017 at 8:34 AM Ernest Burghardt 
> > wrote:
> >
> > > +1 on A
> > >
> > > On Thu, May 25, 2017 at 8:21 AM, Michael William Dodge <
> > mdo...@pivotal.io>
> > > wrote:
> > >
> > > > +1 for A
> > > >
> > > > > On 24 May, 2017, at 21:30, Jared Stewart 
> > wrote:
> > > > >
> > > > > +1 for A
> > > > >
> > > > > On May 24, 2017 6:48 PM, "Kirk Lund"  wrote:
> > > > >
> > > > >> +1 for A
> > > > >>
> > > > >> On Wed, May 24, 2017 at 5:50 PM, Jianxia Chen 
> > > wrote:
> > > > >>
> > > > >>> I prefer option A: Move it into it's own repository, with it's
> own
> > > > >> release
> > > > >>> cycle.
> > > > >>>
> > > > >>> On Wed, May 24, 2017 at 5:17 PM, Dan Smith 
> > > wrote:
> > > > >>>
> > > >  Our geode-spark-connector needs some work. It's currently
> building
> > > > >>> against
> > > >  geode 1.0.0-incubating, because it has it's own separate build
> > > > process.
> > > >  It's also somewhat out of date, we're building against spark
> 1.3.
> > Is
> > > > >>> anyone
> > > >  actually using the spark connector?
> > > > 
> > > >  I think we need to get the spark connector out of the main geode
> > > repo
> > > > >>> since
> > > >  people are currently modifying code in the connector without
> even
> > > > >>> compiling
> > > >  it, since it's not linked into the gradle build.
> > > > 
> > > >  What do the geode devs think we should do with the
> > > > >> geode-spark-connector?
> > > > 
> > > >  A) Move it into it's own repository, with it's own release cycle
> > > >  B) Delete it
> > > >  C) Other??
> > > > 
> > > >  -Dan
> > > > 
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

[GitHub] geode pull request #536: GEODE-2977: make group/name option values consisten...

[YehEmily]

GitHub user YehEmily opened a pull request:

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

GEODE-2977: make group/name option values consistent

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/YehEmily/geode groupname

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

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


commit 01c5119654f27a254f8fb334b9fe8a2d5c4039ac
Author: YehEmily 
Date:   2017-05-23T19:27:40Z

GEODE-2977: make group/name option values consistent




---
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-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF GitHub Bot (JIRA)]

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

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

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/536
  
Precheckin was successful!


> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



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

[jira] [Commented] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF GitHub Bot (JIRA)]

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

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

GitHub user YehEmily opened a pull request:

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

GEODE-2977: make group/name option values consistent

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/YehEmily/geode groupname

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

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


commit 01c5119654f27a254f8fb334b9fe8a2d5c4039ac
Author: YehEmily 
Date:   2017-05-23T19:27:40Z

GEODE-2977: make group/name option values consistent




> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



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

[GitHub] geode issue #536: GEODE-2977: make group/name option values consistent

[YehEmily]

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/536
  
Precheckin was successful!


---
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-2913) Update Lucene documentation

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-2913.

Resolution: Fixed

> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction 
> configured with local destroy. If using Lucene indexing, eviction can only be 
> configured with overflow to disk. In this case, only the region data is 
> overflowed to disk, *NOT* the Lucene index. An UnsupportedOperationException 
> is thrown:
> {quote}
> [error 2017/05/02 16:12:32.461 PDT  tid=0x1] 
> java.lang.UnsupportedOperationEx

Re: Review Request 59505: GEODE-2964: add common-collections to gfsh dependencies

[Patrick Rhomberg]

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


Ship it!




Ship It!

- Patrick Rhomberg


On May 23, 2017, 10:11 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59505/
> ---
> 
> (Updated May 23, 2017, 10:11 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2964: add common-collections to gfsh dependencies
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle a4f0c69ee39342d9a3350d8e3a32cd65b560c75a 
> 
> 
> Diff: https://reviews.apache.org/r/59505/diff/1/
> 
> 
> Testing
> ---
> 
> gfsh manual tests
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Closed] (GEODE-2954) Old client gets null memberID in cache listener

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt closed GEODE-2954.
---

> Old client gets null memberID in cache listener
> ---
>
> Key: GEODE-2954
> URL: https://issues.apache.org/jira/browse/GEODE-2954
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> I was doing backward compatibility testing and found a 1.0 client was getting 
> a null memberID in a cache listener
> {noformat}
> [info 2017/05/18 16:27:38.957 PDT  trout(bridgegemfire5_trout_2254:2254):1030 port 21051> tid=0x2f] 
> Invoked util.SilenceListener for key Object_7399: afterDestroy in edge1, pid 
> 2267, vmID 5, operation DESTROY
>  whereIWasRegistered: 2267
>  event.getKey(): Object_7399
>  event.getOldValue():  (contains 6 levels, aPrimitiveLong=6409636308677575978)>
>  event.getNewValue(): null
>  event.getOperation().isLoad(): false
>  event.getOperation().isLocalLoad(): false
>  event.getOperation().isNetLoad(): false
>  event.getOperation().isNetSearch(): false
>  event.isConcurrencyConflict(): false
>  event.getDistributedMember(): null
>  event.getCallbackArgument(): null
>  event.getRegion(): /testRegion
>  event.getOperation().isDistributed(): true
>  event.getOperation().isExpiration(): false
>  event.isOriginRemote(): true
> {noformat}
> This was in an old test suite whose testing infrastructure isn't in the Geode 
> repo.  I'm writing a unit test to reproduce the problem.
> If you look at EventID.java you can see that it catches IOExceptions in 
> deserializing the memberID of the event and returns null without logging the 
> problem.
> {code}
> try {
>   result = InternalDistributedMember.readEssentialData(dis);
> } catch (IOException e) {
>   // nothing can be done about this
> } catch (ClassNotFoundException e) {
>   // ditto
> }
> {code}



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

[jira] [Resolved] (GEODE-2954) Old client gets null memberID in cache listener

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-2954.
-
Resolution: Fixed

> Old client gets null memberID in cache listener
> ---
>
> Key: GEODE-2954
> URL: https://issues.apache.org/jira/browse/GEODE-2954
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.2.0
>
>
> I was doing backward compatibility testing and found a 1.0 client was getting 
> a null memberID in a cache listener
> {noformat}
> [info 2017/05/18 16:27:38.957 PDT  trout(bridgegemfire5_trout_2254:2254):1030 port 21051> tid=0x2f] 
> Invoked util.SilenceListener for key Object_7399: afterDestroy in edge1, pid 
> 2267, vmID 5, operation DESTROY
>  whereIWasRegistered: 2267
>  event.getKey(): Object_7399
>  event.getOldValue():  (contains 6 levels, aPrimitiveLong=6409636308677575978)>
>  event.getNewValue(): null
>  event.getOperation().isLoad(): false
>  event.getOperation().isLocalLoad(): false
>  event.getOperation().isNetLoad(): false
>  event.getOperation().isNetSearch(): false
>  event.isConcurrencyConflict(): false
>  event.getDistributedMember(): null
>  event.getCallbackArgument(): null
>  event.getRegion(): /testRegion
>  event.getOperation().isDistributed(): true
>  event.getOperation().isExpiration(): false
>  event.isOriginRemote(): true
> {noformat}
> This was in an old test suite whose testing infrastructure isn't in the Geode 
> repo.  I'm writing a unit test to reproduce the problem.
> If you look at EventID.java you can see that it catches IOExceptions in 
> deserializing the memberID of the event and returns null without logging the 
> problem.
> {code}
> try {
>   result = InternalDistributedMember.readEssentialData(dis);
> } catch (IOException e) {
>   // nothing can be done about this
> } catch (ClassNotFoundException e) {
>   // ditto
> }
> {code}



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

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Hitesh Khamesra]

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

(Updated May 25, 2017, 5:12 p.m.)


Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo Kohlmeyer.


Repository: geode


Description (updated)
---

We configure locator list to start the cache. This locator list is validated 
while creating the cache. We verify whether locator host exist or not. Now we 
have remove this verification as in cloud environment host may not available 
for time being. 

Patch from Bruce. Modified couple of tests.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
 c1bfc93 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 01c6157 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 7caad3f 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
 5ab1bed 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
 1dc2fd1 
  
geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
 dc73f04 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 9f6c5fb 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d 
  
geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
 d6d5d7c 


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


Testing
---


Thanks,

Hitesh Khamesra

Re: Geode Nightly build is consistently RED

[Udo Kohlmeyer]

@Kirk, I share your concern. If the builds are RED then we should 
address them. Ideally there should be no flaky tests, but given the 
hyper-threaded nature of the beast, things can go wrong that are really 
hard to reproduce. Arguably, even those scenarios should be addressed, 
but if we wait for the perfect alignment of the planets to have a 
complete green run, then we would never release.


That said. I've accepted, that a clean run of all categories, other than 
flaky, to mean we had a "good" run. It would be awesome to collect some 
metrics (counts,etc.. ), on a weekly,monthly basis, about failing test 
(per category).


This way, we could hopefully identify "burning" failing tests, that need 
to be addressed with urgency.


--Udo


On 5/25/17 09:00, Anthony Baker wrote:

This is topic is very relevant given that we are working towards a 1.2.0 
release.  In order to release we need—at the very minimum--a clean pass through 
distributedTest.

Recently we’ve had some instability that has contributed to failing tests.

Anthony


On May 24, 2017, at 4:54 PM, Kirk Lund  wrote:

If other people are ignoring the results of the flakyTest target and that's
the reason that people do not want to add FlakyTest category to tests that
aren't currently marked with FlakyTest then here's my proposal... we delete
FlakyTest category (well actually just rename it) and replace it with
TestsThatFailMoreFrequentlyAndNeedToRunInFreshJVM category and we educate
all geode developers to NOT ignore the results. If the test keeps failing
when run in isolation under
"TestsThatFailMoreFrequentlyAndNeedToRunInFreshJVM" then that means it
needs to be fixed asap and not ignored. Thoughts?

On Wed, May 24, 2017 at 4:50 PM, Kirk Lund  wrote:


Geode Nightly build is staying consistently RED... each night the tests
that fail vary some. Do we still want to not add FlakyTest category to
these tests and just live with a RED nightly build?

What do you all want to do? Any ideas what to do to get it consistently
GREEN?

The only way I know to get it GREEN is either a) we drop everything we're
working on and fix flaky tests or b) we add FlakyTest category to flaky
tests. The flakyTest target still runs the FlakyTest tests but it does so
with a fresh JVM. In my opinion we should NOT ignore the results of
flakyTest (and I personally do not ignore these results). I think it's a
useful way to run DUnit tests that have special needs.

Re: What to do with Singletons

[Udo Kohlmeyer]

+1 to moving the "OOTB" discussion onto another thread. Very 
distracting, interjecting another topic, into a completely not related 
email thread.


MAYBE, there could be a list of ootb functions that the community would 
like to support/write. This should be done on the Apache Geode Wiki.



On 5/25/17 09:19, William Markito Oliveira wrote:

+1 for Geode functions as well.

Back on the day, I've talked with Barry about it and we got a few basic
ones into this repository.

https://github.com/markito/geode-functions

But we should probably create another thread to talk about it to keep this
one focused on the singletons discussion.

On Thu, May 25, 2017 at 8:45 AM, Wes Williams  wrote:


+1 to utility functions

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

On Wed, May 24, 2017 at 4:59 PM, John Blum  wrote:


On a side but related note, it would be nice if Geode had the notion of
useful, "canned" Functions provided OOTB.  Some of the *Gfsh* functions
would be quite useful for applications in fact, or particularly for
framework/tools to use as well.  Sometime ago I sent a list of Functions

I

thought would be nice to have.

Food for thought.

On Wed, May 24, 2017 at 1:41 PM, Kirk Lund  wrote:


Thanks for pointing out that DistributionManager is internal -- I

forgot

about that. I'm primarily concerned with internal Functions, such as

those

for GFSH commands, so maybe an internal version of FunctionContext

which

exposes more would be good for those.

On Wed, May 24, 2017 at 11:39 AM, Darrel Schneider <

dschnei...@pivotal.io>

wrote:


FunctionContext is an external interface so it can not expose

internal

interfaces like DistributionManager.
But it could expose Cache. DistributedSystem is external so you could

have

it exposed from FunctionContext but it is already exposed from Cache.
SecurityService is also internal.
Are you thinking that for internal Functions you would cast

FunctionContext

to an internal that would then expose these internal classes?



On Thu, May 18, 2017 at 5:13 PM, Kirk Lund  wrote:


I've been digging through our code with close attention to the

singletons.

I believe the majority of singletons in Geode exist for two main

reasons:

1) Insufficient context or lack of service lookup for Function,
DistributionMessage and (Client)Command implementations.

2) Poor OO design. This is where you see code in one class invoking
concrete methods on another class outside of its concerns. Many of

these

need to be teased apart and replaced with some sort of Observer

that

isolates the reaction from the source of the originating event.

Right now my focus is on #1 because that's the area that's

currently

an

obstacle for me.

Function, DistributionMessage and (Client)Command classes need to

have

more

context provided to them (Cache, Security, etc) or they need a

better

mechanism to look up these services. Currently these classes reach

out

to

singletons in order to "get" what they need.

*A) Function*

The main entry-point which injects services into the Function is:

public void execute(FunctionContext context);

The FunctionContext needs to provide the service(s) that any

Function

might

require. This could include Cache, DistributionManager and maybe
SecurityService (anything else?).

*B) (Peer-to-peer) DistributionMessage*

The main entry-point which injects services into the

DistributionMessage

is:

protected abstract void process(DistributionManager dm);

We could provide multiple arguments or a single new

DistributionContext

which then provides DistributionManager and Cache (anything else?).

*C) (Client) Command*

The main entry-point which injects services into the Command is:

public void execute(Message msg, ServerConnection servConn);

ServerConnection is huge but it does already expose Cache.

BaseCommand

is

the only Command that implements "execute" and it defines a new

entry-point

for injection:

abstract public void cmdExecute(Message msg, ServerConnection

servConn,

long start) throws IOException, ClassNotFoundException,
InterruptedException;

We might want to clean that up and define a new CommandContext

which

provides the Cache or anything else that the Command may need.

Thoughts or additional ideas?




--
-John
john.blum10101 (skype)

[jira] [Resolved] (GEODE-2955) gfsh create lucene index command should validate the region name parameter

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2955.

   Resolution: Fixed
Fix Version/s: 1.2.0

> gfsh create lucene index command should validate the region name parameter
> --
>
> Key: GEODE-2955
> URL: https://issues.apache.org/jira/browse/GEODE-2955
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> The gfsh command to create the lucene index should not only validate the 
> lucene index name but also the region name.  It currently is possible to pass 
> an invalid region name as a parameter.  The region will then not be able to 
> be created.



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

Re: What to do with Singletons

[Galen M O'Sullivan]

>
> But we should probably create another thread to talk about it to keep this
> one focused on the singletons discussion.
>
+1


How far can we go down the path of cleaning up Singletons without having a
> DI framework in the mix?


We can do DI without a framework, by just passing the dependencies that a
function needs. Hopefully, this means that coders working on Geode can
think carefully about the requirements for a class or method call and by
thinking about requirements we get a better idea of our architecture and
what sections of the code can be separated.

If it gets too complicated (we start seeing a lot of places where some
inner call in the call graph requires something from further outside), we
can use a framework. I'd rather iterate in a way that's more lightweight
until we start needing something heavier.

[jira] [Created] (GEODE-2987) document finer grained security migration

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2987:
---

 Summary: document finer grained security migration
 Key: GEODE-2987
 URL: https://issues.apache.org/jira/browse/GEODE-2987
 Project: Geode
  Issue Type: Sub-task
  Components: docs
Reporter: Swapnil Bawaskar


We need to document how a user will migrate to the new finer grained security 
model from that in 1.2 release.



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

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Galen O'Sullivan]

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



Good work! I have a few minor comments and a couple of things I'm concerned 
about because I don't understand the rest of the system so well. Maybe you can 
help clarify for me.

It looks like the host will be set when we call `getHost()`. Do we want to 
expire hosts or give up looking for them? Are callers expecting an existing 
locator to be valid and connected? Will this cause delays as we iterate through 
locators that have been dropped or were never up? 

I remember there being a ticket recently to save hostnames for Cache members 
and pass the hostnames from the Locator. I'm wondering if it would make sense 
to have a shared `lazilyEvaluatedHost` class? I don't think that should hold 
this up, though.


geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
Line 196 (original), 196 (patched)


I'd rather this code be deleted than commented out.
Can you explain why we're using the hostname rather than the host?



geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
Line 1555 (original), 1555 (patched)


Will this mess with anything that depends on the canonical locator 
serialization?



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Line 131 (original), 132 (patched)


It looks like taking out this exception will cause us to behave differently 
if we can't look up the hostname. There's a lot going on here. Are we trying to 
retain the hostname for reconnects or keep trying to connect here?



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Lines 234 (patched)


`host` can be null, see line 131 of DistributionLocatorId.java.

It looks like `hostname` can't be null if we call the `String` constructor, 
but it can if we call the IP and port constructor.

I would like to unify the constructors if we can, because it looks like the 
string-only form works differently from the other form, but it's not clear what 
the constraints on `bindAddress` are in the other form.



geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
Lines 278 (patched)


What makes the new code able to throw an exception here? We could still 
specify locators by IP before, right?



geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
Lines 346 (patched)


Could this be split into two tests, one of which continues and the other of 
which triggers a failure later on?


- Galen O'Sullivan


On May 25, 2017, 5:12 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59546/
> ---
> 
> (Updated May 25, 2017, 5:12 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exist or not. Now we 
> have remove this verification as in cloud environment host may not available 
> for time being. 
> 
> Patch from Bruce. Modified couple of tests.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
>  c1bfc93 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
>  01c6157 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
>  5ab1bed 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
>  1dc2fd1 
>   
> geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
>  dc73f04 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
>  9f6c5fb 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d 
>   
> geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
>  d6d5d7c 
> 
> 
> Diff: https://reviews.apache.org/r/59546/diff/1/
> 
> 
> Te

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Galen O'Sullivan]

> On May 25, 2017, 5:51 p.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
> > Lines 346 (patched)
> > 
> >
> > Could this be split into two tests, one of which continues and the 
> > other of which triggers a failure later on?

That is, could one of the tests test what happens when we try to evaluate the 
host later? (See my question in the overall review comment about whether we 
ever give up).


- Galen


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


On May 25, 2017, 5:12 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59546/
> ---
> 
> (Updated May 25, 2017, 5:12 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exist or not. Now we 
> have remove this verification as in cloud environment host may not available 
> for time being. 
> 
> Patch from Bruce. Modified couple of tests.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
>  c1bfc93 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
>  01c6157 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
>  5ab1bed 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
>  1dc2fd1 
>   
> geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
>  dc73f04 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
>  9f6c5fb 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d 
>   
> geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
>  d6d5d7c 
> 
> 
> Diff: https://reviews.apache.org/r/59546/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

[jira] [Created] (GEODE-2988) create a security example

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2988:
---

 Summary: create a security example
 Key: GEODE-2988
 URL: https://issues.apache.org/jira/browse/GEODE-2988
 Project: Geode
  Issue Type: Sub-task
  Components: security
Reporter: Swapnil Bawaskar


create an example for demonstrating security. The example should show how to 
leverage the {{security-manager}}, register the {{AuthInitializer}} on the 
client and have recipes for various roles.



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

[jira] [Created] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2989:


 Summary: Improve mechanism for scanning the classpath to find gfsh 
commands
 Key: GEODE-2989
 URL: https://issues.apache.org/jira/browse/GEODE-2989
 Project: Geode
  Issue Type: Improvement
  Components: gfsh, management
Reporter: Jared Stewart


The current mechanism for scanning the classpath to find gfsh commands 
(ClasspathScanLoadHelper) has some deficiencies, including: 

1) Commands can only be scanned for in an exact package 
("org.apache.geode.management.internal.cli.commands").  We can't pick up 
commands from any subpackages,  prevents us from better organizing the package 
structure of our commands (e.g. 
"org.apache.geode.management.internal.cli.commands.lifecycle").

2) All classes in the target package are eagerly loaded, whether or not they 
contain commands.  

Both of these deficiencies can be removed if we replace the implementation of 
ClasspathScanLoadHelper with calls to FastClasspathScanner.



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

[jira] [Assigned] (GEODE-2989) Improve mechanism for scanning the classpath to find gfsh commands

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2989:


Assignee: Jared Stewart

> Improve mechanism for scanning the classpath to find gfsh commands
> --
>
> Key: GEODE-2989
> URL: https://issues.apache.org/jira/browse/GEODE-2989
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> The current mechanism for scanning the classpath to find gfsh commands 
> (ClasspathScanLoadHelper) has some deficiencies, including: 
> 1) Commands can only be scanned for in an exact package 
> ("org.apache.geode.management.internal.cli.commands").  We can't pick up 
> commands from any subpackages,  prevents us from better organizing the 
> package structure of our commands (e.g. 
> "org.apache.geode.management.internal.cli.commands.lifecycle").
> 2) All classes in the target package are eagerly loaded, whether or not they 
> contain commands.  
> Both of these deficiencies can be removed if we replace the implementation of 
> ClasspathScanLoadHelper with calls to FastClasspathScanner.



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

[jira] [Updated] (GEODE-2988) create a security example

[Joey McAllister (JIRA)]

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

Joey McAllister updated GEODE-2988:
---
Component/s: docs

> create a security example
> -
>
> Key: GEODE-2988
> URL: https://issues.apache.org/jira/browse/GEODE-2988
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> create an example for demonstrating security. The example should show how to 
> leverage the {{security-manager}}, register the {{AuthInitializer}} on the 
> client and have recipes for various roles.



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

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2950:


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

GEODE-2950: Adding validation checks on create lucene index parameter names

This closes #532


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



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

[jira] [Created] (GEODE-2990) fix testXmlCacheCreationWithPools

[Ernest Burghardt (JIRA)]

Ernest Burghardt created GEODE-2990:
---

 Summary: fix testXmlCacheCreationWithPools
 Key: GEODE-2990
 URL: https://issues.apache.org/jira/browse/GEODE-2990
 Project: Geode
  Issue Type: Bug
Reporter: Ernest Burghardt


Fails due to an initialization ordering issue.



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

[GitHub] geode pull request #532: GEODE-2950: Adding validation checks on create Luce...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



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

[jira] [Resolved] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2950.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



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

[jira] [Resolved] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2952.

   Resolution: Fixed
Fix Version/s: 1.2.0

> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



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

Proposal: Remove the "user-command-packages" system property

[Jared Stewart]

I would like to propose that we eliminate the “user-command-packages” system 
property, in favor of scanning the entire classpath to find commands.

To give more detail, Geode currently supports three ways to load GFSH commands: 
Scan the classpath for commands in 
"org.apache.geode.management.internal.cli.commands”
Scan the classpath for commands in a package specified by a user via the 
“user-command-packages” system property. 
Scan the classpath for commands registered in files inside META-INF.services 
(e.g. 
"geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)
 

We have some bespoke code responsible for scanning the classpath 
(ClasspathScanLoadHelper) that I am in the process of replacing with 
FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no longer 
need to eagerly load all of the classes in the target package, I don’t see any 
reason why a user should need to specify a “user-command-package” property or a 
“META-INF/services” file.  Instead, we should just scan the whole classpath and 
register any commands that we find.

Thoughts?

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Hitesh Khamesra]

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

(Updated May 25, 2017, 7:06 p.m.)


Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo Kohlmeyer.


Changes
---

Updated diff; removed commented code


Repository: geode


Description
---

We configure locator list to start the cache. This locator list is validated 
while creating the cache. We verify whether locator host exist or not. Now we 
have remove this verification as in cloud environment host may not available 
for time being. 

Patch from Bruce. Modified couple of tests.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
 c1bfc93 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
 01c6157 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 7caad3f 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
 5ab1bed 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
 1dc2fd1 
  
geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
 dc73f04 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
 9f6c5fb 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d 
  
geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
 d6d5d7c 


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

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


Testing
---


Thanks,

Hitesh Khamesra

[jira] [Reopened] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

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

David Anuta reopened GEODE-2952:


> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



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

Re: Review Request 59546: GEODE-2940 Remove verification of locator host on start

[Hitesh Khamesra]

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




geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
Line 196 (original), 196 (patched)


Removed it. here we validate hist only



geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
Line 277 (original), 281 (patched)


Removed commented code



geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
Line 1555 (original), 1555 (patched)


This is just for compare purpose.



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Line 131 (original), 132 (patched)


Yes, that's the change.Removed commented code



geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
Lines 234 (patched)


line 131; but then hostname will be there. What I am reading is that at 
this point either host/hostname will be there



geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
Lines 278 (patched)


Ip should be fine. This can throw exception when host/hostname is not 
appropriate.



geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
Lines 346 (patched)


If locator host is still not avialable then server won't be able to join 
the cluster.


- Hitesh Khamesra


On May 25, 2017, 7:06 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59546/
> ---
> 
> (Updated May 25, 2017, 7:06 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Galen O'Sullivan, and Udo 
> Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> We configure locator list to start the cache. This locator list is validated 
> while creating the cache. We verify whether locator host exist or not. Now we 
> have remove this verification as in cloud environment host may not available 
> for time being. 
> 
> Patch from Bruce. Modified couple of tests.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/DistributionLocatorImpl.java
>  c1bfc93 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/AbstractDistributionConfig.java
>  01c6157 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/DistributionLocatorId.java
>  5ab1bed 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/RemoteTransportConfig.java
>  1dc2fd1 
>   
> geode-core/src/test/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java
>  dc73f04 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/DistributionConfigJUnitTest.java
>  9f6c5fb 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d 
>   
> geode-wan/src/main/java/org/apache/geode/cache/client/internal/locator/wan/LocatorMembershipListenerImpl.java
>  d6d5d7c 
> 
> 
> Diff: https://reviews.apache.org/r/59546/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

[GitHub] geode pull request #537: GEODE-2957: Added DEFAULT as a standardAnalyzer key...

[DivineEnder]

GitHub user DivineEnder opened a pull request:

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

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier whe…

…n creating Lucene index

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2957

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

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


commit 7b0543a7325ee08fb9b91710c9b406cc41f75451
Author: David Anuta 
Date:   2017-05-25T19:03:43Z

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier when 
creating Lucene index




---
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-2957) null used as a default parameter when specifying analyzers

[ASF GitHub Bot (JIRA)]

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

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

GitHub user DivineEnder opened a pull request:

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

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier whe…

…n creating Lucene index

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2957

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

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


commit 7b0543a7325ee08fb9b91710c9b406cc41f75451
Author: David Anuta 
Date:   2017-05-25T19:03:43Z

GEODE-2957: Added DEFAULT as a standardAnalyzer keyword specifier when 
creating Lucene index




> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



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

[GitHub] geode issue #537: GEODE-2957: Added DEFAULT as a standardAnalyzer keyword sp...

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/537
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


---
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-2957) null used as a default parameter when specifying analyzers

[ASF GitHub Bot (JIRA)]

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

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

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/537
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



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

[jira] [Commented] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

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

David Anuta commented on GEODE-2952:


Turns out you can do exact query matches using double quotes, but it is 
dependent upon the quotes used when actually passing the query string to the 
GFSH shell. Below is an example exact query matching on the string "police 
dept" within a test index which contains both the exact string "police dept" 
and the string "police".

{noformat}
describe lucene index --name index --region region

Index Name | Region Path | Server Name | Indexed Fields | 
Field Analyzer  |   Status| Query Executions | Updates | 
Commits | Documents

-- | --- | --- | -- | 
--- | --- |  | 
--- | --- | -

index  | /region | s1  | [__REGION_VALUE_FIELD] | 
{__REGION_VALUE_FIELD=StandardAnalyzer} | Initialized | 0| 0
   | 0   | 0

gfsh>put --region region --key 1 --value="police dept"

Result  : true

Key Class   : java.lang.String

Key : 1

Value Class : java.lang.String

Old Value   : 





gfsh>put --region region --key 2 --value="police"

Result  : true

Key Class   : java.lang.String

Key : 2

Value Class : java.lang.String

Old Value   : 



gfsh>search lucene --name index --region region --queryStrings='"police dept"' 
--defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region --queryStrings='police dept' 
--defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

2   | police  | 0.2876821

1   | police dept | 0.51623213



gfsh>put --region region --key 3 --value="ABC"

Result  : true

Key Class   : java.lang.String

Key : 3

Value Class : java.lang.String

Old Value   : 





gfsh>search lucene --name index --region region 
--queryStrings='__REGION_VALUE_FIELD:"police dept"' --defaultField 
__REGION_VALUE_FIELD

key |value| score

--- | --- | --

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings='__REGION_VALUE_FIELD:"police dept" OR 
__REGION_VALUE_FIELD:"ABC"' --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

3   | ABC | 0.2876821

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings='__REGION_VALUE_FIELD:"police dept" OR 
__REGION_VALUE_FIELD:\'ABC\'' --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

3   | ABC | 0.2876821

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings="__REGION_VALUE_FIELD:'police dept' OR 
__REGION_VALUE_FIELD:'ABC'" --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

2   | police  | 0.2876821

3   | ABC | 0.2876821

1   | police dept | 0.51623213



gfsh>search lucene --name index --region region 
--queryStrings="__REGION_VALUE_FIELD:\"police dept\" OR 
__REGION_VALUE_FIELD:'ABC'" --defaultField __REGION_VALUE_FIELD

key |value| score

--- | --- | --

3   | ABC | 0.2876821

1   | police dept | 0.51623213

{noformat}

As you can see, the double quotations must be used within the actual query 
string parameter passed to the queryStrings flag in order to get a proper exact 
match on the query string through the API. In the example given in the 
description of this issue, the 'Police Dept' case failed to exact match because 
there were no double quotes around the Police Dept string and the '\"Police 
Dept\"' string failed because the double quotes were escaped when they did not 
need to be. The formatting for exact string matching on the string Police Dept 
right now must be either '"Police Dept"' (no escape characters are needed for 
parsing) or "\"Police Dept\"" (escape characters needed for flag parsing).

> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene 

Re: Proposal: Remove the "user-command-packages" system property

[Udo Kohlmeyer]

imo, I think that GFSH is Spring Shell, it should really only be 
commands that are registered inside of META-INF.services .. aka 
implements CommandMarker.


This way we has standard simple way to specify commands.

--Udo


On 5/25/17 11:52, Jared Stewart wrote:

I would like to propose that we eliminate the “user-command-packages” system 
property, in favor of scanning the entire classpath to find commands.

To give more detail, Geode currently supports three ways to load GFSH commands:
Scan the classpath for commands in 
"org.apache.geode.management.internal.cli.commands”
Scan the classpath for commands in a package specified by a user via the 
“user-command-packages” system property.
Scan the classpath for commands registered in files inside META-INF.services (e.g. 
"geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)

We have some bespoke code responsible for scanning the classpath 
(ClasspathScanLoadHelper) that I am in the process of replacing with 
FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no longer 
need to eagerly load all of the classes in the target package, I don’t see any 
reason why a user should need to specify a “user-command-package” property or a 
“META-INF/services” file.  Instead, we should just scan the whole classpath and 
register any commands that we find.

Thoughts?

[jira] [Resolved] (GEODE-2952) gfsh doesn't support exact match lucene queries

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2952.

Resolution: Not A Problem

> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



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

Re: Proposal: Remove the "user-command-packages" system property

[Jared Stewart]

Can you clarify - I'm proposing we use *implements CommandMarker* alone as
the way to specify commands. What do we gain be *also* requiring a
META-INF.services file?

On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:

imo, I think that GFSH is Spring Shell, it should really only be commands
that are registered inside of META-INF.services .. aka implements
CommandMarker.

This way we has standard simple way to specify commands.

--Udo



On 5/25/17 11:52, Jared Stewart wrote:

> I would like to propose that we eliminate the “user-command-packages”
> system property, in favor of scanning the entire classpath to find commands.
>
> To give more detail, Geode currently supports three ways to load GFSH
> commands:
> Scan the classpath for commands in "org.apache.geode.management.i
> nternal.cli.commands”
> Scan the classpath for commands in a package specified by a user via the
> “user-command-packages” system property.
> Scan the classpath for commands registered in files inside
> META-INF.services (e.g. "geode-core/src/test/resources
> /META-INF/services/org.springframework.shell.core.CommandMarker”)
>
> We have some bespoke code responsible for scanning the classpath
> (ClasspathScanLoadHelper) that I am in the process of replacing with
> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> longer need to eagerly load all of the classes in the target package, I
> don’t see any reason why a user should need to specify a
> “user-command-package” property or a “META-INF/services” file.  Instead, we
> should just scan the whole classpath and register any commands that we find.
>
> Thoughts?
>

Re: Proposal: Remove the "user-command-packages" system property

[Jinmei Liao]

+1 for scanning the whole classpath without eager loading.

On Thu, May 25, 2017 at 11:52 AM, Jared Stewart  wrote:

> I would like to propose that we eliminate the “user-command-packages”
> system property, in favor of scanning the entire classpath to find commands.
>
> To give more detail, Geode currently supports three ways to load GFSH
> commands:
> Scan the classpath for commands in "org.apache.geode.management.
> internal.cli.commands”
> Scan the classpath for commands in a package specified by a user via the
> “user-command-packages” system property.
> Scan the classpath for commands registered in files inside
> META-INF.services (e.g. "geode-core/src/test/resources/META-INF/services/
> org.springframework.shell.core.CommandMarker”)
>
> We have some bespoke code responsible for scanning the classpath
> (ClasspathScanLoadHelper) that I am in the process of replacing with
> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> longer need to eagerly load all of the classes in the target package, I
> don’t see any reason why a user should need to specify a
> “user-command-package” property or a “META-INF/services” file.  Instead, we
> should just scan the whole classpath and register any commands that we find.
>
> Thoughts?




-- 
Cheers

Jinmei

Re: Proposal: Remove the "user-command-packages" system property

[Udo Kohlmeyer]

What I meant was, given our hammer of choice for GFSH is Spring Shell, 
all command definitions should be of type CommandMarker.


Not sure how it loads the correct CommandMarker classes (for different 
commands). But my gut feel is, have single way of doing something... KISS



On 5/25/17 12:22, Jared Stewart wrote:

Can you clarify - I'm proposing we use *implements CommandMarker* alone as
the way to specify commands. What do we gain be *also* requiring a
META-INF.services file?

On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:

imo, I think that GFSH is Spring Shell, it should really only be commands
that are registered inside of META-INF.services .. aka implements
CommandMarker.

This way we has standard simple way to specify commands.

--Udo



On 5/25/17 11:52, Jared Stewart wrote:


I would like to propose that we eliminate the “user-command-packages”
system property, in favor of scanning the entire classpath to find commands.

To give more detail, Geode currently supports three ways to load GFSH
commands:
Scan the classpath for commands in "org.apache.geode.management.i
nternal.cli.commands”
Scan the classpath for commands in a package specified by a user via the
“user-command-packages” system property.
Scan the classpath for commands registered in files inside
META-INF.services (e.g. "geode-core/src/test/resources
/META-INF/services/org.springframework.shell.core.CommandMarker”)

We have some bespoke code responsible for scanning the classpath
(ClasspathScanLoadHelper) that I am in the process of replacing with
FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
longer need to eagerly load all of the classes in the target package, I
don’t see any reason why a user should need to specify a
“user-command-package” property or a “META-INF/services” file.  Instead, we
should just scan the whole classpath and register any commands that we find.

Thoughts?

Re: Proposal: Remove the "user-command-packages" system property

[Jared Stewart]

It sounds like we're on the same page.

The current behavior requires two pieces from a user who wants to add
commands:
1) implement CommandMarker
2) Add a system property pointing to the package of your class, or provide
a META-INF.services file pointing to your class

The proposed behavior is to drop 2) and rely on 1) alone.

On May 25, 2017 12:55 PM, "Udo Kohlmeyer"  wrote:

What I meant was, given our hammer of choice for GFSH is Spring Shell, all
command definitions should be of type CommandMarker.

Not sure how it loads the correct CommandMarker classes (for different
commands). But my gut feel is, have single way of doing something... KISS



On 5/25/17 12:22, Jared Stewart wrote:

> Can you clarify - I'm proposing we use *implements CommandMarker* alone as
> the way to specify commands. What do we gain be *also* requiring a
> META-INF.services file?
>
> On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:
>
> imo, I think that GFSH is Spring Shell, it should really only be commands
> that are registered inside of META-INF.services .. aka implements
> CommandMarker.
>
> This way we has standard simple way to specify commands.
>
> --Udo
>
>
>
> On 5/25/17 11:52, Jared Stewart wrote:
>
> I would like to propose that we eliminate the “user-command-packages”
>> system property, in favor of scanning the entire classpath to find
>> commands.
>>
>> To give more detail, Geode currently supports three ways to load GFSH
>> commands:
>> Scan the classpath for commands in "org.apache.geode.management.i
>> nternal.cli.commands”
>> Scan the classpath for commands in a package specified by a user via the
>> “user-command-packages” system property.
>> Scan the classpath for commands registered in files inside
>> META-INF.services (e.g. "geode-core/src/test/resources
>> /META-INF/services/org.springframework.shell.core.CommandMarker”)
>>
>> We have some bespoke code responsible for scanning the classpath
>> (ClasspathScanLoadHelper) that I am in the process of replacing with
>> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
>> longer need to eagerly load all of the classes in the target package, I
>> don’t see any reason why a user should need to specify a
>> “user-command-package” property or a “META-INF/services” file.  Instead,
>> we
>> should just scan the whole classpath and register any commands that we
>> find.
>>
>> Thoughts?
>>
>>

[jira] [Commented] (GEODE-2990) fix testXmlCacheCreationWithPools

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2990:


Commit 6708bf397485714674365c11ca9b0b9b90a8ff0f in geode-native's branch 
refs/heads/develop from [~eburghardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=6708bf3 ]

GEODE-2990: fix for testXMLCreationWithPools test failure


> fix testXmlCacheCreationWithPools
> -
>
> Key: GEODE-2990
> URL: https://issues.apache.org/jira/browse/GEODE-2990
> Project: Geode
>  Issue Type: Bug
>Reporter: Ernest Burghardt
>
> Fails due to an initialization ordering issue.



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

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2975:


Commit 313febd9eb1cc2b89ab790d00183010b9d5d27b2 in geode's branch 
refs/heads/feature/GEODE-2975 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=313febd ]

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[GitHub] geode pull request #538: GEODE-2975: Change the location of the lucene xsd

[upthewaterspout]

GitHub user upthewaterspout opened a pull request:

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

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [X] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [X] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [X] Is your initial contribution a single, squashed commit?

- [X] Does `gradlew build` run cleanly?

- [X] Have you written or updated unit tests to verify your changes?

- [X] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/apache/geode feature/GEODE-2975

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

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


commit 313febd9eb1cc2b89ab790d00183010b9d5d27b2
Author: Dan Smith 
Date:   2017-05-25T20:05:23Z

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.




---
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-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

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

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

GitHub user upthewaterspout opened a pull request:

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

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [X] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [X] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [X] Is your initial contribution a single, squashed commit?

- [X] Does `gradlew build` run cleanly?

- [X] Have you written or updated unit tests to verify your changes?

- [X] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/apache/geode feature/GEODE-2975

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

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


commit 313febd9eb1cc2b89ab790d00183010b9d5d27b2
Author: Dan Smith 
Date:   2017-05-25T20:05:23Z

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.




> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@nabarunnag @boglesby


---
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-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

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

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

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@nabarunnag @boglesby


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/538
  
Does this also affect the xsd location on http://geode.apache.org?


---
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-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

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

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

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/538
  
Does this also affect the xsd location on http://geode.apache.org?


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@metatype - Yes, we'll need to update the website as well, the location of 
the xsd is also wrong on the website, but for different reasons.


---
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-2975) Attributes are not validated in lucene xml configuration

[Joey McAllister (JIRA)]

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

Joey McAllister updated GEODE-2975:
---
Component/s: docs

> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

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

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

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/538
  
@metatype - Yes, we'll need to update the website as well, the location of 
the xsd is also wrong on the website, but for different reasons.


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[GitHub] geode pull request #533: GEODE-2944: Added __REGION_VALUE_FIELD explanation ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> lucene queries on String values (vs. objects) requires obscure/undocumented 
> defaultField (__REGION_VALUE_FIELD)
> ---
>
> Key: GEODE-2944
> URL: https://issues.apache.org/jira/browse/GEODE-2944
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
>
> When a lucene index is created, one must indicate the field to create the 
> index on.  When the object value is a simple String, that must be specified 
> as --field=__REGION_VALUE_FIELD.
> For example,
> create lucene index --name=newIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> However, the lucene help text (for the gfsh command) does not provide this 
> detail.  In addition, it seems that when executing a lucene search, this must 
> be entered again as --defaultField=__REGION_VALUE_FIELD.
> While this is probably not something one would use in production, I imagine 
> it will be used by developers experimenting with Lucene, so we should 
> consider adding this to the help text.
> {noformat}
> gfsh>help create lucene index
> NAME
> create lucene index
> IS AVAILABLE
> true
> SYNOPSIS
> Create a lucene index that can be used to execute queries.
> SYNTAX
> create lucene index --name=value --region=value --field=value(,value)* 
> [--analyzer=value(,value)*]
> PARAMETERS
> name
> Name of the lucene index to create.
> Required: true
> region
> Name/Path of the region on which to create the lucene index.
> Required: true
> field
> fields on the region values which are stored in the lucene index.
> Required: true
> analyzer
> Type of the analyzer for each field.
> Required: false
> {noformat}



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

[jira] [Commented] (GEODE-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2944:


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

GEODE-2944: Added __REGION_VALUE_FIELD explanation to lucene create index help

This closes #533


> lucene queries on String values (vs. objects) requires obscure/undocumented 
> defaultField (__REGION_VALUE_FIELD)
> ---
>
> Key: GEODE-2944
> URL: https://issues.apache.org/jira/browse/GEODE-2944
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
>
> When a lucene index is created, one must indicate the field to create the 
> index on.  When the object value is a simple String, that must be specified 
> as --field=__REGION_VALUE_FIELD.
> For example,
> create lucene index --name=newIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> However, the lucene help text (for the gfsh command) does not provide this 
> detail.  In addition, it seems that when executing a lucene search, this must 
> be entered again as --defaultField=__REGION_VALUE_FIELD.
> While this is probably not something one would use in production, I imagine 
> it will be used by developers experimenting with Lucene, so we should 
> consider adding this to the help text.
> {noformat}
> gfsh>help create lucene index
> NAME
> create lucene index
> IS AVAILABLE
> true
> SYNOPSIS
> Create a lucene index that can be used to execute queries.
> SYNTAX
> create lucene index --name=value --region=value --field=value(,value)* 
> [--analyzer=value(,value)*]
> PARAMETERS
> name
> Name of the lucene index to create.
> Required: true
> region
> Name/Path of the region on which to create the lucene index.
> Required: true
> field
> fields on the region values which are stored in the lucene index.
> Required: true
> analyzer
> Type of the analyzer for each field.
> Required: false
> {noformat}



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

[jira] [Commented] (GEODE-2941) Pulse documentation is outdated

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2941:


Commit 7b34cfd9fd7865ee30f2d1518977b3c7bce294a4 in geode's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7b34cfd ]

GEODE-2941 Update Pulse documentation


> Pulse documentation is outdated
> ---
>
> Key: GEODE-2941
> URL: https://issues.apache.org/jira/browse/GEODE-2941
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Jinmei Liao
>Assignee: Dave Barnes
>
> the pulse documentation:
> http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D
> is no longer accurate anymore.
> 1. jmxUsername and jmxpassword no long applies
> 2. the logging configurations has changed too.



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

[jira] [Resolved] (GEODE-2941) Pulse documentation is outdated

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-2941.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Pulse documentation is outdated
> ---
>
> Key: GEODE-2941
> URL: https://issues.apache.org/jira/browse/GEODE-2941
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Jinmei Liao
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> the pulse documentation:
> http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D
> is no longer accurate anymore.
> 1. jmxUsername and jmxpassword no long applies
> 2. the logging configurations has changed too.



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

[GitHub] geode pull request #539: GEODE-2818: add alias to any command's options that...

[YehEmily]

GitHub user YehEmily opened a pull request:

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

GEODE-2818: add alias to any command's options that involves "group", 
"member", "jar"

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/YehEmily/geode synonyms

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

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


commit 01c5119654f27a254f8fb334b9fe8a2d5c4039ac
Author: YehEmily 
Date:   2017-05-23T19:27:40Z

GEODE-2977: make group/name option values consistent

commit 2076f03d8cd3748f204518c47b3a6245f9f6a714
Author: YehEmily 
Date:   2017-05-25T19:18:45Z

Edited command files to allow either 'group' or 'groups' and 'member' or 
'members




---
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 #539: GEODE-2818: add alias to any command's options that involv...

[YehEmily]

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/539
  
Precheckin pending!


---
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-2818) add alias to any command's options that involves "group", "member", "jar"

[ASF GitHub Bot (JIRA)]

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

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

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/539
  
Precheckin pending!


> add alias to any command's options that involves "group", "member", "jar"
> -
>
> Key: GEODE-2818
> URL: https://issues.apache.org/jira/browse/GEODE-2818
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>
> Or anything that would have confusion about if we are going to use singular 
> or plural at all.
> 1) add alias for those options
> 2) make sure it parameter type is an array type, some method only accepts a 
> string and split it inside the command.



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

[jira] [Commented] (GEODE-2818) add alias to any command's options that involves "group", "member", "jar"

[ASF GitHub Bot (JIRA)]

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

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

GitHub user YehEmily opened a pull request:

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

GEODE-2818: add alias to any command's options that involves "group", 
"member", "jar"

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/YehEmily/geode synonyms

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

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


commit 01c5119654f27a254f8fb334b9fe8a2d5c4039ac
Author: YehEmily 
Date:   2017-05-23T19:27:40Z

GEODE-2977: make group/name option values consistent

commit 2076f03d8cd3748f204518c47b3a6245f9f6a714
Author: YehEmily 
Date:   2017-05-25T19:18:45Z

Edited command files to allow either 'group' or 'groups' and 'member' or 
'members




> add alias to any command's options that involves "group", "member", "jar"
> -
>
> Key: GEODE-2818
> URL: https://issues.apache.org/jira/browse/GEODE-2818
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>
> Or anything that would have confusion about if we are going to use singular 
> or plural at all.
> 1) add alias for those options
> 2) make sure it parameter type is an array type, some method only accepts a 
> string and split it inside the command.



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

[jira] [Resolved] (GEODE-2944) lucene queries on String values (vs. objects) requires obscure/undocumented defaultField (__REGION_VALUE_FIELD)

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2944.

   Resolution: Fixed
Fix Version/s: 1.2.0

> lucene queries on String values (vs. objects) requires obscure/undocumented 
> defaultField (__REGION_VALUE_FIELD)
> ---
>
> Key: GEODE-2944
> URL: https://issues.apache.org/jira/browse/GEODE-2944
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> When a lucene index is created, one must indicate the field to create the 
> index on.  When the object value is a simple String, that must be specified 
> as --field=__REGION_VALUE_FIELD.
> For example,
> create lucene index --name=newIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> However, the lucene help text (for the gfsh command) does not provide this 
> detail.  In addition, it seems that when executing a lucene search, this must 
> be entered again as --defaultField=__REGION_VALUE_FIELD.
> While this is probably not something one would use in production, I imagine 
> it will be used by developers experimenting with Lucene, so we should 
> consider adding this to the help text.
> {noformat}
> gfsh>help create lucene index
> NAME
> create lucene index
> IS AVAILABLE
> true
> SYNOPSIS
> Create a lucene index that can be used to execute queries.
> SYNTAX
> create lucene index --name=value --region=value --field=value(,value)* 
> [--analyzer=value(,value)*]
> PARAMETERS
> name
> Name of the lucene index to create.
> Required: true
> region
> Name/Path of the region on which to create the lucene index.
> Required: true
> field
> fields on the region values which are stored in the lucene index.
> Required: true
> analyzer
> Type of the analyzer for each field.
> Required: false
> {noformat}



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

[GitHub] geode issue #538: GEODE-2975: Change the location of the lucene xsd

[boglesby]

Github user boglesby commented on the issue:

https://github.com/apache/geode/pull/538
  
This looks good for these xmls:
```

```
```

```
it still throws a ClassCastException for this, though:
```

```
I'm not sure if thats a problem or if its ok.




---
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-2975) Attributes are not validated in lucene xml configuration

[ASF GitHub Bot (JIRA)]

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

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

Github user boglesby commented on the issue:

https://github.com/apache/geode/pull/538
  
This looks good for these xmls:
```

```
```

```
it still throws a ClassCastException for this, though:
```

```
I'm not sure if thats a problem or if its ok.




> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[jira] [Created] (GEODE-2991) "destroy gateway-sender" command not in documentation

[Emily Yeh (JIRA)]

Emily Yeh created GEODE-2991:


 Summary: "destroy gateway-sender" command not in documentation
 Key: GEODE-2991
 URL: https://issues.apache.org/jira/browse/GEODE-2991
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Emily Yeh


Documentation for the "destroy gateway-sender" command (handled by the 
destroyGatewaySender method under WanCommands.java) isn't available in the docs 
yet.



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

Re: Proposal: Remove the "user-command-packages" system property

[Darrel Schneider]

What JVM does this scanning? Is it just the top-level shell JVM or does it
happen on the jmx-manager side?

On Thu, May 25, 2017 at 1:01 PM, Jared Stewart  wrote:

> It sounds like we're on the same page.
>
> The current behavior requires two pieces from a user who wants to add
> commands:
> 1) implement CommandMarker
> 2) Add a system property pointing to the package of your class, or provide
> a META-INF.services file pointing to your class
>
> The proposed behavior is to drop 2) and rely on 1) alone.
>
> On May 25, 2017 12:55 PM, "Udo Kohlmeyer"  wrote:
>
> What I meant was, given our hammer of choice for GFSH is Spring Shell, all
> command definitions should be of type CommandMarker.
>
> Not sure how it loads the correct CommandMarker classes (for different
> commands). But my gut feel is, have single way of doing something... KISS
>
>
>
> On 5/25/17 12:22, Jared Stewart wrote:
>
> > Can you clarify - I'm proposing we use *implements CommandMarker* alone
> as
> > the way to specify commands. What do we gain be *also* requiring a
> > META-INF.services file?
> >
> > On May 25, 2017 12:18 PM, "Udo Kohlmeyer"  wrote:
> >
> > imo, I think that GFSH is Spring Shell, it should really only be commands
> > that are registered inside of META-INF.services .. aka implements
> > CommandMarker.
> >
> > This way we has standard simple way to specify commands.
> >
> > --Udo
> >
> >
> >
> > On 5/25/17 11:52, Jared Stewart wrote:
> >
> > I would like to propose that we eliminate the “user-command-packages”
> >> system property, in favor of scanning the entire classpath to find
> >> commands.
> >>
> >> To give more detail, Geode currently supports three ways to load GFSH
> >> commands:
> >> Scan the classpath for commands in "org.apache.geode.management.i
> >> nternal.cli.commands”
> >> Scan the classpath for commands in a package specified by a user via the
> >> “user-command-packages” system property.
> >> Scan the classpath for commands registered in files inside
> >> META-INF.services (e.g. "geode-core/src/test/resources
> >> /META-INF/services/org.springframework.shell.core.CommandMarker”)
> >>
> >> We have some bespoke code responsible for scanning the classpath
> >> (ClasspathScanLoadHelper) that I am in the process of replacing with
> >> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> >> longer need to eagerly load all of the classes in the target package, I
> >> don’t see any reason why a user should need to specify a
> >> “user-command-package” property or a “META-INF/services” file.  Instead,
> >> we
> >> should just scan the whole classpath and register any commands that we
> >> find.
> >>
> >> Thoughts?
> >>
> >>
>

Re: Proposal: Remove the "user-command-packages" system property

[Jinmei Liao]

both sides.

On Thu, May 25, 2017 at 2:16 PM, Darrel Schneider 
wrote:

> What JVM does this scanning? Is it just the top-level shell JVM or does it
> happen on the jmx-manager side?
>
> On Thu, May 25, 2017 at 1:01 PM, Jared Stewart 
> wrote:
>
> > It sounds like we're on the same page.
> >
> > The current behavior requires two pieces from a user who wants to add
> > commands:
> > 1) implement CommandMarker
> > 2) Add a system property pointing to the package of your class, or
> provide
> > a META-INF.services file pointing to your class
> >
> > The proposed behavior is to drop 2) and rely on 1) alone.
> >
> > On May 25, 2017 12:55 PM, "Udo Kohlmeyer"  wrote:
> >
> > What I meant was, given our hammer of choice for GFSH is Spring Shell,
> all
> > command definitions should be of type CommandMarker.
> >
> > Not sure how it loads the correct CommandMarker classes (for different
> > commands). But my gut feel is, have single way of doing something... KISS
> >
> >
> >
> > On 5/25/17 12:22, Jared Stewart wrote:
> >
> > > Can you clarify - I'm proposing we use *implements CommandMarker* alone
> > as
> > > the way to specify commands. What do we gain be *also* requiring a
> > > META-INF.services file?
> > >
> > > On May 25, 2017 12:18 PM, "Udo Kohlmeyer" 
> wrote:
> > >
> > > imo, I think that GFSH is Spring Shell, it should really only be
> commands
> > > that are registered inside of META-INF.services .. aka implements
> > > CommandMarker.
> > >
> > > This way we has standard simple way to specify commands.
> > >
> > > --Udo
> > >
> > >
> > >
> > > On 5/25/17 11:52, Jared Stewart wrote:
> > >
> > > I would like to propose that we eliminate the “user-command-packages”
> > >> system property, in favor of scanning the entire classpath to find
> > >> commands.
> > >>
> > >> To give more detail, Geode currently supports three ways to load GFSH
> > >> commands:
> > >> Scan the classpath for commands in "org.apache.geode.management.i
> > >> nternal.cli.commands”
> > >> Scan the classpath for commands in a package specified by a user via
> the
> > >> “user-command-packages” system property.
> > >> Scan the classpath for commands registered in files inside
> > >> META-INF.services (e.g. "geode-core/src/test/resources
> > >> /META-INF/services/org.springframework.shell.core.CommandMarker”)
> > >>
> > >> We have some bespoke code responsible for scanning the classpath
> > >> (ClasspathScanLoadHelper) that I am in the process of replacing with
> > >> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> > >> longer need to eagerly load all of the classes in the target package,
> I
> > >> don’t see any reason why a user should need to specify a
> > >> “user-command-package” property or a “META-INF/services” file.
> Instead,
> > >> we
> > >> should just scan the whole classpath and register any commands that we
> > >> find.
> > >>
> > >> Thoughts?
> > >>
> > >>
> >
>



-- 
Cheers

Jinmei

[jira] [Updated] (GEODE-2990) fix testXmlCacheCreationWithPools

[Ernest Burghardt (JIRA)]

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

Ernest Burghardt updated GEODE-2990:

Component/s: native client

> fix testXmlCacheCreationWithPools
> -
>
> Key: GEODE-2990
> URL: https://issues.apache.org/jira/browse/GEODE-2990
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> Fails due to an initialization ordering issue.



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

[jira] [Created] (GEODE-2992) Update openssl download URI

[Ernest Burghardt (JIRA)]

Ernest Burghardt created GEODE-2992:
---

 Summary: Update openssl download URI
 Key: GEODE-2992
 URL: https://issues.apache.org/jira/browse/GEODE-2992
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Ernest Burghardt


It changed again for older versions...
https://www.openssl.org/source/old/1.0.1/openssl-1.0.1u.tar.gz



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

[jira] [Commented] (GEODE-2992) Update openssl download URI

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2992:


Commit 5ee98401edf8e7861be1bf5af5b668fe356c0b37 in geode-native's branch 
refs/heads/develop from [~eburghardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=5ee9840 ]

GEODE-2992: updated URI for openssl download.


> Update openssl download URI
> ---
>
> Key: GEODE-2992
> URL: https://issues.apache.org/jira/browse/GEODE-2992
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> It changed again for older versions...
> https://www.openssl.org/source/old/1.0.1/openssl-1.0.1u.tar.gz



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

[GitHub] geode pull request #536: GEODE-2977: make group/name option values consisten...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2977:


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

GEODE-2977: make group/name option values consistent

* this closes #536


> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



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

[jira] [Commented] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



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

[GitHub] geode pull request #540: GEODE-2950: Updated error messages

[DivineEnder]

GitHub user DivineEnder opened a pull request:

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

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2950

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

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


commit 382f3e672964c76c3854f33c3b628c5a0234eb66
Author: David Anuta 
Date:   2017-05-25T22:18:40Z

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.




---
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 #540: GEODE-2950: Updated error messages

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/540
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


---
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-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF GitHub Bot (JIRA)]

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

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

GitHub user DivineEnder opened a pull request:

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

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2950

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

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


commit 382f3e672964c76c3854f33c3b628c5a0234eb66
Author: David Anuta 
Date:   2017-05-25T22:18:40Z

GEODE-2950: Updated error messages

* Different error messages are displayed when validating region names 
versus indexes.
* Added flexible enum allowing for expanded error messages and name 
validation.




> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



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

[jira] [Commented] (GEODE-2950) Lucene index names should be restricted to valid region names since the index name becomes part of a region

[ASF GitHub Bot (JIRA)]

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

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

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/540
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou 


> Lucene index names should be restricted to valid region names since the index 
> name becomes part of a region
> ---
>
> Key: GEODE-2950
> URL: https://issues.apache.org/jira/browse/GEODE-2950
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> Currently, invalid region name characters can be used as index names. The 
> index name becomes part of the async event queue id which becomes part of the 
> colocated region name, so invalid characters shouldn't be allowed as index 
> names. LocalRegion has a validateRegionName method that restricts the names 
> to {{\[aA-zZ0-9-_.\]+}}. This method should be called to validate index names.
> Here is an example (option-j creates the ∆):
> {noformat}
> gfsh>create lucene index --name=∆∆∆ --region=data --field=text
>   Member| Status
> --- | -
> 192.168.2.4(server2:53308):1025 | Successfully created lucene index
> 192.168.2.4(server1:53315):1026 | Successfully created lucene index
> {noformat}
> {noformat}
> gfsh>create region --name=data --type=PARTITION
> Member  | Status
> --- | ---
> server2 | Region "/data" created on "server2"
> server1 | Region "/data" created on "server1"
> {noformat}
> {noformat}
> gfsh>put --key=0 --value=0 --region=data
> Result  : true
> Key Class   : java.lang.String
> Key : 0
> Value Class : java.lang.String
> Old Value   : 
> {noformat}
> {noformat}
> gfsh>describe lucene index --name=∆∆∆ --region=/data
> Index Name | Region Path | Server Name | Indexed Fields | Field Analyzer  
> |   Status| Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- | 
> --- | --- |  | --- | --- 
> | -
> ∆∆∆| /data   | server1 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 0   | 0   
> | 0
> ∆∆∆| /data   | server2 | [text] | 
> {text=StandardAnalyzer} | Initialized | 0| 1   | 1   
> | 1
> {noformat}



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

[jira] [Updated] (GEODE-2993) Lucene query inconsistency detected after user region event fired during cache close

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2993:
---
Affects Version/s: 1.2.0

> Lucene query inconsistency detected after user region event fired during 
> cache close
> 
>
> Key: GEODE-2993
> URL: https://issues.apache.org/jira/browse/GEODE-2993
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> Lucene indexes may not be updated when the member hosting the primary is 
> undergoing cache close while the CacheListener is being fired (resulting in 
> data inconsistency between user region and lucene query).
> AbstractGatwaySender.distribute() simply catches and logs 
> CacheClosedExceptions which causes those events to be lost.



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

[jira] [Created] (GEODE-2993) Lucene query inconsistency detected after user region event fired during cache close

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2993:
--

 Summary: Lucene query inconsistency detected after user region 
event fired during cache close
 Key: GEODE-2993
 URL: https://issues.apache.org/jira/browse/GEODE-2993
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


Lucene indexes may not be updated when the member hosting the primary is 
undergoing cache close while the CacheListener is being fired (resulting in 
data inconsistency between user region and lucene query).

AbstractGatwaySender.distribute() simply catches and logs CacheClosedExceptions 
which causes those events to be lost.



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

Re: Proposal: Remove the "user-command-packages" system property

[Darrel Schneider]

The only concern I would have is that this might cause gfsh to load other
things that implement the spring CommandMarker that have nothing to do with
gfsh simply because they are in one of the jars. I really don't know how
likely that would be to happen but it seems more likely since the scan
happens on both sides.

Since the default for this property is the empty string you could just
change the default behavior to scan everything (instead of nothing) but
still allow them to limit where it scans be specifying a non-default value.


On Thu, May 25, 2017 at 2:30 PM, Jinmei Liao  wrote:

> both sides.
>
> On Thu, May 25, 2017 at 2:16 PM, Darrel Schneider 
> wrote:
>
> > What JVM does this scanning? Is it just the top-level shell JVM or does
> it
> > happen on the jmx-manager side?
> >
> > On Thu, May 25, 2017 at 1:01 PM, Jared Stewart 
> > wrote:
> >
> > > It sounds like we're on the same page.
> > >
> > > The current behavior requires two pieces from a user who wants to add
> > > commands:
> > > 1) implement CommandMarker
> > > 2) Add a system property pointing to the package of your class, or
> > provide
> > > a META-INF.services file pointing to your class
> > >
> > > The proposed behavior is to drop 2) and rely on 1) alone.
> > >
> > > On May 25, 2017 12:55 PM, "Udo Kohlmeyer" 
> wrote:
> > >
> > > What I meant was, given our hammer of choice for GFSH is Spring Shell,
> > all
> > > command definitions should be of type CommandMarker.
> > >
> > > Not sure how it loads the correct CommandMarker classes (for different
> > > commands). But my gut feel is, have single way of doing something...
> KISS
> > >
> > >
> > >
> > > On 5/25/17 12:22, Jared Stewart wrote:
> > >
> > > > Can you clarify - I'm proposing we use *implements CommandMarker*
> alone
> > > as
> > > > the way to specify commands. What do we gain be *also* requiring a
> > > > META-INF.services file?
> > > >
> > > > On May 25, 2017 12:18 PM, "Udo Kohlmeyer" 
> > wrote:
> > > >
> > > > imo, I think that GFSH is Spring Shell, it should really only be
> > commands
> > > > that are registered inside of META-INF.services .. aka implements
> > > > CommandMarker.
> > > >
> > > > This way we has standard simple way to specify commands.
> > > >
> > > > --Udo
> > > >
> > > >
> > > >
> > > > On 5/25/17 11:52, Jared Stewart wrote:
> > > >
> > > > I would like to propose that we eliminate the “user-command-packages”
> > > >> system property, in favor of scanning the entire classpath to find
> > > >> commands.
> > > >>
> > > >> To give more detail, Geode currently supports three ways to load
> GFSH
> > > >> commands:
> > > >> Scan the classpath for commands in "org.apache.geode.management.i
> > > >> nternal.cli.commands”
> > > >> Scan the classpath for commands in a package specified by a user via
> > the
> > > >> “user-command-packages” system property.
> > > >> Scan the classpath for commands registered in files inside
> > > >> META-INF.services (e.g. "geode-core/src/test/resources
> > > >> /META-INF/services/org.springframework.shell.core.CommandMarker”)
> > > >>
> > > >> We have some bespoke code responsible for scanning the classpath
> > > >> (ClasspathScanLoadHelper) that I am in the process of replacing with
> > > >> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will
> no
> > > >> longer need to eagerly load all of the classes in the target
> package,
> > I
> > > >> don’t see any reason why a user should need to specify a
> > > >> “user-command-package” property or a “META-INF/services” file.
> > Instead,
> > > >> we
> > > >> should just scan the whole classpath and register any commands that
> we
> > > >> find.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >>
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

[jira] [Commented] (GEODE-2993) Lucene query inconsistency detected after user region event fired during cache close

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2993:


Commit 0fe0a1061065f07d4b734d7055f56ad1635f1a2a in geode's branch 
refs/heads/develop from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0fe0a10 ]

GEODE-2993: Rethrow CacheClosedException from AbstractGatewaySender.distribute()

- rethrow CacheClosedException
- Add test for cache close while enqueuing event in AEQ.
- Add cleanup of disk dirs created by test.


> Lucene query inconsistency detected after user region event fired during 
> cache close
> 
>
> Key: GEODE-2993
> URL: https://issues.apache.org/jira/browse/GEODE-2993
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> Lucene indexes may not be updated when the member hosting the primary is 
> undergoing cache close while the CacheListener is being fired (resulting in 
> data inconsistency between user region and lucene query).
> AbstractGatwaySender.distribute() simply catches and logs 
> CacheClosedExceptions which causes those events to be lost.



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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #565 was successful.
---
Scheduled
1850 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo