wsit
  1. wsit
  2. WSIT-1681

MakeConnection response does not seem to be getting saved due to a NullPointerException

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: ha
    • Labels:
      None

      Description

      This issue may have existed in all of the GF 4.0 builds. The issue has been found via HA tests that were only recently been run. The issue is also reproducible on a single GF instance.

      To reproduce the issue:

      • Deploy a Simple Make Connection application to a GF domain and run the application's client.
        A sample application and its client have been attached to this bug.

      On running the client, the client is found to receive the 202 response correctly, but does not receive the 200 response on the subsequent MakeConnection request.

      The complete server log has been attached to the issue.

      Here is the snippet that shows the NPE:
      *******
      [#|2012-05-10T03:09:59.867-0700|SEVERE|44.0|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=393;_ThreadName=Thread-2;|java.lang.NullPointerException
      at org.glassfish.grizzly.http.server.Request.getRawCookies(Request.java:1930)
      at org.glassfish.grizzly.http.server.Request.parseCookies(Request.java:1882)
      at org.glassfish.grizzly.http.server.Request.getCookies(Request.java:1477)
      at org.apache.catalina.connector.Request.parseCookies(Request.java:3213)
      at org.apache.catalina.connector.Request.getCookies(Request.java:2456)
      at org.apache.catalina.connector.RequestFacade.getCookies(RequestFacade.java:699)
      at com.sun.xml.ws.transport.http.servlet.ServletConnectionImpl.getHaInfo(ServletConnectionImpl.java:382)
      at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:601)
      at org.jvnet.ws.message.PropertySet$MethodAccessor.get(PropertySet.java:266)
      at org.jvnet.ws.message.PropertySet.get(PropertySet.java:318)
      at org.jvnet.ws.message.DistributedPropertySet.get(DistributedPropertySet.java:134)
      at com.sun.xml.ws.commons.ha.HaContext.initFrom(HaContext.java:90)
      at com.sun.xml.ws.rx.mc.runtime.McServerTube$AppRequestProcessingCallback.onCompletion(McServerTube.java:100)
      at com.sun.xml.ws.rx.util.FiberExecutor$1.onCompletion(FiberExecutor.java:124)
      at com.sun.xml.ws.api.pipe.Fiber.completionCheck(Fiber.java:868)
      at com.sun.xml.ws.api.pipe.Fiber.run(Fiber.java:775)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
      at java.lang.Thread.run(Thread.java:722)

      #]

        Issue Links

          Activity

          Hide
          Lukas Jungmann added a comment -

          this looks like grizzly issue - ServletConnectionImpl.getHaInfo(..) calls request.getCookies but from some reason 'request' instance in org.glassfish.grizzly.http.server.Request.getRawCookies(..), line 1931 is null

          passing there for further evaluation

          Show
          Lukas Jungmann added a comment - this looks like grizzly issue - ServletConnectionImpl.getHaInfo(..) calls request.getCookies but from some reason 'request' instance in org.glassfish.grizzly.http.server.Request.getRawCookies(..), line 1931 is null passing there for further evaluation
          Hide
          oleksiys added a comment -

          Hi Lukas,

          looks like the HTTP request/response processing goes asynchronous in this usecase, I can see the NPE happens in a custom (not Grizzly) thread.
          Are you sure web-services properly use async Servlet 3.0 API (AsyncContext) in order to pass HTTP request/response processing to a custom thread and run it asynchronously?

          Thanks.

          Show
          oleksiys added a comment - Hi Lukas, looks like the HTTP request/response processing goes asynchronous in this usecase, I can see the NPE happens in a custom (not Grizzly) thread. Are you sure web-services properly use async Servlet 3.0 API (AsyncContext) in order to pass HTTP request/response processing to a custom thread and run it asynchronously? Thanks.
          Hide
          Lukas Jungmann added a comment - - edited

          Hi Alex,

          sorry I missed the fact that this is async use-case. Anyway I tried to test various combinations and even though there may be something wrong on our - metro - side it looks like the problem is somewhere else:

          Following combinations do work properly:
          GF 3.1.2 with default Metro (2.2.0-2) on the server and client side
          GF 3.1.2 with current Metro (2.3-b210) on the server and client side

          Following combinations are able to reproduce the bug:
          GF-trunk default Metro (2.3-b210) on the server and client side
          GF-trunk old Metro (2.2.0-2) on the server and client side

          so GF is the difference here...

          Any tip?

          Thanks!

          Show
          Lukas Jungmann added a comment - - edited Hi Alex, sorry I missed the fact that this is async use-case. Anyway I tried to test various combinations and even though there may be something wrong on our - metro - side it looks like the problem is somewhere else: Following combinations do work properly: GF 3.1.2 with default Metro (2.2.0-2) on the server and client side GF 3.1.2 with current Metro (2.3-b210) on the server and client side Following combinations are able to reproduce the bug: GF-trunk default Metro (2.3-b210) on the server and client side GF-trunk old Metro (2.2.0-2) on the server and client side so GF is the difference here... Any tip? Thanks!
          Hide
          oleksiys added a comment -

          Hi Lukas,

          difficult to say, it's thread racing, so sometimes it may pass sometimes not.
          It would be good to double check how async execution is implemented in web services' pipes.

          Show
          oleksiys added a comment - Hi Lukas, difficult to say, it's thread racing, so sometimes it may pass sometimes not. It would be good to double check how async execution is implemented in web services' pipes.
          Hide
          oleksiys added a comment -

          Hi Lukas,

          any update on this issue?

          Show
          oleksiys added a comment - Hi Lukas, any update on this issue?
          Hide
          Lukas Jungmann added a comment -

          Hi Alex,

          yes, I have an update

          from what I've found it looks like our code is holding a (threadlocal?) reference to invalidated instance of the request somewhere. This used to work in the past but that was apparently only due to some 'bug' within tomcat/web-core. So I'll transfer this back to us.

          Thanks,
          --lukas

          Show
          Lukas Jungmann added a comment - Hi Alex, yes, I have an update from what I've found it looks like our code is holding a (threadlocal?) reference to invalidated instance of the request somewhere. This used to work in the past but that was apparently only due to some 'bug' within tomcat/web-core. So I'll transfer this back to us. Thanks, --lukas

            People

            • Assignee:
              Lukas Jungmann
              Reporter:
              varunrupela
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: