Help to reproduce GEODE-7060

[Alberto Bustamante Reyes]

Hi,

I need some info to reproduce the issue described in GEODE-7060, about an ACE 
resource leak.
The ticket says the problem was seen using a test called "gemfire-node-client 
putall.js", but I suppose that test is not part of Geode.

Could someone with access to that test describe what it is doing? Any idea to 
reproduce the issue is welcome.

Thanks in advance.


Alberto B.

Re: Help to reproduce GEODE-7060

[Blake Bender]

Hi Alberto,

I apologize for the mention of gemfire-node-client in OSS Geode JIRA, this
is a proprietary product that you don't have access to.  For the time
being, I believe, we have fixed all of the ACE leaks we've found, so
GEODE-7060 can be safely closed.

Just for context, we found that, on MacOS, if nativeclient items were
leaking at app shutdown and any of them contained an ACE object, certain of
these would leak an OS resource that couldn't be recovered.  Eventually
(typically after a number of test runs) this resource would run out, and
the only way to recover was to restart the OS.  We've since fixed a number
of "resource leak at shutdown" bugs in the native client, and haven't seen
GEODE-7060 in a couple of months or more.

Thanks,

Blake


On Mon, Nov 25, 2019 at 5:49 AM Alberto Bustamante Reyes
 wrote:

> Hi,
>
> I need some info to reproduce the issue described in GEODE-7060, about an
> ACE resource leak.
> The ticket says the problem was seen using a test called
> "gemfire-node-client putall.js", but I suppose that test is not part of
> Geode.
>
> Could someone with access to that test describe what it is doing? Any idea
> to reproduce the issue is welcome.
>
> Thanks in advance.
>
>
> Alberto B.
>

RE: Help to reproduce GEODE-7060

[Alberto Bustamante Reyes]

Ok, then Im going to close the ticket. Thanks for the info Blake!

De: Blake Bender 
Enviado: lunes, 25 de noviembre de 2019 15:11
Para: dev@geode.apache.org 
Asunto: Re: Help to reproduce GEODE-7060

Hi Alberto,

I apologize for the mention of gemfire-node-client in OSS Geode JIRA, this
is a proprietary product that you don't have access to.  For the time
being, I believe, we have fixed all of the ACE leaks we've found, so
GEODE-7060 can be safely closed.

Just for context, we found that, on MacOS, if nativeclient items were
leaking at app shutdown and any of them contained an ACE object, certain of
these would leak an OS resource that couldn't be recovered.  Eventually
(typically after a number of test runs) this resource would run out, and
the only way to recover was to restart the OS.  We've since fixed a number
of "resource leak at shutdown" bugs in the native client, and haven't seen
GEODE-7060 in a couple of months or more.

Thanks,

Blake


On Mon, Nov 25, 2019 at 5:49 AM Alberto Bustamante Reyes
 wrote:

> Hi,
>
> I need some info to reproduce the issue described in GEODE-7060, about an
> ACE resource leak.
> The ticket says the problem was seen using a test called
> "gemfire-node-client putall.js", but I suppose that test is not part of
> Geode.
>
> Could someone with access to that test describe what it is doing? Any idea
> to reproduce the issue is welcome.
>
> Thanks in advance.
>
>
> Alberto B.
>

Re: WAN Get-Initial-Image

[anjana_nair]

Hi,

We are trying to solve cloud replication  using  asyncEventListeners.However
the sample AsyncEventListener is not  getting fired when I try a put. Could
you please look into this. Commands tried out are below.

I am starting to write   an AsyncEventListener  to store messages to
Cassandra.However Listener is not getting fired. Following are the commands
tried from command line.

1.gfsh>deploy --jars=test-2019.11.17.jar

Deploying files: test-2019.11.17.jar
Total file size is: 0.00MB

Continue?  (Y/n): y
Member  |Deployed JAR | Deployed JAR Location
--- | --- |

server1 | test-2019.11.17.jar |
H:\GemFire_Server\server1\test-2019.11.17.v1.jar

2.gfsh>create region --name=sample1 --type=REPLICATE 
--async-event-queue-id=sampleq
Member  | Status
--- | --
server1 | Region "/sample1" created on "server1"

3.gfsh>create region --name=sample1 --type=REPLICATE 
--async-event-queue-id=sample
Member  | Status
--- | --
server1 | Region "/sample1" created on "server1"

gfsh>put --key=('123') --value=('ABC') --region=sample1
Result  : true
Key Class   : java.lang.String
Key : ('123')
Value Class : java.lang.String
Old Value   : 


gfsh>put --key=('123') --value=('ABC1') --region=sample1
Result  : true
Key Class   : java.lang.String
Key : ('123')
Value Class : java.lang.String
Old Value   : ('ABC')


