Re: [EM] Closing the TCP connection after accept? One request at-a-time.

[kashyap k]

If I understand this right, you want to block the TCP socket until the request processing is done. Best way to do this is not to use any EM based modules and you'll get that functionality in a natural way without jumping through a lot of hoops. 

It is feasible but is a bad idea to design a HTTP server that handles only one request at a time.

On Monday, February 18, 2013, Daniel Doubrovkine wrote:

We're trying to figure out how to make a server reject connections wihle a request is in the queue. Servers don't respect the parameters to listen(..) so we have to do it the hard way.

I'd like to experiment with em or em-proxy to close the listening TCP socket after a request has been accepted and reopening it after processing of an entire HTTP request has completed. Anyone things it's feasible or, maybe, a bad idea?

Thanks,

dB.

--
You received this message because you are subscribed to the Google Groups "EventMachine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventmachine...@googlegroups.com.
To post to this group, send email to eventm...@googlegroups.com.
Visit this group at http://groups.google.com/group/eventmachine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Kashyap KMBC

[Daniel Doubrovkine]

That's not quite right. We'd like to *close* the TCP socket until request processing is done. It's an experiment, so not trying to worry about any real world scenarios, just see if this is feasible. The purpose is to indicate to an upstream proxy that the service is not available. The upstream proxy can't be modified right now, but it will try another back-end if it cannot connect to one that it is connecting to. If the back-end does an accept, we lost.

dB. | Moscow - Geneva - Seattle - New York
dblock.org - @dblockdotorg

[Iñaki Baz Castillo]

2013/2/18 Daniel Doubrovkine <dbl...@dblock.org>:

> That's not quite right. We'd like to *close* the TCP socket until request
> processing is done. It's an experiment, so not trying to worry about any
> real world scenarios, just see if this is feasible. The purpose is to
> indicate to an upstream proxy that the service is not available. The
> upstream proxy can't be modified right now, but it will try another back-end
> if it cannot connect to one that it is connecting to. If the back-end does
> an accept, we lost.

I understand your point but it's not feasible with EventMachine (not
with the current API).


--
Iñaki Baz Castillo
<i...@aliax.net>

[Thomas O'Rourke]

Interesting scenario. Don't know if this is entirely relevant... but
Have you looked at zermomq? It can do some pretty cool topologies with sockets and can do reconnects, load balancing, etc.. There's also this:
https://github.com/andrewvc/em-zeromq

Tom.

[James Tucker]

You just want to be able to set the listen backlog. We don't have an API for this today, but I would be happy to accept a patch for it.

[Daniel Doubrovkine]

Unfortunately most operating systems don't respect this number and will adjust it dynamically, usually larger than the number set. So it's nothing more than a hint.

http://stackoverflow.com/questions/10749636/listen-ignoring-backlog-value