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.
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?
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
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.
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).