Hello,
I am requesting permission to add and edit Geode Wiki pages.
My user ID on Apache Confluence is: demery
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
Hi,
I am requesting Jira permission to assign Jira tickets to myself.
My user ID is demery
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
oining lines only in method chains.
Comments?
Dale
—
Dale Emery
dem...@pivotal.io
to organize tests for those purposes, then use tagging for
crosscutting or ad hoc selection.
—
Dale Emery
dem...@pivotal.io
> On Jun 26, 2018, at 4:34 PM, Patrick Rhomberg wrote:
>
> I like the idea of good structure around our test-complexity @Category
> layout.
>
> @Alexa
t or Assertj? I am happy with either though I will note that
> JUnit Assert does not seem to have a fail where you can pass in the
> exception, which is used a lot in Geode. I look forward to an answer.
>
> Thanks,
> Mark
>
>
—
Dale Emery
dem...@pivotal.io
> }
>
> // example usage:
> new ConcurrentTestHelper()
> .runAndExpectException(runnable, UnsupportedOperationException.class)
> .runAndExpectNoException(runnable)
> .runAndExpectValue(callable, result)
> .repeatUntilAllOtherRunnablesFinish(runnable)
> .repeatFor(runnable, time) //keep doing this for time amount of time
> .repeat(runnable, iterations) //keep doing this for N times
> .setTimeout(seconds) //Throws exception if test takes too long
> .executeInParallel();
—
Dale Emery
dem...@pivotal.io
ick Rhomberg]
> GEODE-5578 - [Robert Houghton]
> GEODE-5492 - [Robert Houghton]
> GEODE-5280 - [xiaojian zhou & Biju Kunjummen]
> GEODE-5254 - [Dale Emery]
>
> GEODE-4794 - [Sai]
> GEODE-5594 - [Sai]
>
> Regards
> Nabarun Nag
>
>
> On Fri, Aug 31, 2018 at 3
all of these elements, we may have some of them. That can
help us
calibrate our confidence. But the elements work together. If we’re lacking one,
the others
are shaky, to some extent.
The more elements are missing in our explanation, the more times I’d want to
run the test
before trusting it.
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
the
> category from the rest?
>
> I think will we get more benefit from shaking out and fixing the issues we
> have in the current codebase than we will from carefully explaining the
> flaky failures from the past.
>
> -Dan
>
> On Thu, Jul 5, 2018 at 7:03 PM, Dale Emery
If there’s enough duplication in the lambdas, or in the code around the
lambdas, extracting the duplication into methods would reduce the number of
lambdas.
> On Sep 10, 2018, at 11:03 AM, Kirk Lund wrote:
>
> Alright I'm more up-to-date on this thread. Some things to consider:
>
> The
Hello,
I am a new hire at Pivotal. I would like access to the Geode CI Pipeline. Can
you add me?
My GitHub account is: dhemery
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
; output to standard out (using System.out.println or such). I also propose
> we add this to the Geode style guide.
>
> Thoughts/questions/objections?
>
> Thanks,
> Galen
—
Dale Emery
dem...@pivotal.io
that are small enough, focused
enough, and clear enough that logs/printouts are unnecessary.
—
Dale Emery
dem...@pivotal.io
> On Sep 21, 2018, at 10:34 AM, Kirk Lund wrote:
>
> Most of these logWriter or logger usages are in larger end-to-end tests
> that were written before we cou
of
metrics, and criteria for evaluating the goodness of the hierarchy?
And for which details to represent in the meter name hierarchy vs
tags/dimensions?
Dale
—
Dale Emery
dem...@pivotal.io
We are exploring adding one or more public Service Provider Interfaces (SPIs)
for Geode, and would like some guidance about standards, conventions,
precedent, and such.
Do we have standards or conventions for creating SPIs? Good examples? Bad
examples?
Are there standards or conventions
The Micrometer API is in, and marked as experimental. But we have not yet
updated CacheFactory to allow injecting a meter registry (or metrics publishing
service) there. So currently the only way to publish is to add metrics
publishing service via the ServiceLoader mechanism.
—
Dale Emery
dem
haven’t done it yet.
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
romise to do it.
FYI, the additional work to improve usability is non-trivial, which is why we
haven’t done it already.
—
Dale Emery
dem...@pivotal.io
> On Mar 20, 2019, at 11:25 AM, Alexander Murmann wrote:
>
> Dale, is there any downside to making these changes in 1.10 other than
I have submitted a new PR https://github.com/apache/geode/pull/3180
<https://github.com/apache/geode/pull/3180>, superseding the original one.
I invite your review.
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
> On Feb 4, 2019, at 9:10 AM, Kirk Lund wrote:
>
> +1 to
Hello all,
I've created a PR to add Micrometer to Geode:
https://github.com/apache/geode/pull/3153
I invite your review.
The Micrometer system includes a rich suite of Meter types for
instrumenting code, and several styles of meter registries for
maintaining the meters. It also includes (as
whenever the developer wants to explicitly show the intent of
> making that the variable effectively constant.
How will we know whether it’s an explicit intention, vs an old habit or
something else?
—
Dale Emery
dem...@pivotal.io
> On Jun 13, 2019, at 4:29 PM, Juan José Ramos wrote:
&g
to use a PrometheusMeterRegistry to publish Geode’s
Micrometer-based metrics via HTTP. Geode’s existing HTTP server would be a
convenient way to publish that information.
I invite your feedback and ideas.
Dale
—
Dale Emery
dem...@pivotal.io
of server implementations in mind.
I don’t have any insight into that, so I don’t know how to assess the cost or
value of making this independent of Jetty.
—
Dale Emery
dem...@pivotal.io
> On Aug 23, 2019, at 9:59 AM, Aaron Lindsey wrote:
>
> Would it be practical to remove the d
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 app
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 wr
ow we can inform the function stats constructor so that it
knows whether to create the meters.
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
are intended to be
ongoing? An example is the proposal for Instrumenting Geode Code. The intention
is that it applies each time we add or change instrumentation. It will never be
Completed.
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
> On Jul 15, 2019, at 4:52 PM, Dan Smith wrote:
>
>
Running a ‘devBuild’ once on the command line will fix up some modules,
sometimes. It doesn’t appear to help with running the acceptance tests in
geode-assembly, but (usually? often?) does allow running geode-core tests in
IntelliJ.
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
> On Jul
t go so far as to say it’s invalid to do so.
I would like to know more about the intent, so …
If such a local variable were not marked final, what bad thing do you think
might happen?
A more positive version of the same question: If you’re able to show that the
variable is effectively constant
+1
To the extent possible without breaking existing APIs, please name the new
stuff to indicate what’s in the pool (E.g. ConnectionPool,
ConnectionPoolService, and so on).
—
Dale Emery
dem...@pivotal.io
> On Dec 5, 2019, at 4:40 PM, Dan Smith wrote:
>
> Hi,
>
> I wrot
y all of its method signatures
forward.
An alternative to consider: Each ConnectionPool implementation delegates to a
Pool. I suspect that this would make it harder to migrate existing uses from
Pool to ConnectionPool.
—
Dale Emery
dem...@pivotal.io
+ힹ
—
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).
h threads should uncaught exceptions be logged and ignored?
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
dem...@vmware.com
/pull/4992
<https://github.com/apache/geode/pull/4992>
Cheers,
Dale
—
Dale Emery
dem...@pivotal.io
dem...@vmware.com
>>
>>> On Fri, Apr 24, 2020 at 2:53 PM Anthony Baker wrote:
>>>
>>>> +1
>>>>
>>>>> On Apr 24, 2020, at 2:46 PM, Dale Emery wrote:
>>>>>
>>>>> During the cleanup of the gradle build and logging, the Pulse w
production code this value should probably be retrieved from the Cache,
DistributedSystem or some child of those instances. If this is for test code
only then ignore me the above concerns.
> On Oct 6, 2020, at 12:12 PM, Dale Emery wrote:
>
> Hi all,
>
> I have
t modules reference
the JVM's working directory.
Cheers,
Dale
On 10/6/20, 12:12 PM, "Dale Emery" wrote:
Hi all,
I have submitted an RFC to make Geode’s working directory configurable:
https://cwiki.apache.org/confluence/display/GEODE/Make+Geode%27s+Working+Directory+Config
But having this
option in the product doesn't seem like a bad idea.
-Dan
From: Dale Emery
Sent: Tuesday, October 6, 2020 12:12 PM
To: dev@geode.apache.org
Subject: [Discussion] RFC to make Geode's working directory configurable
Hi all,
Hi all,
I have submitted an RFC to make Geode’s working directory configurable:
https://cwiki.apache.org/confluence/display/GEODE/Make+Geode%27s+Working+Directory+Configurable
Please review it and comment by Oct 26.
Cheers,
Dale
> On Jun 30, 2020, at 12:28 PM, Jinmei Liao wrote:
>
> I would vote for fixing the tests to use gradle's normal forking. If we are
> going to invest time and effort, let's invest in an option that can reduce
> our dependencies
I agree wholeheartedly!
Dale
t has improved and it might be
worth trying that again.
Docker on windows has improved a lot but wasn’t the major issue the
docker plugin for Gradle needed some serious work?
I have recently been experimenting with the Docker/Kubernetes for
Windows experience. Perhaps we can take another stab at th
I would like to use the Geode GCP project. How can I get access to that?
—
Dale Emery
dem...@vmware.com<mailto:dem...@vmware.com>
Maybe we can find a way to relax the requirement, or to allow addressing
specific situations like the tangle you find yourself in.
Removing the requirement altogether feels overly broad. I fear it would allow
us to quietly disregard all intermittent test failures, and I think we already
ty to override stress-new-test, then we
need to encourage them not to override this too often.
On Tue, Jun 8, 2021 at 11:11 AM Dale Emery wrote:
> Maybe we can find a way to relax the requirement, or to allow addressing
> specific situations like the tangle you find yourself in.
>
>
the override) must cite a link to
the vote thread
On 6/9/21, 10:16 AM, "Dale Emery" wrote:
I too like #1 best for now… assuming it’s possible to give code
owners this ability.
Coincidentally, about option #3, II was reading the git release
notes just
Count me as -0. I have some concerns, but I’m okay trying this and seeing how
it goes.
Dale
From: Owen Nichols
Date: Wednesday, June 9, 2021 at 2:25 PM
To: dev@geode.apache.org
Subject: Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs
Summarizing this thread so far:
In
We might also use IntelliJ to enforce any guidelines that we want to enforce.
You can run inspections on the command line:
https://www.jetbrains.com/help/idea/command-line-code-inspector.html
An advantage of using IntelliJ inspections is that we can provide an inspection
profile that treats
Does this mean that a Jira would have to be approved before assigned?
Dale
From: Mark Hanson
Date: Friday, May 28, 2021 at 10:36 AM
To: dev@geode.apache.org
Subject: [Discuss] New feature work approval state in Geode project?
Hi All,
There has been some discussion about adding a new state of
On Monday I will merge GEODE-8899 (https://github.com/apache/geode/pull/6280),
which upgrades the Geode build to use Gradle 6.8.3 (from the current Gradle
5.5). This has implications for IntelliJ IDEA and for running tests with
parallelDunit. The implications are minor, but you’ll probably be
My test for whether enforce a guideline in a PR review is: Would I be willing
to automate enforcing it in CI?
I am -0 on this particular guideline.
IntelliJ offers two competing inspections for Java coding style:
* Local variable or parameter can be final
* Unnecessary 'final' on local
Geode wiki):
https://cwiki.apache.org/confluence/display/GEODE/Using+JUnit+5
Dale Emery
Hi Jens and all,
A possibility to consider: Instead of generating an arbitrary-but-unique ID,
use an existing identifier from the test environment… such as the ID in the
test worker directory name. That might make it easier to map a given log line
to the other artifacts from the test. So if
> *Do the Gfsh distributed tests on Windows leave behind more artifacts on
> the harddrive than other test targets?*
On Linux, the artifact file for a full distributed test run is ~750mb.
On Windows, the artifact file for just the gfsh distributed tests is ~1gb.
> *Are we running the Gfsh
As of July, 2021, Geode's build system no longer executes test worker processes
in separate Docker containers.
This increases the risk of port collisions between tests. Each test worker JVM
and each Java process started by a test executes directly in the environment
provided by the host
Kirk and I often use @VisibleForTesting as part of a technique for making
complex code more testable.
Many classes have “hidden” dependencies that make that class hard to test. A
useful technique is to add a constructor parameter to allow a test to inject a
more controllable, more observable
I’ve spent the last few hours analyzing uses of @VisibleForTesting. Within the
first dozen or so I’ve discovered a few patterns.
@VisibleForTesting is a highly reliable indicator that:
1. The existence, name, and value/behavior of the annotated element are
implementation details and not
+1
From: Owen Nichols
Sent: Wednesday, March 16, 2022 2:12 PM
To: geode
Subject: [PROPOSAL] annul support/1.15
Seven weeks after cutting support/1.15, Jira now shows 11 blockers, up from 5 a
few weeks ago. I wonder if perhaps we cut the release branch
57 matches
Mail list logo
