Cactus
  1. Cactus
  2. CACTUS-74

java.lang.NullPointerException in first test -- thread synchronization prob?

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5-rc1
    • Fix Version/s: None
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Operating System: Other
      Platform: PC

      Description

      I've written a fairly simple test case to test a servlet of mine. I log in, as
      required, and do a "doGet":

      public void testOne () throws javax.servlet.ServletException

      { ShowLinks servlet = new ShowLinks (); servlet.init (config); UserValue user = LFGetter.findUserByUsername("user"); Login.login (request, user); servlet.doGet (request, response); }

      This is the only test case in my Cactus suite. Right after deploying it to my
      jboss (jboss-3.2.2), and testing over the browser (with ServletTestRunner), I
      found out that Cactus reports a failure in this test. If I hit "reload" on the
      browser it reports success (and keeps on reporting sucess from then on). If I
      redeploy the EAR file, the same happens: the first time failure, afterwards,
      success. The failure happens with a Cactus NullPointerException (the Exception
      is at the framework itself, not in my servlet), which I narrowed down to this
      line in the method doGetResults():

      writer.write(result.toXml());

      The reason for the exception is that "result" is null. "result" is populated
      right before that with this line:

      WebTestResult result = (WebTestResult) (this.webImplicitObjects
      .getServletContext().getAttribute(TEST_RESULTS));

      I've also figured that it is set in the servletContext by this line in doTest():

      this.webImplicitObjects.getServletContext()
      .setAttribute(TEST_RESULTS, result);

      That comes right after the servlet itself is excecuted, from the line:

      testInstance.runBare();

      After more debugging, I figured out the this "runBare" will open a secondary
      thread, which will execute the "doGetResults()", while the "current thread" will
      be the one that continues the execution of "doTest()".

      ***************************************

      WHAT I THINK:

      The way I see it, the second thread should wait for the first one to set
      "TEST_RESULTS" before it executes "doGetResults()". And I think the reason it
      succeeds from the second test onwards is that this is cached from one run to the
      next.

      Please let me know if you need more information.

      Zorzella

        Activity

        Hide
        Per Olesen added a comment -

        I get this too, with the exact same problem and symptoms. I also, debugged
        downto the line where this happens:

        writer.write(result.toXml());

        and when I run it second time, it is ok.

        We are running wls61. I think this bug have been reported before as bugid 17653,
        but closed because the problem seemed to disappear for the parties there. Well,
        it seems to have reappered.

        Also, the mailinglists shows a thread about this at:

        http://www.mail-archive.com/cactus-user@jakarta.apache.org/msg04087.html

        Which mentions something about putting in a sleep. Can anyone figure iut exactly
        where such a wait can be put it, to get this working just for now?

        This is kind-off killing us

        Show
        Per Olesen added a comment - I get this too, with the exact same problem and symptoms. I also, debugged downto the line where this happens: writer.write(result.toXml()); and when I run it second time, it is ok. We are running wls61. I think this bug have been reported before as bugid 17653, but closed because the problem seemed to disappear for the parties there. Well, it seems to have reappered. Also, the mailinglists shows a thread about this at: http://www.mail-archive.com/cactus-user@jakarta.apache.org/msg04087.html Which mentions something about putting in a sleep. Can anyone figure iut exactly where such a wait can be put it, to get this working just for now? This is kind-off killing us
        Hide
        Per Olesen added a comment -

        Hmm, think I've got a fix for this. This is ugly code, but it seems to get me
        going. Based on the information provided by Luiz, I tried adding the following
        code in AbstractWebTestCaller.doGetResults():

        BEFORE line 208 was:
        WebTestResult result =
        (WebTestResult)webImplicitObjects.getServletContext().getAttribute("ServletTestRedirector_TestResults");

        REPLACED WITH this:
        WebTestResult result = null;
        while (result == null) {
        System.out.println("FIX: Going to get result ...");
        result =
        (WebTestResult)webImplicitObjects.getServletContext().getAttribute("ServletTestRedirector_TestResults");
        System.out.println("FIX: Result was " + result);
        if (result == null) {
        System.out.println("FIX: Will sleep a bit .. zzzz ..");
        try

        { Thread.sleep(1000); }

        catch (InterruptedException e)

        { /* who cares */ }

        }
        }

        And my server log says this when I run the tests:

        FIX: Going to get result ...
        FIX: Result was null
        FIX: Will sleep a bit .. zzzz ..
        FIX: Going to get result ...
        FIX: Result was Test ok

        and the next test run on the same testcase says:

        FIX: Going to get result ...
        FIX: Result was Test ok

        Hope the second test on the testcase gets the correct result then. As I
        understand it, getting there "too quick" might make it get the result of the
        last test. That is, if there is a race condition.

        Maybe the "ServletTestRedirector_TestResults" attribute should be removed from
        ServletContext after use!?

        A real quick-in-and-quick-out fix

        Show
        Per Olesen added a comment - Hmm, think I've got a fix for this. This is ugly code, but it seems to get me going. Based on the information provided by Luiz, I tried adding the following code in AbstractWebTestCaller.doGetResults(): BEFORE line 208 was: WebTestResult result = (WebTestResult)webImplicitObjects.getServletContext().getAttribute("ServletTestRedirector_TestResults"); REPLACED WITH this: WebTestResult result = null; while (result == null) { System.out.println("FIX: Going to get result ..."); result = (WebTestResult)webImplicitObjects.getServletContext().getAttribute("ServletTestRedirector_TestResults"); System.out.println("FIX: Result was " + result); if (result == null) { System.out.println("FIX: Will sleep a bit .. zzzz .."); try { Thread.sleep(1000); } catch (InterruptedException e) { /* who cares */ } } } And my server log says this when I run the tests: FIX: Going to get result ... FIX: Result was null FIX: Will sleep a bit .. zzzz .. FIX: Going to get result ... FIX: Result was Test ok and the next test run on the same testcase says: FIX: Going to get result ... FIX: Result was Test ok Hope the second test on the testcase gets the correct result then. As I understand it, getting there "too quick" might make it get the result of the last test. That is, if there is a race condition. Maybe the "ServletTestRedirector_TestResults" attribute should be removed from ServletContext after use!? A real quick-in-and-quick-out fix
        Hide
        Per Olesen added a comment -

        Oops, forgot to give some version info:

        This was done against cactus-1.5-beta1.

        Show
        Per Olesen added a comment - Oops, forgot to give some version info: This was done against cactus-1.5-beta1.
        Hide
        Luiz-Otavio Zorzella added a comment -

        Per,

        I'm glad someone else is interested. I haven't gotten any time, after I first
        reported the bug, to debug it further. I'll try your hack, as soon as I have
        some time. If you do find a better solution, please keep me informed through the
        bug!

        PS: I go by "Zorzella".

        Thanks again,

        Zorzella

        Show
        Luiz-Otavio Zorzella added a comment - Per, I'm glad someone else is interested. I haven't gotten any time, after I first reported the bug, to debug it further. I'll try your hack, as soon as I have some time. If you do find a better solution, please keep me informed through the bug! PS: I go by "Zorzella". Thanks again, Zorzella

          People

          • Assignee:
            Unassigned
            Reporter:
            Luiz-Otavio Zorzella
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development