date:20200708

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

2020-07-08 Thread Alexander Murmann

Hi Alberto,

The timing on this RFC feels really tight. Would you be open to extending
this to next week?

On Wed, Jul 8, 2020 at 1:04 PM Eric Shu  wrote:

> I think the only case the memory issue occurred is when all gateway
> senders are stopped in the wan-site. Otherwise another member would assume
> to be the primary queue. No more events will be enqueued in
> tmpDroppedEvents on the member with original primary queue. (For parallel
> wan queue, I do not think stop one gateway queue is a valid case to
> support.)
>
> For all gateway senders are stopped case, no need to notify any other
> members in the wan site if the limit is reached. The tmpDroppedEvents is
> only used for remove events on the secondary queue. If no events are
> enqueued in the secondary queue, there is no need to add into
> tmpDroppedEvents at all. To me, it should be only used for limited events
> to be queued.
>
> Regards,
> Eric
> 
> From: Alberto Gomez 
> Sent: Wednesday, July 8, 2020 12:02 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the
> primary gateway sender when the gateway sender is stopped
>
> Thanks for your comments, Eric.
>
> Limiting the size of the queue would be a simple solution but I think it
> would pose several problems on the the one configuring and operating Geode:
>
>   *   How big should the queue be? Probably not easy to dimension. Should
> the limit by on the memory occupied by the elements or on the number of
> elements in the queue (in which case, depending on the size of the
> elements, the memory used could vary a lot)?
>   *   What  to do when the limit has been reached? how do we notify that
> it was reached, what to do afterwards, how would we know what dropped
> events did not make it to the queue but should have been removed from the
> secondary's queue...
>
> I think the solution proposed in the RFC is simple enough and also
> addresses a possible confusion with the semantics of the gateway sender
> stop command.
> Stopping a gateway sender currently makes that all events received while
> the sender is stopped are dropped; but at the same time, unlimited memory
> may be consumed by the dropped events. We could put a limit on the amount
> of memory used by the queued dropped events but what would be the point in
> the first place to store them if those events will not be sent to the
> remote site anyway?
> I would expect that after stopping a gateway sender no resources (or at
> least a minimal part) would be consumed by it. Otherwise we may as well not
> stop it or use the pause command depending on what we want to achieve.
>
> From what I have seen, queuing dropped events has its place while the
> gateway sender is starting and while it is stopping but if it is done in a
> sender to be started manually or in a manually stopped server it could
> provoke an unexpected memory exhaustion.
>
> I really think the solution proposed makes the behavior of the gateway
> sender command more logical.
>
> Best regards,
>
> Alberto
> 
> From: Eric Shu 
> Sent: Wednesday, July 8, 2020 7:32 PM
> To: dev@geode.apache.org 
> Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the
> primary gateway sender when the gateway sender is stopped
>
> It seems that I was not able to comment on the RFC in the wiki yet.
>
> Just try to find out if we have a simple solution for the issue you raised
> -- can we have a up-limit for the tmpDroppedEvents queue in question?
>
> Always check the limit before adding to the queue -- so that the tmp queue
> is not unbound?
>
> Regards,
> Eric
> 
> From: Alberto Gomez 
> Sent: Monday, July 6, 2020 8:24 AM
> To: geode 
> Subject: [DISCUSS] RFC - Avoid the queueing of dropped events by the
> primary gateway sender when the gateway sender is stopped
>
> Hi,
>
> I have published a new RFC in the Apache Geode wiki with the following
> title: "Avoid the queueing of dropped events by the primary gateway sender
> when the gateway sender is stopped".
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAvoid%2Bthe%2Bqueuing%2Bof%2Bdropped%2Bevents%2Bby%2Bthe%2Bprimary%2Bgateway%2Bsender%2Bwhen%2Bthe%2Bgateway%2Bsender%2Bis%2Bstoppeddata=02%7C01%7Ceshu%40vmware.com%7C82aeb2f0bd30435131bd08d8237173c3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298317468898044sdata=ihK%2BeTvnhiA0XXcw22fv5VjjgzjYL2EQwL5%2Fe0KK%2F08%3Dreserved=0
>
> Could you please give comments by Thursday, July 9th, 2020?
>
> Thanks in advance,
>
> Alberto G.
>

Re: Request for wiki permission

2020-07-08 Thread Eric Shu

Thanks!

Eric

From: Kirk Lund 
Sent: Wednesday, July 8, 2020 1:28 PM
To: dev@geode.apache.org 
Subject: Re: Request for wiki permission

Ok, you should be good to go now, Eric! I added you to Geode AND gave you
write permissions.

On Wed, Jul 8, 2020 at 1:24 PM Kirk Lund  wrote:

