Travis CI reporting checks failures but no issues on my local machine

[Avinash Dongre]

Hi,

I am getting geode-core:spotlessJavaCheck errors on travis-ci.

But When I ran ./gradlew clean build -Dskip.tests=true on my local machine
everything is fine.

https://travis-ci.org/apache/geode/builds/188749592

What I am missing here ?

Thanks
Avinash

[jira] [Commented] (GEODE-1887) Client PROXY region should delegate all operations to server

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davinash opened a pull request:

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

[GEODE-1887] #comment Fix for Issue #1887 

Issue : Client PROXY region should delegate all operations to server

1. If client and data policy is empty then size API goes through 
ServerRegionProxy
2. Wrote a test for Replicated and PR to verify size and isEmpty
3. Precheckin complete 

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

$ git pull https://github.com/davinash/geode bugfix/GEODE-1887

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

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


commit ce639204a2d9e0fb7d1df464b5836c83ff041b7a
Author: adongre 
Date:   2017-01-03T10:47:37Z

GEODE-1887: Now Size api goes through ServerProxy when cache is of type 
client and DataPolicy is Empty.
Added a test for both PR and Replicated regions.




> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 and true 
> respectively, even though there may be data in the servers for that region.
> A PROXY region should not attempt to consult its local state for any 
> operation. 



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

[GitHub] geode pull request #329: [GEODE-1887] #comment Fix for Issue #1887

[davinash]

GitHub user davinash opened a pull request:

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

[GEODE-1887] #comment Fix for Issue #1887 

Issue : Client PROXY region should delegate all operations to server

1. If client and data policy is empty then size API goes through 
ServerRegionProxy
2. Wrote a test for Replicated and PR to verify size and isEmpty
3. Precheckin complete 

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

$ git pull https://github.com/davinash/geode bugfix/GEODE-1887

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

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


commit ce639204a2d9e0fb7d1df464b5836c83ff041b7a
Author: adongre 
Date:   2017-01-03T10:47:37Z

GEODE-1887: Now Size api goes through ServerProxy when cache is of type 
client and DataPolicy is Empty.
Added a test for both PR and Replicated regions.




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

Re: New proposal for type definitons

[Jacob Barrett]

I don't know that I would be concerned with optimization of unstructured
data from the start. Given that the data is unstructured it means that it
can be restructured at a later time. You could have a lazy task running on
the server the restructures unstructured data to be more uniform and
compact.

I also don't think there are many good reasons to try wedge this into PDX.
The only reason I see for wedging this into PDX is to avoid progress on
modularizing and extending Geode.

If all the where we access fields on a stored object, query, indexing,
etc., where made a bit more generic then any object that supports a simple
getValue(field) like interface could be accessed without deserialization or
specialization.

Consider:
public interface FieldReadable {
public object getValue(String field);
}

You could have an implementation that can getValue on PDX, POJO, JSON,
BSON, XML, etc. There is no concern at this level with underlying storage
type or the original unserialized form of the object (if any).

-Jake




On Tue, Jan 3, 2017 at 4:46 PM Dan Smith  wrote:

> Hi Hitesh,
>
> There are a few different ways to store self describing data. One way might
> be to just store the json string, or convert it to bson, and then enhance
> the query engine to handle those formats. Another way might be extend PDX
> to support self describing serialized values. We xould add a selfDescribing
> boolean flag to RegionService.createPdxInstanceFactory. If that flag is
> set, we will not register the PDX type in the type registry but instead
> store it as part of the value. The JSONFormatter could set that flag to
> true or expose it as an option.
>
> Storing self describing documents is a different approach than Udo's
> original proposal. I do agree there is value in being able to store
> consistently structured json documents the way we do now to save memory. I
> think maybe I would be happier if the original proposal was more of an
> external tool or wrapper focused on sanitizing json documents without being
> concerned with type ids or a central registry service. I could picture just
> having a single sanitize method that takes a json string and a standard
> json
> schema  and returns a cleaned up json document.
> That seems like it would be a lot easier to implement and wouldn't require
> the user to add typeIds to their json documents.
>
> I still feel like storing self describing values might serve more users. It
> is probably more work than a simple sanitize method like above though.
>
> -Dan
>
>
> On Tue, Jan 3, 2017 at 4:07 PM, Hitesh Khamesra
>  > wrote:
>
> > >>If we give people the option to store
> > and query self describing values, then users with inconsistent json could
> > just use that option and pay the extra storage cost.
> > Dan, are you saying expose some interface to serialize/de and "query the
> > some field in data - getFieldValue(fieldname)" dtata?  Some sort of
> > ExternalSerializer with getFieldValue() capability.
> >
> >
> >   From: Dan Smith 
> >  To: dev@geode.apache.org
> >  Sent: Wednesday, December 21, 2016 6:20 PM
> >  Subject: Re: New proposal for type definitons
> >
> > I'm assuming the type ids here are a different set than the type ids used
> > with regular PDX serialization so they won't conflict if the pdx registry
> > assigns 1 to some class and a user puts @typeId: 1 in their json?
> >
> > I'm concerned that this won't really address the type explosion issue.
> > Users that are able to go to the effort of adding these typeIds to all of
> > their json are probably users that can produce consistently formatted
> json
> > in the first place. Users that have inconsistently formatted json are
> > probably not going to want or be able to add these type ids.
> >
> > It might be better for us to pursue a way to store arbitrary documents
> that
> > are self describing. Our current approach for json documents is assuming
> > that the documents are all consistently formatted. We are infer a schema
> > for their documents store the field names in the type registry and the
> > field values in the serialized data. If we give people the option to
> store
> > and query self describing values, then users with inconsistent json could
> > just use that option and pay the extra storage cost.
> >
> > -Dan
> >
> > On Tue, Dec 20, 2016 at 4:53 PM, Udo Kohlmeyer 
> > wrote:
> >
> > > Hey there,
> > >
> > > I've just completed a new proposal on the wiki for a new mechanism that
> > > could be used to define a type definition for an object.
> > > https://cwiki.apache.org/confluence/display/GEODE/Custom+
> > > External+Type+Definition+Proposal+for+JSON
> > >
> > > Primarily the new type definition proposal will hopefully help with the
> > > "structuring" of JSON document definitions in a manner that will allow
> > > users to submit JSON documents for data types without the need to
> provide
> 

Re: New proposal for type definitons

[Dan Smith]

Hi Hitesh,

There are a few different ways to store self describing data. One way might
be to just store the json string, or convert it to bson, and then enhance
the query engine to handle those formats. Another way might be extend PDX
to support self describing serialized values. We xould add a selfDescribing
boolean flag to RegionService.createPdxInstanceFactory. If that flag is
set, we will not register the PDX type in the type registry but instead
store it as part of the value. The JSONFormatter could set that flag to
true or expose it as an option.

Storing self describing documents is a different approach than Udo's
original proposal. I do agree there is value in being able to store
consistently structured json documents the way we do now to save memory. I
think maybe I would be happier if the original proposal was more of an
external tool or wrapper focused on sanitizing json documents without being
concerned with type ids or a central registry service. I could picture just
having a single sanitize method that takes a json string and a standard json
schema  and returns a cleaned up json document.
That seems like it would be a lot easier to implement and wouldn't require
the user to add typeIds to their json documents.

I still feel like storing self describing values might serve more users. It
is probably more work than a simple sanitize method like above though.

-Dan


On Tue, Jan 3, 2017 at 4:07 PM, Hitesh Khamesra  wrote:

> >>If we give people the option to store
> and query self describing values, then users with inconsistent json could
> just use that option and pay the extra storage cost.
> Dan, are you saying expose some interface to serialize/de and "query the
> some field in data - getFieldValue(fieldname)" dtata?  Some sort of
> ExternalSerializer with getFieldValue() capability.
>
>
>   From: Dan Smith 
>  To: dev@geode.apache.org
>  Sent: Wednesday, December 21, 2016 6:20 PM
>  Subject: Re: New proposal for type definitons
>
> I'm assuming the type ids here are a different set than the type ids used
> with regular PDX serialization so they won't conflict if the pdx registry
> assigns 1 to some class and a user puts @typeId: 1 in their json?
>
> I'm concerned that this won't really address the type explosion issue.
> Users that are able to go to the effort of adding these typeIds to all of
> their json are probably users that can produce consistently formatted json
> in the first place. Users that have inconsistently formatted json are
> probably not going to want or be able to add these type ids.
>
> It might be better for us to pursue a way to store arbitrary documents that
> are self describing. Our current approach for json documents is assuming
> that the documents are all consistently formatted. We are infer a schema
> for their documents store the field names in the type registry and the
> field values in the serialized data. If we give people the option to store
> and query self describing values, then users with inconsistent json could
> just use that option and pay the extra storage cost.
>
> -Dan
>
> On Tue, Dec 20, 2016 at 4:53 PM, Udo Kohlmeyer 
> wrote:
>
> > Hey there,
> >
> > I've just completed a new proposal on the wiki for a new mechanism that
> > could be used to define a type definition for an object.
> > https://cwiki.apache.org/confluence/display/GEODE/Custom+
> > External+Type+Definition+Proposal+for+JSON
> >
> > Primarily the new type definition proposal will hopefully help with the
> > "structuring" of JSON document definitions in a manner that will allow
> > users to submit JSON documents for data types without the need to provide
> > every field of the whole domain object type.
> >
> > Please review and comment as required.
> >
> > --Udo
> >
> >
>
>
>
>

[jira] [Created] (GEODE-2265) Some entry operations using JTA do not start transaction in GEODE

[Eric Shu (JIRA)]

Eric Shu created GEODE-2265:
---

 Summary: Some entry operations using JTA do not start transaction 
in GEODE
 Key: GEODE-2265
 URL: https://issues.apache.org/jira/browse/GEODE-2265
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Eric Shu


When using JTA, certain operations do not start transaction in GEODE. This will 
cause certain set operations like region.values() etc not being put into 
TXState and cause subsequent access failed with Exception.



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

Re: New proposal for type definitons

[Hitesh Khamesra]

>>If we give people the option to store
and query self describing values, then users with inconsistent json could
just use that option and pay the extra storage cost.
Dan, are you saying expose some interface to serialize/de and "query the some 
field in data - getFieldValue(fieldname)" dtata?  Some sort of 
ExternalSerializer with getFieldValue() capability. 


  From: Dan Smith 
 To: dev@geode.apache.org 
 Sent: Wednesday, December 21, 2016 6:20 PM
 Subject: Re: New proposal for type definitons
   
I'm assuming the type ids here are a different set than the type ids used
with regular PDX serialization so they won't conflict if the pdx registry
assigns 1 to some class and a user puts @typeId: 1 in their json?

I'm concerned that this won't really address the type explosion issue.
Users that are able to go to the effort of adding these typeIds to all of
their json are probably users that can produce consistently formatted json
in the first place. Users that have inconsistently formatted json are
probably not going to want or be able to add these type ids.

It might be better for us to pursue a way to store arbitrary documents that
are self describing. Our current approach for json documents is assuming
that the documents are all consistently formatted. We are infer a schema
for their documents store the field names in the type registry and the
field values in the serialized data. If we give people the option to store
and query self describing values, then users with inconsistent json could
just use that option and pay the extra storage cost.

-Dan

On Tue, Dec 20, 2016 at 4:53 PM, Udo Kohlmeyer  wrote:

> Hey there,
>
> I've just completed a new proposal on the wiki for a new mechanism that
> could be used to define a type definition for an object.
> https://cwiki.apache.org/confluence/display/GEODE/Custom+
> External+Type+Definition+Proposal+for+JSON
>
> Primarily the new type definition proposal will hopefully help with the
> "structuring" of JSON document definitions in a manner that will allow
> users to submit JSON documents for data types without the need to provide
> every field of the whole domain object type.
>
> Please review and comment as required.
>
> --Udo
>
>


   

Re: Review Request 55124: fix duplicate entries from list lucene index and search lucene index

[Dan Smith]

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


Fix it, then Ship it!





geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
 (line 120)


You could probably remove duplicates just by adding these 
LuceneIndexDetails to a sorted set.


- Dan Smith


