6

Is HTTPBuilder in Grails thread safe?

If HTTPBuilder is wired to a Grails service class, will it be safe to use? Or should it be instantiated on every invocation?

There doesn't seem to be any concrete answer as to whether HTTPBuilder in Grails is thread safe or not. I'm inclined to go with non thread safe due to the lack of documentation regarding that particular aspect, but I'd like a definitive answer.

The code seem to indicate it should be ok to handle multiple requests from multiple threads so long as they will go through to the same URL with the same context (headers, authenticators etc.).

Thihara
  • 7,031
  • 2
  • 29
  • 56

1 Answers1

3

Do you mean groovyx.net.http.HTTPBuilder? It has several fields that are modified by calling methods, and there's no synchronization or locking, and no use of thread-safe collections or other classes, so no, it's very much non-thread-safe. Most builders are similarly stateful and should be assumed to not be thread-safe.

Burt Beckwith
  • 75,342
  • 5
  • 143
  • 156
  • Which fields are actually modified by the calling methods other than constructors? There is an AsyncHttpBuilder http://groovy.codehaus.org/modules/http-builder/doc/async.html that extends HttpBuilder by submitting calls to a threadpool and using a threadsafe connection manager. But, if HttpBuilder fields were modified by calling methods, then this wouldn't work... – Jeff Storey Jan 02 '15 at 04:51
  • Lots :) One example - `setHeaders` calls `clear` on `defaultRequestHeaders`, which is an instance of `StringHashMap`, a simple subclass of `HashMap`. There are also several mutators, e.g. `setEncoderRegistry`, `setParserRegistry`, etc. – Burt Beckwith Jan 02 '15 at 04:55
  • Right, but you would have to explicitly call those. So I guess if you were making the SAME request with the same headers, it could work. Though `getClient` is lazy too, which could pose some problems. AsyncHTTPBuilder is a bit misleading then. – Jeff Storey Jan 02 '15 at 04:58
  • @BurtBeckwith Yes. From what I could tell form the source code it seems that for a single URL multiple get, post requests seem to ok with multi threading. Particularly because `AbstractHttpClient client` seem to be thread safe. Am I getting it wrong? – Thihara Jan 02 '15 at 04:59
  • @Thihara The `DefaultHttpClient` uses the `BasicHttpClientConnectionManager` http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/BasicHttpClientConnectionManager.html, which is thread safe but only allows one connection at a time. You would need to use the `PoolingHttpClientConnectionManager` http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/PoolingHttpClientConnectionManager.html – Jeff Storey Jan 02 '15 at 05:09
  • @JeffStorey So generally using the same HTTPBuilder as a shared resource in a service shouldn't be an problem so long as the URL and the context remains the same? That was my feeling as well, but was confused because that wasn't really specified in the docs anywhere. – Thihara Jan 02 '15 at 05:18
  • @BurtBeckwith Can you edit your answer a bit to reflect the things in this chat? I can accept it then. – Thihara Jan 02 '15 at 05:18
  • @Thihara Not quite. In my previous comment, I mentioned that only one thread can actually use the `DefaultHttpClient` at once (per the API docs), so you still need to use the right connection manager. But as far as I can tell, if you don't call the setters as @BurtBeckwith described, it looks like you should be ok. You also would want to explicitly call `setClient` since it's lazy loaded and you wouldn't want to load it twice. – Jeff Storey Jan 02 '15 at 05:21
  • This seems concerning since there seems to be a bunch of blogs out there demonstrating injecting HTTPBuilders into services via spring without talking about any thread safety problems. – krock Sep 23 '15 at 22:04