> I see what's missing!
>
> On Wed, Jul 8, 2020 at 1:04 PM Eric Shu  wrote:
>
>> Here is what I have when I search the name with my profile:
>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fusers%2Fviewuserprofile.action%3Fusername%3Deshudata=02%7C01%7Ceshu%40vmware.com%7C85e1fcf181824caaf2b308d8237d770f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298369060664462sdata=TBPoA2lN8G40GFrvNNdTHTxDUp%2BRXEzP2vZczaoTdy8%3Dreserved=0
>>
>> Personal
>> Full NameEric Shu
>> Email
>> Phone
>> IM
>> Website
>>
>> Not sure what else I supposedly to do.
>>
>> Regards,
>> Eric
>> 
>> From: Kirk Lund 
>> Sent: Wednesday, July 8, 2020 10:44 AM
>> To: dev@geode.apache.org 
>> Subject: Re: Request for wiki permission
>>
>> Hi Eric,
>>
>> I can't find the "eshu" account on
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fdata=02%7C01%7Ceshu%40vmware.com%7C85e1fcf181824caaf2b308d8237d770f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298369060664462sdata=7FErISHJDEoH7PfToEiwcg5rlPFrApHw9%2FlH7pVLcC8%3Dreserved=0.
>> Please make
>> sure you've created the account on that server first. Then I can add the
>> edit permissions for Geode.
>>
>> Thanks,
>> Kirk
>>
>> On Wed, Jul 8, 2020 at 9:58 AM Eric Shu  wrote:
>>
>> > Hi,
>> >
>> > I am trying to comment on a wiki doc and need permissions for
>> Confluence.
>> > Please grant it.
>> >
>> > UserName: eshu
>> >
>> > Regards,
>> > Eric
>> >
>>
>

Re: Flaky test caused by missing JDK dependency

2020-07-08 Thread Kirk Lund

The Attach API is optional for Users running the product.

The Attach API is required to compile the classes that use the Attach API
and to run tests that cover this feature (such as "--pid").

On Wed, Jul 8, 2020 at 12:11 PM Anthony Baker  wrote:

> I thought we made the dependency on the Attach API optional when we added
> support for JDK 11?
>
> Anthony
>
>
> > On Jul 8, 2020, at 10:17 AM, Kirk Lund  wrote:
> >
> > To transition away from Attach API, the community needs a proposal to do
> so
> > and we'll need to deprecate the GFSH options that depend on Attach API
> such
> > as "--pid" in "status server --pid 20938". Even then we're looking at a
> > minimum of one major release before we can remove options after they are
> > deprecated.
> >
> > We haven't had a major release in 4+ years so don't hold your breath! :)
> >
> > On Wed, Jul 8, 2020 at 9:59 AM Sean Goller  wrote:
> >
> >> The Liberica JDK does not include the Attach API. I'm investigating why.
> >> Given the inherent insecurity of this API, I recommend we transition
> away
> >> from using it.
> >> 
> >> From: Kirk Lund 
> >> Sent: Monday, July 6, 2020 10:36 AM
> >> To: dev@geode.apache.org 
> >> Subject: Flaky test caused by missing JDK dependency
> >>
> >> CI Failure:
> >> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles
> >> failed with ConditionTimeoutException
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6183data=02%7C01%7Cbakera%40vmware.com%7Cdb5c3b93c1994223ff8b08d82362e699%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298254971916697sdata=g67yHspVjXA8pJjp0shhYf7fZWltB7EexUXJ6sck8F8%3Dreserved=0
> >>
> >> I've debugged the latest occurrence of GEODE-6183 (intermittent failure
> >> CI):
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main%2Fjobs%2FWindowsCoreIntegrationTestOpenJDK11%2Fbuilds%2F34data=02%7C01%7Cbakera%40vmware.com%7Cdb5c3b93c1994223ff8b08d82362e699%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298254971916697sdata=bACP7X6c%2By%2FtzyN6S65UEJ0xWRYxgEhM1KyvlYaYbSU%3Dreserved=0
> >>
> >> The underlying cause is a missing dependency: the Attach API. In the
> Oracle
> >> JDK, the Attach API is found in the JAVA_HOME/lib/tools.jar. In some
> JDKs,
> >> including LibericaJDK, there may not be a tools.jar or it may be missing
> >> from our image of specific JDKs or a specific OS. I confirmed that the
> >> Attach API is actually inside a different .jar on some Mac releases of
> the
> >> JDK.
> >>
> >> Other than JDK differences, I'm not sure why tools.jar would
> intermittently
> >> be missing from our testing image, but that's definitely the cause of
> >> WindowsCoreIntegrationTestOpenJDK11 failing. I've reviewed a couple
> other
> >> older runs and it was the same intermittent cause of failure.
> >>
> >> Does anyone know if LibericaJDK includes tools.jar or the Attach API?
> >>
> >> Does anyone know how to verify that our images all have tools.jar or its
> >> equivalent?
> >>
> >> java.util.ServiceConfigurationError:
> >> com.sun.tools.attach.spi.AttachProvider: Provider
> >> sun.tools.attach.WindowsAttachProvider not found
> >> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
> >> at
> >>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1211)
> >> at
> >>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
> >> at
> >>
> >>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
> >> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
> >> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
> >> at
> >>
> >>
> jdk.attach/com.sun.tools.attach.spi.AttachProvider.providers(AttachProvider.java:258)
> >> at
> >>
> >>
> jdk.attach/com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:144)
> >> at
> >>
> >>
> org.apache.geode.internal.process.AttachProcessUtils.isProcessAlive(AttachProcessUtils.java:35)
> >> at
> >>
> >>
> org.apache.geode.internal.process.ProcessUtils.isProcessAlive(ProcessUtils.java:99)
> >> at
> >>
> >>
> org.apache.geode.internal.process.lang.AvailablePid.findAvailablePid(AvailablePid.java:117)
> >> at
> >>
> >>
> org.apache.geode.distributed.LauncherIntegrationTestCase.setUpAbstractLauncherIntegrationTestCase(LauncherIntegrationTestCase.java:92)
> >>
>
>

Re: Request for wiki permission

2020-07-08 Thread Kirk Lund