On Jan. 3, 2017, 10:45 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55124/
> ---
> 
> (Updated Jan. 3, 2017, 10:45 p.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: geode-2241
> https://issues.apache.org/jira/browse/geode-2241
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> list lucene index is at cache level, region might not be ready. But it's a 
> light-weigh command, I just filter out the duplicated entries. 
> 
> search lucene index currently will be called on all members, which is bad. I 
> pick one of the members with region to execute.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
>  4dcf3e0 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  b3a11fa 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
>  66ac8ca 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
>  0941834 
> 
> Diff: https://reviews.apache.org/r/55124/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: The right way to remove a region's cache listener?

[Kevin Duling]

Yes, it does exist.  I'm sure I'm deploying correctly because when I add
the listeners programmatically, they write to the server.log file.

On Tue, Jan 3, 2017 at 3:13 PM, Jinmei Liao  wrote:

> You probably did not deploy the jars correctly? See if that jar exist in
> your server's dir.
>
> On Tue, Jan 3, 2017 at 2:51 PM, Kevin Duling  wrote:
>
> > I must have some syntax wrong, because I'm not able to add a cache
> listener
> > from the gfsh command line out of the jar I deployed.
> >
> > ListenerTypeA and ListenerTypeB exist in the package 'geode' in my
> > custard-1.0-SNAPSHOT.jar.  I'm able to add those programmatically as I
> > showed earlier.
> >
> > So that I could try to add these via gfsh, I changed my region creation
> > line to:
> >
> > Region region = cache. > Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_
> > PROXY).create("regionA");
> >
> >
> > Then I go through the standard steps of starting a locator, server,
> region,
> > and deploy my jar.
> >
> > Now when I try to assign the listener, I get:
> >
> >
> > gfsh>alter region --cache-listener="geode.ListenerTypeA" --name=/regionA
> >
> > Member | Status
> >
> > -- |
> > 
> > ---
> >
> > server | ERROR: Could not find class "geode.ListenerTypeA" specified for
> > "cache-listener".
> >
> >
> > Am I doing something wrong, or is this not working as expected?  I wasn't
> > able to find documentation that illustrates how this should work.  The
> best
> > I could find was:
> > http://geode.apache.org/docs/guide/developing/events/cache_
> > event_handler_examples.html
> >
> >
> > On Tue, Jan 3, 2017 at 11:52 AM, John Blum  wrote:
> >
> > > `describe region` will show the CacheListeners registered on a Region.
> > >
> > > On Tue, Jan 3, 2017 at 11:44 AM, Dave Barnes 
> wrote:
> > >
> > > > What gfsh command (if any) lists the cache-listeners available on a
> > given
> > > > region? Seems like if the intention is to support adding and deleting
> > by
> > > > name, there should be a way to list existing names.
> > > >
> > > > On Tue, Jan 3, 2017 at 11:29 AM, Jinmei Liao 
> > wrote:
> > > >
> > > > > +1 for remove by specifying only the ones you want to keep:
> > > > >
> > > > > $ alter region --name=data --cache-listener="" will remove all the
> > > cache
> > > > > listeners
> > > > >
> > > > > On Tue, Jan 3, 2017 at 11:08 AM, Kirk Lund 
> wrote:
> > > > >
> > > > > > +1 I'm for the approach you're proposing. As long as it's
> > documented
> > > in
> > > > > > user docs (it's not currently) then this provides a
> straightforward
> > > use
> > > > > of
> > > > > > the existing gfsh syntax without introducing too many new command
> > > > > options.
> > > > > >
> > > > > > Create the region with two cache listeners:
> > > > > > $ create region --name=data
> > > > > > --cache-listener="my.package.ListenerTypeA,my.package.
> > ListenerTypeB"
> > > > > >
> > > > > > Change my mind and decide to remove one of the cache listeners:
> > > > > > $ alter region --name=data --cache-listener="my.package.
> > > ListenerTypeB"
> > > > > >
> > > > > > -Kirk
> > > > > >
> > > > > >
> > > > > > On Tue, Jan 3, 2017 at 10:52 AM, Kevin Duling <
> kdul...@pivotal.io>
> > > > > wrote:
> > > > > >
> > > > > > > Is this an intuitive User Experience?
> > > > > > >
> > > > > > > Given these two classes:
> > > > > > >
> > > > > > > public class ListenerTypeA extends CacheListenerAdapter
> > implements
> > > > > > > Declarable
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > > public class ListenerTypeB extends CacheListenerAdapter
> > implements
> > > > > > > Declarable
> > > > > > >
> > > > > > > And they are programmatically added to a region:
> > > > > > >
> > > > > > > CacheListener listener1 = new ListenerTypeA();
> > > > > > >
> > > > > > > CacheListener listener2 = new ListenerTypeB();
> > > > > > >
> > > > > > > Region region = cache. > > > > > > Customer>createClientRegionFactory(
> ClientRegionShortcut.CACHING_
> > > > PROXY)
> > > > > > >
> > > > > > > .initCacheListeners(new CacheListener[]{listener1,
> > > > > > > listener2}).create("regionA");
> > > > > > >
> > > > > > >
> > > > > > > What would the expected gfsh command to remove them.  Should we
> > > > remove
> > > > > > the
> > > > > > > listeners via omission?  For example, removing listener1 might
> > be:
> > > > > > >
> > > > > > > alter region --name=data --cache-listener='my.package.
> > > ListenerTypeB'
> > > > > > >
> > > > > > >
> > > > > > > By only listing the listeners I want...either to keep and/or to
> > > add,
> > > > > > > listener1 which is a ListenerTypeA, would be removed.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling <
> > kdul...@pivotal.io>
> > > > > > wrote:

Broken: apache/geode#1715 (develop - 8b8084f)

[Travis CI]

Build Update for apache/geode
-

Build: #1715
Status: Broken

Duration: 10 minutes and 6 seconds
Commit: 8b8084f (develop)
Author: Bruce Schuchardt
Message: GEODE-2253 Locator may fail to respond to a valid request

This introduces a retry loop in the locator when a handler for an
incoming message can't be found.  It waits for an amount of time
for the handler to be installed, which I've set to the locator-
wait-time or 5 seconds if that property hasn't been set.

I've also changed InternalLocator to always install the handler
for cluster configuration status so that you can query any locator
to see if it has a cluster configuration service and, if so, what
state it's in.

View the changeset: 
https://github.com/apache/geode/compare/32004475460b...8b8084f024b8

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

--

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

Re: The right way to remove a region's cache listener?

[Jinmei Liao]

You probably did not deploy the jars correctly? See if that jar exist in
your server's dir.

On Tue, Jan 3, 2017 at 2:51 PM, Kevin Duling  wrote:

> I must have some syntax wrong, because I'm not able to add a cache listener
> from the gfsh command line out of the jar I deployed.
>
> ListenerTypeA and ListenerTypeB exist in the package 'geode' in my
> custard-1.0-SNAPSHOT.jar.  I'm able to add those programmatically as I
> showed earlier.
>
> So that I could try to add these via gfsh, I changed my region creation
> line to:
>
> Region region = cache. Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_
> PROXY).create("regionA");
>
>
> Then I go through the standard steps of starting a locator, server, region,
> and deploy my jar.
>
> Now when I try to assign the listener, I get:
>
>
> gfsh>alter region --cache-listener="geode.ListenerTypeA" --name=/regionA
>
> Member | Status
>
> -- |
> 
> ---
>
> server | ERROR: Could not find class "geode.ListenerTypeA" specified for
> "cache-listener".
>
>
> Am I doing something wrong, or is this not working as expected?  I wasn't
> able to find documentation that illustrates how this should work.  The best
> I could find was:
> http://geode.apache.org/docs/guide/developing/events/cache_
> event_handler_examples.html
>
>
> On Tue, Jan 3, 2017 at 11:52 AM, John Blum  wrote:
>
> > `describe region` will show the CacheListeners registered on a Region.
> >
> > On Tue, Jan 3, 2017 at 11:44 AM, Dave Barnes  wrote:
> >
> > > What gfsh command (if any) lists the cache-listeners available on a
> given
> > > region? Seems like if the intention is to support adding and deleting
> by
> > > name, there should be a way to list existing names.
> > >
> > > On Tue, Jan 3, 2017 at 11:29 AM, Jinmei Liao 
> wrote:
> > >
> > > > +1 for remove by specifying only the ones you want to keep:
> > > >
> > > > $ alter region --name=data --cache-listener="" will remove all the
> > cache
> > > > listeners
> > > >
> > > > On Tue, Jan 3, 2017 at 11:08 AM, Kirk Lund  wrote:
> > > >
> > > > > +1 I'm for the approach you're proposing. As long as it's
> documented
> > in
> > > > > user docs (it's not currently) then this provides a straightforward
> > use
> > > > of
> > > > > the existing gfsh syntax without introducing too many new command
> > > > options.
> > > > >
> > > > > Create the region with two cache listeners:
> > > > > $ create region --name=data
> > > > > --cache-listener="my.package.ListenerTypeA,my.package.
> ListenerTypeB"
> > > > >
> > > > > Change my mind and decide to remove one of the cache listeners:
> > > > > $ alter region --name=data --cache-listener="my.package.
> > ListenerTypeB"
> > > > >
> > > > > -Kirk
> > > > >
> > > > >
> > > > > On Tue, Jan 3, 2017 at 10:52 AM, Kevin Duling 
> > > > wrote:
> > > > >
> > > > > > Is this an intuitive User Experience?
> > > > > >
> > > > > > Given these two classes:
> > > > > >
> > > > > > public class ListenerTypeA extends CacheListenerAdapter
> implements
> > > > > > Declarable
> > > > > >
> > > > > > and
> > > > > >
> > > > > > public class ListenerTypeB extends CacheListenerAdapter
> implements
> > > > > > Declarable
> > > > > >
> > > > > > And they are programmatically added to a region:
> > > > > >
> > > > > > CacheListener listener1 = new ListenerTypeA();
> > > > > >
> > > > > > CacheListener listener2 = new ListenerTypeB();
> > > > > >
> > > > > > Region region = cache. > > > > > Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_
> > > PROXY)
> > > > > >
> > > > > > .initCacheListeners(new CacheListener[]{listener1,
> > > > > > listener2}).create("regionA");
> > > > > >
> > > > > >
> > > > > > What would the expected gfsh command to remove them.  Should we
> > > remove
> > > > > the
> > > > > > listeners via omission?  For example, removing listener1 might
> be:
> > > > > >
> > > > > > alter region --name=data --cache-listener='my.package.
> > ListenerTypeB'
> > > > > >
> > > > > >
> > > > > > By only listing the listeners I want...either to keep and/or to
> > add,
> > > > > > listener1 which is a ListenerTypeA, would be removed.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling <
> kdul...@pivotal.io>
> > > > > wrote:
> > > > > >
> > > > > > > I'm looking at GEODE-2236
> > > > > > >  and
> > protecting
> > > > > > against
> > > > > > > the NPE is trivial.  But the question is, what is the right way
> > to
> > > do
> > > > > > > this?  What is the syntax people would expect to use?
> > > > > > >
> > > > > > >
> > > > > > > What if there are multiple listeners and you wanted to delete
> one
> > > or
> > > > > more
> > > > > > > of them?
> > > > > > >
> > > > > > >
> > > > 

Review Request 55155: GEODE-2155 Auto-reconnect fails with NPE

[Bruce Schuchardt]

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

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


Bugs: geode-2155
https://issues.apache.org/jira/browse/geode-2155


Repository: geode


Description
---

I created a test to reproduce the problem by introducing a non-Declarable cache 
listener and then initiating a forced-disconnect.  cache.xml is generated and 
when it's used to rebuild the cache a CacheXmlException is thrown, reliably 
reproducing the problem.

The fix is to simply catch the CacheXmlException in 
InternalDistributedSystem.reconnect() and terminate reconnection attempts.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 3d51fb92f3f00bb796bca955b32465cdc2e7e768 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
7f5fa328f3542aca89cd51a4cb44b1aef1f08f84 
  geode-core/src/test/java/org/apache/geode/cache30/ReconnectDUnitTest.java 
e324576005ef9530a86ab7b2854c8d4b2a4d9e03 

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


Testing
---


Thanks,

Bruce Schuchardt

[jira] [Assigned] (GEODE-2155) Auto-reconnect fails with NPE

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt reassigned GEODE-2155:
---

Assignee: Bruce Schuchardt

> Auto-reconnect fails with NPE
> -
>
> Key: GEODE-2155
> URL: https://issues.apache.org/jira/browse/GEODE-2155
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>
> The symptom of this bug is
> {noformat}
> [severe 2016/11/29 15:55:42.982 PST gemfire1_carlos_13646  
> tid=0x4d] Unexpected exception while booting membership services
> java.lang.NullPointerException
>   at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.establishLocalAddress(JGroupsMessenger.java:446)
>   at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:342)
>   at 
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:153)
>   at 
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
>   at 
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:683)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2688)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2521)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:989)
>   at 
> org.apache.geode.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4299)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1530)
>   at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$18(GMSMembershipManager.java:2550)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is caused by a previous attempt to recreate the cache in a "reconnect 
> thread" encountered problems
> {noformat}
> [warning 2016/11/29 15:54:42.943 PST gemfire1_carlos_13646  
> tid=0x4d] Exception occurred while trying to create the cache during reconnect
> org.apache.geode.cache.CacheXmlException: While reading Cache XML null. Class 
> "tx.TxLoader" is not an instance of Declarable.
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.createDeclarable(CacheXmlParser.java:1946)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endCacheLoader(CacheXmlParser.java:1997)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.endElement(CacheXmlParser.java:2964)
>   at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser$DefaultHandlerDelegate.endElement(CacheXmlParser.java:3379)
>   at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
>   at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:857)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1783)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2970)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)
>   at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
>   at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
>   at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
>   at 
> 

[jira] [Resolved] (GEODE-2253) Locator may fail to respond to a valid request

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-2253.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> Locator may fail to respond to a valid request
> --
>
> Key: GEODE-2253
> URL: https://issues.apache.org/jira/browse/GEODE-2253
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> When a locator is spinning up it may get a request from a peer process or a 
> client process that it isn't ready to handle.  In some cases it will log a 
> warning that it received a request of class C but is only configured to 
> handle requests of classes X, Y or Z.   It ought to wait and retry for a 
> little while for the service associated with class C to finish initializing.



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

Re: The right way to remove a region's cache listener?

[Kevin Duling]

I must have some syntax wrong, because I'm not able to add a cache listener
from the gfsh command line out of the jar I deployed.

ListenerTypeA and ListenerTypeB exist in the package 'geode' in my
custard-1.0-SNAPSHOT.jar.  I'm able to add those programmatically as I
showed earlier.

So that I could try to add these via gfsh, I changed my region creation
line to:

Region region = cache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY).create("regionA");


Then I go through the standard steps of starting a locator, server, region,
and deploy my jar.

Now when I try to assign the listener, I get:


gfsh>alter region --cache-listener="geode.ListenerTypeA" --name=/regionA

Member | Status

-- |
---

server | ERROR: Could not find class "geode.ListenerTypeA" specified for
"cache-listener".


Am I doing something wrong, or is this not working as expected?  I wasn't
able to find documentation that illustrates how this should work.  The best
I could find was:
http://geode.apache.org/docs/guide/developing/events/cache_event_handler_examples.html


On Tue, Jan 3, 2017 at 11:52 AM, John Blum  wrote:

> `describe region` will show the CacheListeners registered on a Region.
>
> On Tue, Jan 3, 2017 at 11:44 AM, Dave Barnes  wrote:
>
> > What gfsh command (if any) lists the cache-listeners available on a given
> > region? Seems like if the intention is to support adding and deleting by
> > name, there should be a way to list existing names.
> >
> > On Tue, Jan 3, 2017 at 11:29 AM, Jinmei Liao  wrote:
> >
> > > +1 for remove by specifying only the ones you want to keep:
> > >
> > > $ alter region --name=data --cache-listener="" will remove all the
> cache
> > > listeners
> > >
> > > On Tue, Jan 3, 2017 at 11:08 AM, Kirk Lund  wrote:
> > >
> > > > +1 I'm for the approach you're proposing. As long as it's documented
> in
> > > > user docs (it's not currently) then this provides a straightforward
> use
> > > of
> > > > the existing gfsh syntax without introducing too many new command
> > > options.
> > > >
> > > > Create the region with two cache listeners:
> > > > $ create region --name=data
> > > > --cache-listener="my.package.ListenerTypeA,my.package.ListenerTypeB"
> > > >
> > > > Change my mind and decide to remove one of the cache listeners:
> > > > $ alter region --name=data --cache-listener="my.package.
> ListenerTypeB"
> > > >
> > > > -Kirk
> > > >
> > > >
> > > > On Tue, Jan 3, 2017 at 10:52 AM, Kevin Duling 
> > > wrote:
> > > >
> > > > > Is this an intuitive User Experience?
> > > > >
> > > > > Given these two classes:
> > > > >
> > > > > public class ListenerTypeA extends CacheListenerAdapter implements
> > > > > Declarable
> > > > >
> > > > > and
> > > > >
> > > > > public class ListenerTypeB extends CacheListenerAdapter implements
> > > > > Declarable
> > > > >
> > > > > And they are programmatically added to a region:
> > > > >
> > > > > CacheListener listener1 = new ListenerTypeA();
> > > > >
> > > > > CacheListener listener2 = new ListenerTypeB();
> > > > >
> > > > > Region region = cache. > > > > Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_
> > PROXY)
> > > > >
> > > > > .initCacheListeners(new CacheListener[]{listener1,
> > > > > listener2}).create("regionA");
> > > > >
> > > > >
> > > > > What would the expected gfsh command to remove them.  Should we
> > remove
> > > > the
> > > > > listeners via omission?  For example, removing listener1 might be:
> > > > >
> > > > > alter region --name=data --cache-listener='my.package.
> ListenerTypeB'
> > > > >
> > > > >
> > > > > By only listing the listeners I want...either to keep and/or to
> add,
> > > > > listener1 which is a ListenerTypeA, would be removed.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling 
> > > > wrote:
> > > > >
> > > > > > I'm looking at GEODE-2236
> > > > > >  and
> protecting
> > > > > against
> > > > > > the NPE is trivial.  But the question is, what is the right way
> to
> > do
> > > > > > this?  What is the syntax people would expect to use?
> > > > > >
> > > > > >
> > > > > > What if there are multiple listeners and you wanted to delete one
> > or
> > > > more
> > > > > > of them?
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

[jira] [Updated] (GEODE-2263) CliUtil.getRegionAssociatedMembers()'s returnAll parameter is not used

[xiaojian zhou (JIRA)]

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

xiaojian zhou updated GEODE-2263:
-
Description: And DataCommands has a same name method which did use 
returnAll parameter. I think the DataCommands's one should be moved to replace 
the CliUtil's. We should not have 2 methods doing the same thing in 2 different 
class. 

> CliUtil.getRegionAssociatedMembers()'s returnAll parameter is not used
> --
>
> Key: GEODE-2263
> URL: https://issues.apache.org/jira/browse/GEODE-2263
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>
> And DataCommands has a same name method which did use returnAll parameter. I 
> think the DataCommands's one should be moved to replace the CliUtil's. We 
> should not have 2 methods doing the same thing in 2 different class. 



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

Re: The right way to remove a region's cache listener?

[Michael Stolz]

I think it would make sense to have a --remove_listener=ListenerTypeB.
Gfsh is really about verbs not end-state I think.

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

On Tue, Jan 3, 2017 at 1:52 PM, Kevin Duling  wrote:

> Is this an intuitive User Experience?
>
> Given these two classes:
>
> public class ListenerTypeA extends CacheListenerAdapter implements
> Declarable
>
> and
>
> public class ListenerTypeB extends CacheListenerAdapter implements
> Declarable
>
> And they are programmatically added to a region:
>
> CacheListener listener1 = new ListenerTypeA();
>
> CacheListener listener2 = new ListenerTypeB();
>
> Region region = cache. Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
>
> .initCacheListeners(new CacheListener[]{listener1,
> listener2}).create("regionA");
>
>
> What would the expected gfsh command to remove them.  Should we remove the
> listeners via omission?  For example, removing listener1 might be:
>
> alter region --name=data --cache-listener='my.package.ListenerTypeB'
>
>
> By only listing the listeners I want...either to keep and/or to add,
> listener1 which is a ListenerTypeA, would be removed.
>
>
>
>
>
> On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling  wrote:
>
> > I'm looking at GEODE-2236
> >  and protecting
> against
> > the NPE is trivial.  But the question is, what is the right way to do
> > this?  What is the syntax people would expect to use?
> >
> >
> > What if there are multiple listeners and you wanted to delete one or more
> > of them?
> >
> >
>

