HttpClient - multiple hosts

[develop...@gmail.com]

Hello all,

I have a use-case where I have to make Http Requests to serve incoming request but the hosts of the are pretty dynamic (driven by the corresponding incoming request).  Looking at the docs, looks like a HttpClient is tied to a particular host. (Vertx 1.3.1).  What is the inteded usage pattern in this case?  

1. Create a HttpClient/host and maintain a local cache(map) between hosts and HttpClient - and this is per verticle as verticles cannot share state.

2. Create a HttpClient for each host per each incoming request and discard once done.

3. ?

Is there are plan to provide a generic HttpClient that is not tied to a host+port in the near future? (this is the pattern provided by most of the http clients)

Thanks,

[Tim Fox]

On 11/06/13 20:13, develop...@gmail.com wrote:
> Hello all,
>
> I have a use-case where I have to make Http Requests to serve incoming
> request but the hosts of the are pretty dynamic (driven by the
> corresponding incoming request). Looking at the docs, looks like a
> HttpClient is tied to a particular host. (Vertx 1.3.1). What is the
> inteded usage pattern in this case?
>
> 1. Create a HttpClient/host and maintain a local cache(map) between hosts
> and HttpClient - and this is per verticle as verticles cannot share state.
> 2. Create a HttpClient for each host per each incoming request and discard
> once done.

Yep. The HttpClient is pretty lightweight so there's not much overhead
in creating them frequently.

Caching them would only really make sense if you want to use keep-alive
to keep connections open to the hosts. But most servers will close
inactive keep alive connections after a few seconds anyway, so unless
you're sending a lot of requests to the same hosts in a short period of
time it probably wouldn't make much sense. And from your description
that doesn't really sound like what you're doing.

> 3. ?
>
> Is there are plan to provide a generic HttpClient that is not tied to a
> host+port in the near future? (this is the pattern provided by most of the
> http clients)

I'm not sure what the advantage would be.

>
> Thanks,
>

[develop...@gmail.com]

Hello Tim,

Thanks for your response.  Please find my responses embedded.

Thanks

On Tuesday, June 11, 2013 3:28:58 PM UTC-4, Tim Fox wrote:

On 11/06/13 20:13, develop...@gmail.com wrote:
> Hello all,
>
> I have a use-case where I have to make Http Requests to serve incoming
> request but the hosts of the are pretty dynamic (driven by the
> corresponding incoming request).  Looking at the docs, looks like a
> HttpClient is tied to a particular host. (Vertx 1.3.1).  What is the
> inteded usage pattern in this case?
>
> 1. Create a HttpClient/host and maintain a local cache(map) between hosts
> and HttpClient - and this is per verticle as verticles cannot share state.
> 2. Create a HttpClient for each host per each incoming request and discard
> once done.

Yep. The HttpClient is pretty lightweight so there's not much overhead
in creating them frequently.

chandra: That is good to know.  I will use this pattern then.

Caching them would only really make sense if you want to use keep-alive
to keep connections open to the hosts. But most servers will close
inactive keep alive connections after a few seconds anyway, so unless
you're sending a lot of requests to the same hosts in a short period of
time it probably wouldn't make much sense. And from your description
that doesn't really sound like what you're doing.

chandra: correct 

> 3. ?
>
> Is there are plan to provide a generic HttpClient that is not tied to a
> host+port in the near future? (this is the pattern provided by most of the
> http clients)

I'm not sure what the advantage would be.

chandra:  I wasn't sure earlier that HttpClient is a light-weight object, and therefore thought it would be advantageous to decouple a HttpClient from a host.  And also it feels from a user/client perspective, not restricting httpclient to a host and port would make it more friendly. 

>
> Thanks,
>

 

[Tim Fox]

On 11/06/13 21:04, develop...@gmail.com wrote:
> Hello Tim,
>

> Thanks for your response. Please find my *responses* embedded.

>
> Thanks
>
>
> On Tuesday, June 11, 2013 3:28:58 PM UTC-4, Tim Fox wrote:

>> On 11/06/13 20:13, develop...@gmail.com <javascript:> wrote:
>>> Hello all,
>>>
>>> I have a use-case where I have to make Http Requests to serve incoming
>>> request but the hosts of the are pretty dynamic (driven by the
>>> corresponding incoming request). Looking at the docs, looks like a
>>> HttpClient is tied to a particular host. (Vertx 1.3.1). What is the
>>> inteded usage pattern in this case?
>>>
>>> 1. Create a HttpClient/host and maintain a local cache(map) between
>> hosts
>>> and HttpClient - and this is per verticle as verticles cannot share
>> state.
>>> 2. Create a HttpClient for each host per each incoming request and
>> discard
>>> once done.
>> Yep. The HttpClient is pretty lightweight so there's not much overhead
>> in creating them frequently.
>>

> *chandra: That is good to know. I will use this pattern then.*

>
>> Caching them would only really make sense if you want to use keep-alive
>> to keep connections open to the hosts. But most servers will close
>> inactive keep alive connections after a few seconds anyway, so unless
>> you're sending a lot of requests to the same hosts in a short period of
>> time it probably wouldn't make much sense. And from your description
>> that doesn't really sound like what you're doing.
>>

> *chandra: correct*

>
>>> 3. ?
>>>
>>> Is there are plan to provide a generic HttpClient that is not tied to a
>>> host+port in the near future? (this is the pattern provided by most of
>> the
>>> http clients)
>> I'm not sure what the advantage would be.
>>

> *chandra: I wasn't sure earlier that HttpClient is a light-weight object,

> and therefore thought it would be advantageous to decouple a HttpClient
> from a host. And also it feels from a user/client perspective, not

> restricting httpclient to a host and port would make it more friendly. *

Yes possibly the API could be improved, but let's thing how the two
approaches would compare:

Current API

HttpClient client = new HttpClient().host("foo.com");
client.get("/blah/bar.html", new Handler<HttpServerResponse>() {
public void handle(HttpServerResponse resp) {
// Do something
client.close();
}
});

Alternative client:

client.get("http://foo.com/blah/bar.html", new
Handler<HttpServerResponse>() {
public void handle(HttpServerResponse resp) {
// Do something
}
});


So it probably wouldn't be a whole lot different for the user.


>
>>> Thanks,
>>>
>>

[develop...@gmail.com]

Hello Tim,

Probably, I am more used to the existing Http Clients that provide a way to do a request just given a url, and therefore feels more natural.   A simple wrapper over the current api should be able to accomplish the same, but that wrapper has to split the given url into host, port and path everytime a request is made - not a big deal, but again just doesn't feel natural after using other http clients.

Regardless, thanks for your insight.

Best regards,

[Tim Fox]

On 12/06/13 13:28, develop...@gmail.com wrote:
> Hello Tim,
>
> Probably, I am more used to the existing Http Clients that provide a way to
> do a request just given a url, and therefore feels more natural. A simple
> wrapper over the current api should be able to accomplish the same, but
> that wrapper has to split the given url into host, port and path everytime
> a request is made - not a big deal, but again just doesn't feel natural
> after using other http clients.

It's an interesting point and it has come up before.

The rationale behind the Vert.x HTTP client is it models closely what
actually happens on the HTTP protocol.

When you send an HTTP requests to a server, the actual URL that gets
sent (in almost all cases - an exception is proxying) is a _relative_
url, and the host (and port) is used to create the connection to the
server - it is not present in the url that is sent in the request. (The
host is usually present as a HTTP header in the request).

So, the argument can be made that a client that uses an absolute URL to
send a request is kind of unnatural and disjointed from how HTTP
actually works ;)