However I see that Listener is not fired.

What could be wrong ? My Listener is very simple with some simple print
statements.
 



--
Sent from: http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/

RE: Async queue mechanism

[anjana_nair]

Hi,

I am trying to create a an asyncEventqueue thru gfsh and it gives me the
error below :

gfsh>create async-event-queue --id=sampleq7 
--listener=test.gemfire.GemFireListener
Could not process command due to error. Error while processing command
 Reason : No results received.


Sever throws no error on startup.

what could be the reason ? The error message does not say anything.





--
Sent from: http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/

Re: [DISCUSS] - Move gfsh into its own submodule

[Dale Emery]

+𝞹
—
Dale Emery
dem...@pivotal.io



> On Nov 22, 2019, at 8:39 AM, Jens Deppe  wrote:
> 
> Hello All,
> 
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to decouple geode core from any Spring
> dependencies.
> 
> The proposal is outlined here:
> https://cwiki.apache.org/confluence/display/GEODE/Move+gfsh+code+to+a+separate+gradle+sub-project
> 
> Please provide feedback for this proposal *on this email thread* and not in
> the comment section of the proposal page.
> 
> The deadline for this proposal will be Monday, December 2.
> 
> Thanks in advance for feedback / comments.
> 
> --Jens & Patrick

Re: WAN Get-Initial-Image

[Xiaojian Zhou]

DId you run "create async-event-queue"?

On Mon, Nov 25, 2019 at 9:23 AM anjana_nair  wrote:

> Hi,
>
> We are trying to solve cloud replication  using
> asyncEventListeners.However
> the sample AsyncEventListener is not  getting fired when I try a put. Could
> you please look into this. Commands tried out are below.
>
> I am starting to write   an AsyncEventListener  to store messages to
> Cassandra.However Listener is not getting fired. Following are the commands
> tried from command line.
>
> 1.gfsh>deploy --jars=test-2019.11.17.jar
>
> Deploying files: test-2019.11.17.jar
> Total file size is: 0.00MB
>
> Continue?  (Y/n): y
> Member  |Deployed JAR | Deployed JAR Location
> --- | --- |
> 
> server1 | test-2019.11.17.jar |
> H:\GemFire_Server\server1\test-2019.11.17.v1.jar
>
> 2.gfsh>create region --name=sample1 --type=REPLICATE
> --async-event-queue-id=sampleq
> Member  | Status
> --- | --
> server1 | Region "/sample1" created on "server1"
>
> 3.gfsh>create region --name=sample1 --type=REPLICATE
> --async-event-queue-id=sample
> Member  | Status
> --- | --
> server1 | Region "/sample1" created on "server1"
>
> gfsh>put --key=('123') --value=('ABC') --region=sample1
> Result  : true
> Key Class   : java.lang.String
> Key : ('123')
> Value Class : java.lang.String
> Old Value   : 
>
>
> gfsh>put --key=('123') --value=('ABC1') --region=sample1
> Result  : true
> Key Class   : java.lang.String
> Key : ('123')
> Value Class : java.lang.String
> Old Value   : ('ABC')
>
>
> However I see that Listener is not fired.
>
> What could be wrong ? My Listener is very simple with some simple print
> statements.
>
>
>
>
> --
> Sent from:
> http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/
>

Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

[Bill Burcham]

Thanks for the feedback. We have rough consensus for the new module so we
will make it so.

On Mon, Nov 18, 2019 at 5:34 PM Joris Melchior  wrote:

