Stick with the JDK implementation as it is compliant with the current RFC. Most
certs still have the CN set to the hostname for legacy clients but newer
clients use the SAN. It’s doubtful many CA’s still produce certs without a SAN
entry.
> On Aug 24, 2018, at 6:49 PM, Sai Boorlagadda
> wrote
all,
While testing I found that JDK's endpoint identification algorithm
('HTTPS')
validates the server's hostname:
1) against 'subject alternative name' (SAN) when available
2) against 'common name' (CN) if SAN is absent
I was a little concerned about #2, which is deprecated as per [1].
> So wh
Regarding GEODE-5594, though the current implementation is good and needed
more coverage.
While adding tests to cover negative cases, I found something about JDK's
default implementation of
hostname validation which I am not happy about and so it needs a rethought.
It could result in
implementing
Kirk, Yes I have seen this thread. But in my case,
In my case, the exception is in a background thread.
SerialGatewaySenderEventProcessor uses
ConnectionPool to initiate and send events in the background when the test
code does a put. So
the test code is in not control to handle or even catch exce
Hey Sai, did you see this thread? It might help with your exception testing
that you asked about. DeltaPropagationFailureRegressionTest and
RegisterInterestDistributedTest (mentioned below) are both dunit tests.
On Thu, Aug 23, 2018 at 4:03 PM, Kirk Lund wrote:
> I goofed on #1. We should be usi
ShowMissingDiskStoresFunction is probably ok for a test to use. I'll try to
change the test to use that instead. Thanks!
On Fri, Aug 24, 2018 at 1:04 PM, Jens Deppe wrote:
> If you're looking for a non-deprecated way but still (unfortunately)
> internal then 'ShowMissingDiskStoresFunction' will
---
Spring Data GemFire > Nightly-ApacheGeode > #1019 was successful.
---
Scheduled
2425 tests in total.
https://build.spring.io/browse/SGF-NAG-1019/
--
Thi
I tried the new property that's supposed to let you limit the number of
tests run in parallel and it didn't seem to work.
./gradlew -PtestMaxParallelForks=2 build
Instead of using half of my machine's CPUs this caused it to use all 8
of them:
> :geode-connectors:test > 96 tests completed
> :
That went in a few days ago so this run is already using that.
On Fri, Aug 24, 2018 at 2:49 PM Jacob Barrett wrote:
> Dan just merged a change to gradle that drops the scanner plugin that
> seems to suck up a ton of ram.
>
> > On Aug 24, 2018, at 2:38 PM, Jens Deppe wrote:
> >
> > Not in the bu
See
https://github.com/apache/geode/blob/cb202f25b93e0a56f4776813da0bf6dcbba231cd/geode-core/src/distributedTest/java/org/apache/geode/security/ClientAuthorizationLegacyConfigurationDUnitTest.java#L130
On Fri, Aug 24, 2018 at 2:22 PM Sai Boorlagadda
wrote:
> Are there any tests that I can refer
Dan just merged a change to gradle that drops the scanner plugin that seems to
suck up a ton of ram.
> On Aug 24, 2018, at 2:38 PM, Jens Deppe wrote:
>
> Not in the build process.
>
> Having them all fail simultaneously is very suspicious though. I restarted
> one of them and it ran fine.
>
>
Not in the build process.
Having them all fail simultaneously is very suspicious though. I restarted
one of them and it ran fine.
We're about to switch the build model for Windows to match the linux builds
where a 'heavy lifter' is spawned for each job. During my testing of that I
found the Gradl
I will be rebasing the release branch with develop, to bring in all the
improvements/ enhancements that went in in the past few months.
I am waiting on the tickets mentioned in this thread to be closed to start
on a fresh release branch.
Regards
Nabarun Nag
On Fri, Aug 24, 2018 at 12:20 PM Jens
Are there any tests that I can refer to catch expected exceptions in
distributed tests? I have a scenario where GW sender tries to send an event
to other site and the connection fails with an expected exception.
Currently, the event is retired a few times an exception is logged every
time but does
It looks like all of the windows jobs are failing. The code changes between
the failed job and the passed job don't seem like they could be related,
did something else change?
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/WindowsUnitTest/builds/70
-Dan
Tests don't need to catch non-runtime exceptions and rethrow them. The
following:
Awaitility.await().atMost(60, TimeUnit.SECONDS).untilAsserted(() -> {
try {
assertEquals(size, query.findPages().size());
} catch (LuceneQueryException e) {
throw new RuntimeException(
If you're looking for a non-deprecated way but still (unfortunately)
internal then 'ShowMissingDiskStoresFunction' will probably help.
--Jens
On Thu, Aug 23, 2018 at 2:27 PM Dan Smith wrote:
> I think this was replaced with a gfsh command that does the same thing.
> Unfortunately, we don't have
5619 is marked as resolved now.
Is the Release Manager planning to pick these onto 1.7 or should each
person do their own?
--Jens
On Fri, Aug 24, 2018 at 10:52 AM Alexander Murmann
wrote:
> To summarize where we are right now in this discussion, I see the following
> tickets listed in this thr
To summarize where we are right now in this discussion, I see the following
tickets listed in this thread as want-to-haves for 1.7:
- GEODE-5615 - ✅ resolved
- GEODE-5601 - 🏃♀️ in progress
- GEODE-5594 - 🏃♀️ waiting for PR review
- GEODE-5338 - 🏃♀️ waiting for PR review
- GEODE-5
We also have iss...@geode.apache.org, which is getting all of the JIRA
messages. Maybe we should just send the PR notifications to that list?
-Dan
On Fri, Aug 24, 2018 at 9:40 AM, Anthony Baker wrote:
> I’m not proposing to increase your unwanted email load. Here’s what I’m
> saying:
>
> - Sen
I’m not proposing to increase your unwanted email load. Here’s what I’m saying:
- Send GitHub notifications to a NEW geode mailing list. You don’t have to
subscribe to it. Maybe you’re already sending GH notifications to your
personal email accounts and that’s perfectly fine.
- By default, a
+1 for less Spam 🎵 spam 🎵 spam 🎵 spam
Seriously - considering the comments started by Kirk's email, given the
amount of spam, it's not surprising that folks would use a different means
of getting a speedier response (Slack) rather than using email. Point being
that the lower the noise/signal ratio
+1 for lowering SPAM
On Thu, Aug 23, 2018 at 9:19 PM, Jacob Barrett wrote:
> Must we get spammed with every thing that happens? It seems to me a log in
> GitHub, JIRA and email is obscene.
>
> All this email we get now just gets bulk deleted and I often miss
> important conversations. If we move
23 matches
Mail list logo
