On Sun, 06 Jan 2013 04:04:31 GMT, zhaopuming wrote:
On Sat, 05 Jan 2013 09:01:26 GMT, Sönke Ludwig wrote:
A little background, we are currently using vert.x for our project, but after first online traffic tests,
we found that their client code does not satisfy our requirements.Btw. is it the case that for client code, that vert.x drops back to threads+synchronous I/O?
I just briefly read a bit about it and it seems like it uses the asynchronous I/O only for handling requests and provides thread pools with traditional I/O for anything on top of that.
The HttpClient in Vert.x is also Asynchronous I/O
Each HttpClient is associated with a connection pool, and each request will try to use an available connection, if no one is available, it will try to create a new connection, if the max pool size is reached, the request is stored in a waiter queue.
Each connection has a requests queue (as pipelining) to store requests that are already written, but no response is replied.
Once a request is written, the connection is considered available and will be accepting new requests.When a response is send back, an asynchronized callback will be invoked, and the request at the top of the connection will be removed.
Ah, I missed the part about HTTP pipelining before. The vibe.d client currently doesn't do this, only keep-alive and parallel connections when necessary.
I need to think a bit about how the API would have to look like to support pipelining. I'd want to avoid any possibility of misuse (i.e. trying to read responses in the wrong order) and not resort to buffering of responses. Callbacks would work, but they are kind of ugly here since they rip apart the request-response context for the individual contexts. Also it would be nice to keep this at least a semi-manual process for the reason you mentioned (possibly cluttering up the pipeline). For now there is a new TODO entry for this.
