Vert.x Proxy example

[AlanT]

Hi, All

I've been testing out the proxy server in the vert.x github examples, on vert.x 2.1.1.

On the surface it seems to work ok. However, if I use it to proxy a website, and then go to the site in my browser, I see quite a few connections made by the browser just hanging and not returning any response. 

If I make these requests individually, they all return successfully.

I'm generating lots of load, just requesting a web page which has a number of images, javascript files etc. 

Am I missing something obvious here? 

[AlanT]

Sorry that should read:

"Im *not" generating lots of load"

So I'm assuming that I'm missing something obvious, and that Vert.x can handle vastly more concurrent requests than the 20 or so generated by this web page being proxied

[Alexander Lehmann]

What are you doing in the proxy code? Most likely you have some blocking operation in the your code that causes the requests to be processed one after another and not concurrently.

[AlanT]

Hi,

I'm just running the example proxy from the vert.x website:

https://github.com/vert-x/vertx-examples/blob/master/src/raw/java/proxy/ProxyServer.java

And pointing it to a website an accessing a page.

On further inspection. I can see that failing requests get handled by the web server request handler, but I don't see those requests reach the actual origin server (i.e. they don't appear in the access logs of the origin).

I also did some other tests just to satisfy myself that the example was non-blocking, and it appears to be.

[AlanT]

I have at least one clue to the issue, and that is, if I set keepalive to 'false' on the HttpClient, all the requests made by the browser are handled successfully, and effectively the problem goes away.

Could there be some issue with the using keepalive in this circumstance ?

[Stream Liu]

Did you have try to setMaxPoolSize.

I think the problem is that httpclient could not have enough thread to
connect to the same host.

[Tim Fox]

Bear in mind that the examples are supposed to be simple examples and snippets to get you familiar with Vert.x coding. They are not designed to be real production ready applications, so no guarantees are made that they are "perfect".

Probably what's happening is the proxy is attempting to pipeline to the target server but that server doesn't support it so closes the connection immediately thus losing any other requests that have already been written...

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[AlanT]

Sorry didn't want to knock the demo examples, they're hugely useful and comprehensive. Just was getting a bit confused over how it was behaving.

I'm going to be doing more work with Vert.x and end user facing reverse-proxies, so will hopefully be able to contribute some code at some point. I definitely think there's room for an alternative to Varnish Cache written for Vert.x

 

Needless to say, from what I've seen so far, I think Vert.x is seriously good

[ddimensia]

Try forcing pipelining off and see if that helps things, for whatever reason it's on by default even though there are issues with it's abilities to handle servers that close connections.

I have a proxy written in Vertx 2.0 that peaks out about 15k rps per box in production.  We've been running it for 6 months in production and for the most part have found that things work well.  However, we also found that there were various issues with the keepAlive support in 2.0 and the unbounded wait queue in the HttpClient implementation.  The tip of the 2.x branch has some of these issues resolved but we've just started testing to see if we can move to it and finally enable http keepAlive (but not pipelining).   

If you're going to write a proxy then there's a few things that you'll need to think about.  First is that fact clients can drop their connections (especially with mobile) and you'll need to handle that case and clean up the backend request/response to not stall the associated IO channel and tie up a connection.  You'll also need to deal with the fact that you'll potentially be translating HTTP 1.0 requests to HTTP 1.1 (vert.x client doesn't allow specifying http version) which can get interesting when you start talking an HTTP 1.0 keepalive request with a HTTP 1.1 chunked response from the backend. There's also various things like the 'Connection' header that you need to deal with.

[Tim Fox]

On 12/07/14 01:23, ddimensia wrote:

Try forcing pipelining off and see if that helps things, for whatever reason it's on by default even though there are issues with it's abilities to handle servers that close connections.

I have a proxy written in Vertx 2.0 that peaks out about 15k rps per box in production.  We've been running it for 6 months in production and for the most part have found that things work well.  However, we also found that there were various issues with the keepAlive support in 2.0 and the unbounded wait queue in the HttpClient implementation.  The tip of the 2.x branch

I think this change was actually in the last release 2.1.1 (?)

BTW, the Vert.x 3.0 client has been completely rewritten, I think you'll like it :)