Re: Review Request 55124: fix duplicate entries from list lucene index and search lucene index

[xiaojian zhou]

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

(Updated Jan. 3, 2017, 10:45 p.m.)


Review request for geode and Dan Smith.


Changes
---

Introduce a parameter returnAll.


Bugs: geode-2241
https://issues.apache.org/jira/browse/geode-2241


Repository: geode


Description
---

list lucene index is at cache level, region might not be ready. But it's a 
light-weigh command, I just filter out the duplicated entries. 

search lucene index currently will be called on all members, which is bad. I 
pick one of the members with region to execute.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java 
4dcf3e0 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
 b3a11fa 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GemfireDataCommandsDUnitTest.java
 66ac8ca 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
 0941834 

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


Testing
---


Thanks,

xiaojian zhou

[jira] [Commented] (GEODE-2042) Add a RMI "Blackboard" into the DUnit framework for VM to communicate over

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-2042:
-

The blackboard was added in this commit:

{quote}
commit 43f376f2a25cc83e9eb3de33ad97f86c4457cc4e
Author: Bruce Schuchardt 
Date:   Tue Jan 3 14:25:29 2017 -0800

GEODE-1580 ci failure: 
GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

Added a dunit blackboard to coordinate creation of a deadlock with the
DistributedLockService.  Removed pauses and added use of Awaitility to
wait for conditions.
{quote}

See JUnit4DistributedTestCase.getBlackboard() and DUnitBlackboard for details.

> Add a RMI "Blackboard" into the DUnit framework for VM to communicate over
> --
>
> Key: GEODE-2042
> URL: https://issues.apache.org/jira/browse/GEODE-2042
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, tests
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Minor
> Fix For: 1.1.0
>
>
> Add a common communications channel into the DUnit Framework that will allow 
> VM's within a DUnit tests to communicate and coordinate over.



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

[jira] [Resolved] (GEODE-2042) Add a RMI "Blackboard" into the DUnit framework for VM to communicate over

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-2042.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> Add a RMI "Blackboard" into the DUnit framework for VM to communicate over
> --
>
> Key: GEODE-2042
> URL: https://issues.apache.org/jira/browse/GEODE-2042
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, tests
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Minor
> Fix For: 1.1.0
>
>
> Add a common communications channel into the DUnit Framework that will allow 
> VM's within a DUnit tests to communicate and coordinate over.



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

[jira] [Resolved] (GEODE-1580) ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-1580.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock
> -
>
> Key: GEODE-1580
> URL: https://issues.apache.org/jira/browse/GEODE-1580
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Hitesh Khamesra
>Assignee: Bruce Schuchardt
>  Labels: CI
> Fix For: 1.1.0
>
>
> https://brazil.gemstone.com:8080/job/Geode_develop_DistributedTests/2969/testReport/com.gemstone.gemfire.distributed.internal.deadlock/GemFireDeadlockDetectorDUnitTest/testDistributedDeadlockWithDLock/
> Skip to content
> titletitle log in
> search
>  
> ENABLE AUTO REFRESH
> Jenkins
> Geode_develop_DistributedTests
> #2969
> Test Results
> com.gemstone.gemfire.distributed.internal.deadlock
> GemFireDeadlockDetectorDUnitTest
> testDistributedDeadlockWithDLock
>  Back to Project
>  Status
>  Changes
>  Console Output
>  View Build Information
>  History
>  Parameters
>  Metadata
>  Environment Variables
>  Git Build Data
>  Test Result
>  Changes since last success
>  Compare environment
>  JS Widgets
>  Previous Build
>  Next Build
> Regression
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock
> Failing for the past 1 build (Since Failed#2969 )
> Took 1 min 4 sec.
>  Failed 2 times in the last 22 runs. Stability: 90 %
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:177)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Updated] (GEODE-1580) ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-1580:

Labels: CI  (was: CI Flaky)

> ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock
> -
>
> Key: GEODE-1580
> URL: https://issues.apache.org/jira/browse/GEODE-1580
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Hitesh Khamesra
>Assignee: Bruce Schuchardt
>  Labels: CI
> Fix For: 1.1.0
>
>
> https://brazil.gemstone.com:8080/job/Geode_develop_DistributedTests/2969/testReport/com.gemstone.gemfire.distributed.internal.deadlock/GemFireDeadlockDetectorDUnitTest/testDistributedDeadlockWithDLock/
> Skip to content
> titletitle log in
> search
>  
> ENABLE AUTO REFRESH
> Jenkins
> Geode_develop_DistributedTests
> #2969
> Test Results
> com.gemstone.gemfire.distributed.internal.deadlock
> GemFireDeadlockDetectorDUnitTest
> testDistributedDeadlockWithDLock
>  Back to Project
>  Status
>  Changes
>  Console Output
>  View Build Information
>  History
>  Parameters
>  Metadata
>  Environment Variables
>  Git Build Data
>  Test Result
>  Changes since last success
>  Compare environment
>  JS Widgets
>  Previous Build
>  Next Build
> Regression
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock
> Failing for the past 1 build (Since Failed#2969 )
> Took 1 min 4 sec.
>  Failed 2 times in the last 22 runs. Stability: 90 %
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:177)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Commented] (GEODE-1580) ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1580:


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

GEODE-1580 ci failure: 
GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

Added a dunit blackboard to coordinate creation of a deadlock with the
DistributedLockService.  Removed pauses and added use of Awaitility to
wait for conditions.


> ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock
> -
>
> Key: GEODE-1580
> URL: https://issues.apache.org/jira/browse/GEODE-1580
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Hitesh Khamesra
>Assignee: Bruce Schuchardt
>  Labels: CI, Flaky
>
> https://brazil.gemstone.com:8080/job/Geode_develop_DistributedTests/2969/testReport/com.gemstone.gemfire.distributed.internal.deadlock/GemFireDeadlockDetectorDUnitTest/testDistributedDeadlockWithDLock/
> Skip to content
> titletitle log in
> search
>  
> ENABLE AUTO REFRESH
> Jenkins
> Geode_develop_DistributedTests
> #2969
> Test Results
> com.gemstone.gemfire.distributed.internal.deadlock
> GemFireDeadlockDetectorDUnitTest
> testDistributedDeadlockWithDLock
>  Back to Project
>  Status
>  Changes
>  Console Output
>  View Build Information
>  History
>  Parameters
>  Metadata
>  Environment Variables
>  Git Build Data
>  Test Result
>  Changes since last success
>  Compare environment
>  JS Widgets
>  Previous Build
>  Next Build
> Regression
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock
> Failing for the past 1 build (Since Failed#2969 )
> Took 1 min 4 sec.
>  Failed 2 times in the last 22 runs. Stability: 90 %
> Error Message
> java.lang.AssertionError
> Stacktrace
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> com.gemstone.gemfire.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:177)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>

Re: geode-examples vs geode/geode-examples

[Joey McAllister]

+1 to moving the existing examples from the module to the new repo and then
editing/replacing them as appropriate.

On Tue, Jan 3, 2017 at 2:02 PM Kirk Lund  wrote:

> What's the plan for the new geode-examples repo and the existing
> geode-examples module of the geode repo? Are we planning to move examples
> and then delete geode/geode-examples?
>
> -Kirk
>

Re: geode-examples vs geode/geode-examples

[Karen Miller]

Yes.  I'm moving everything over now, and after moving will remove it from
the
geode repository.  See https://issues.apache.org/jira/browse/GEODE-2260.

On Tue, Jan 3, 2017 at 2:02 PM, Kirk Lund  wrote:

> What's the plan for the new geode-examples repo and the existing
> geode-examples module of the geode repo? Are we planning to move examples
> and then delete geode/geode-examples?
>
> -Kirk
>

geode-examples vs geode/geode-examples

[Kirk Lund]

What's the plan for the new geode-examples repo and the existing
geode-examples module of the geode repo? Are we planning to move examples
and then delete geode/geode-examples?

-Kirk

