Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NullPointerException when handling responses with empty bodies #374

maly7 opened this Issue Jun 20, 2018 · 3 comments


None yet
5 participants
Copy link

maly7 commented Jun 20, 2018

If you have a controller mapping that looks something like:

fun delete(@PathVariable id: String) = repository.deleteById(id)

Then a null pointer occurs while handling the request:

2018-06-20 01:26:04.254 ERROR 1 --- [reactor-http-client-epoll-11] .a.w.r.e.DefaultErrorWebExceptionHandler : Failed to handle request [DELETE http://localhost:8080/entity/5b29ad2cb3cb1f00010a1546]

java.lang.NullPointerException: null
        at java.util.concurrent.ConcurrentHashMap.putVal( ~[na:1.8.0_111]
        at java.util.concurrent.ConcurrentHashMap.put( ~[na:1.8.0_111]
        at$filter$3( ~[spring-cloud-gateway-core-2.0.0.RELEASE.jar!/:2.0.0.RELEASE]
        at reactor.core.publisher.FluxPeek$PeekSubscriber.onNext( ~[reactor-core-3.1.8.RELEASE.jar!/:3.1.8.RELEASE]
        at reactor.core.publisher.FluxMap$MapSubscriber.onNext( ~[reactor-core-3.1.8.RELEASE.jar!/:3.1.8.RELEASE]
        at reactor.core.publisher.FluxRetryPredicate$RetryPredicateSubscriber.onNext( ~[reactor-core-3.1.8.RELEASE.jar!/:3.1.8.RELEASE]
        at reactor.core.publisher.MonoCreate$DefaultMonoSink.success( ~[reactor-core-3.1.8.RELEASE.jar!/:3.1.8.RELEASE]
        at ~[reactor-netty-0.7.8.RELEASE.jar!/:0.7.8.RELEASE]
        at reactor.ipc.netty.http.client.HttpClientOperations.onInboundNext( ~[reactor-netty-0.7.8.RELEASE.jar!/:0.7.8.RELEASE]
        at ~[reactor-netty-0.7.8.RELEASE.jar!/:0.7.8.RELEASE]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at$DelegatingChannelHandlerContext.fireChannelRead( ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead( ~[netty-codec-4.1.25.Final.jar!/:4.1.25.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead( ~[netty-codec-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at$HeadContext.channelRead( ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-4.1.25.Final.jar!/:4.1.25.Final]
        at$EpollStreamUnsafe.epollInReady( ~[netty-transport-native-epoll-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-native-epoll-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[netty-transport-native-epoll-4.1.25.Final.jar!/:4.1.25.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$ ~[netty-common-4.1.25.Final.jar!/:4.1.25.Final]
        at ~[na:1.8.0_111]

My guess is the null pointer is occurring here since there's no content type on the response

If it helps, this is what the response from the under lying service looks like in httptrace:

  "timestamp": "2018-06-20T01:26:04.209Z",
  "principal": null,
  "session": null,
  "request": {
    "method": "DELETE",
    "uri": "http://6d2b3e41eeb8:8280/entity/5b29ad2cb3cb1f00010a1546",
    "headers": {
      "accept": [
      "user-agent": [
        "Apache-HttpClient/4.5.5 (Java/1.8.0_172)"
      "accept-encoding": [
      "forwarded": [
      "x-forwarded-for": [
      "x-forwarded-proto": [
      "x-forwarded-port": [
      "x-forwarded-host": [
      "host": [
      "content-length": [
    "remoteAddress": null
  "response": {
    "status": 204,
    "headers": {}
  "timeTaken": 43

@spencergibb spencergibb added the bug label Jun 20, 2018

@spencergibb spencergibb added this to the 2.0.1.RELEASE milestone Jun 20, 2018


This comment has been minimized.

Copy link

phillipuniverse commented Jun 20, 2018

Just an FYI, this also fails on any redirect responses that the gateway is proxying, specifically tested with a 302 response (which is also an empty response body).


This comment has been minimized.

Copy link

Junior-Sousa commented Jun 21, 2018

Do you think this problem makes using the gateway unfeasible until a new version is generated? I made a simpler test where when I access the UI from my application through the gateway the page is displayed as expected, but on a second I got the same error presented previously.

This is my routing:

- id: web
   uri: lb://web
   - Path=/**
   - RewritePath=/web/(?<path>.*), /$\{path}


This comment has been minimized.

Copy link

luohaoGit commented Sep 28, 2018


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.