Ok, you should be good to go now, Eric! I added you to Geode AND gave you
write permissions.

On Wed, Jul 8, 2020 at 1:24 PM Kirk Lund  wrote:

> I see what's missing!
>
> On Wed, Jul 8, 2020 at 1:04 PM Eric Shu  wrote:
>
>> Here is what I have when I search the name with my profile:
>>
>>
>> https://cwiki.apache.org/confluence/users/viewuserprofile.action?username=eshu
>>
>> Personal
>> Full NameEric Shu
>> Email
>> Phone
>> IM
>> Website
>>
>> Not sure what else I supposedly to do.
>>
>> Regards,
>> Eric
>> 
>> From: Kirk Lund 
>> Sent: Wednesday, July 8, 2020 10:44 AM
>> To: dev@geode.apache.org 
>> Subject: Re: Request for wiki permission
>>
>> Hi Eric,
>>
>> I can't find the "eshu" account on
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fdata=02%7C01%7Ceshu%40vmware.com%7C42904c454b304d2a248708d82366aa44%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637298271131613202sdata=dHngozyOCrQmZNTg%2FhebEUZxmVOleGDWPF3oQ2yytJc%3Dreserved=0.
>> Please make
>> sure you've created the account on that server first. Then I can add the
>> edit permissions for Geode.
>>
>> Thanks,
>> Kirk
>>
>> On Wed, Jul 8, 2020 at 9:58 AM Eric Shu  wrote:
>>
>> > Hi,
>> >
>> > I am trying to comment on a wiki doc and need permissions for
>> Confluence.
>> > Please grant it.
>> >
>> > UserName: eshu
>> >
>> > Regards,
>> > Eric
>> >
>>
>

Re: Request for wiki permission

2020-07-08 Thread Kirk Lund

I see what's missing!

On Wed, Jul 8, 2020 at 1:04 PM Eric Shu  wrote:

> Here is what I have when I search the name with my profile:
>
>
> https://cwiki.apache.org/confluence/users/viewuserprofile.action?username=eshu
>
> Personal
> Full NameEric Shu
> Email
> Phone
> IM
> Website
>
> Not sure what else I supposedly to do.
>
> Regards,
> Eric
> 
> From: Kirk Lund 
> Sent: Wednesday, July 8, 2020 10:44 AM
> To: dev@geode.apache.org 
> Subject: Re: Request for wiki permission
>
> Hi Eric,
>
> I can't find the "eshu" account on
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fdata=02%7C01%7Ceshu%40vmware.com%7C42904c454b304d2a248708d82366aa44%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637298271131613202sdata=dHngozyOCrQmZNTg%2FhebEUZxmVOleGDWPF3oQ2yytJc%3Dreserved=0.
> Please make
> sure you've created the account on that server first. Then I can add the
> edit permissions for Geode.
>
> Thanks,
> Kirk
>
> On Wed, Jul 8, 2020 at 9:58 AM Eric Shu  wrote:
>
> > Hi,
> >
> > I am trying to comment on a wiki doc and need permissions for Confluence.
> > Please grant it.
> >
> > UserName: eshu
> >
> > Regards,
> > Eric
> >
>

Re: Request for wiki permission

2020-07-08 Thread Eric Shu

Here is what I have when I search the name with my profile:

https://cwiki.apache.org/confluence/users/viewuserprofile.action?username=eshu

Personal
Full NameEric Shu
Email
Phone
IM
Website

Not sure what else I supposedly to do.

Regards,
Eric

From: Kirk Lund 
Sent: Wednesday, July 8, 2020 10:44 AM
To: dev@geode.apache.org 
Subject: Re: Request for wiki permission

Hi Eric,

I can't find the "eshu" account on 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fdata=02%7C01%7Ceshu%40vmware.com%7C42904c454b304d2a248708d82366aa44%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637298271131613202sdata=dHngozyOCrQmZNTg%2FhebEUZxmVOleGDWPF3oQ2yytJc%3Dreserved=0.
 Please make
sure you've created the account on that server first. Then I can add the
edit permissions for Geode.

Thanks,
Kirk

On Wed, Jul 8, 2020 at 9:58 AM Eric Shu  wrote:

> Hi,
>
> I am trying to comment on a wiki doc and need permissions for Confluence.
> Please grant it.
>
> UserName: eshu
>
> Regards,
> Eric
>

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

2020-07-08 Thread Eric Shu

I think the only case the memory issue occurred is when all gateway senders are 
stopped in the wan-site. Otherwise another member would assume to be the 
primary queue. No more events will be enqueued in tmpDroppedEvents on the 
member with original primary queue. (For parallel wan queue, I do not think 
stop one gateway queue is a valid case to support.)

For all gateway senders are stopped case, no need to notify any other members 
in the wan site if the limit is reached. The tmpDroppedEvents is only used for 
remove events on the secondary queue. If no events are enqueued in the 
secondary queue, there is no need to add into tmpDroppedEvents at all. To me, 
it should be only used for limited events to be queued.

Regards,
Eric

From: Alberto Gomez 
Sent: Wednesday, July 8, 2020 12:02 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the 
primary gateway sender when the gateway sender is stopped

Thanks for your comments, Eric.

Limiting the size of the queue would be a simple solution but I think it would 
pose several problems on the the one configuring and operating Geode:

  *   How big should the queue be? Probably not easy to dimension. Should the 
limit by on the memory occupied by the elements or on the number of elements in 
the queue (in which case, depending on the size of the elements, the memory 
used could vary a lot)?
  *   What  to do when the limit has been reached? how do we notify that it was 