Re: Review Request 55074: GEODE-2253 Locator may fail to respond to a valid request

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Dec. 28, 2016, 5:15 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55074/
> ---
> 
> (Updated Dec. 28, 2016, 5:15 p.m.)
> 
> 
> Review request for geode, Udo Kohlmeyer and Dan Smith.
> 
> 
> Bugs: GEODE-2238 and GEODE-2253
> https://issues.apache.org/jira/browse/GEODE-2238
> https://issues.apache.org/jira/browse/GEODE-2253
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> __Background__
> 
> Initially the Locator had but one service - peer-location.
> 
> When connection pools were added to client caches a server-location service 
> was added to the locator, which boots up after the peer location service and 
> isn't actually available until after StartupMessages have been exchanged.  
> During the interval between joining and StartupMessage exchange the handler 
> for server-location messages isn't available and the Locator used to log a 
> warning.  I fixed that by supressing the warning if we knew that 
> server-location was going to be enabled.
> 
> Now a Cluster Configuration service has been added that isn't initialized and 
> available until some time after a Cache has been created in the Locator, 
> which is an even longer gap than the server-location service had.  During 
> this time a new member might join and try to get the shared configuration 
> from the locator.  The locator then logs a warning and does not respond, so 
> the new member ends up shutting down.
> 
> __The Fix__
> 
> This introduces a retry loop in the locator when a handler for an incoming 
> message can't be found.  It waits for an amount of time for the handler to be 
> installed, which I've set to the locator-wait-time or 5 seconds if that 
> property hasn't been set.
> 
> I've also changed InternalLocator to always install the handler for cluster 
> configuration status so that you can query any locator to see if it has a 
> cluster configuration service and, if so, what state it's in.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalLocator.java
>  59488ad66e861fde67840f75dae413f247c821f4 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
>  83fdd0b1697f541034a91e02e1e0c96de4493cd0 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorJUnitTest.java 
> 65f09476ff06542739c63147dab29b71d5550dd0 
> 
> Diff: https://reviews.apache.org/r/55074/diff/
> 
> 
> Testing
> ---
> 
> precheckin, new unit test
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 55106: GEODE-1580 ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Jan. 3, 2017, 6:03 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55106/
> ---
> 
> (Updated Jan. 3, 2017, 6:03 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-1580
> https://issues.apache.org/jira/browse/GEODE-1580
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added a dunit blackboard to coordinate creation of a deadlock with the 
> DistributedLockService.  Removed pauses and added use of Awaitility to wait 
> for conditions.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  17ec800517066b1a7564a91be10c7d659f24a8fb 
>   geode-core/src/test/java/org/apache/geode/test/dunit/DUnitBlackboard.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/DUnitBlackboardDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/InternalBlackboard.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/InternalBlackboardImpl.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/JUnit4DistributedTestCase.java
>  ebbb2fd5fffd5b4e1120a05c5103698b6be9e1f5 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/ChildVM.java 
> 7a9d7f00ff2efcdb811217c5dd42baeebe862685 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  5a80a64f82ad0d7ed6e22c06e006e82d7d1e9d95 
> 
> Diff: https://reviews.apache.org/r/55106/diff/
> 
> 
> Testing
> ---
> 
> Running precheckin since some dunit infrastructure was modified
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 55106: GEODE-1580 ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

[Hitesh Khamesra]

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


Ship it!




Ship It!

- Hitesh Khamesra


On Jan. 3, 2017, 6:03 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55106/
> ---
> 
> (Updated Jan. 3, 2017, 6:03 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo 
> Kohlmeyer.
> 
> 
> Bugs: GEODE-1580
> https://issues.apache.org/jira/browse/GEODE-1580
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added a dunit blackboard to coordinate creation of a deadlock with the 
> DistributedLockService.  Removed pauses and added use of Awaitility to wait 
> for conditions.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  17ec800517066b1a7564a91be10c7d659f24a8fb 
>   geode-core/src/test/java/org/apache/geode/test/dunit/DUnitBlackboard.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/DUnitBlackboardDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/InternalBlackboard.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/InternalBlackboardImpl.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/JUnit4DistributedTestCase.java
>  ebbb2fd5fffd5b4e1120a05c5103698b6be9e1f5 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/ChildVM.java 
> 7a9d7f00ff2efcdb811217c5dd42baeebe862685 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
>  5a80a64f82ad0d7ed6e22c06e006e82d7d1e9d95 
> 
> Diff: https://reviews.apache.org/r/55106/diff/
> 
> 
> Testing
> ---
> 
> Running precheckin since some dunit infrastructure was modified
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Fixed: apache/geode#1714 (develop - 3200447)

[Travis CI]

Build Update for apache/geode
-

Build: #1714
Status: Fixed

Duration: 9 minutes and 8 seconds
Commit: 3200447 (develop)
Author: Jinmei Liao
Message: spotless fix

View the changeset: 
https://github.com/apache/geode/compare/30891423d83b...32004475460b

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

--

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

[jira] [Created] (GEODE-2262) Improve cluster config: do not allow mix of locators that has CC enabled and not enabled in one cluster.

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2262:
--

 Summary: Improve cluster config: do not allow mix of locators that 
has CC enabled and not enabled in one cluster.
 Key: GEODE-2262
 URL: https://issues.apache.org/jira/browse/GEODE-2262
 Project: Geode
  Issue Type: Sub-task
Reporter: Jinmei Liao


When a locator is started with CC enabled, do not allow another locator without 
CC to join it or vise versa.



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

[jira] [Resolved] (GEODE-2197) Refactor cluster config so that cluster.xml and properties don't need to be saved in the file system.

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2197.

Resolution: Fixed

> Refactor cluster config so that cluster.xml and properties don't need to be 
> saved in the file system.
> -
>
> Key: GEODE-2197
> URL: https://issues.apache.org/jira/browse/GEODE-2197
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jared Stewart
>




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

Broken: apache/geode#1713 (develop - 3089142)

[Travis CI]

Build Update for apache/geode
-

Build: #1713
Status: Broken

Duration: 8 minutes and 26 seconds
Commit: 3089142 (develop)
Author: Jinmei Liao
Message: GEODE-2197: refactor cluster config and fix the test failures

View the changeset: 
https://github.com/apache/geode/compare/017db36d2fc7...30891423d83b

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

--

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

[jira] [Assigned] (GEODE-2261) refactor ClusterConfigWriter do not need to use remote call to change cluster config

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2261:
--

Assignee: Jinmei Liao

> refactor ClusterConfigWriter do not need to use remote call to change cluster 
> config
> 
>
> Key: GEODE-2261
> URL: https://issues.apache.org/jira/browse/GEODE-2261
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>
> Currently the ClusterConfigWriter gets a list of locators with CC enabled and 
> uses remote function calls to change CC. Since it's very uncommon that a 
> cluster would have a mix of locators with and without CC. We should just 
> change the CC on the current locator. If, in the rare case of this locator 
> not having cc enabled, we will just output a warning message.



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

[jira] [Commented] (GEODE-2197) Refactor cluster config so that cluster.xml and properties don't need to be saved in the file system.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2197:


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

GEODE-2197: refactor cluster config and fix the test failures


> Refactor cluster config so that cluster.xml and properties don't need to be 
> saved in the file system.
> -
>
> Key: GEODE-2197
> URL: https://issues.apache.org/jira/browse/GEODE-2197
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jared Stewart
>




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

[jira] [Commented] (GEODE-2197) Refactor cluster config so that cluster.xml and properties don't need to be saved in the file system.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2197:


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

GEODE-2197: refactor cluster config

 * not to save the xml, properties in the file system.
 * the cc region's change listener is to download the jar from other locators


> Refactor cluster config so that cluster.xml and properties don't need to be 
> saved in the file system.
> -
>
> Key: GEODE-2197
> URL: https://issues.apache.org/jira/browse/GEODE-2197
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Jared Stewart
>




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

[jira] [Updated] (GEODE-2261) refactor ClusterConfigWriter do not need to use remote call to change cluster config

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-2261:
---
Summary: refactor ClusterConfigWriter do not need to use remote call to 
change cluster config  (was: ClusterConfigWriter do not need to use remote call 
to change cluster config)

> refactor ClusterConfigWriter do not need to use remote call to change cluster 
> config
> 
>
> Key: GEODE-2261
> URL: https://issues.apache.org/jira/browse/GEODE-2261
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>
> Currently the ClusterConfigWriter gets a list of locators with CC enabled and 
> uses remote function calls to change CC. Since it's very uncommon that a 
> cluster would have a mix of locators with and without CC. We should just 
> change the CC on the current locator. If, in the rare case of this locator 
> not having cc enabled, we will just output a warning message.



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

Re: Off-Heap Annotations

[Kirk Lund]

Oh yeah! We were hoping to get more feedback from users to find out what
they want or need for migrating a region from heap to off-heap. Right now
it doesn't support anything like that but it was definitely discussed.


On Tue, Jan 3, 2017 at 12:27 PM, Hitesh Khamesra <
hitesh...@yahoo.com.invalid> wrote:

> I was considering the case when one want to change its "value" through
> rolling upgrade. In an ideal world, I would expect that every node will
> have the same heap/off configuration, but other can happen.
>
>
>
>   From: Kirk Lund 
>  To: geode 
>  Sent: Tuesday, January 3, 2017 12:16 PM
>  Subject: Re: Off-Heap Annotations
>
> The region is required to be off-heap in every member in the cluster.
> Imagine memberA with 12 GB heap, 100 GB off-heap and memberB with 8 GB
> heap, 0 GB off-heap. What's the point of having replicated regionA be
> off-heap in memberA but on heap in memberB? The region will always be
> limited by the heap size of memberB. More importantly, the ResourceManager
> would not handle things correctly unless regionA is consistently off-heap
> in every member. The documentation also recommends that every member have
> the same off-heap-memory-size because of the way the ResourceManager is
> implemented as well. Any major differences in memory size between members
> is a good way to cause one or more of them to run out of memory unless you
> constrain the amount of data that can go into the region in some way.
>
>
> On Tue, Jan 3, 2017 at 11:51 AM, Hitesh Khamesra <
> hitesh...@yahoo.com.invalid> wrote:
>
> > >>>The first cluster member to create the region
> > wins and all the other members need to conform to the first one's
> > configuration.
> > Is there any technical reason to check this? Or we just want same
> > configuration across cluster.
> >
> >  From: Darrel Schneider 
> >  To: dev@geode.apache.org
> >  Sent: Tuesday, January 3, 2017 11:33 AM
> >  Subject: Re: Off-Heap Annotations
> >
> > When a region is created you need to mark it as off-heap or on-heap. Once
> > it is created you can not change it on that region.
> > You can create and destroy regions on the fly.
> >
> > c
> >
> > On Tue, Jan 3, 2017 at 8:01 AM, Dor Ben Dov 
> > wrote:
> >
> > > Udo,
> > >
> > > This means it can't be changed on the fly in runtime ? Need to be
> flagged
> > > before?
> > >
> > > Dor
> > >
> > > -Original Message-
> > > From: Udo Kohlmeyer [mailto:u...@apache.org]
> > > Sent: יום ג 03 ינואר 2017 17:32
> > > To: dev@geode.apache.org
> > > Subject: Re: Off-Heap Annotations
> > >
> > > Hi there Gal,
> > >
> > > That is not possible. A region is either on-heap or off-heap.
> > >
> > > --Udo
> > >
> > >
> > > On 1/2/17 13:50, Gal Palmery wrote:
> > > > Ok,
> > > > So if I want to have just a certain part of the region off heap and
> the
> > > rest of it on heap - how do I do that?
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Dan Smith [mailto:dsm...@pivotal.io]
> > > > Sent: Monday, January 02, 2017 19:46
> > > > To: dev@geode.apache.org
> > > > Subject: Re: Off-Heap Annotations
> > > >
> > > > Hi Gal,
> > > >
> > > > The way to control what is on or off heap is when you configure a
> > region.
> > > > Regions that are configured with off-heap=true will store all of the
> > > values in off heap memory, regions with off-heap= false will store the
> > > values on the heap.
> > > >
> > > > -Dan
> > > >
> > > > On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery 
> > > wrote:
> > > >
> > > >> Thanks Kirk.
> > > >>
> > > >> for example, before I call put, I'd like to indicate to geode server
> > > >> that I want to keep specific data off heap. how can I do that?
> > > >> is there an api that will move data off or on heap?
> > > >>
> > > >> Gal
> > > >>
> > > >> -Original Message-
> > > >> From: Kirk Lund [mailto:kl...@apache.org]
> > > >> Sent: Tuesday, December 27, 2016 06:33
> > > >> To: dev@geode.apache.org
> > > >> Subject: Re: Off-Heap Annotations
> > > >>
> > > >> Those annotations are part of the internal implementation of Geode.
> > > >> The developers used it as a way to help keep track of references to
> > > off-heap.
> > > >>
> > > >> -Kirk
> > > >>
> > > >>
> > > >> On Mon, Dec 26, 2016 at 1:34 AM, Gal Palmery <
> gal.palm...@amdocs.com>
> > > >> wrote:
> > > >>
> > > >>> Hi everyone,
> > > >>>
> > > >>> Is this feature:
> > > >>> https://cwiki.apache.org/confluence/display/GEODE/Off-
> Heap+Annotatio
> > > >>> ns a part of the last release? (1.0.0-incubating)
> > > >>>
> > > >>> thanks,
> > > >>> Gal
> > > >>>
> > > >>> This message and the information contained herein is proprietary
> and
> > > >>> confidential and subject to the Amdocs policy statement, you may
> > > >>> review at http://www.amdocs.com/email_disclaimer.asp
> > > >>>
> > > >> This message and the information contained herein is proprietary and
> > > >> confidential 

Re: Cluster Config

[William Markito Oliveira]

+1 -  Configuration should be consistent on the locators, specially cause
we should consider them source of truth for "distributed configuration"
anyway...

On Tue, Jan 3, 2017 at 1:59 PM, Swapnil Bawaskar 
wrote:

> I think we should not allow a mix of cc enabled or disabled across any
> member in the cluster (servers as well as locators)
> https://issues.apache.org/jira/browse/GEODE-1961.
>
> On Tue, Jan 3, 2017 at 11:25 AM, Jinmei Liao  wrote:
>
> > yeah, the reason we have issue2 is because of issue1, if we fix issue1,
> > then local changes are definitely more welcome than remote calls. The
> whole
> > idea of proposing change#2 is to get rid of some of the silliness of the
> > implementation. Change #2 would get rid of 4or 5 remote functions class
> at
> > least. The only change is that when user is connected to a locator
> without
> > CC, the command will get a output message saying "CC is not affected",
> but
> > we all know it's a rare case anyway.
> >
> > On Tue, Jan 3, 2017 at 10:41 AM, Jacob Barrett 
> > wrote:
> >
> > > If you fix issue 1 do you really need to change 2? I agree it is silly
> > that
> > > it remotes to another locator to execute the CC change but would it
> have
> > > any effect should all the locators be configured the same?
> > >
> > >
> > >
> > > On Tue, Jan 3, 2017 at 10:29 AM Jinmei Liao  wrote:
> > >
> > > > Ok, currently we have 2 issues:
> > > > 1) a cluster might have a mix of locators with and without CC
> enabled.
> > > The
> > > > change proposed is to reject locator that does not CC enabled to
> join a
> > > > locator that has CC enabled (or vise versa).
> > > > 2) commands that change CC does remote calls to a locator with CC to
> > > change
> > > > the cluster config. The change proposed is to simply do it on the
> > current
> > > > locator.
> > > >
> > > > Fix for issue 2 is NOT a workaround for issue 1, it's a step towards
> > > fixing
> > > > issue 1. No matter we fix issue 1 or not, change for issue 2 is
> needed.
> > > >
> > > >
> > > > On Tue, Jan 3, 2017 at 10:18 AM, Jacob Barrett 
> > > > wrote:
> > > >
> > > > > I am not a fan of complicated work arounds for things like this.
> > Feels
> > > > like
> > > > > a lot of moving parts to address something that was more likely a
> > > > careless
> > > > > oversight than an intended use case. Why do you feel like we can't
> > > > address
> > > > > the underlying issue?
> > > > >
> > > > >
> > > > > On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao 
> > wrote:
> > > > >
> > > > > > Currently our API or gfsh commands allow you to create a cluster
> > > with a
> > > > > mix
> > > > > > of locators with and without CC. Our DM maintains a list of
> > locators
> > > > and
> > > > > a
> > > > > > separate list of locators with CC enabled. It is bad, I know.
> But I
> > > am
> > > > > not
> > > > > > sure if we can change it.
> > > > > >
> > > > > > Assuming we have to live with cluster with mix of locators, would
> > my
> > > > > > proposal make sense?
> > > > > >
> > > > > > On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer 
> > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > I think that the configurations of all locators should be
> > > identical,
> > > > or
> > > > > > at
> > > > > > > least in terms of a few "critical" properties. One would also
> > need
> > > to
> > > > > be
> > > > > > > able to amend some property changes at runtime, to allow for
> the
> > > > > changing
> > > > > > > of configuration without taking all the locators offline.
> > > > > > "remote-locators"
> > > > > > > would be a good candidate.
> > > > > > >
> > > > > > > --Udo
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 1/3/17 09:50, Jacob Barrett wrote:
> > > > > > >
> > > > > > >> If we consider the locators as the directory service for the
> > > cluster
> > > > > > then
> > > > > > >> it makes no sense for them to be configured differently. I
> think
> > > > > > locators
> > > > > > >> should be force to adopt the configuration of the other
> locator
> > in
> > > > the
> > > > > > >> cluster or refuse to join the cluster until their config is
> > > updated
> > > > to
> > > > > > >> match.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  >
> > > > wrote:
> > > > > > >>
> > > > > > >> Calling all the pros with knowledge on cluster configurations:
> > > > > > >>>
> > > > > > >>> This is regarding this current behavior of Cluster Config:
> > > > Assuming a
> > > > > > >>> cluster has 2 locators, locator-A-with-CC (with cluster
> config
> > > > > > enabled),
> > > > > > >>> and locator-B-without-CC (without cluster config enabled),
> > > > currently
> > > > > > any
> > > > > > >>> commands a user executes through Gfsh that affects cluster
> > config
> > > > > > (create
> > > > > > >>> region, deploy/undeploy 

Re: Off-Heap Annotations

[Hitesh Khamesra]

I was considering the case when one want to change its "value" through rolling 
upgrade. In an ideal world, I would expect that every node will have the same 
heap/off configuration, but other can happen.



  From: Kirk Lund 
 To: geode  
 Sent: Tuesday, January 3, 2017 12:16 PM
 Subject: Re: Off-Heap Annotations
   
The region is required to be off-heap in every member in the cluster.
Imagine memberA with 12 GB heap, 100 GB off-heap and memberB with 8 GB
heap, 0 GB off-heap. What's the point of having replicated regionA be
off-heap in memberA but on heap in memberB? The region will always be
limited by the heap size of memberB. More importantly, the ResourceManager
would not handle things correctly unless regionA is consistently off-heap
in every member. The documentation also recommends that every member have
the same off-heap-memory-size because of the way the ResourceManager is
implemented as well. Any major differences in memory size between members
is a good way to cause one or more of them to run out of memory unless you
constrain the amount of data that can go into the region in some way.


On Tue, Jan 3, 2017 at 11:51 AM, Hitesh Khamesra <
hitesh...@yahoo.com.invalid> wrote:

> >>>The first cluster member to create the region
> wins and all the other members need to conform to the first one's
> configuration.
> Is there any technical reason to check this? Or we just want same
> configuration across cluster.
>
>      From: Darrel Schneider 
>  To: dev@geode.apache.org
>  Sent: Tuesday, January 3, 2017 11:33 AM
>  Subject: Re: Off-Heap Annotations
>
> When a region is created you need to mark it as off-heap or on-heap. Once
> it is created you can not change it on that region.
> You can create and destroy regions on the fly.
>
> c
>
> On Tue, Jan 3, 2017 at 8:01 AM, Dor Ben Dov 
> wrote:
>
> > Udo,
> >
> > This means it can't be changed on the fly in runtime ? Need to be flagged
> > before?
> >
> > Dor
> >
> > -Original Message-
> > From: Udo Kohlmeyer [mailto:u...@apache.org]
> > Sent: יום ג 03 ינואר 2017 17:32
> > To: dev@geode.apache.org
> > Subject: Re: Off-Heap Annotations
> >
> > Hi there Gal,
> >
> > That is not possible. A region is either on-heap or off-heap.
> >
> > --Udo
> >
> >
> > On 1/2/17 13:50, Gal Palmery wrote:
> > > Ok,
> > > So if I want to have just a certain part of the region off heap and the
> > rest of it on heap - how do I do that?
> > >
> > >
> > >
> > > -Original Message-
> > > From: Dan Smith [mailto:dsm...@pivotal.io]
> > > Sent: Monday, January 02, 2017 19:46
> > > To: dev@geode.apache.org
> > > Subject: Re: Off-Heap Annotations
> > >
> > > Hi Gal,
> > >
> > > The way to control what is on or off heap is when you configure a
> region.
> > > Regions that are configured with off-heap=true will store all of the
> > values in off heap memory, regions with off-heap= false will store the
> > values on the heap.
> > >
> > > -Dan
> > >
> > > On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery 
> > wrote:
> > >
> > >> Thanks Kirk.
> > >>
> > >> for example, before I call put, I'd like to indicate to geode server
> > >> that I want to keep specific data off heap. how can I do that?
> > >> is there an api that will move data off or on heap?
> > >>
> > >> Gal
> > >>
> > >> -Original Message-
> > >> From: Kirk Lund [mailto:kl...@apache.org]
> > >> Sent: Tuesday, December 27, 2016 06:33
> > >> To: dev@geode.apache.org
> > >> Subject: Re: Off-Heap Annotations
> > >>
> > >> Those annotations are part of the internal implementation of Geode.
> > >> The developers used it as a way to help keep track of references to
> > off-heap.
> > >>
> > >> -Kirk
> > >>
> > >>
> > >> On Mon, Dec 26, 2016 at 1:34 AM, Gal Palmery 
> > >> wrote:
> > >>
> > >>> Hi everyone,
> > >>>
> > >>> Is this feature:
> > >>> https://cwiki.apache.org/confluence/display/GEODE/Off-Heap+Annotatio
> > >>> ns a part of the last release? (1.0.0-incubating)
> > >>>
> > >>> thanks,
> > >>> Gal
> > >>>
> > >>> This message and the information contained herein is proprietary and
> > >>> confidential and subject to the Amdocs policy statement, you may
> > >>> review at http://www.amdocs.com/email_disclaimer.asp
> > >>>
> > >> This message and the information contained herein is proprietary and
> > >> confidential and subject to the Amdocs policy statement,
> > >>
> > >> you may review at http://www.amdocs.com/email_disclaimer.asp
> > >>
> > > This message and the information contained herein is proprietary and
> > > confidential and subject to the Amdocs policy statement,
> > >
> > > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
> >
>
>
>

   

Re: Cluster Config

[Swapnil Bawaskar]

I think we should not allow a mix of cc enabled or disabled across any
member in the cluster (servers as well as locators)
https://issues.apache.org/jira/browse/GEODE-1961.

On Tue, Jan 3, 2017 at 11:25 AM, Jinmei Liao  wrote:

> yeah, the reason we have issue2 is because of issue1, if we fix issue1,
> then local changes are definitely more welcome than remote calls. The whole
> idea of proposing change#2 is to get rid of some of the silliness of the
> implementation. Change #2 would get rid of 4or 5 remote functions class at
> least. The only change is that when user is connected to a locator without
> CC, the command will get a output message saying "CC is not affected", but
> we all know it's a rare case anyway.
>
> On Tue, Jan 3, 2017 at 10:41 AM, Jacob Barrett 
> wrote:
>
> > If you fix issue 1 do you really need to change 2? I agree it is silly
> that
> > it remotes to another locator to execute the CC change but would it have
> > any effect should all the locators be configured the same?
> >
> >
> >
> > On Tue, Jan 3, 2017 at 10:29 AM Jinmei Liao  wrote:
> >
> > > Ok, currently we have 2 issues:
> > > 1) a cluster might have a mix of locators with and without CC enabled.
> > The
> > > change proposed is to reject locator that does not CC enabled to join a
> > > locator that has CC enabled (or vise versa).
> > > 2) commands that change CC does remote calls to a locator with CC to
> > change
> > > the cluster config. The change proposed is to simply do it on the
> current
> > > locator.
> > >
> > > Fix for issue 2 is NOT a workaround for issue 1, it's a step towards
> > fixing
> > > issue 1. No matter we fix issue 1 or not, change for issue 2 is needed.
> > >
> > >
> > > On Tue, Jan 3, 2017 at 10:18 AM, Jacob Barrett 
> > > wrote:
> > >
> > > > I am not a fan of complicated work arounds for things like this.
> Feels
> > > like
> > > > a lot of moving parts to address something that was more likely a
> > > careless
> > > > oversight than an intended use case. Why do you feel like we can't
> > > address
> > > > the underlying issue?
> > > >
> > > >
> > > > On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao 
> wrote:
> > > >
> > > > > Currently our API or gfsh commands allow you to create a cluster
> > with a
> > > > mix
> > > > > of locators with and without CC. Our DM maintains a list of
> locators
> > > and
> > > > a
> > > > > separate list of locators with CC enabled. It is bad, I know. But I
> > am
> > > > not
> > > > > sure if we can change it.
> > > > >
> > > > > Assuming we have to live with cluster with mix of locators, would
> my
> > > > > proposal make sense?
> > > > >
> > > > > On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer 
> > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > I think that the configurations of all locators should be
> > identical,
> > > or
> > > > > at
> > > > > > least in terms of a few "critical" properties. One would also
> need
> > to
> > > > be
> > > > > > able to amend some property changes at runtime, to allow for the
> > > > changing
> > > > > > of configuration without taking all the locators offline.
> > > > > "remote-locators"
> > > > > > would be a good candidate.
> > > > > >
> > > > > > --Udo
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 1/3/17 09:50, Jacob Barrett wrote:
> > > > > >
> > > > > >> If we consider the locators as the directory service for the
> > cluster
> > > > > then
> > > > > >> it makes no sense for them to be configured differently. I think
> > > > > locators
> > > > > >> should be force to adopt the configuration of the other locator
> in
> > > the
> > > > > >> cluster or refuse to join the cluster until their config is
> > updated
> > > to
> > > > > >> match.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao 
> > > wrote:
> > > > > >>
> > > > > >> Calling all the pros with knowledge on cluster configurations:
> > > > > >>>
> > > > > >>> This is regarding this current behavior of Cluster Config:
> > > Assuming a
> > > > > >>> cluster has 2 locators, locator-A-with-CC (with cluster config
> > > > > enabled),
> > > > > >>> and locator-B-without-CC (without cluster config enabled),
> > > currently
> > > > > any
> > > > > >>> commands a user executes through Gfsh that affects cluster
> config
> > > > > (create
> > > > > >>> region, deploy/undeploy etc) will change cluster config no
> matter
> > > > which
> > > > > >>> locator he connects to.
> > > > > >>>
> > > > > >>> The implementation of this behavior is quite complicated: the
> > > command
> > > > > >>> needs
> > > > > >>> to:
> > > > > >>>
> > > > > >>> 1. find out from DM if there is any locator that has CC enabled
> > > (the
> > > > DM
> > > > > >>> needs to maintain a flag simply for this purpose).
> > > > > >>> 2. find out from DM the list of locators that has CC enabled.
> > > > > >>> 3. loop through this 