> +1
>
> On Mon, Nov 18, 2019 at 6:22 PM Owen Nichols  wrote:
>
> > +1
> >
> > > On Nov 18, 2019, at 3:00 PM, Nabarun Nag  wrote:
> > >
> > > +1
> > >
> > > On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer  wrote:
> > >
> > >> Thank you for this Bill,
> > >>
> > >> I must admit that I'm starting to get a feeling of "scope creep"
> here..
> > >> I understand that all efforts to "modularize" membership would require
> > >> some form of peripheral decoupling.
> > >>
> > >> BUT
> > >>
> > >> I'm starting to get concerned that we are hitting a rabbit hole
> > >> scenario. Maybe this is normal for an effort of this manner, BUT, I
> > >> would like to urge that we start discussing/proposing other
> > >> modulizations, like, Serialization and now TCP communications as real
> > >> modules with own proposals and with their own merit.
> > >>
> > >> YES, I understand this is minimal touch modulizations, but I'm
> concerned
> > >> that we are doing work under the incorrect banner. Just enough to
> > >> complete one "piece of it", but possibly a rework, of the module
> because
> > >> of the "good enough" approach we take.
> > >>
> > >> Maybe we are discovering that there is some pre-work that needed to
> have
> > >> been completed before the whole membership modularization effort was
> > >> started.. And maybe this is the time where we need to take a step
> back,
> > >> look at this from a higher perspective and decide if membership is
> > >> really still the priority here with serialization and transport
> > >> (TCPServer) being a side-effect.
> > >>
> > >> For this reason alone I vote: *-0 *on this matter.. (it is only a
> little
> > >> better than -1)
> > >>
> > >> --Udo
> > >>
> > >> On 11/18/19 1:48 PM, Bill Burcham wrote:
> > >>> Dear Geode,
> > >>>
> > >>> In support of the Membership modularization efforts
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
> > >> ,
> > >>> we would like to move the types in the
> > >>> org.apache.geode.distributed.internal.tcpserver package (i.e. the
> > >> TcpServer
> > >>> class and related types) into a separate module in order to eliminate
> > >>> dependencies on geode-core.
> > >>>
> > >>> The membership subsystem is dependent on this group of types, which
> in
> > >> turn
> > >>> are (were) highly-dependent on geode-core. We have been
> systematically
> > >>> eliminating dependencies from these types to geode-core as part of
> > >>> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should
> not
> > >>> depend on geode-core_ The final sub-task on that ticket puts
> TcpServer
> > >> and
> > >>> related types into its own separate module.
> > >>>
> > >>> The proposed module would be called "geode-tcp-server" and would
> > contain
> > >>> TcpServer and the other types in the
> > >>> org.apache.geode.distributed.internal.tcpserver package.
> > >>>
> > >>> Your feedback is welcomed and appreciated.
> > >>>
> > >>> Your Friend,
> > >>> Bill
> > >>>
> > >>
> >
> >
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> 
>

Re: Async queue mechanism

[Barry Oglesby]

Can you check your locator log file?

You should see a message like this:

[info 2019/11/25 09:39:35.432 PST 
tid=0x55] Executing command: create async-event-queue --id=sampleq7
--listener=test.gemfire.GemFireListener

And then the exception with stack like:

[error 2019/11/25 09:56:19.507 PST 
tid=0x43] Could not execute "create async-event-queue --id=sampleq7
--listener=test.gemfire.GemFireListener".
java.lang.Exception: No results received.
...

Thanks,
Barry Oglesby



On Mon, Nov 25, 2019 at 9:23 AM anjana_nair  wrote:

> Hi,
>
> I am trying to create a an asyncEventqueue thru gfsh and it gives me the
> error below :
>
> gfsh>create async-event-queue --id=sampleq7
> --listener=test.gemfire.GemFireListener
> Could not process command due to error. Error while processing command
>  --listener=test.gemfire.GemFireListener> Reason : No results received.
>
>
> Sever throws no error on startup.
>
> what could be the reason ? The error message does not say anything.
>
>
>
>
>
> --
> Sent from:
> http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/
>

Cache.close is not synchronous?

[Kirk Lund]

I found a test that closes the cache and then recreates the cache multiple
times with 2 second sleep between each. I tried to remove the Thread.sleep
and found that recreating the cache
throws DistributedSystemDisconnectedException (see below).

This seems like a usability nightmare. Anyone have any ideas WHY it's this
way?

Personally, I want Cache.close() to block until both Cache and
DistributedSystem are closed and the API is ready to create a new Cache.

org.apache.geode.distributed.DistributedSystemDisconnectedException: This
connection to a distributed system has been disconnected.
at
org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:945)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1665)
at
org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:791)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)

Re: Cache.close is not synchronous?

[John Blum]

+1 ^ 64!

I found this out the hard way some time ago and is why STDG exists in the
first place (i.e. usability issues, particularly with testing).

On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund  wrote:

> I found a test that closes the cache and then recreates the cache multiple
> times with 2 second sleep between each. I tried to remove the Thread.sleep
> and found that recreating the cache
> throws DistributedSystemDisconnectedException (see below).
>
> This seems like a usability nightmare. Anyone have any ideas WHY it's this
> way?
>
> Personally, I want Cache.close() to block until both Cache and
> DistributedSystem are closed and the API is ready to create a new Cache.
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> at
>
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:945)
> at
>
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1665)
> at
>
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:791)
> at
>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> at
>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
>


-- 
-John
john.blum10101 (skype)

Re: Cache.close is not synchronous?

[Mark Hanson]

+1 to fix.