reached, what to do afterwards, how would we know what dropped events did not 
make it to the queue but should have been removed from the secondary's queue...

I think the solution proposed in the RFC is simple enough and also addresses a 
possible confusion with the semantics of the gateway sender stop command.
Stopping a gateway sender currently makes that all events received while the 
sender is stopped are dropped; but at the same time, unlimited memory may be 
consumed by the dropped events. We could put a limit on the amount of memory 
used by the queued dropped events but what would be the point in the first 
place to store them if those events will not be sent to the remote site anyway?
I would expect that after stopping a gateway sender no resources (or at least a 
minimal part) would be consumed by it. Otherwise we may as well not stop it or 
use the pause command depending on what we want to achieve.

>From what I have seen, queuing dropped events has its place while the gateway 
>sender is starting and while it is stopping but if it is done in a sender to 
>be started manually or in a manually stopped server it could provoke an 
>unexpected memory exhaustion.

I really think the solution proposed makes the behavior of the gateway sender 
command more logical.

Best regards,

Alberto

From: Eric Shu 
Sent: Wednesday, July 8, 2020 7:32 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the 
primary gateway sender when the gateway sender is stopped

It seems that I was not able to comment on the RFC in the wiki yet.

Just try to find out if we have a simple solution for the issue you raised -- 
can we have a up-limit for the tmpDroppedEvents queue in question?

Always check the limit before adding to the queue -- so that the tmp queue is 
not unbound?

Regards,
Eric

From: Alberto Gomez 
Sent: Monday, July 6, 2020 8:24 AM
To: geode 
Subject: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary 
gateway sender when the gateway sender is stopped

Hi,

I have published a new RFC in the Apache Geode wiki with the following title: 
"Avoid the queueing of dropped events by the primary gateway sender when the 
gateway sender is stopped".

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAvoid%2Bthe%2Bqueuing%2Bof%2Bdropped%2Bevents%2Bby%2Bthe%2Bprimary%2Bgateway%2Bsender%2Bwhen%2Bthe%2Bgateway%2Bsender%2Bis%2Bstoppeddata=02%7C01%7Ceshu%40vmware.com%7C82aeb2f0bd30435131bd08d8237173c3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298317468898044sdata=ihK%2BeTvnhiA0XXcw22fv5VjjgzjYL2EQwL5%2Fe0KK%2F08%3Dreserved=0

Could you please give comments by Thursday, July 9th, 2020?

Thanks in advance,

Alberto G.

Re: Flaky test caused by missing JDK dependency

2020-07-08 Thread Anthony Baker

I thought we made the dependency on the Attach API optional when we added 
support for JDK 11?

Anthony


> On Jul 8, 2020, at 10:17 AM, Kirk Lund  wrote:
> 
> To transition away from Attach API, the community needs a proposal to do so
> and we'll need to deprecate the GFSH options that depend on Attach API such
> as "--pid" in "status server --pid 20938". Even then we're looking at a
> minimum of one major release before we can remove options after they are
> deprecated.
> 
> We haven't had a major release in 4+ years so don't hold your breath! :)
> 
> On Wed, Jul 8, 2020 at 9:59 AM Sean Goller  wrote:
> 
>> The Liberica JDK does not include the Attach API. I'm investigating why.
>> Given the inherent insecurity of this API, I recommend we transition away
>> from using it.
>> 
>> From: Kirk Lund 
>> Sent: Monday, July 6, 2020 10:36 AM
>> To: dev@geode.apache.org 
>> Subject: Flaky test caused by missing JDK dependency
>> 
>> CI Failure:
>> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles
>> failed with ConditionTimeoutException
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6183data=02%7C01%7Cbakera%40vmware.com%7Cdb5c3b93c1994223ff8b08d82362e699%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298254971916697sdata=g67yHspVjXA8pJjp0shhYf7fZWltB7EexUXJ6sck8F8%3Dreserved=0
>> 
>> I've debugged the latest occurrence of GEODE-6183 (intermittent failure
>> CI):
>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main%2Fjobs%2FWindowsCoreIntegrationTestOpenJDK11%2Fbuilds%2F34data=02%7C01%7Cbakera%40vmware.com%7Cdb5c3b93c1994223ff8b08d82362e699%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298254971916697sdata=bACP7X6c%2By%2FtzyN6S65UEJ0xWRYxgEhM1KyvlYaYbSU%3Dreserved=0
>> 
>> The underlying cause is a missing dependency: the Attach API. In the Oracle
>> JDK, the Attach API is found in the JAVA_HOME/lib/tools.jar. In some JDKs,
>> including LibericaJDK, there may not be a tools.jar or it may be missing
>> from our image of specific JDKs or a specific OS. I confirmed that the
>> Attach API is actually inside a different .jar on some Mac releases of the
>> JDK.
>> 
>> Other than JDK differences, I'm not sure why tools.jar would intermittently
>> be missing from our testing image, but that's definitely the cause of
>> WindowsCoreIntegrationTestOpenJDK11 failing. I've reviewed a couple other
>> older runs and it was the same intermittent cause of failure.
>> 
>> Does anyone know if LibericaJDK includes tools.jar or the Attach API?
>> 
>> Does anyone know how to verify that our images all have tools.jar or its
>> equivalent?
>> 
>> java.util.ServiceConfigurationError:
>> com.sun.tools.attach.spi.AttachProvider: Provider
>> sun.tools.attach.WindowsAttachProvider not found
>> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
>> at
>> 
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1211)
>> at
>> 
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
>> at
>> 
>> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
>> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
>> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
>> at
>> 
>> jdk.attach/com.sun.tools.attach.spi.AttachProvider.providers(AttachProvider.java:258)
>> at
>> 
>> jdk.attach/com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:144)
>> at
>> 
>> org.apache.geode.internal.process.AttachProcessUtils.isProcessAlive(AttachProcessUtils.java:35)
>> at
>> 
>> org.apache.geode.internal.process.ProcessUtils.isProcessAlive(ProcessUtils.java:99)
>> at
>> 
>> org.apache.geode.internal.process.lang.AvailablePid.findAvailablePid(AvailablePid.java:117)
>> at
>> 
>> org.apache.geode.distributed.LauncherIntegrationTestCase.setUpAbstractLauncherIntegrationTestCase(LauncherIntegrationTestCase.java:92)
>>

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