Re: The right way to remove a region's cache listener?

[John Blum]

`describe region` will show the CacheListeners registered on a Region.

On Tue, Jan 3, 2017 at 11:44 AM, Dave Barnes  wrote:

> What gfsh command (if any) lists the cache-listeners available on a given
> region? Seems like if the intention is to support adding and deleting by
> name, there should be a way to list existing names.
>
> On Tue, Jan 3, 2017 at 11:29 AM, Jinmei Liao  wrote:
>
> > +1 for remove by specifying only the ones you want to keep:
> >
> > $ alter region --name=data --cache-listener="" will remove all the cache
> > listeners
> >
> > On Tue, Jan 3, 2017 at 11:08 AM, Kirk Lund  wrote:
> >
> > > +1 I'm for the approach you're proposing. As long as it's documented in
> > > user docs (it's not currently) then this provides a straightforward use
> > of
> > > the existing gfsh syntax without introducing too many new command
> > options.
> > >
> > > Create the region with two cache listeners:
> > > $ create region --name=data
> > > --cache-listener="my.package.ListenerTypeA,my.package.ListenerTypeB"
> > >
> > > Change my mind and decide to remove one of the cache listeners:
> > > $ alter region --name=data --cache-listener="my.package.ListenerTypeB"
> > >
> > > -Kirk
> > >
> > >
> > > On Tue, Jan 3, 2017 at 10:52 AM, Kevin Duling 
> > wrote:
> > >
> > > > Is this an intuitive User Experience?
> > > >
> > > > Given these two classes:
> > > >
> > > > public class ListenerTypeA extends CacheListenerAdapter implements
> > > > Declarable
> > > >
> > > > and
> > > >
> > > > public class ListenerTypeB extends CacheListenerAdapter implements
> > > > Declarable
> > > >
> > > > And they are programmatically added to a region:
> > > >
> > > > CacheListener listener1 = new ListenerTypeA();
> > > >
> > > > CacheListener listener2 = new ListenerTypeB();
> > > >
> > > > Region region = cache. > > > Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_
> PROXY)
> > > >
> > > > .initCacheListeners(new CacheListener[]{listener1,
> > > > listener2}).create("regionA");
> > > >
> > > >
> > > > What would the expected gfsh command to remove them.  Should we
> remove
> > > the
> > > > listeners via omission?  For example, removing listener1 might be:
> > > >
> > > > alter region --name=data --cache-listener='my.package.ListenerTypeB'
> > > >
> > > >
> > > > By only listing the listeners I want...either to keep and/or to add,
> > > > listener1 which is a ListenerTypeA, would be removed.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling 
> > > wrote:
> > > >
> > > > > I'm looking at GEODE-2236
> > > > >  and protecting
> > > > against
> > > > > the NPE is trivial.  But the question is, what is the right way to
> do
> > > > > this?  What is the syntax people would expect to use?
> > > > >
> > > > >
> > > > > What if there are multiple listeners and you wanted to delete one
> or
> > > more
> > > > > of them?
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
-John
john.blum10101 (skype)

Re: The right way to remove a region's cache listener?

[Dave Barnes]

What gfsh command (if any) lists the cache-listeners available on a given
region? Seems like if the intention is to support adding and deleting by
name, there should be a way to list existing names.

On Tue, Jan 3, 2017 at 11:29 AM, Jinmei Liao  wrote:

> +1 for remove by specifying only the ones you want to keep:
>
> $ alter region --name=data --cache-listener="" will remove all the cache
> listeners
>
> On Tue, Jan 3, 2017 at 11:08 AM, Kirk Lund  wrote:
>
> > +1 I'm for the approach you're proposing. As long as it's documented in
> > user docs (it's not currently) then this provides a straightforward use
> of
> > the existing gfsh syntax without introducing too many new command
> options.
> >
> > Create the region with two cache listeners:
> > $ create region --name=data
> > --cache-listener="my.package.ListenerTypeA,my.package.ListenerTypeB"
> >
> > Change my mind and decide to remove one of the cache listeners:
> > $ alter region --name=data --cache-listener="my.package.ListenerTypeB"
> >
> > -Kirk
> >
> >
> > On Tue, Jan 3, 2017 at 10:52 AM, Kevin Duling 
> wrote:
> >
> > > Is this an intuitive User Experience?
> > >
> > > Given these two classes:
> > >
> > > public class ListenerTypeA extends CacheListenerAdapter implements
> > > Declarable
> > >
> > > and
> > >
> > > public class ListenerTypeB extends CacheListenerAdapter implements
> > > Declarable
> > >
> > > And they are programmatically added to a region:
> > >
> > > CacheListener listener1 = new ListenerTypeA();
> > >
> > > CacheListener listener2 = new ListenerTypeB();
> > >
> > > Region region = cache. > > Customer>createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
> > >
> > > .initCacheListeners(new CacheListener[]{listener1,
> > > listener2}).create("regionA");
> > >
> > >
> > > What would the expected gfsh command to remove them.  Should we remove
> > the
> > > listeners via omission?  For example, removing listener1 might be:
> > >
> > > alter region --name=data --cache-listener='my.package.ListenerTypeB'
> > >
> > >
> > > By only listing the listeners I want...either to keep and/or to add,
> > > listener1 which is a ListenerTypeA, would be removed.
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling 
> > wrote:
> > >
> > > > I'm looking at GEODE-2236
> > > >  and protecting
> > > against
> > > > the NPE is trivial.  But the question is, what is the right way to do
> > > > this?  What is the syntax people would expect to use?
> > > >
> > > >
> > > > What if there are multiple listeners and you wanted to delete one or
> > more
> > > > of them?
> > > >
> > > >
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: New proposal for type definitons

[Jacob Barrett]

A little late to the game here but I want to go back to Dan's idea of
storing the JSON or other self describing objects as a first class object
in Geode. As it stands right now an entry can be a POJO, Java serialized
object, or PDX, so why not other types? Seems perfectly reasonable to allow
first class storage of JSON (or BSON) without sacrificing any features that
we support today with PDX or POJO. In fact one could even implement a
version of PdxInstance that wraps a JSON document.

It seems to me that any attempt to add structure to something without
structure is going to give us way more heartache than trying to add support
for truly unstructured data in Geode. We are part of the way there with PDX
since get/set field operations hide any real formal structure.

In my last deep dive into PDX over a year ago it seemed very doable to me
at the time to add support for something like this.

-Jake


On Wed, Dec 28, 2016 at 9:52 AM Udo Kohlmeyer  wrote:

> You are correct here. Ordering the fields would be a simple solution IF
> the only problem was that fields were incorrectly ordered. In most cases
> not all fields are provided thus causing an explosion of type
> definitions that would be generated.
>
>
> On 12/22/16 16:11, Darrel Schneider wrote:
> > When generating a pdx type for a JSON document couldn't we sort the field
> > names from the JSON document so that field order would not generated
> > different pdx types?
> > Also when choosing a pdx field type if we always picked a "wider" type
> then
> > it would reduce the number of types generated because of different field
> > types.
> >
> >
> > On Thu, Dec 22, 2016 at 10:02 AM, Udo Kohlmeyer 
> > wrote:
> >
> >> Hi there Dan,
> >>
> >> You are correct, the thought is there to add a flag to the registry to
> >> indicate that a definition is custom and thus should not conflict with
> the
> >> existing ids. Even if they types were to be stored with the current Pdx
> >> type definitions, upon loading/registration of the custom type
> definitions,
> >> any conflict will be reported and the custom set will not be registered
> >> until all issues were addressed.
> >>
> >> I also had the opinion of the "if they can provide me a typeId, then
> >> surely they can provide me with a fully populated JSON document".
> >> Referencing the example document from the wiki, an user can be created
> with
> >> just a first and surname. It is not required to provide currentAddress,
> >> previousAddresses, dob,etc... Whilst one could force the client to
> provide
> >> all fields in the JSON document, it is not always possible nor feasible
> to
> >> do so. In the POJO world we have a structured data definition and the
> >> generation of a type definition is simple. This done because from a
> >> serialization perspective we always make sure that all fields are
> >> serialized. BUT if we were to change the serialization, i.e not
> serialize a
> >> field because it is null, the type definition behavior would be exactly
> the
> >> same as JSON. Only, in this case, because we changed the type definition
> >> for the 'com.demo.User' object (at runtime) the deserialization step for
> >> previous versions would fail.
> >>
> >> I believe that if we were to be able to describe WHAT the structure of a
> >> JSON document should be and define the type according to that
> definition,
> >> we could improve performance (as we don't have to determine type
> >> definitions for every JSON document), be more flexible in consuming JSON
> >> documents that are only partially populated and lastly not potentially
> >> cause a vast amount of JSON-based type definitions to be generated.
> >>
> >> In addition to just the JSON benefits, having a formal way of describing
> >> the type definitions will allow us to better maintain the current
> >> registered type definitions. In addition to this, it would allow
> >> customers/clients to create type definitions, by hand, if they were to
> have
> >> lost their type registry.
> >>
> >> As  final thought, the addition of the external type registration
> process
> >> is not meant replace the current behavior. But rather enhance its
> >> capabilities. If no external types will have been defined OR the client
> >> does not provide a '@typeId' tag, the current JSON type definition
> behavior
> >> will stay the same.
> >>
> >> --Udo
> >>
> >>
> >> On 12/21/16 18:20, Dan Smith wrote:
> >>
> >>> I'm assuming the type ids here are a different set than the type ids
> used
> >>> with regular PDX serialization so they won't conflict if the pdx
> registry
> >>> assigns 1 to some class and a user puts @typeId: 1 in their json?
> >>>
> >>> I'm concerned that this won't really address the type explosion issue.
> >>> Users that are able to go to the effort of adding these typeIds to all
> of
> >>> their json are probably users that can produce consistently formatted
> json
> >>> in the first place. Users that have inconsistently 

Re: Off-Heap Annotations

[Darrel Schneider]

When a region is created you need to mark it as off-heap or on-heap. Once
it is created you can not change it on that region.
You can create and destroy regions on the fly.

Also the region needs to be consistently configured on-heap or off-heap
across the entire cluster. The first cluster member to create the region
wins and all the other members need to conform to the first one's
configuration.

On Tue, Jan 3, 2017 at 8:01 AM, Dor Ben Dov  wrote:

> Udo,
>
> This means it can't be changed on the fly in runtime ? Need to be flagged
> before?
>
> Dor
>
> -Original Message-
> From: Udo Kohlmeyer [mailto:u...@apache.org]
> Sent: יום ג 03 ינואר 2017 17:32
> To: dev@geode.apache.org
> Subject: Re: Off-Heap Annotations
>
> Hi there Gal,
>
> That is not possible. A region is either on-heap or off-heap.
>
> --Udo
>
>
> On 1/2/17 13:50, Gal Palmery wrote:
> > Ok,
> > So if I want to have just a certain part of the region off heap and the
> rest of it on heap - how do I do that?
> >
> >
> >
> > -Original Message-
> > From: Dan Smith [mailto:dsm...@pivotal.io]
> > Sent: Monday, January 02, 2017 19:46
> > To: dev@geode.apache.org
> > Subject: Re: Off-Heap Annotations
> >
> > Hi Gal,
> >
> > The way to control what is on or off heap is when you configure a region.
> > Regions that are configured with off-heap=true will store all of the
> values in off heap memory, regions with off-heap= false will store the
> values on the heap.
> >
> > -Dan
> >
> > On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery 
> wrote:
> >
> >> Thanks Kirk.
> >>
> >> for example, before I call put, I'd like to indicate to geode server
> >> that I want to keep specific data off heap. how can I do that?
> >> is there an api that will move data off or on heap?
> >>
> >> Gal
> >>
> >> -Original Message-
> >> From: Kirk Lund [mailto:kl...@apache.org]
> >> Sent: Tuesday, December 27, 2016 06:33
> >> To: dev@geode.apache.org
> >> Subject: Re: Off-Heap Annotations
> >>
> >> Those annotations are part of the internal implementation of Geode.
> >> The developers used it as a way to help keep track of references to
> off-heap.
> >>
> >> -Kirk
> >>
> >>
> >> On Mon, Dec 26, 2016 at 1:34 AM, Gal Palmery 
> >> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> Is this feature:
> >>> https://cwiki.apache.org/confluence/display/GEODE/Off-Heap+Annotatio
> >>> ns a part of the last release? (1.0.0-incubating)
> >>>
> >>> thanks,
> >>> Gal
> >>>
> >>> This message and the information contained herein is proprietary and
> >>> confidential and subject to the Amdocs policy statement, you may
> >>> review at http://www.amdocs.com/email_disclaimer.asp
> >>>
> >> This message and the information contained herein is proprietary and
> >> confidential and subject to the Amdocs policy statement,
> >>
> >> you may review at http://www.amdocs.com/email_disclaimer.asp
> >>
> > This message and the information contained herein is proprietary and
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at http://www.amdocs.com/email_disclaimer.asp
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Cluster Config

[Jinmei Liao]

yeah, the reason we have issue2 is because of issue1, if we fix issue1,
then local changes are definitely more welcome than remote calls. The whole
idea of proposing change#2 is to get rid of some of the silliness of the
implementation. Change #2 would get rid of 4or 5 remote functions class at
least. The only change is that when user is connected to a locator without
CC, the command will get a output message saying "CC is not affected", but
we all know it's a rare case anyway.

On Tue, Jan 3, 2017 at 10:41 AM, Jacob Barrett  wrote:

> If you fix issue 1 do you really need to change 2? I agree it is silly that
> it remotes to another locator to execute the CC change but would it have
> any effect should all the locators be configured the same?
>
>
>
> On Tue, Jan 3, 2017 at 10:29 AM Jinmei Liao  wrote:
>
> > Ok, currently we have 2 issues:
> > 1) a cluster might have a mix of locators with and without CC enabled.
> The
> > change proposed is to reject locator that does not CC enabled to join a
> > locator that has CC enabled (or vise versa).
> > 2) commands that change CC does remote calls to a locator with CC to
> change
> > the cluster config. The change proposed is to simply do it on the current
> > locator.
> >
> > Fix for issue 2 is NOT a workaround for issue 1, it's a step towards
> fixing
> > issue 1. No matter we fix issue 1 or not, change for issue 2 is needed.
> >
> >
> > On Tue, Jan 3, 2017 at 10:18 AM, Jacob Barrett 
> > wrote:
> >
> > > I am not a fan of complicated work arounds for things like this. Feels
> > like
> > > a lot of moving parts to address something that was more likely a
> > careless
> > > oversight than an intended use case. Why do you feel like we can't
> > address
> > > the underlying issue?
> > >
> > >
> > > On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao  wrote:
> > >
> > > > Currently our API or gfsh commands allow you to create a cluster
> with a
> > > mix
> > > > of locators with and without CC. Our DM maintains a list of locators
> > and
> > > a
> > > > separate list of locators with CC enabled. It is bad, I know. But I
> am
> > > not
> > > > sure if we can change it.
> > > >
> > > > Assuming we have to live with cluster with mix of locators, would my
> > > > proposal make sense?
> > > >
> > > > On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer 
> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > I think that the configurations of all locators should be
> identical,
> > or
> > > > at
> > > > > least in terms of a few "critical" properties. One would also need
> to
> > > be
> > > > > able to amend some property changes at runtime, to allow for the
> > > changing
> > > > > of configuration without taking all the locators offline.
> > > > "remote-locators"
> > > > > would be a good candidate.
> > > > >
> > > > > --Udo
> > > > >
> > > > >
> > > > >
> > > > > On 1/3/17 09:50, Jacob Barrett wrote:
> > > > >
> > > > >> If we consider the locators as the directory service for the
> cluster
> > > > then
> > > > >> it makes no sense for them to be configured differently. I think
> > > > locators
> > > > >> should be force to adopt the configuration of the other locator in
> > the
> > > > >> cluster or refuse to join the cluster until their config is
> updated
> > to
> > > > >> match.
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao 
> > wrote:
> > > > >>
> > > > >> Calling all the pros with knowledge on cluster configurations:
> > > > >>>
> > > > >>> This is regarding this current behavior of Cluster Config:
> > Assuming a
> > > > >>> cluster has 2 locators, locator-A-with-CC (with cluster config
> > > > enabled),
> > > > >>> and locator-B-without-CC (without cluster config enabled),
> > currently
> > > > any
> > > > >>> commands a user executes through Gfsh that affects cluster config
> > > > (create
> > > > >>> region, deploy/undeploy etc) will change cluster config no matter
> > > which
> > > > >>> locator he connects to.
> > > > >>>
> > > > >>> The implementation of this behavior is quite complicated: the
> > command
> > > > >>> needs
> > > > >>> to:
> > > > >>>
> > > > >>> 1. find out from DM if there is any locator that has CC enabled
> > (the
> > > DM
> > > > >>> needs to maintain a flag simply for this purpose).
> > > > >>> 2. find out from DM the list of locators that has CC enabled.
> > > > >>> 3. loop through this list, execute a remote function on that
> > locator
> > > to
> > > > >>> change the CC. (depending on the nature of the command, the
> > function
> > > is
> > > > >>> different).
> > > > >>> 4. break out of the loop if one execution is successful. (it only
> > > needs
> > > > >>> to
> > > > >>> update only one locator, since the cc region is replicated across
> > > > >>> locators).
> > > > >>>
> > > > >>> Quite often, the locator that ends up executing the function call
> > > will
> > > > >>> the
> > > > >>> be 