> On Nov 25, 2019, at 2:02 PM, John Blum  wrote:
> 
> +1 ^ 64!
> 
> I found this out the hard way some time ago and is why STDG exists in the
> first place (i.e. usability issues, particularly with testing).
> 
> On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund  wrote:
> 
>> I found a test that closes the cache and then recreates the cache multiple
>> times with 2 second sleep between each. I tried to remove the Thread.sleep
>> and found that recreating the cache
>> throws DistributedSystemDisconnectedException (see below).
>> 
>> This seems like a usability nightmare. Anyone have any ideas WHY it's this
>> way?
>> 
>> Personally, I want Cache.close() to block until both Cache and
>> DistributedSystem are closed and the API is ready to create a new Cache.
>> 
>> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
>> connection to a distributed system has been disconnected.
>>at
>> 
>> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:945)
>>at
>> 
>> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1665)
>>at
>> 
>> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:791)
>>at
>> 
>> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
>>at
>> 
>> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
>>at
>> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
>> 
> 
> 
> -- 
> -John
> john.blum10101 (skype)

Re: Cache.close is not synchronous?

[Anilkumar Gingade]

Looking at the code, the cache.close() and InternalCacheBuilder.create()
are synchronized on "GemFireCacheImpl.class"'; it's the
internalCachebuilder create that seems to be using reference to the old
distributed-system.
The GemFireCacheImpl.getInstance() and getExisting() both perform
"isClosing" check and does early return. The InternalCacheBuilder is new;
not sure if its missing early checks.

-Anil.

On Mon, Nov 25, 2019 at 2:47 PM Mark Hanson  wrote:

> +1 to fix.
>
> > On Nov 25, 2019, at 2:02 PM, John Blum  wrote:
> >
> > +1 ^ 64!
> >
> > I found this out the hard way some time ago and is why STDG exists in the
> > first place (i.e. usability issues, particularly with testing).
> >
> > On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund  wrote:
> >
> >> I found a test that closes the cache and then recreates the cache
> multiple
> >> times with 2 second sleep between each. I tried to remove the
> Thread.sleep
> >> and found that recreating the cache
> >> throws DistributedSystemDisconnectedException (see below).
> >>
> >> This seems like a usability nightmare. Anyone have any ideas WHY it's
> this
> >> way?
> >>
> >> Personally, I want Cache.close() to block until both Cache and
> >> DistributedSystem are closed and the API is ready to create a new Cache.
> >>
> >> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> This
> >> connection to a distributed system has been disconnected.
> >>at
> >>
> >>
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:945)
> >>at
> >>
> >>
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1665)
> >>at
> >>
> >>
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:791)
> >>at
> >>
> >>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> >>at
> >>
> >>
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> >>at
> >> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> >>
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
>
>

Errored: apache/geode-examples#393 (rel/v1.11.0.RC3 - 8bb28ea)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #393
Status: Errored

Duration: 1 min and 39 secs
Commit: 8bb28ea (rel/v1.11.0.RC3)
Author: Mark Hanson
Message: temporarily point to staging repo for CI purposes

View the changeset: 
https://github.com/apache/geode-examples/compare/rel/v1.11.0.RC3

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/616987035?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11483039&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Passed: apache/geode-native#2233 (rel/v1.11.0.RC3 - 5d01219)

[Travis CI]

Build Update for apache/geode-native
-

Build: #2233
Status: Passed

Duration: 1 hr, 38 mins, and 58 secs
Commit: 5d01219 (rel/v1.11.0.RC3)
Author: Jacob Barrett
Message: GEODE-7418: Fixes issue deserializing unregistered PDX types. (#546)

* GEODE-7418: Fixes issue deserializing unregistered PDX types.
* If a PDX type does not have a domain class or registered serializer then
we now fall back to PdxInstance objects.
* Add test case to reproduce crash deserializing JSON values
* Add test case for serializing non-PDX types
* Test macro cleanup - Fixes test macros to properly handle ;


(cherry picked from commit c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c)

View the changeset: 
https://github.com/apache/geode-native/compare/rel/v1.11.0.RC3

View the full build log and details: 
https://travis-ci.org/apache/geode-native/builds/616987039?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11948127&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

[VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Mark Hanson]

Hello Geode Dev Community,

This is a release candidate for Apache Geode version 1.11.0.RC3.
Thanks to all the community members for their contributions to this release!

Please do a review and give your feedback, including the checks you performed.

Voting deadline:
11AM PST Monday December 2 2019.

Please note that we are voting upon the source tag:
rel/v1.11.0.RC3

Release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0

Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1063

GitHub:
https://github.com/apache/geode/tree/rel/v1.11.0.RC3
https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3

Pipelines:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc

Geode's KEYS file containing PGP keys we use to sign the release:
https://github.com/apache/geode/blob/develop/KEYS

Command to run geode-examples:
./gradlew 
-PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3 
-PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1063
 build runAll

Regards
Mark Hanson