Announcement Announcement Module
Collapse
No announcement yet.
HttpClient usage and ApplicationContext close in relation to Spring Social Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • HttpClient usage and ApplicationContext close in relation to Spring Social

    I have been working on tracking down a memory leak in HttpClient, where when you redeploy your web app, if HttpClient has created a ThreadLocal, that it does not get removed when your app is undeployed.

    Is there anything in Spring Social classes that have a method that could be an @PostConstruct or a method I can call in destroy-method that might clean this up?

    I know it is HttpClient specific and I can do another workaround, but if something like this was already built into Spring Social, that would be really cool and save me time to write up a ServletListener to close HttpClient.

    Thanks

    Mark

  • #2
    Where is the ThreadLocal being created? I'm not aware of anything in Spring Social that creates the ThreadLocal, therefore why would Spring Social be responsible for (or even offer support for) cleaning it up?

    Some of the Spring Social samples use ThreadLocal, but those are just samples that use ThreadLocal as a shortcut/alternative to Spring Security. It's just how those samples are implemented and not intrinsic to Spring Social itself.

    Comment


    • #3
      No Spring Social isn't creating the ThreadLocal, HttpClient is. However, it is possible that Spring Social's usage of HttpClient is not closing the connection correctly.

      http://stackoverflow.com/questions/1...-kill-required

      I was never saying that Spring Social was creating this issue. it seems to be a known issue with HttpClient, but since I am not using HttpClient directly in our code, it is indirectly through Spring Social.

      http://stackoverflow.com/questions/1...-in-threadpool

      Actually, in my research I have found some wild stuff. Like Apache Commons Logging has some bad ThreadLocal references in there that causes lots of leaks.

      Mark

      Comment


      • #4
        The connection is between HttpClient and Spring Social is this.

        I deploy my webapp, with Spring Social in it. Do nothing, then redeploy. No ThreadLocals.

        I deploy my webapp, with Spring Social, do a Login with Twitter then redeploy. Two ThreadLocals there leaking.

        Again, I am not blaming Spring Social, it is HttpClient that is the problem. But I can't get access to it in my app because it is hidden behind Spring Social. So it might be nice to have a simple pass through to get to HttpClient to make sure it closes everything when done.

        Thanks

        Mark

        Comment


        • #5
          Yeah, I don't quite even see how you could even provide a passthrough.

          HttpClient is used in ClientHttpRequestFactorySelector, which shows up elsewhere when creating a Spring RestTemplate. At that point it is in another project.

          But I see

          private static final boolean HTTP_COMPONENTS_AVAILABLE = ClassUtils.isPresent("org.apache.http.client.HttpC lient", ClientHttpRequestFactory.class.getClassLoader());

          And

          Code:
          if (HTTP_COMPONENTS_AVAILABLE) {
          			return HttpComponentsClientRequestFactoryCreator.createRequestFactory(proxyHost, proxyPort);
          		} else {
          			SimpleClientHttpRequestFactory requestFactory = new SimpleClientHttpRequestFactory();
          			if (proxyHost != null) {
          				requestFactory.setProxy(new Proxy(Proxy.Type.HTTP, new InetSocketAddress(proxyHost, proxyPort)));
          			}
          			return requestFactory;
          		}
          Which to me means, I don't have to have HttpClient as a dependency, Spring Social can do fine without it. Is that correct?

          Thanks

          Mark

          Comment


          • #6
            Yep, that is correct. And that worked. By removing the dependency in maven to HttpClient, Spring Social will not use it and use SimpleClientHttpRequestFactory instead. And my memory leak is now gone.

            Thanks for listening.

            Sometimes I post stuff like this to sound off and think through the problems. Again as I said before, I wasn't blaming Spring Social, but I knew my path to solution was through Spring Social and it was by examining the code. And that is why open source is great and github makes it even better.

            Mark

            Comment

            Working...
            X