2020-07-08 Thread Alberto Gomez

Thanks for your comments, Eric.

Limiting the size of the queue would be a simple solution but I think it would 
pose several problems on the the one configuring and operating Geode:

  *   How big should the queue be? Probably not easy to dimension. Should the 
limit by on the memory occupied by the elements or on the number of elements in 
the queue (in which case, depending on the size of the elements, the memory 
used could vary a lot)?
  *   What  to do when the limit has been reached? how do we notify that it was 
reached, what to do afterwards, how would we know what dropped events did not 
make it to the queue but should have been removed from the secondary's queue...

I think the solution proposed in the RFC is simple enough and also addresses a 
possible confusion with the semantics of the gateway sender stop command.
Stopping a gateway sender currently makes that all events received while the 
sender is stopped are dropped; but at the same time, unlimited memory may be 
consumed by the dropped events. We could put a limit on the amount of memory 
used by the queued dropped events but what would be the point in the first 
place to store them if those events will not be sent to the remote site anyway?
I would expect that after stopping a gateway sender no resources (or at least a 
minimal part) would be consumed by it. Otherwise we may as well not stop it or 
use the pause command depending on what we want to achieve.

>From what I have seen, queuing dropped events has its place while the gateway 
>sender is starting and while it is stopping but if it is done in a sender to 
>be started manually or in a manually stopped server it could provoke an 
>unexpected memory exhaustion.

I really think the solution proposed makes the behavior of the gateway sender 
command more logical.

Best regards,

Alberto

From: Eric Shu 
Sent: Wednesday, July 8, 2020 7:32 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the 
primary gateway sender when the gateway sender is stopped

It seems that I was not able to comment on the RFC in the wiki yet.

Just try to find out if we have a simple solution for the issue you raised -- 
can we have a up-limit for the tmpDroppedEvents queue in question?

Always check the limit before adding to the queue -- so that the tmp queue is 
not unbound?

Regards,
Eric

From: Alberto Gomez 
Sent: Monday, July 6, 2020 8:24 AM
To: geode 
Subject: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary 
gateway sender when the gateway sender is stopped

Hi,

I have published a new RFC in the Apache Geode wiki with the following title: 
"Avoid the queueing of dropped events by the primary gateway sender when the 
gateway sender is stopped".

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAvoid%2Bthe%2Bqueuing%2Bof%2Bdropped%2Bevents%2Bby%2Bthe%2Bprimary%2Bgateway%2Bsender%2Bwhen%2Bthe%2Bgateway%2Bsender%2Bis%2Bstoppeddata=02%7C01%7Ceshu%40vmware.com%7Cf4d61d141c014854f4c508d821c0a78e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637296458615861191sdata=Nqd%2FeUxXR713XIzn5KRg4x2V6CJIGHSgTEEwlTEzryk%3Dreserved=0

Could you please give comments by Thursday, July 9th, 2020?

Thanks in advance,

Alberto G.

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

2020-07-08 Thread steve mathew

Thanks Jacob and Anthony for sharing the details.

I have tried to understand list_of_mbeans supported but finding it tough to
understand completely. I can see "DiskStoreMXBean" and document says it can
provide region(s) specific disk usage.

For my experiment, looking for *mbeans that provide data node's (member)
specific heap and disk usage*.. It would be great help if someone can guide
me about these MBeans and how to use it to get the required stats (or point
me some reference outlining this details.)

Thanks
-Steve

On Wed, Jul 8, 2020 at 10:27 PM Anthony Baker  wrote:

> Another option is JMX, see
> https://geode.apache.org/docs/guide/19/managing/management/list_of_mbeans.html
> .
>
> Anthony
>
>
> On Jul 8, 2020, at 9:24 AM, Jacob Barrett  jabarr...@vmware.com>> wrote:
>
> Steve,
>
> Geode is in a transition from its on disk proprietary stats format to
> utilizing Micrometer.io<
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrometer.io%2F=02%7C01%7Cbakera%40vmware.com%7C839050aa773449021fec08d8235b6e94%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298222885245763=akhmzrYaO3ARYP5mV6vhSAjcoudT1kp1QLeJVCjTdFM%3D=0>.
> Some of what you are looking for may already be exposed via Micrometer. If
> so you can just use whatever registry of your choice to publish those
> stats. If the metric you need is not converted to Micrometer its pretty
> easy in most cases to refactor it and we would welcome a JIRA or even
> better a PR.
>
> -Jake
>
>
> On Jul 7, 2020, at 9:58 PM, steve mathew  steve.mathe...@gmail.com>> wrote:
>
> Hello Geode Dev and users
>
> We have a requirement to constantly monitor the resource utilization (Disk
> and Heap usage) for the cluster nodes from external processes.
> Seeking help to understand the recommended way (or APIs available ) to get
> this in a separate process...We need to trigger some actions/custom logic
> if it goes above some threshold..
>
> Thanks
> Steve.
>
>
>

