Synchronization cleanup

[jekh]

In my use of the proxy, I'm serving a fairly large number of requests simultaneously (several thousand, via Selenium). I started to notice some overhead from synchronization, so I decided to undertake a cleanup of synchronization-related code. This is a large changeset, so I've been testing extensively and have not yet seen any problems -- but I would appreciate feedback on other high-volume scenarios to test.

Summary of changes:

• Synchronization updates:
  • Moved to java.util.concurrent collections if it allowed removing synchronized blocks. Almost all synchronization blocks are now gone, and there should be no synchronization when serving requests.
  • Refactored WhitelistEntry into immutable Whitelist to avoid synchronizing on the WhitelistEntry
  • Made fields in BrowserMobHttpClient volatile, since they can be set asynchronously through web service calls.
  • Made immutable fields in BrowserMobHttpClient final
• Made UA Detector initialize-on-demand, to avoid resource use and log pollution when not using it. Updated pom latest version of UA Detector.
• Fixed minor defect where calling stop() would not prevent proxy server from handling new requests

[lightbody]

Pretty cool -- I'd love to hear more about your usage that pushes so much through it!

I was ready to merge this, but sadly it doesn't auto merge. Any change you can update it (I must have pulled in another conflicting PR) and then I'll go ahead and merge it. Thanks!

[jekh]

Just updated, should be good to merge now. We're using the proxy to blacklist and whitelist requests for a Selenium grid with several dozen browser sessions running simultanously, and each page makes anywhere from a couple to 50 (!) HTTP requests, resulting in a very large number of concurrent requests coming into the proxy.

Overall the proxy performs admirably. The biggest bottleneck I've found so far is threads -- each request to the Jetty server requires its own thread, so we had to reduce stack size significantly in order to avoid OutOfMemory issues caused by the threads' stacks. That's one reason I'm looking into the Jetty code, to see if we can somehow take advantage of Java's NIO to reduce the number of threads we spawn, since most of our threads are just parked waiting for the upstream server to respond. But as you pointed out, enhancing the embedded Jetty in any way is a nearly insurmountable challenge.