>> 2) not test default ports?
> > > If the product supports default port; we need to have test for
> > that...Most
> > > of the early product evaluation is done with default port...
> > >
> > > -Anil.
> > >
> > >
> > > On Wed,
>>> 2) not test default ports?
> > If the product supports default port; we need to have test for
> that...Most
> > of the early product evaluation is done with default port...
> >
> > -Anil.
> >
> >
> > On Wed, Aug 23, 2017 at 11:15 AM, Kirk Lund
>
>>> 2) not test default ports?
> If the product supports default port; we need to have test for that...Most
> of the early product evaluation is done with default port...
>
> -Anil.
>
>
> On Wed, Aug 23, 2017 at 11:15 AM, Kirk Lund wrote:
>
>> Th
rote:
> The following nightly build failures are tests that are testing default
> ports which are failing because the port is not available.
>
> Should we:
>
> 1) use Docker for AcceptanceTest and IntegrationTest targets?
>
> 2) not test default ports?
>
> 3) use a hacky Sy
The following nightly build failures are tests that are testing default
ports which are failing because the port is not available.
Should we:
1) use Docker for AcceptanceTest and IntegrationTest targets?
2) not test default ports?
3) use a hacky System property to force Geode to think that
I'm working on these failures from the last 4 days:
GEODE-2648 - DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles -
race condition in test
GEODE-2647
- ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled -
race condition in test
GEODE-2646 - PulseDataExportTest.dataBrow
Looking at
https://builds.apache.org/job/Geode-nightly/747/testReport/org.apache.geode.management.internal.cli/NetstatDUnitTest/classMethod/
...it looks like NetstatFunction.executeLsof keeps executing infinitely
once it gets triggered.
I tried to run "netstat --with-lsof=true" on my Mac, but app
We've seen some netstat command tests fail with OutOfMemoryError else where
as well. I don't know why forking a netstat command and reading the output
back into the JVM would take up that much memory. It makes me wonder if
there's a memory leak bug in MiscellaneousCommands#netstat.
Does anyone hav
I have a fix for JMXMBeanDUnitTest, the code review is sent out.
NetstatDUnitTest fails with OutofMemeoryError, probably the machine does
not have enough memory to run this test?
On Mon, Feb 13, 2017 at 8:40 AM, Kirk Lund wrote:
> Some tests still seem to fail only on specific build machines (i
Some tests still seem to fail only on specific build machines (including
UniversalMembershipListenerAdapterDUnitTest after my fixes). Mostly
management dunits, but one Locator dunit failed. We may need to mark some
of these as Flaky but I'll try to fix anything obvious before resorting to
that.
I'
Kirk, I think it already has those assertions, but I think you're
correct to delete the toString() based checks.
Le 2/10/2017 à 11:25 AM, Kirk Lund a écrit :
UniversalMembershipListenerAdapterDUnitTest is failing because the
assertion is incorrect. It asserts that the MembershipEvent.getMemberI
UniversalMembershipListenerAdapterDUnitTest is failing because the
assertion is incorrect. It asserts that the MembershipEvent.getMemberId()
is equal to DistributedMember.toString(). It should instead assert that
MembershipEvent.getMemberId() is equal to DistributedMember.getId().
I'll be committi
Nightly build hasn't passed in a looonnngg time...
https://builds.apache.org/job/Geode-nightly/744/testReport/
These two tests continue to fail in the geode nightly build:
org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverNonSSL
org.apache.geode.management.UniversalMembershipListenerAdapt
If the Geode Nightly Build is running FlakyTests but not adding those
results to the Test Results, then I'm 100% for removing the execution of
FlakyTests from the nightly build job.
If others want the nightly build to run FlakyTests, then would someone
please add it to the Test Results so we can s
I'm looking at Geode Nightly Build #724. The console output shows
that MemoryThresholdsOffHeapDUnitTest, however the Test Results shows zero
failures.
The failure in the console output does not show the full stack so there's
no way to determine which assertion failed.
#724 console output shows fa
15 matches
Mail list logo