Re: Request for wiki permission

2020-07-08 Thread Kirk Lund

Hi Eric,

I can't find the "eshu" account on https://cwiki.apache.org/. Please make
sure you've created the account on that server first. Then I can add the
edit permissions for Geode.

Thanks,
Kirk

On Wed, Jul 8, 2020 at 9:58 AM Eric Shu  wrote:

> Hi,
>
> I am trying to comment on a wiki doc and need permissions for Confluence.
> Please grant it.
>
> UserName: eshu
>
> Regards,
> Eric
>

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

2020-07-08 Thread Eric Shu

It seems that I was not able to comment on the RFC in the wiki yet.

Just try to find out if we have a simple solution for the issue you raised -- 
can we have a up-limit for the tmpDroppedEvents queue in question?

Always check the limit before adding to the queue -- so that the tmp queue is 
not unbound?

Regards,
Eric

From: Alberto Gomez 
Sent: Monday, July 6, 2020 8:24 AM
To: geode 
Subject: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary 
gateway sender when the gateway sender is stopped

Hi,

I have published a new RFC in the Apache Geode wiki with the following title: 
"Avoid the queueing of dropped events by the primary gateway sender when the 
gateway sender is stopped".

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FAvoid%2Bthe%2Bqueuing%2Bof%2Bdropped%2Bevents%2Bby%2Bthe%2Bprimary%2Bgateway%2Bsender%2Bwhen%2Bthe%2Bgateway%2Bsender%2Bis%2Bstoppeddata=02%7C01%7Ceshu%40vmware.com%7Cf4d61d141c014854f4c508d821c0a78e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637296458615861191sdata=Nqd%2FeUxXR713XIzn5KRg4x2V6CJIGHSgTEEwlTEzryk%3Dreserved=0

Could you please give comments by Thursday, July 9th, 2020?

Thanks in advance,

Alberto G.

Re: about Liberica JDK

2020-07-08 Thread Jacob Barrett



> On Jul 8, 2020, at 10:25 AM, Robert Houghton  wrote:
> 
> Only partially tongue-in-cheek, but isn’t the promise of the JDK, that it is 
> the same everywhere, on all versions, builds, and platforms?

No, only the JRE.

-Jake

Re: about Liberica JDK

2020-07-08 Thread Robert Houghton

Only partially tongue-in-cheek, but isn’t the promise of the JDK, that it is 
the same everywhere, on all versions, builds, and platforms?

From: Kirk Lund 
Date: Wednesday, July 8, 2020 at 10:23 AM
To: dev@geode.apache.org 
Subject: Re: about Liberica JDK
In the future, I think we should discuss and propose changing the JDK on
this dev-list before making the changes.

On Tue, Jul 7, 2020 at 9:01 AM Anthony Baker  wrote:

> Liberica is an OpenJDK distribution like AdoptOpenJDK, Oracle, RedHat,
> Amazon, Azul, etc.  I have yet to find a behavioral difference between the
> distributions—it’s mostly about ease of acquiring binaries and LTS support.
> Just for simplicity I would prefer to use a single JDK distribution across
> versions in our CI pipelines.
>
>
> Anthony
>
>
> > On Jul 7, 2020, at 2:21 AM, Alberto Bustamante Reyes
>  wrote:
> >
> > Hi devs,
> >
> > I have seen in develop branch this commit that changes openjdk by
> Liberica JDK (
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5312data=02%7C01%7Crhoughton%40vmware.com%7C3b7d69b430bc4bd4faf408d823639d41%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637298258028125419sdata=SH3ASp6W1EjfWUccN5ssm1EmNihh9T8FK%2F1NsHxmS7k%3Dreserved=0
> ), although it was reverted later so I suppose there are still issues to be
> solved.
> >
> > I didn't know Liberica and I'm curious about the change. Why is this
> change being implemented?
> >
> > BR/
> >
> > Alberto B.
> >
>
>

Re: about Liberica JDK

2020-07-08 Thread Kirk Lund

In the future, I think we should discuss and propose changing the JDK on
this dev-list before making the changes.

On Tue, Jul 7, 2020 at 9:01 AM Anthony Baker  wrote:

> Liberica is an OpenJDK distribution like AdoptOpenJDK, Oracle, RedHat,
> Amazon, Azul, etc.  I have yet to find a behavioral difference between the
> distributions—it’s mostly about ease of acquiring binaries and LTS support.
> Just for simplicity I would prefer to use a single JDK distribution across
> versions in our CI pipelines.
>
>
> Anthony
>
>
> > On Jul 7, 2020, at 2:21 AM, Alberto Bustamante Reyes
>  wrote:
> >
> > Hi devs,
> >
> > I have seen in develop branch this commit that changes openjdk by
> Liberica JDK (
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5312data=02%7C01%7Cbakera%40vmware.com%7C92aa27c47a164abdd6b808d822573a33%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637297105319626477sdata=X3V4jcQ7DWEVtJuUaXOQy%2F0l3xri9g4a0%2BfflLmui1g%3Dreserved=0
> ), although it was reverted later so I suppose there are still issues to be
> solved.
> >
> > I didn't know Liberica and I'm curious about the change. Why is this
> change being implemented?
> >
> > BR/
> >
> > Alberto B.
> >
>
>