Re: The right way to remove a region's cache listener?

[Kevin Duling]

Is this an intuitive User Experience?

Given these two classes:

public class ListenerTypeA extends CacheListenerAdapter implements Declarable

and

public class ListenerTypeB extends CacheListenerAdapter implements Declarable

And they are programmatically added to a region:

CacheListener listener1 = new ListenerTypeA();

CacheListener listener2 = new ListenerTypeB();

Region region = cache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)

.initCacheListeners(new CacheListener[]{listener1,
listener2}).create("regionA");


What would the expected gfsh command to remove them.  Should we remove the
listeners via omission?  For example, removing listener1 might be:

alter region --name=data --cache-listener='my.package.ListenerTypeB'


By only listing the listeners I want...either to keep and/or to add,
listener1 which is a ListenerTypeA, would be removed.





On Tue, Dec 20, 2016 at 2:11 PM, Kevin Duling  wrote:

> I'm looking at GEODE-2236
>  and protecting against
> the NPE is trivial.  But the question is, what is the right way to do
> this?  What is the syntax people would expect to use?
>
>
> What if there are multiple listeners and you wanted to delete one or more
> of them?
>
>

Re: Cluster Config

[Jacob Barrett]

If you fix issue 1 do you really need to change 2? I agree it is silly that
it remotes to another locator to execute the CC change but would it have
any effect should all the locators be configured the same?



On Tue, Jan 3, 2017 at 10:29 AM Jinmei Liao  wrote:

> Ok, currently we have 2 issues:
> 1) a cluster might have a mix of locators with and without CC enabled. The
> change proposed is to reject locator that does not CC enabled to join a
> locator that has CC enabled (or vise versa).
> 2) commands that change CC does remote calls to a locator with CC to change
> the cluster config. The change proposed is to simply do it on the current
> locator.
>
> Fix for issue 2 is NOT a workaround for issue 1, it's a step towards fixing
> issue 1. No matter we fix issue 1 or not, change for issue 2 is needed.
>
>
> On Tue, Jan 3, 2017 at 10:18 AM, Jacob Barrett 
> wrote:
>
> > I am not a fan of complicated work arounds for things like this. Feels
> like
> > a lot of moving parts to address something that was more likely a
> careless
> > oversight than an intended use case. Why do you feel like we can't
> address
> > the underlying issue?
> >
> >
> > On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao  wrote:
> >
> > > Currently our API or gfsh commands allow you to create a cluster with a
> > mix
> > > of locators with and without CC. Our DM maintains a list of locators
> and
> > a
> > > separate list of locators with CC enabled. It is bad, I know. But I am
> > not
> > > sure if we can change it.
> > >
> > > Assuming we have to live with cluster with mix of locators, would my
> > > proposal make sense?
> > >
> > > On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer  wrote:
> > >
> > > > +1
> > > >
> > > > I think that the configurations of all locators should be identical,
> or
> > > at
> > > > least in terms of a few "critical" properties. One would also need to
> > be
> > > > able to amend some property changes at runtime, to allow for the
> > changing
> > > > of configuration without taking all the locators offline.
> > > "remote-locators"
> > > > would be a good candidate.
> > > >
> > > > --Udo
> > > >
> > > >
> > > >
> > > > On 1/3/17 09:50, Jacob Barrett wrote:
> > > >
> > > >> If we consider the locators as the directory service for the cluster
> > > then
> > > >> it makes no sense for them to be configured differently. I think
> > > locators
> > > >> should be force to adopt the configuration of the other locator in
> the
> > > >> cluster or refuse to join the cluster until their config is updated
> to
> > > >> match.
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao 
> wrote:
> > > >>
> > > >> Calling all the pros with knowledge on cluster configurations:
> > > >>>
> > > >>> This is regarding this current behavior of Cluster Config:
> Assuming a
> > > >>> cluster has 2 locators, locator-A-with-CC (with cluster config
> > > enabled),
> > > >>> and locator-B-without-CC (without cluster config enabled),
> currently
> > > any
> > > >>> commands a user executes through Gfsh that affects cluster config
> > > (create
> > > >>> region, deploy/undeploy etc) will change cluster config no matter
> > which
> > > >>> locator he connects to.
> > > >>>
> > > >>> The implementation of this behavior is quite complicated: the
> command
> > > >>> needs
> > > >>> to:
> > > >>>
> > > >>> 1. find out from DM if there is any locator that has CC enabled
> (the
> > DM
> > > >>> needs to maintain a flag simply for this purpose).
> > > >>> 2. find out from DM the list of locators that has CC enabled.
> > > >>> 3. loop through this list, execute a remote function on that
> locator
> > to
> > > >>> change the CC. (depending on the nature of the command, the
> function
> > is
> > > >>> different).
> > > >>> 4. break out of the loop if one execution is successful. (it only
> > needs
> > > >>> to
> > > >>> update only one locator, since the cc region is replicated across
> > > >>> locators).
> > > >>>
> > > >>> Quite often, the locator that ends up executing the function call
> > will
> > > >>> the
> > > >>> be locator that executes the command, but we still need to do the
> > > remote
> > > >>> call. So I am wondering:
> > > >>>
> > > >>> A: What are the use cases where a cluster might have a mix of
> > locators
> > > >>> with
> > > >>> and without CC? Is it quite common?
> > > >>> B: Is there a chance that when a user connects to a locator without
> > CC
> > > >>> enabled, he actually WANTS all the commands he execute WON'T affect
> > CC?
> > > >>> C: Can we change the behavior to B? That is: the commands will only
> > > >>> change
> > > >>> CC only if the user is connected to a locator that has CC enabled?
> > (of
> > > >>> course, we will provide enough warning if the commands are on a
> > locator
> > > >>> without CC telling him that won't affect cluster config. We will
> also
> > > >>> provides commands that will show 

[jira] [Updated] (GEODE-2174) Provide more detailed reason when unregistering clients

[Barry Oglesby (JIRA)]

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

Barry Oglesby updated GEODE-2174:
-
Assignee: Hitesh Khamesra  (was: Barry Oglesby)

> Provide more detailed reason when unregistering clients
> ---
>
> Key: GEODE-2174
> URL: https://issues.apache.org/jira/browse/GEODE-2174
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Barry Oglesby
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> This is the same as GEM-778.
> When a client is unregistered for an abnormal reason, log the reason.
> In previous versions, when a client was unregistered from the server, a 
> message like this was logged:
> {noformat}
> [info 2015/01/07 16:19:55.992 JST cache1  Thread 3> tid=0x44] ClientHealthMonitor: Unregistering client with member id 
> identity(,connection=1
> {noformat}
> Then, that message was eliminated altogether since it was logged when a 
> client left normally as well as abnormally. Now, the request is to add it 
> back in for clients who unregister abnormally.



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

Re: Cluster Config

[Jinmei Liao]

Ok, currently we have 2 issues:
1) a cluster might have a mix of locators with and without CC enabled. The
change proposed is to reject locator that does not CC enabled to join a
locator that has CC enabled (or vise versa).
2) commands that change CC does remote calls to a locator with CC to change
the cluster config. The change proposed is to simply do it on the current
locator.

Fix for issue 2 is NOT a workaround for issue 1, it's a step towards fixing
issue 1. No matter we fix issue 1 or not, change for issue 2 is needed.


On Tue, Jan 3, 2017 at 10:18 AM, Jacob Barrett  wrote:

> I am not a fan of complicated work arounds for things like this. Feels like
> a lot of moving parts to address something that was more likely a careless
> oversight than an intended use case. Why do you feel like we can't address
> the underlying issue?
>
>
> On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao  wrote:
>
> > Currently our API or gfsh commands allow you to create a cluster with a
> mix
> > of locators with and without CC. Our DM maintains a list of locators and
> a
> > separate list of locators with CC enabled. It is bad, I know. But I am
> not
> > sure if we can change it.
> >
> > Assuming we have to live with cluster with mix of locators, would my
> > proposal make sense?
> >
> > On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer  wrote:
> >
> > > +1
> > >
> > > I think that the configurations of all locators should be identical, or
> > at
> > > least in terms of a few "critical" properties. One would also need to
> be
> > > able to amend some property changes at runtime, to allow for the
> changing
> > > of configuration without taking all the locators offline.
> > "remote-locators"
> > > would be a good candidate.
> > >
> > > --Udo
> > >
> > >
> > >
> > > On 1/3/17 09:50, Jacob Barrett wrote:
> > >
> > >> If we consider the locators as the directory service for the cluster
> > then
> > >> it makes no sense for them to be configured differently. I think
> > locators
> > >> should be force to adopt the configuration of the other locator in the
> > >> cluster or refuse to join the cluster until their config is updated to
> > >> match.
> > >>
> > >>
> > >>
> > >> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  wrote:
> > >>
> > >> Calling all the pros with knowledge on cluster configurations:
> > >>>
> > >>> This is regarding this current behavior of Cluster Config: Assuming a
> > >>> cluster has 2 locators, locator-A-with-CC (with cluster config
> > enabled),
> > >>> and locator-B-without-CC (without cluster config enabled), currently
> > any
> > >>> commands a user executes through Gfsh that affects cluster config
> > (create
> > >>> region, deploy/undeploy etc) will change cluster config no matter
> which
> > >>> locator he connects to.
> > >>>
> > >>> The implementation of this behavior is quite complicated: the command
> > >>> needs
> > >>> to:
> > >>>
> > >>> 1. find out from DM if there is any locator that has CC enabled (the
> DM
> > >>> needs to maintain a flag simply for this purpose).
> > >>> 2. find out from DM the list of locators that has CC enabled.
> > >>> 3. loop through this list, execute a remote function on that locator
> to
> > >>> change the CC. (depending on the nature of the command, the function
> is
> > >>> different).
> > >>> 4. break out of the loop if one execution is successful. (it only
> needs
> > >>> to
> > >>> update only one locator, since the cc region is replicated across
> > >>> locators).
> > >>>
> > >>> Quite often, the locator that ends up executing the function call
> will
> > >>> the
> > >>> be locator that executes the command, but we still need to do the
> > remote
> > >>> call. So I am wondering:
> > >>>
> > >>> A: What are the use cases where a cluster might have a mix of
> locators
> > >>> with
> > >>> and without CC? Is it quite common?
> > >>> B: Is there a chance that when a user connects to a locator without
> CC
> > >>> enabled, he actually WANTS all the commands he execute WON'T affect
> CC?
> > >>> C: Can we change the behavior to B? That is: the commands will only
> > >>> change
> > >>> CC only if the user is connected to a locator that has CC enabled?
> (of
> > >>> course, we will provide enough warning if the commands are on a
> locator
> > >>> without CC telling him that won't affect cluster config. We will also
> > >>> provides commands that will show the current state of Cluster Config)
> > >>>
> > >>> This behavior change would greatly simply our implementation of
> cluster
> > >>> config and get rid of lots of spaghetti code.
> > >>>
> > >>> --
> > >>> Cheers
> > >>>
> > >>> Jinmei
> > >>>
> > >>>
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>



-- 
Cheers

Jinmei

Re: Cluster Config

[Jacob Barrett]

I am not a fan of complicated work arounds for things like this. Feels like
a lot of moving parts to address something that was more likely a careless
oversight than an intended use case. Why do you feel like we can't address
the underlying issue?


On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao  wrote:

> Currently our API or gfsh commands allow you to create a cluster with a mix
> of locators with and without CC. Our DM maintains a list of locators and a
> separate list of locators with CC enabled. It is bad, I know. But I am not
> sure if we can change it.
>
> Assuming we have to live with cluster with mix of locators, would my
> proposal make sense?
>
> On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer  wrote:
>
> > +1
> >
> > I think that the configurations of all locators should be identical, or
> at
> > least in terms of a few "critical" properties. One would also need to be
> > able to amend some property changes at runtime, to allow for the changing
> > of configuration without taking all the locators offline.
> "remote-locators"
> > would be a good candidate.
> >
> > --Udo
> >
> >
> >
> > On 1/3/17 09:50, Jacob Barrett wrote:
> >
> >> If we consider the locators as the directory service for the cluster
> then
> >> it makes no sense for them to be configured differently. I think
> locators
> >> should be force to adopt the configuration of the other locator in the
> >> cluster or refuse to join the cluster until their config is updated to
> >> match.
> >>
> >>
> >>
> >> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  wrote:
> >>
> >> Calling all the pros with knowledge on cluster configurations:
> >>>
> >>> This is regarding this current behavior of Cluster Config: Assuming a
> >>> cluster has 2 locators, locator-A-with-CC (with cluster config
> enabled),
> >>> and locator-B-without-CC (without cluster config enabled), currently
> any
> >>> commands a user executes through Gfsh that affects cluster config
> (create
> >>> region, deploy/undeploy etc) will change cluster config no matter which
> >>> locator he connects to.
> >>>
> >>> The implementation of this behavior is quite complicated: the command
> >>> needs
> >>> to:
> >>>
> >>> 1. find out from DM if there is any locator that has CC enabled (the DM
> >>> needs to maintain a flag simply for this purpose).
> >>> 2. find out from DM the list of locators that has CC enabled.
> >>> 3. loop through this list, execute a remote function on that locator to
> >>> change the CC. (depending on the nature of the command, the function is
> >>> different).
> >>> 4. break out of the loop if one execution is successful. (it only needs
> >>> to
> >>> update only one locator, since the cc region is replicated across
> >>> locators).
> >>>
> >>> Quite often, the locator that ends up executing the function call will
> >>> the
> >>> be locator that executes the command, but we still need to do the
> remote
> >>> call. So I am wondering:
> >>>
> >>> A: What are the use cases where a cluster might have a mix of locators
> >>> with
> >>> and without CC? Is it quite common?
> >>> B: Is there a chance that when a user connects to a locator without CC
> >>> enabled, he actually WANTS all the commands he execute WON'T affect CC?
> >>> C: Can we change the behavior to B? That is: the commands will only
> >>> change
> >>> CC only if the user is connected to a locator that has CC enabled? (of
> >>> course, we will provide enough warning if the commands are on a locator
> >>> without CC telling him that won't affect cluster config. We will also
> >>> provides commands that will show the current state of Cluster Config)
> >>>
> >>> This behavior change would greatly simply our implementation of cluster
> >>> config and get rid of lots of spaghetti code.
> >>>
> >>> --
> >>> Cheers
> >>>
> >>> Jinmei
> >>>
> >>>
> >
>
>
> --
> Cheers
>
> Jinmei
>

[jira] [Created] (GEODE-2261) ClusterConfigWriter do not need to use remote call to change cluster config

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2261:
--

 Summary: ClusterConfigWriter do not need to use remote call to 
change cluster config
 Key: GEODE-2261
 URL: https://issues.apache.org/jira/browse/GEODE-2261
 Project: Geode
  Issue Type: Sub-task
Reporter: Jinmei Liao


Currently the ClusterConfigWriter gets a list of locators with CC enabled and 
uses remote function calls to change CC. Since it's very uncommon that a 
cluster would have a mix of locators with and without CC. We should just change 
the CC on the current locator. If, in the rare case of this locator not having 
cc enabled, we will just output a warning message.



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

Re: Cluster Config

[Jinmei Liao]

Currently our API or gfsh commands allow you to create a cluster with a mix
of locators with and without CC. Our DM maintains a list of locators and a
separate list of locators with CC enabled. It is bad, I know. But I am not
sure if we can change it.

Assuming we have to live with cluster with mix of locators, would my
proposal make sense?

On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer  wrote:

> +1
>
> I think that the configurations of all locators should be identical, or at
> least in terms of a few "critical" properties. One would also need to be
> able to amend some property changes at runtime, to allow for the changing
> of configuration without taking all the locators offline. "remote-locators"
> would be a good candidate.
>
> --Udo
>
>
>
> On 1/3/17 09:50, Jacob Barrett wrote:
>
>> If we consider the locators as the directory service for the cluster then
>> it makes no sense for them to be configured differently. I think locators
>> should be force to adopt the configuration of the other locator in the
>> cluster or refuse to join the cluster until their config is updated to
>> match.
>>
>>
>>
>> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  wrote:
>>
>> Calling all the pros with knowledge on cluster configurations:
>>>
>>> This is regarding this current behavior of Cluster Config: Assuming a
>>> cluster has 2 locators, locator-A-with-CC (with cluster config enabled),
>>> and locator-B-without-CC (without cluster config enabled), currently any
>>> commands a user executes through Gfsh that affects cluster config (create
>>> region, deploy/undeploy etc) will change cluster config no matter which
>>> locator he connects to.
>>>
>>> The implementation of this behavior is quite complicated: the command
>>> needs
>>> to:
>>>
>>> 1. find out from DM if there is any locator that has CC enabled (the DM
>>> needs to maintain a flag simply for this purpose).
>>> 2. find out from DM the list of locators that has CC enabled.
>>> 3. loop through this list, execute a remote function on that locator to
>>> change the CC. (depending on the nature of the command, the function is
>>> different).
>>> 4. break out of the loop if one execution is successful. (it only needs
>>> to
>>> update only one locator, since the cc region is replicated across
>>> locators).
>>>
>>> Quite often, the locator that ends up executing the function call will
>>> the
>>> be locator that executes the command, but we still need to do the remote
>>> call. So I am wondering:
>>>
>>> A: What are the use cases where a cluster might have a mix of locators
>>> with
>>> and without CC? Is it quite common?
>>> B: Is there a chance that when a user connects to a locator without CC
>>> enabled, he actually WANTS all the commands he execute WON'T affect CC?
>>> C: Can we change the behavior to B? That is: the commands will only
>>> change
>>> CC only if the user is connected to a locator that has CC enabled? (of
>>> course, we will provide enough warning if the commands are on a locator
>>> without CC telling him that won't affect cluster config. We will also
>>> provides commands that will show the current state of Cluster Config)
>>>
>>> This behavior change would greatly simply our implementation of cluster
>>> config and get rid of lots of spaghetti code.
>>>
>>> --
>>> Cheers
>>>
>>> Jinmei
>>>
>>>
>


-- 
Cheers

Jinmei

Re: Review Request 55106: GEODE-1580 ci failure: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock

[Bruce Schuchardt]

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

(Updated Jan. 3, 2017, 6:03 p.m.)


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


Changes
---

I've moved RMI blackboard to internal package.  Unit tests now interact with it 
using a non-RMI object, removing the need to catch RemoteException.
I also added unit tests for the blackboard, which exposed a problem in 
waitForGate().


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


Repository: geode


Description
---

Added a dunit blackboard to coordinate creation of a deadlock with the 
DistributedLockService.  Removed pauses and added use of Awaitility to wait for 
conditions.


Diffs (updated)
-

  
geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
 17ec800517066b1a7564a91be10c7d659f24a8fb 
  geode-core/src/test/java/org/apache/geode/test/dunit/DUnitBlackboard.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/internal/DUnitBlackboardDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/internal/InternalBlackboard.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/internal/InternalBlackboardImpl.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/internal/JUnit4DistributedTestCase.java
 ebbb2fd5fffd5b4e1120a05c5103698b6be9e1f5 
  geode-core/src/test/java/org/apache/geode/test/dunit/standalone/ChildVM.java 
7a9d7f00ff2efcdb811217c5dd42baeebe862685 
  
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
 5a80a64f82ad0d7ed6e22c06e006e82d7d1e9d95 

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


Testing
---

Running precheckin since some dunit infrastructure was modified


Thanks,

Bruce Schuchardt

Re: Cluster Config

[Udo Kohlmeyer]

+1

I think that the configurations of all locators should be identical, or 
at least in terms of a few "critical" properties. One would also need to 
be able to amend some property changes at runtime, to allow for the 
changing of configuration without taking all the locators offline. 
"remote-locators" would be a good candidate.


--Udo


On 1/3/17 09:50, Jacob Barrett wrote:

If we consider the locators as the directory service for the cluster then
it makes no sense for them to be configured differently. I think locators
should be force to adopt the configuration of the other locator in the
cluster or refuse to join the cluster until their config is updated to
match.



On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  wrote:


Calling all the pros with knowledge on cluster configurations:

This is regarding this current behavior of Cluster Config: Assuming a
cluster has 2 locators, locator-A-with-CC (with cluster config enabled),
and locator-B-without-CC (without cluster config enabled), currently any
commands a user executes through Gfsh that affects cluster config (create
region, deploy/undeploy etc) will change cluster config no matter which
locator he connects to.

The implementation of this behavior is quite complicated: the command needs
to:

1. find out from DM if there is any locator that has CC enabled (the DM
needs to maintain a flag simply for this purpose).
2. find out from DM the list of locators that has CC enabled.
3. loop through this list, execute a remote function on that locator to
change the CC. (depending on the nature of the command, the function is
different).
4. break out of the loop if one execution is successful. (it only needs to
update only one locator, since the cc region is replicated across
locators).

Quite often, the locator that ends up executing the function call will the
be locator that executes the command, but we still need to do the remote
call. So I am wondering:

A: What are the use cases where a cluster might have a mix of locators with
and without CC? Is it quite common?
B: Is there a chance that when a user connects to a locator without CC
enabled, he actually WANTS all the commands he execute WON'T affect CC?
C: Can we change the behavior to B? That is: the commands will only change
CC only if the user is connected to a locator that has CC enabled? (of
course, we will provide enough warning if the commands are on a locator
without CC telling him that won't affect cluster config. We will also
provides commands that will show the current state of Cluster Config)

This behavior change would greatly simply our implementation of cluster
config and get rid of lots of spaghetti code.

--
Cheers

Jinmei

Re: Cluster Config

[Dan Smith]

+1 for what Jake said - I think locators should refuse to join if their
settings don't match.

Having a mix of locators that do and don't support cluster configuration
seems confusing. That means your system may or may not update cluster
configuration, depending on which locators are actually running at any
given time.

-Dan

On Tue, Jan 3, 2017 at 9:50 AM, Jacob Barrett  wrote:

> If we consider the locators as the directory service for the cluster then
> it makes no sense for them to be configured differently. I think locators
> should be force to adopt the configuration of the other locator in the
> cluster or refuse to join the cluster until their config is updated to
> match.
>
>
>
> On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  wrote:
>
> > Calling all the pros with knowledge on cluster configurations:
> >
> > This is regarding this current behavior of Cluster Config: Assuming a
> > cluster has 2 locators, locator-A-with-CC (with cluster config enabled),
> > and locator-B-without-CC (without cluster config enabled), currently any
> > commands a user executes through Gfsh that affects cluster config (create
> > region, deploy/undeploy etc) will change cluster config no matter which
> > locator he connects to.
> >
> > The implementation of this behavior is quite complicated: the command
> needs
> > to:
> >
> > 1. find out from DM if there is any locator that has CC enabled (the DM
> > needs to maintain a flag simply for this purpose).
> > 2. find out from DM the list of locators that has CC enabled.
> > 3. loop through this list, execute a remote function on that locator to
> > change the CC. (depending on the nature of the command, the function is
> > different).
> > 4. break out of the loop if one execution is successful. (it only needs
> to
> > update only one locator, since the cc region is replicated across
> > locators).
> >
> > Quite often, the locator that ends up executing the function call will
> the
> > be locator that executes the command, but we still need to do the remote
> > call. So I am wondering:
> >
> > A: What are the use cases where a cluster might have a mix of locators
> with
> > and without CC? Is it quite common?
> > B: Is there a chance that when a user connects to a locator without CC
> > enabled, he actually WANTS all the commands he execute WON'T affect CC?
> > C: Can we change the behavior to B? That is: the commands will only
> change
> > CC only if the user is connected to a locator that has CC enabled? (of
> > course, we will provide enough warning if the commands are on a locator
> > without CC telling him that won't affect cluster config. We will also
> > provides commands that will show the current state of Cluster Config)
> >
> > This behavior change would greatly simply our implementation of cluster
> > config and get rid of lots of spaghetti code.
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>

Re: Cluster Config

[Darrel Schneider]

It seems questionable to me that you would have one locator with CC enabled
and another with CC disabled. Usually you have extra locators for fault
tolerance.
What happens if the one with CC enabled dies? Will gfsh commands quit
getting recorded in CC because we now only have a locator with CC disabled?
I agree with Jake that the locators should have matching CC configuration.
Does a use case exist that requires a locator that does not have CC enabled
on a cluster that does?

If we want to have gfsh commands that are intentionally transient (i.e. not
remembered in CC) then I think that should be an option on the gfsh command
itself. But you also need to consider who the gfsh commands will work on a
cluster that has not enabled CC.

On Tue, Jan 3, 2017 at 8:51 AM, Jinmei Liao  wrote:

> Calling all the pros with knowledge on cluster configurations:
>
> This is regarding this current behavior of Cluster Config: Assuming a
> cluster has 2 locators, locator-A-with-CC (with cluster config enabled),
> and locator-B-without-CC (without cluster config enabled), currently any
> commands a user executes through Gfsh that affects cluster config (create
> region, deploy/undeploy etc) will change cluster config no matter which
> locator he connects to.
>
> The implementation of this behavior is quite complicated: the command needs
> to:
>
> 1. find out from DM if there is any locator that has CC enabled (the DM
> needs to maintain a flag simply for this purpose).
> 2. find out from DM the list of locators that has CC enabled.
> 3. loop through this list, execute a remote function on that locator to
> change the CC. (depending on the nature of the command, the function is
> different).
> 4. break out of the loop if one execution is successful. (it only needs to
> update only one locator, since the cc region is replicated across
> locators).
>
> Quite often, the locator that ends up executing the function call will the
> be locator that executes the command, but we still need to do the remote
> call. So I am wondering:
>
> A: What are the use cases where a cluster might have a mix of locators with
> and without CC? Is it quite common?
> B: Is there a chance that when a user connects to a locator without CC
> enabled, he actually WANTS all the commands he execute WON'T affect CC?
> C: Can we change the behavior to B? That is: the commands will only change
> CC only if the user is connected to a locator that has CC enabled? (of
> course, we will provide enough warning if the commands are on a locator
> without CC telling him that won't affect cluster config. We will also
> provides commands that will show the current state of Cluster Config)
>
> This behavior change would greatly simply our implementation of cluster
> config and get rid of lots of spaghetti code.
>
> --
> Cheers
>
> Jinmei
>

Re: Cluster Config

[Jacob Barrett]

If we consider the locators as the directory service for the cluster then
it makes no sense for them to be configured differently. I think locators
should be force to adopt the configuration of the other locator in the
cluster or refuse to join the cluster until their config is updated to
match.



On Tue, Jan 3, 2017 at 8:52 AM Jinmei Liao  wrote:

> Calling all the pros with knowledge on cluster configurations:
>
> This is regarding this current behavior of Cluster Config: Assuming a
> cluster has 2 locators, locator-A-with-CC (with cluster config enabled),
> and locator-B-without-CC (without cluster config enabled), currently any
> commands a user executes through Gfsh that affects cluster config (create
> region, deploy/undeploy etc) will change cluster config no matter which
> locator he connects to.
>
> The implementation of this behavior is quite complicated: the command needs
> to:
>
> 1. find out from DM if there is any locator that has CC enabled (the DM
> needs to maintain a flag simply for this purpose).
> 2. find out from DM the list of locators that has CC enabled.
> 3. loop through this list, execute a remote function on that locator to
> change the CC. (depending on the nature of the command, the function is
> different).
> 4. break out of the loop if one execution is successful. (it only needs to
> update only one locator, since the cc region is replicated across
> locators).
>
> Quite often, the locator that ends up executing the function call will the
> be locator that executes the command, but we still need to do the remote
> call. So I am wondering:
>
> A: What are the use cases where a cluster might have a mix of locators with
> and without CC? Is it quite common?
> B: Is there a chance that when a user connects to a locator without CC
> enabled, he actually WANTS all the commands he execute WON'T affect CC?
> C: Can we change the behavior to B? That is: the commands will only change
> CC only if the user is connected to a locator that has CC enabled? (of
> course, we will provide enough warning if the commands are on a locator
> without CC telling him that won't affect cluster config. We will also
> provides commands that will show the current state of Cluster Config)
>
> This behavior change would greatly simply our implementation of cluster
> config and get rid of lots of spaghetti code.
>
> --
> Cheers
>
> Jinmei
>

[jira] [Updated] (GEODE-2238) Member may fail to receive cluster configuration from locator

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-2238:

Labels:   (was: Flaky)

