Stackexchange.redis: [coreclr] rc2 - UnableToResolvePhysicalConnection on GET

[colemickens]

This repro shows me using redis-cli to PING on 172.17.0.1. Then it shows a dotnet app running on dotnet 1.0.0-rc2-002345. It attempts to connect to the same address and fails. In this repro I was using StackExchange.Redis 1.1.572-alpha, but I've tried this from source with master (had to comment out the Azure detection code that touches AppDomain) and got the same results.

https://asciinema.org/a/42001

root@fbe9491e1a07:/opt/dotkube/Dotkube.Api# dotnet --version 
1.0.0-rc2-002345

root@fbe9491e1a07:/opt/dotkube/Dotkube.Api# redis-cli -h 172.17.0.1
172.17.0.1:6379> ping
PONG
172.17.0.1:6379> exit

This is what was written to the StringWriter during connection:

172.17.0.1:6379
Connecting 172.17.0.1:6379/Interactive...
BeginConnect: 172.17.0.1:6379
1 unique nodes specified
EndConnect: 172.17.0.1:6379
Requesting tie-break from 172.17.0.1:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:05 to respond...
172.17.0.1:6379 faulted: SocketFailure on PING
172.17.0.1:6379 failed to nominate (Faulted)
> UnableToResolvePhysicalConnection on GET
No masters detected
172.17.0.1:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Disconnected; sub: Disconnected; not in use: DidNotRespond
172.17.0.1:6379: int ops=0, qu=0, qs=0, qc=0, wr=0, sync=1, socks=1; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=2
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago
resetting failing connections to retry...
retrying; attempts left: 2...
1 unique nodes specified
Requesting tie-break from 172.17.0.1:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:05 to respond...
172.17.0.1:6379 faulted: SocketFailure on PING
172.17.0.1:6379 failed to nominate (WaitingForActivation)
No masters detected
172.17.0.1:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Connecting; sub: Disconnected; not in use: DidNotRespond
172.17.0.1:6379: int ops=0, qu=2, qs=0, qc=0, wr=0, sync=4, socks=2; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=3
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago
resetting failing connections to retry...
retrying; attempts left: 1...
1 unique nodes specified
Requesting tie-break from 172.17.0.1:6379 > __Booksleeve_TieBreak...
Allowing endpoints 00:00:05 to respond...
172.17.0.1:6379 did not respond
172.17.0.1:6379 failed to nominate (WaitingForActivation)
No masters detected
172.17.0.1:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: Connecting; sub: Disconnected; not in use: DidNotRespond
172.17.0.1:6379: int ops=0, qu=4, qs=0, qc=0, wr=0, sync=4, socks=2; sub ops=0, qu=0, qs=0, qc=0, wr=0, socks=4
Circular op-count snapshot; int: 0 (0.00 ops/s; spans 10s); sub: 0 (0.00 ops/s; spans 10s)
Sync timeouts: 0; fire and forget: 0; last heartbeat: -1s ago

[NinoFloris]

This is because PhysicalConnection does a call to SslStream's AuthenticateAsClient method, this synchronous api is gone in current corefx implementations of SslStream as can be seen here https://github.com/dotnet/corefx/commit/36270c6ea4741054b48b33be06dafee3438f07b3
What happens is once the JIT gets to the method it throws a MissingMethodException and this manifests as a SocketFailure because the outer method catches all exceptions (yay!).

I will open a new issue for this with a pull request, but I guess this will take a while before being merged and finds itself in a package.

For now I have this fixed in a compiled package for netstandard1.4 on:
https://www.myget.org/F/stackexchange-redis-corefx/api/v3/index.json
Add this to your NuGet.config:

    <add key="Stackexchange-redis-corefx" value="https://www.myget.org/F/stackexchange-redis-corefx/api/v3/index.json" />

And this as dependency:

    "StackExchange.Redis.CoreFx": "1.0.0-alpha1",

I hope rc2 support gets some love from the SO guys soon as the ecosystem is stabilising fast by now. @mgravell

[colemickens]

Fantastic! For a simple test of setting and retrieving a string value, it works!

[colemickens]

@NinoFloris Did you wind up sending a PR for this?

[gecmasters]

You are awesome, NinoFloris. Any idea when this will be pushed? Is there something I can follow to see when?

[NickCraver]

I have a fix for this in the RC2 branch, but there's more to validate on the unit testing side - working through them now.

[NickCraver]

Okay new plan: when in tonight I'll get an alpha up on NuGet with the Async fix in (the only build error) while I continue to work on all the tests for .NET Core. I'll reply here when there's a version up for usage. Same caveats as before: it's an alpha, and since we're held back a bit by the test runners and their late port to .NET Core - testing is far more trouble at the moment. There's progress on the nunit front though.

For what it's worth, I have a stash of a full port to xUnit, but it brings a myriad of other problems when testing a connection/socket based library. I've stashed it away and am focusing on getting nunit to work (and pass) now.

[NickCraver]

I've opened a PR for eyes here: https://github.com/StackExchange/StackExchange.Redis/pull/408
If no one finds any issues tonight, I'll push a 1.604-alpha to NuGet, I've got them ready to go.

[NickCraver]

I just pushed 1.604-alpha to NuGet:

• https://www.nuget.org/packages/StackExchange.Redis/1.1.604-alpha
• https://www.nuget.org/packages/StackExchange.Redis.StrongName/1.1.604-alpha

Please let me know if you see any issues!

[gecmasters]

You're awesome! Thanks! :+1:

[zaozaoniao]

I am testing the 1.603 lastest-stable version from nuget.
I am looking for to resolve the #42 issue.

[colemickens]

I haven't seen this issue repro with the package that @NickCraver pushed. I'm going to go ahead and close this.