Re: Flaky test caused by missing JDK dependency

2020-07-08 Thread Kirk Lund

To transition away from Attach API, the community needs a proposal to do so
and we'll need to deprecate the GFSH options that depend on Attach API such
as "--pid" in "status server --pid 20938". Even then we're looking at a
minimum of one major release before we can remove options after they are
deprecated.

We haven't had a major release in 4+ years so don't hold your breath! :)

On Wed, Jul 8, 2020 at 9:59 AM Sean Goller  wrote:

> The Liberica JDK does not include the Attach API. I'm investigating why.
> Given the inherent insecurity of this API, I recommend we transition away
> from using it.
> 
> From: Kirk Lund 
> Sent: Monday, July 6, 2020 10:36 AM
> To: dev@geode.apache.org 
> Subject: Flaky test caused by missing JDK dependency
>
> CI Failure:
> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles
> failed with ConditionTimeoutException
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6183data=02%7C01%7Csgoller%40vmware.com%7Cbcfa660e6577442247ee08d821d3283c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637296538083290882sdata=7HMMMxvHvdlJf8Awc9zAl7Xr9291Ep0HMoto5%2F%2BgUys%3Dreserved=0
>
> I've debugged the latest occurrence of GEODE-6183 (intermittent failure
> CI):
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main%2Fjobs%2FWindowsCoreIntegrationTestOpenJDK11%2Fbuilds%2F34data=02%7C01%7Csgoller%40vmware.com%7Cbcfa660e6577442247ee08d821d3283c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637296538083290882sdata=x1FIsAQOyZd%2Bvl%2BRRkzI8yGeFW%2B04sMuO4JM%2F67vu8w%3Dreserved=0
>
> The underlying cause is a missing dependency: the Attach API. In the Oracle
> JDK, the Attach API is found in the JAVA_HOME/lib/tools.jar. In some JDKs,
> including LibericaJDK, there may not be a tools.jar or it may be missing
> from our image of specific JDKs or a specific OS. I confirmed that the
> Attach API is actually inside a different .jar on some Mac releases of the
> JDK.
>
> Other than JDK differences, I'm not sure why tools.jar would intermittently
> be missing from our testing image, but that's definitely the cause of
> WindowsCoreIntegrationTestOpenJDK11 failing. I've reviewed a couple other
> older runs and it was the same intermittent cause of failure.
>
> Does anyone know if LibericaJDK includes tools.jar or the Attach API?
>
> Does anyone know how to verify that our images all have tools.jar or its
> equivalent?
>
> java.util.ServiceConfigurationError:
> com.sun.tools.attach.spi.AttachProvider: Provider
> sun.tools.attach.WindowsAttachProvider not found
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
> at
>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1211)
> at
>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
> at
>
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
> at
>
> jdk.attach/com.sun.tools.attach.spi.AttachProvider.providers(AttachProvider.java:258)
> at
>
> jdk.attach/com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:144)
> at
>
> org.apache.geode.internal.process.AttachProcessUtils.isProcessAlive(AttachProcessUtils.java:35)
> at
>
> org.apache.geode.internal.process.ProcessUtils.isProcessAlive(ProcessUtils.java:99)
> at
>
> org.apache.geode.internal.process.lang.AvailablePid.findAvailablePid(AvailablePid.java:117)
> at
>
> org.apache.geode.distributed.LauncherIntegrationTestCase.setUpAbstractLauncherIntegrationTestCase(LauncherIntegrationTestCase.java:92)
>

Request for wiki permission

2020-07-08 Thread Eric Shu

Hi,

I am trying to comment on a wiki doc and need permissions for Confluence. 
Please grant it.

UserName: eshu

Regards,
Eric

Re: Flaky test caused by missing JDK dependency

2020-07-08 Thread Sean Goller

The Liberica JDK does not include the Attach API. I'm investigating why. Given 
the inherent insecurity of this API, I recommend we transition away from using 
it.

From: Kirk Lund 
Sent: Monday, July 6, 2020 10:36 AM
To: dev@geode.apache.org 
Subject: Flaky test caused by missing JDK dependency

CI Failure:
LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles
failed with ConditionTimeoutException
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6183data=02%7C01%7Csgoller%40vmware.com%7Cbcfa660e6577442247ee08d821d3283c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637296538083290882sdata=7HMMMxvHvdlJf8Awc9zAl7Xr9291Ep0HMoto5%2F%2BgUys%3Dreserved=0

I've debugged the latest occurrence of GEODE-6183 (intermittent failure CI):
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-13-main%2Fjobs%2FWindowsCoreIntegrationTestOpenJDK11%2Fbuilds%2F34data=02%7C01%7Csgoller%40vmware.com%7Cbcfa660e6577442247ee08d821d3283c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637296538083290882sdata=x1FIsAQOyZd%2Bvl%2BRRkzI8yGeFW%2B04sMuO4JM%2F67vu8w%3Dreserved=0

The underlying cause is a missing dependency: the Attach API. In the Oracle
JDK, the Attach API is found in the JAVA_HOME/lib/tools.jar. In some JDKs,
including LibericaJDK, there may not be a tools.jar or it may be missing
from our image of specific JDKs or a specific OS. I confirmed that the
Attach API is actually inside a different .jar on some Mac releases of the
JDK.