> Member may fail to receive cluster configuration from locator
> -
>
> Key: GEODE-2238
> URL: https://issues.apache.org/jira/browse/GEODE-2238
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration
>  is failing frequently in precheckin. I'm going to mark it as FlakyTest. 
> Below is the stack trace:
> {noformat}
> :geode-lucene:distributedTest
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest
>  > indexWithAnalyzerGetsCreatedUsingClusterConfiguration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest$$Lambda$29/613305101.run
>  in VM 2 running on Host 3fb23bc375ef with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at org.apache.geode.test.dunit.rules.Member.invoke(Member.java:60)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration(LuceneClusterConfigurationDUnitTest.java:102)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.lambda$indexWithAnalyzerGetsCreatedUsingClusterConfiguration$bb17a952$1(LuceneClusterConfigurationDUnitTest.java:105)
> 94 tests completed, 1 failed
> {noformat}



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

[jira] [Commented] (GEODE-2138) gfsh 'start' reports 'GemFire Version'

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/328
  
+1
Looks good to me. 


> gfsh 'start' reports 'GemFire Version'
> --
>
> Key: GEODE-2138
> URL: https://issues.apache.org/jira/browse/GEODE-2138
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Dave Barnes
>Assignee: Nilkanth Patel
>Priority: Minor
>
> The gfsh 'start locator' and 'start server' commands report 'GemFire version' 
> followed by a Geode version string. For example:
> $ start locator --name=locator1
> Starting a Geode Locator in /Users/dbarnes/my_geode/locator1...
> ...
> Locator in /Users/dbarnes/my_geode/locator1 on 192.168.1.80[10334] as 
> locator1 is currently online.
> Process ID: 1327
> Uptime: 4 seconds
> GemFire Version: 1.1.0-SNAPSHOT



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

[GitHub] geode issue #328: [GEODE-2138] #comment Fix issues GEODE-2138

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/328
  
+1
Looks good to me. 


---
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-2257) Client configured to use locator with addPoolServer fails to connect

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2257:


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

GEODE-2257 Client configured to use locator with addPoolServer fails to connect

My previous commit did not include the changes to TcpServer required for the
test to pass.


> Client configured to use locator with addPoolServer fails to connect
> 
>
> Key: GEODE-2257
> URL: https://issues.apache.org/jira/browse/GEODE-2257
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> If a client cache is incorrectly configured to use a locator address with 
> ClientConnectionFactory.addPoolServer() instead of addPoolLocator() it is 
> very difficult to figure out why it's unable to connect.  The locator rejects 
> all attempts to contact it because the client tries to perform a 
> server-handshake with it and the locator just closes the connection without a 
> response.  The client ends up having an empty connection pool and is unable 
> to find any of the available servers.



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

Re: Off-Heap Annotations

[Michael Stolz]

Dor,

I'd like to understand the reason you would like to have different
semantics than what's in Geode with regard to off-heap.
Can you expand a bit on what you are trying to achieve?


On Tue, Jan 3, 2017 at 11:22 AM, Udo Kohlmeyer  wrote:

> Hi there Dor,
>
> I will allow someone with better knowledge to answer this, but I think it
> would be safe to assume that you cannot change this at runtime.
>
> --Udo
>
>
>
> On 1/3/17 08:01, Dor Ben Dov wrote:
>
>> Udo,
>>
>> This means it can't be changed on the fly in runtime ? Need to be flagged
>> before?
>>
>> Dor
>>
>> -Original Message-
>> From: Udo Kohlmeyer [mailto:u...@apache.org]
>> Sent: יום ג 03 ינואר 2017 17:32
>> To: dev@geode.apache.org
>> Subject: Re: Off-Heap Annotations
>>
>> Hi there Gal,
>>
>> That is not possible. A region is either on-heap or off-heap.
>>
>> --Udo
>>
>>
>> On 1/2/17 13:50, Gal Palmery wrote:
>>
>>> Ok,
>>> So if I want to have just a certain part of the region off heap and the
>>> rest of it on heap - how do I do that?
>>>
>>>
>>>
>>> -Original Message-
>>> From: Dan Smith [mailto:dsm...@pivotal.io]
>>> Sent: Monday, January 02, 2017 19:46
>>> To: dev@geode.apache.org
>>> Subject: Re: Off-Heap Annotations
>>>
>>> Hi Gal,
>>>
>>> The way to control what is on or off heap is when you configure a region.
>>> Regions that are configured with off-heap=true will store all of the
>>> values in off heap memory, regions with off-heap= false will store the
>>> values on the heap.
>>>
>>> -Dan
>>>
>>> On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery 
>>> wrote:
>>>
>>> Thanks Kirk.

 for example, before I call put, I'd like to indicate to geode server
 that I want to keep specific data off heap. how can I do that?
 is there an api that will move data off or on heap?

 Gal

 -Original Message-
 From: Kirk Lund [mailto:kl...@apache.org]
 Sent: Tuesday, December 27, 2016 06:33
 To: dev@geode.apache.org
 Subject: Re: Off-Heap Annotations

 Those annotations are part of the internal implementation of Geode.
 The developers used it as a way to help keep track of references to
 off-heap.

 -Kirk


 On Mon, Dec 26, 2016 at 1:34 AM, Gal Palmery 
 wrote:

 Hi everyone,
>
> Is this feature:
> https://cwiki.apache.org/confluence/display/GEODE/Off-Heap+Annotatio
> ns a part of the last release? (1.0.0-incubating)
>
> thanks,
> Gal
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement, you may
> review at http://www.amdocs.com/email_disclaimer.asp
>
> This message and the information contained herein is proprietary and
 confidential and subject to the Amdocs policy statement,

 you may review at http://www.amdocs.com/email_disclaimer.asp

 This message and the information contained herein is proprietary and
>>> confidential and subject to the Amdocs policy statement,
>>>
>>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>>
>> This message and the information contained herein is proprietary and
>> confidential and subject to the Amdocs policy statement,
>>
>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>
>
>

Re: Off-Heap Annotations

[Udo Kohlmeyer]

Hi there Dor,

I will allow someone with better knowledge to answer this, but I think 
it would be safe to assume that you cannot change this at runtime.


--Udo



On 1/3/17 08:01, Dor Ben Dov wrote:

Udo,

This means it can't be changed on the fly in runtime ? Need to be flagged 
before?

Dor

-Original Message-
From: Udo Kohlmeyer [mailto:u...@apache.org]
Sent: יום ג 03 ינואר 2017 17:32
To: dev@geode.apache.org
Subject: Re: Off-Heap Annotations

Hi there Gal,

That is not possible. A region is either on-heap or off-heap.

--Udo


On 1/2/17 13:50, Gal Palmery wrote:

Ok,
So if I want to have just a certain part of the region off heap and the rest of 
it on heap - how do I do that?



-Original Message-
From: Dan Smith [mailto:dsm...@pivotal.io]
Sent: Monday, January 02, 2017 19:46
To: dev@geode.apache.org
Subject: Re: Off-Heap Annotations

Hi Gal,

The way to control what is on or off heap is when you configure a region.
Regions that are configured with off-heap=true will store all of the values in 
off heap memory, regions with off-heap= false will store the values on the heap.

-Dan

On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery  wrote:


Thanks Kirk.

for example, before I call put, I'd like to indicate to geode server
that I want to keep specific data off heap. how can I do that?
is there an api that will move data off or on heap?

Gal

-Original Message-
From: Kirk Lund [mailto:kl...@apache.org]
Sent: Tuesday, December 27, 2016 06:33
To: dev@geode.apache.org
Subject: Re: Off-Heap Annotations

Those annotations are part of the internal implementation of Geode.
The developers used it as a way to help keep track of references to off-heap.

-Kirk


On Mon, Dec 26, 2016 at 1:34 AM, Gal Palmery 
wrote:


Hi everyone,

Is this feature:
https://cwiki.apache.org/confluence/display/GEODE/Off-Heap+Annotatio
ns a part of the last release? (1.0.0-incubating)

thanks,
Gal

This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement, you may
review at http://www.amdocs.com/email_disclaimer.asp


This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp


This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

[jira] [Commented] (GEODE-2257) Client configured to use locator with addPoolServer fails to connect

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2257:


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

GEODE-2257 Client configured to use locator with addPoolServer fails to connect

Disabling the test added for this ticket while I look into why it's started
to fail.


> Client configured to use locator with addPoolServer fails to connect
> 
>
> Key: GEODE-2257
> URL: https://issues.apache.org/jira/browse/GEODE-2257
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> If a client cache is incorrectly configured to use a locator address with 
> ClientConnectionFactory.addPoolServer() instead of addPoolLocator() it is 
> very difficult to figure out why it's unable to connect.  The locator rejects 
> all attempts to contact it because the client tries to perform a 
> server-handshake with it and the locator just closes the connection without a 
> response.  The client ends up having an empty connection pool and is unable 
> to find any of the available servers.



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

RE: Off-Heap Annotations

[Dor Ben Dov]

Udo,

This means it can't be changed on the fly in runtime ? Need to be flagged 
before?

Dor

-Original Message-
From: Udo Kohlmeyer [mailto:u...@apache.org] 
Sent: יום ג 03 ינואר 2017 17:32
To: dev@geode.apache.org
Subject: Re: Off-Heap Annotations

Hi there Gal,

That is not possible. A region is either on-heap or off-heap.

--Udo


On 1/2/17 13:50, Gal Palmery wrote:
> Ok,
> So if I want to have just a certain part of the region off heap and the rest 
> of it on heap - how do I do that?
>
>
>
> -Original Message-
> From: Dan Smith [mailto:dsm...@pivotal.io]
> Sent: Monday, January 02, 2017 19:46
> To: dev@geode.apache.org
> Subject: Re: Off-Heap Annotations
>
> Hi Gal,
>
> The way to control what is on or off heap is when you configure a region.
> Regions that are configured with off-heap=true will store all of the values 
> in off heap memory, regions with off-heap= false will store the values on the 
> heap.
>
> -Dan
>
> On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery  wrote:
>
>> Thanks Kirk.
>>
>> for example, before I call put, I'd like to indicate to geode server 
>> that I want to keep specific data off heap. how can I do that?
>> is there an api that will move data off or on heap?
>>
>> Gal
>>
>> -Original Message-
>> From: Kirk Lund [mailto:kl...@apache.org]
>> Sent: Tuesday, December 27, 2016 06:33
>> To: dev@geode.apache.org
>> Subject: Re: Off-Heap Annotations
>>
>> Those annotations are part of the internal implementation of Geode.
>> The developers used it as a way to help keep track of references to off-heap.
>>
>> -Kirk
>>
>>
>> On Mon, Dec 26, 2016 at 1:34 AM, Gal Palmery 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> Is this feature:
>>> https://cwiki.apache.org/confluence/display/GEODE/Off-Heap+Annotatio
>>> ns a part of the last release? (1.0.0-incubating)
>>>
>>> thanks,
>>> Gal
>>>
>>> This message and the information contained herein is proprietary and 
>>> confidential and subject to the Amdocs policy statement, you may 
>>> review at http://www.amdocs.com/email_disclaimer.asp
>>>
>> This message and the information contained herein is proprietary and 
>> confidential and subject to the Amdocs policy statement,
>>
>> you may review at http://www.amdocs.com/email_disclaimer.asp
>>
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at http://www.amdocs.com/email_disclaimer.asp

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

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

[Bruce Schuchardt]

A new test that I checked in last week is failing.  I'm going to disable 
it while I look into the matter.


Le 1/3/2017 à 7:56 AM, Apache Jenkins Server a écrit :

See 

--
[...truncated 544 lines...]
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-web:processTestResources UP-TO-DATE
:geode-web:testClasses
:geode-web:checkMissedTests
:geode-web:spotlessJavaCheck
:geode-web:spotlessCheck
:geode-web:test
:geode-web:check
:geode-web:build
:geode-web:distributedTest
:geode-web:flakyTest
:geode-web:integrationTest
:geode-web-api:assemble
:geode-web-api:compileTestJava UP-TO-DATE
:geode-web-api:processTestResources UP-TO-DATE

[jira] [Resolved] (GEODE-1754) InternalLocator.startLocator needs to be cleaned up

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-1754.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

Thanks for the reminder Amey.  Your changes were included in commit 
c33ce7db8148fe0b300066581f26582e3e044e96.

> InternalLocator.startLocator needs to be cleaned up
> ---
>
> Key: GEODE-1754
> URL: https://issues.apache.org/jira/browse/GEODE-1754
> Project: Geode
>  Issue Type: Task
>  Components: management
>Reporter: Bruce Schuchardt
>Assignee: Amey Barve
> Fix For: 1.1.0
>
>
> InternalLocator.startLocator was modified to have a loadSharedConfigFromDir 
> parameter that is never used.  It should be removed.
> {noformat}
>   /**
>* Creates a distribution locator that runs in this VM on the given
>* port and bind address.
>* 
>* This is for internal use only as it does not create a distributed
>* system unless told to do so.
>* 
>* @param port
>*the tcp/ip port to listen on
>* @param logFile
>*the file that log messages should be written to
>* @param logger
>*a log writer that should be used (logFile parameter is ignored)
>* @param securityLogger
>*the logger to be used for security related log messages
>* @param startDistributedSystem
>*if true, a distributed system is started
>* @param dsProperties
>*optional properties to configure the distributed system (e.g., mcast 
> addr/port, other locators)
>* @param peerLocator
>*enable peer location services
>* @param enableServerLocator
>*enable server location services
>* @param hostnameForClients
>*the name to give to clients for connecting to this locator
>* @param loadSharedConfigFromDir TODO:CONFIG
>* @throws IOException 
>*/
>   public static InternalLocator startLocator(
> int port,
> File logFile,
> File stateFile,
> InternalLogWriter logger,
> InternalLogWriter securityLogger,
> InetAddress bindAddress,
> boolean startDistributedSystem,
> java.util.Properties dsProperties,
> boolean peerLocator, 
> boolean enableServerLocator, 
> String hostnameForClients, 
> boolean loadSharedConfigFromDir
> )
> {noformat}



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

Re: Off-Heap Annotations

[Udo Kohlmeyer]

Hi there Gal,

That is not possible. A region is either on-heap or off-heap.

--Udo


On 1/2/17 13:50, Gal Palmery wrote:

Ok,
So if I want to have just a certain part of the region off heap and the rest of 
it on heap - how do I do that?



-Original Message-
From: Dan Smith [mailto:dsm...@pivotal.io]
Sent: Monday, January 02, 2017 19:46
To: dev@geode.apache.org
Subject: Re: Off-Heap Annotations

Hi Gal,

The way to control what is on or off heap is when you configure a region.
Regions that are configured with off-heap=true will store all of the values in 
off heap memory, regions with off-heap= false will store the values on the heap.

-Dan

On Mon, Jan 2, 2017 at 5:57 AM, Gal Palmery  wrote:


Thanks Kirk.

for example, before I call put, I'd like to indicate to geode server
that I want to keep specific data off heap. how can I do that?
is there an api that will move data off or on heap?

Gal

-Original Message-
From: Kirk Lund [mailto:kl...@apache.org]
Sent: Tuesday, December 27, 2016 06:33
To: dev@geode.apache.org
Subject: Re: Off-Heap Annotations

Those annotations are part of the internal implementation of Geode.
The developers used it as a way to help keep track of references to off-heap.

-Kirk


On Mon, Dec 26, 2016 at 1:34 AM, Gal Palmery 
wrote:


Hi everyone,

Is this feature:
https://cwiki.apache.org/confluence/display/GEODE/Off-Heap+Annotatio
ns a part of the last release? (1.0.0-incubating)

thanks,
Gal

This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement, you may
review at http://www.amdocs.com/email_disclaimer.asp


This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

[jira] [Assigned] (GEODE-2049) unit of measure wrong in DistributionStats tcpFinalCheck statitistics

[Amey Barve (JIRA)]

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

Amey Barve reassigned GEODE-2049:
-

Assignee: Amey Barve

> unit of measure wrong in DistributionStats tcpFinalCheck statitistics
> -
>
> Key: GEODE-2049
> URL: https://issues.apache.org/jira/browse/GEODE-2049
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Amey Barve
>Priority: Minor
>
> The unit of measure for all of the tcpfinalCheck statistics is currently 
> "nanoseconds" but should be "messages".



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