Wicket
  1. Wicket
  2. WICKET-5147

WicketTester MockHttpRequest.getCookies very slow / OutOfMemory

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.7.0
    • Fix Version/s: 6.8.0
    • Component/s: None
    • Labels:
      None

      Description

      We have an extensive set of WicketTester tests. Recently, the wicket RELEASE in the maven repository changed to 6.7.0. After the new version, our tests got very slow.

      When profiling, I discovered that the MockHttpRequest.getCookies() was taking up a lot of time. Also, tests failed because of OutOfMemory exceptions. My guess is that somehow a lot of objects are created at such speeds that the GC cannot clean them

      I will investigate further, but switching back to 6.6.0 solved the issue.

      [Edit]
      The tests are run with TestNG and using 'mvn test'

      1. testcookies.zip
        28 kB
        Rob Audenaerde

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          Martin Grigorov made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 6.8.0 [ 12324068 ]
          Resolution Fixed [ 1 ]
          Martin Grigorov made changes -
          Assignee Martin Grigorov [ mgrigorov ]
          Rob Audenaerde made changes -
          Attachment testcookies.zip [ 12579119 ]
          Rob Audenaerde made changes -
          Comment [ I think the problem is in the BaseWicketTester:

          transferRequestCookies();

          response = new MockHttpServletResponse(request);

          // Preserve response cookies in redirects
          // XXX: is this really needed ? Browsers wont do that, but some
          // Wicket tests assert that a cookie is in the response,
          // even after redirects (see org.apache.wicket.util.cookies.SetCookieAndRedirectTest.statefulPage())
          // They should assert that the cookie is in the next *request*
          if (lastResponse != null && lastResponse.isRedirect())
          {
          List<Cookie> lastResponseCookies = lastResponse.getCookies();
          for (Cookie cookie : lastResponseCookies)
          {
          if (cookie.getMaxAge() != 0)
          {
          // max-age==0 are already handled in #transferRequestCookies() above
          response.addCookie(cookie);
          }
          }
          }


          Cookies are transferred in the 'transferRequestCookies()' method. Then, after all the cookies are transferred to the request, another run of same cookies are added.
          ]
          Rob Audenaerde made changes -
          Description We have an extensive set of WicketTester tests. Recently, the wicket RELEASE in the maven repository changed to 6.7.0. After the new version, our tests got very slow.

          When profiling, I discovered that the MockHttpRequest.getCookies() was taking up a lot of time. Also, tests failed because of OutOfMemory exceptions. My guess is that somehow a lot of objects are created at such speeds that the GC cannot clean them

          I will investigate further, but switching back to 6.6.0 solved the issue.

          [Edit]
          The tests are run with TestNG and using 'mvn test'

          We have an extensive set of WicketTester tests. Recently, the wicket RELEASE in the maven repository changed to 6.7.0. After the new version, our tests got very slow.

          When profiling, I discovered that the MockHttpRequest.getCookies() was taking up a lot of time. Also, tests failed because of OutOfMemory exceptions. My guess is that somehow a lot of objects are created at such speeds that the GC cannot clean them

          I will investigate further, but switching back to 6.6.0 solved the issue.

          [Edit]
          The tests are run with TestNG and using 'mvn test'
          Rob Audenaerde made changes -
          Description We have an extensive set of WicketTester tests. Recently, the wicket RELEASE in the maven repository changed to 6.7.0. After the new version, our tests got very slow.

          When profiling, I discovered that the MockHttpRequest.getCookies() was taking up a lot of time. Also, tests failed because of OutOfMemory exceptions. My guess is that somehow a lot of objects are created at such speeds that the GC cannot clean them

          I will investigate further, but switching back to 6.6.0 solved the issue.

          [Edit]
          The test are run with TestNG and using 'mvn test'
          We have an extensive set of WicketTester tests. Recently, the wicket RELEASE in the maven repository changed to 6.7.0. After the new version, our tests got very slow.

          When profiling, I discovered that the MockHttpRequest.getCookies() was taking up a lot of time. Also, tests failed because of OutOfMemory exceptions. My guess is that somehow a lot of objects are created at such speeds that the GC cannot clean them

          I will investigate further, but switching back to 6.6.0 solved the issue.

          [Edit]
          The tests are run with TestNG and using 'mvn test'
          Rob Audenaerde made changes -
          Description We have an extensive set of WicketTester tests. Recently, the wicket RELEASE in the maven repository changed to 6.7.0. After the new version, our tests got very slow.

          When profiling, I discovered that the MockHttpRequest.getCookies() was taking up a lot of time. Also, tests failed because of OutOfMemory exceptions. My guess is that somehow a lot of objects are created at such speeds that the GC cannot clean them

          I will investigate further, but switching back to 6.6.0 solved the issue.
          We have an extensive set of WicketTester tests. Recently, the wicket RELEASE in the maven repository changed to 6.7.0. After the new version, our tests got very slow.

          When profiling, I discovered that the MockHttpRequest.getCookies() was taking up a lot of time. Also, tests failed because of OutOfMemory exceptions. My guess is that somehow a lot of objects are created at such speeds that the GC cannot clean them

          I will investigate further, but switching back to 6.6.0 solved the issue.

          [Edit]
          The test are run with TestNG and using 'mvn test'
          Sven Meier made changes -
          Field Original Value New Value
          Link This issue relates to WICKET-4989 [ WICKET-4989 ]
          Rob Audenaerde created issue -

            People

            • Assignee:
              Martin Grigorov
              Reporter:
              Rob Audenaerde
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development