Re: [Proposal] Make gfsh "stop server" command synchronous

Blocking or non-blocking, I don't have a strong opinion.  What I'd really like to have gfsh ensure, though, is that no-one is able to start a new instance of a server while the old process is still around.  Maybe the PID file is the way to do that. On 9/10/19 3:08 PM, Mark Hanson wrote: Hello

Re: [Proposal] Make gfsh "stop server" command synchronous

To circle back to the original test failure that prompted this discussion - the failing test was getting intermittent bind exceptions on subsequent server restarts. I believe it's quite likely that a process' ports will remain unavailable even after it is gone (I'm not sure if we create listening

resource manager requirements & recommendations

Hi all, Im interested on using the resource manager with G1 garbage collector. To check if it is possible, I have been reading documentation about heap memory management and I came up with some questions because there are some points in the documentation where it is not clear for me if they are

Re: resource manager requirements & recommendations

The challenge with designing a good approach for managing heap use in Java is that we *can’t* know how much of the current heap use is really garbage. That means that it can be really easy to evict too much or too little data. With the CMS engine there are tuning parameters like occupancy fract

Re: [Proposal] Make gfsh "stop server" command synchronous

It does seem like we should make stop synchronous, or at least make start wait for the old process to die as Bruce suggested. Otherwise it is difficult for someone to script the restart of a server. Looking at the code, it does look like gfsh stop is asynchronous. There are multiple ways to stop a

Question about excluding serialized classes

As part of a PR to add Micrometer timers for function executions , we implemented a decorator Function that wraps all registered non-internal functions and adds instrumentation. This PR is failing AnalyzeSerializablesJUnitTest.testSerializables because the

Re: [Proposal] Make gfsh "stop server" command synchronous

The idea I am working with at the moment that Kirk pointed me at was to use the pid file in the directory as indicator. Once that file disappears the server is stopped. That seems to work in my testing. Thoughts? Thanks, Mark > On Sep 11, 2019, at 10:23 AM, Dan Smith wrote: > > It does seem

Re: [Proposal] Make gfsh "stop server" command synchronous

+1 to Bruce's comments as well. This is exactly the kind of thing I needed to do (handle) inside of the *Spring Test for Apache Geode* (STDG) project from a framework perspective, to ensure that other projects relying on STDG (e.g. SBDG, SSDG) for their integration testing purposes (e.g. client/se

Re: Question about excluding serialized classes

Functions are serialized when you call Execution.execute(Function) instead of Execution.execute(String). Invoking execute on a function object serializes the function and executes it on the remote side. Functions executed this way don't have be registered. Users can also get registered function ob

Re: [Proposal] Make gfsh "stop server" command synchronous

> The idea I am working with at the moment that Kirk pointed me at was to use the pid file in the directory as indicator. Once that file disappears the server is stopped. How will this work if stop server --member is invoked some a different machine than the member that is being stopped? -Dan On

Re: Question about excluding serialized classes

Thanks for your response, Dan. The second scenario you mentioned (i.e. users calling FunctionService.getFunction(String)) worries me because our PR changes the FunctionService so they would now get back an instance of the decorator function instead of the specific instance they registered by calli

Re: Question about excluding serialized classes

Yeah, I would expect that FunctionService.getFunction() would return the same function object I registered with FunctionService.registerFunction. -Dan On Wed, Sep 11, 2019 at 12:01 PM Aaron Lindsey wrote: > Thanks for your response, Dan. > > The second scenario you mentioned (i.e. users calling

Re: Question about excluding serialized classes

I think the Decorator approach you outlined could have other impacts as well. Would I still be able to see specific function executions in statistics or would they all become “TImingFunction”? Anthony > On Sep 11, 2019, at 12:00 PM, Aaron Lindsey wrote: > > Thanks for your response, Dan. >

Re: Question about excluding serialized classes

They would be the specific functions, but this doesn’t get us around they other problem. I think this approach is not going to work and we are about to start looking into other ways. Thanks, Mark > On Sep 11, 2019, at 12:14 PM, Anthony Baker wrote: > > I think the Decorator approach you outli

Re: Question about excluding serialized classes

I think you could still use your decorator approach if you also unwrap the Functions when returning them from the public APIs like getFunction etc. In that case your TimingFunction could probably safely by added to excludedClasses.txt. You will miss collecting metrics about functions that aren't r

Re: [Proposal] Make gfsh "stop server" command synchronous

Good question. I will have to look into that. Thanks, Mark > On Sep 11, 2019, at 10:53 AM, Dan Smith wrote: > >> The idea I am working with at the moment that Kirk pointed me at was to > use the pid file in the directory as indicator. Once that file disappears > the server is stopped. > > How

Re: Question about excluding serialized classes

The stats use the ID of the function, and each TimingFunction reports the same ID as the function it wraps. So I think the stats would look like they always did. Dale — Dale Emery dem...@pivotal.io > On Sep 11, 2019, at 12:14 PM, Anthony Baker wrote: > > I think the Decorator approach you

Re: Question about excluding serialized classes

As far as I can tell, the things that execute functions use the public API to find the function to execute. So if we unwrap the functions in the public API, only the un-instrumented functions will be executed. — Dale Emery dem...@pivotal.io > On Sep 11, 2019, at 1:38 PM, Dan Smith wrote: >

Re: [DISCUSS] Improvements on client function execution API

+1 - Ok, I think I've come around to option (a). We can go head and add a new execute(timeout, TimeUnit) method to the java API that is blocking. We can leave the existing execute() method alone, except for documenting what it is doing. I would like implement execute(timeout, TimeUnit) on the ser

important change in backward-compatibility testing

To fix GEODE-7168 I have modified the backward-compatibility framework to preserve periods in version names.  Prior to the change versions were in the form "100", "110", "120", etc.  Now they are "1.0.0-incubating", "1.1.0", "1.2.0", etc. When requesting a VM that's running a particular versio

Errored: apache/geode-native#2084 (release/1.10.0 - 0668f6b)

Build Update for apache/geode-native - Build: #2084 Status: Errored Duration: 2 hrs, 0 mins, and 18 secs Commit: 0668f6b (release/1.10.0) Author: Owen Nichols Message: GEODE-7182: fix a warning in TcpSslConn.cpp that prevents successful compilation on gcc 8.3

Re: [DISCUSS] Improvements on client function execution API

+1 I echo Dan’s comments as well. Thanks for tackling this. -jake > On Sep 11, 2019, at 2:36 PM, Dan Smith wrote: > > +1 - Ok, I think I've come around to option (a). We can go head and add a > new execute(timeout, TimeUnit) method to the java API that is blocking. We > can leave the exist