Other than JDK differences, I'm not sure why tools.jar would intermittently
be missing from our testing image, but that's definitely the cause of
WindowsCoreIntegrationTestOpenJDK11 failing. I've reviewed a couple other
older runs and it was the same intermittent cause of failure.

Does anyone know if LibericaJDK includes tools.jar or the Attach API?

Does anyone know how to verify that our images all have tools.jar or its
equivalent?

java.util.ServiceConfigurationError:
com.sun.tools.attach.spi.AttachProvider: Provider
sun.tools.attach.WindowsAttachProvider not found
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
at
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1211)
at
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
at
java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
at
jdk.attach/com.sun.tools.attach.spi.AttachProvider.providers(AttachProvider.java:258)
at
jdk.attach/com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:144)
at
org.apache.geode.internal.process.AttachProcessUtils.isProcessAlive(AttachProcessUtils.java:35)
at
org.apache.geode.internal.process.ProcessUtils.isProcessAlive(ProcessUtils.java:99)
at
org.apache.geode.internal.process.lang.AvailablePid.findAvailablePid(AvailablePid.java:117)
at
org.apache.geode.distributed.LauncherIntegrationTestCase.setUpAbstractLauncherIntegrationTestCase(LauncherIntegrationTestCase.java:92)

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

2020-07-08 Thread Anthony Baker

Another option is JMX, see 
https://geode.apache.org/docs/guide/19/managing/management/list_of_mbeans.html.

Anthony


On Jul 8, 2020, at 9:24 AM, Jacob Barrett 
mailto:jabarr...@vmware.com>> wrote:

Steve,

Geode is in a transition from its on disk proprietary stats format to utilizing 
Micrometer.io.
 Some of what you are looking for may already be exposed via Micrometer. If so 
you can just use whatever registry of your choice to publish those stats. If 
the metric you need is not converted to Micrometer its pretty easy in most 
cases to refactor it and we would welcome a JIRA or even better a PR.

-Jake


On Jul 7, 2020, at 9:58 PM, steve mathew 
mailto:steve.mathe...@gmail.com>> wrote:

Hello Geode Dev and users

We have a requirement to constantly monitor the resource utilization (Disk
and Heap usage) for the cluster nodes from external processes.
Seeking help to understand the recommended way (or APIs available ) to get
this in a separate process...We need to trigger some actions/custom logic
if it goes above some threshold..

Thanks
Steve.

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

2020-07-08 Thread Jacob Barrett

Steve,

Geode is in a transition from its on disk proprietary stats format to utilizing 
Micrometer.io. Some of what you are looking for may 
already be exposed via Micrometer. If so you can just use whatever registry of 
your choice to publish those stats. If the metric you need is not converted to 
Micrometer its pretty easy in most cases to refactor it and we would welcome a 
JIRA or even better a PR.

-Jake


On Jul 7, 2020, at 9:58 PM, steve mathew 
mailto:steve.mathe...@gmail.com>> wrote:

Hello Geode Dev and users

We have a requirement to constantly monitor the resource utilization (Disk
and Heap usage) for the cluster nodes from external processes.
Seeking help to understand the recommended way (or APIs available ) to get
this in a separate process...We need to trigger some actions/custom logic
if it goes above some threshold..

Thanks
Steve.

Re: geode docker question

2020-07-08 Thread Joris Melchior

You might also want to look at docker compose so that locator and server can 
run in separate containers.

On 2020-07-08, 12:18 AM, "Mark Hanson"  wrote:

Here is a command that actually runs.. 

You need to be in the Geode directory, the run the command below to start 
everything.  
docker run -it -v $(pwd):/apache-geode  openjdk:8 sh -c 
"apache-geode/bin/gfsh -e 'start locator --name=Locator1' -e  'start server 
--name=Server1'" -c ""

Thanks,
Mark
On 7/7/20, 10:42 AM, "Mark Hanson"  wrote:

Hi Barry,

Are you looking for something like this?

docker run -it -v $(pwd):/apache_geode  openjdk:8 sh -c 
"apache-geode/bin/gfsh -e "start locator --name=Locator1" -e  "start server 
--name=Server1" 
^ shared location   
^ not sure this path is right but you get the idea.

Thanks,
Mark

On 7/7/20, 10:29 AM, "Barry Barrios"  wrote:

Do you have Apache Geode examples using docker? Is there a way to 
run a
docker container that automatically creates locator and server by
specifying some parameters without typing them in the gfsh shell 
prompt?
Also, same for deploying jars, is there a way to automatically 
deploy jars
when running docker? I was browsing through your apache geode 
examples
github repo to see if there were examples but didn't find what I was
looking for.

Best,
Barry

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

Re: Request for wiki permission

Re: Flaky test caused by missing JDK dependency

Re: Request for wiki permission

Re: Request for wiki permission

Re: Request for wiki permission

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

Re: Flaky test caused by missing JDK dependency

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

Re: Request for wiki permission

Re: [DISCUSS] RFC - Avoid the queueing of dropped events by the primary gateway sender when the gateway sender is stopped

Re: about Liberica JDK

Re: about Liberica JDK

Re: about Liberica JDK

Re: Flaky test caused by missing JDK dependency

Request for wiki permission

Re: Flaky test caused by missing JDK dependency

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

Re: geode docker question

21 matches

Site Navigation

Mail list logo

Footer information