Sporadical Connection Reset when calling POST /oauth/token since 2020-08-12 01:50 UTC

Help
#1

Hi!

We are on the free plan, so we have no support, otherwise I would have opened a support ticket for this issue.

Since today (2020-08-12 01:50 UTC) we see Connection Resets when calling POST /oauth/token.
Here is the exception from the Java code:

Caused by: javax.net.ssl.SSLException: Connection reset Suppressed: java.net.SocketException: Broken pipe (Write failed) Caused by: java.net.SocketException: Connection reset

I was able to get it failing once with Postman:

Error: write EADDRNOTAVAIL

Did today something change regarding domains, nameservers or certificates?

Thanks in advance for the help!

Kind Regards,
Bernhard

4 Likes
#2

We’re seeing the same. Interested to know if this is only happening on the free tier? And what can be done to resolve this.

3 Likes
#3

Same problem for us, lots of “Connection Resets” with the odd successful login. Logs show its started around the same time as you reported. We are running on the EU region and connecting in from AWS eu-west-1.

2 Likes
#4

We’re having this issue also. We are also running on the EU region.

#5

Ok, I am glad that I am not the only one with this issue. Does anybody have the possibility to create a support ticket or contact a support employee or developer from Auth0?

#6

We are also running in the EU region.

I think I managed through the sales team and UK office to inform the Auth0 support about the issue. Let’s see 


#7

Same is happening here:

java.io.IOException: Connection reset by peer
    at sun.nio.ch.FileDispatcherImpl.read0
    at sun.nio.ch.SocketDispatcher.read
    at sun.nio.ch.IOUtil.readIntoNativeBuffer
    at sun.nio.ch.IOUtil.read
    at sun.nio.ch.IOUtil.read
    at sun.nio.ch.SocketChannelImpl.read
    at org.apache.http.nio.reactor.ssl.SSLIOSession.receiveEncryptedData(SSLIOSession.java:474)
    at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:536)
    at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
    at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
    at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
    at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
    at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
    at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
    at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:591)
    at java.lang.Thread.run

Also running on AWS eu-west-1

#8

Same issue is happening again.

Suppressed: java.net.SocketException: Broken pipe (Write failed)

  • at java.net.SocketOutputStream.socketWrite0(Native Method)*

  • at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)*

  • at java.net.SocketOutputStream.write(SocketOutputStream.java:155)*

  • at sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81)*

  • at sun.security.ssl.TransportContext.fatal(TransportContext.java:355)*
#9

Connection reset simply means that a TCP RST was received. This happens when your peer receives data that it can’t process, and there can be various reasons for that. A reset packet is simply one with no payload and with the RST bit set in the TCP header flags. The simplest is when you close the java socket, and then write more data on the output stream. By closing the socket, you told your peer that you are done talking, and it can forget about your connection. When you send more data on that stream anyway, the peer rejects it with an RST to let you know it isn’t listening.

There are several possible causes.

  • The other end has deliberately reset the connection.
  • Writing to a connection that the other end has already closed
  • Closing a socket when there is unread data in the socket receive buffer.
  • In Windows, ‘software caused connection abort’, which is not the same as ‘connection reset’, is caused by network problems sending from your end.
#10

I met the same issue, <--- ERROR SSLException: Connection reset (8ms) . Is there any work around for this?

1 Like
#11

Hello. I come in really late, but we recently faced this issue. We had a setup with Kubernetes/Docker in AWS, but this can maybe happen with different setups than that.

In our case, we were using the standard NimbusJwtDecoder, the default of Spring Boot OAuth2 Security.

However, we needed to override the default JwtDecoder bean of spring, because Auth0 requires some tuning to work properly. Here is our setup.

val jwtDecoder = NimbusJwtDecoder.withJwkSetUri(
    UriComponentsBuilder
        .fromUriString(issuerUri)
        .path("/.well-known/jwks.json")
        .toUriString()
).restOperations(
    // Default timeout is 500ms when using `JwtDecoders.fromIssuerUri`, which is sometimes not enough for Auth0. We ended up with some `connectTimeoutException` 
    RestTemplateBuilder()
        .setConnectTimeout(Duration.ofSeconds(5))
        .setReadTimeout(Duration.ofSeconds(5))
        .requestFactory { SimpleClientHttpRequestFactory() } 
        .build()
)
    .jwsAlgorithm(SignatureAlgorithm.RS256) // What Auth0 supports
    .build()

The important part for this thread is the requestFactory. Default RF uses an ApacheHttpClient, which uses a connection pool. For some reason that we did not manage to figure out, the connection pool at some point re-use some connections, and that re-usage produces the SSLException. Our solution was to use another Connection Factory that does not have a connection pool (In this case, the one from spring).

1 Like