HttpUtils, merge newMultithreadedClient and newMultithreadedClientHttps
12316
Reporter: mdoering
Assignee: mdoering
Type: Improvement
Summary: HttpUtils, merge newMultithreadedClient and newMultithreadedClientHttps
Priority: Trivial
Resolution: Fixed
Status: Closed
Created: 2012-11-13 16:55:49.245
Updated: 2013-12-06 12:06:44.215
Resolved: 2012-11-21 00:04:47.412
Description: Is there a reason to have two different factories for a multi threaded http client?
Better to merge the two methods and only keep the new https one, but call it newMultithreadedClient.
public static DefaultHttpClient newMultithreadedClient() {
public static DefaultHttpClient newMultithreadedClientHttps() {]]>
Author: lfrancke@gbif.org
Created: 2012-11-13 18:52:55.614
Updated: 2012-11-13 18:52:55.614
I actually marked those methods as deprecated and I think they should all be removed.
Without knowing exactly how the client is configured that you receive back you'll not be able to trust it (as is apparent by the problems we've had with it). So to understand that it needs to be very good documented which then isn't much code saved, if any. Also by explicitly creating the client where needed it's much more visible and force you to think about what this tool actually needs to do. Setting the timeouts to 10 minutes (as is done now) is unreasonable for almost all purposes but setting them lower could cause trouble for some code etc.
I'd like to close this as WONTFIX
Author: mdoering@gbif.org
Comment: Not sure if I agree. If these methods would not exist I doubt we would see a better use of the client and instead see various uses with people forgetting certain configurations or not updating older code with new insights we gain. I would very much prefer to see a default GBIF setting that can be adjusted in one place. But that method should probably accept an additional config param that can override the defaults.
Created: 2012-11-13 23:57:04.922
Updated: 2012-11-13 23:57:04.922
Author: lfrancke@gbif.org
Comment: Good points. But I think the current methods promote bad usage. How about we create a method that takes mandatory parameters for things like timeouts. So everyone is forced to think about the usage while still making sure that we can use sane and safe defaults for everything else?
Created: 2012-11-14 00:08:34.32
Updated: 2012-11-14 00:08:34.32