Re: [mongrel2] Proposed Change To Handler Config
- From:
- Alfred Tascon
- Date:
- 2011-05-09 @ 23:12
+1 for me - as previously stated to have separate SUB points AND sending IDs
back always "smelled" redundant :)
Re: Documenting it:
Could we follow ZeroMQ's lead here?
From the config file's point of view:
Call it sub_spec for Server and push_spec for the Handler?
From the Handler's point of view:
Call it pull_spec and pub_spec as appropriate?
Or have I missed the point?
On Mon, May 9, 2011 at 12:39 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> Hey Everyone,
>
> I'm going to fix up the manual today and push out a 1.6 release of
> Mongrel2. While working on this release, I realized that we could
> simplify the configuration and improve reloading if I made this change:
>
> There is just one SUB socket, defined on the Server, then each Handler
> has a PUB socket.
>
> That means the config would be more like this:
>
> handler_test = Handler(send_spec='tcp://127.0.0.1:9997',
> send_ident='34f9ceee-cd52-4b7f-b197-88bf2f0ec378')
>
> main = Server(
> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
> ....
> recv_spec='tcp://127.0.0.1:9996',
> recv_ident=''
> )
>
> This would simplify the configuration, and internally the reloads
> wouldn't have to deal with more than one recv socket. More importantly,
> this is how things turned out to actually work, since you can pretty
> much just send to any of the SUB sockets at a server because they're all
> stateless.
>
> Downside is people's configurations have to change, and any frameworks
> autoloading the config out of the database would have to update (Tir) is
> like this.
>
> So, thoughts on this change?
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Ryan Kelly
- Date:
- 2011-05-08 @ 21:57
On Sun, 2011-05-08 at 09:39 -0700, Zed A. Shaw wrote:
> Hey Everyone,
>
> I'm going to fix up the manual today and push out a 1.6 release of
> Mongrel2. While working on this release, I realized that we could
> simplify the configuration and improve reloading if I made this change:
>
> There is just one SUB socket, defined on the Server, then each Handler
> has a PUB socket.
>
> That means the config would be more like this:
>
> handler_test = Handler(send_spec='tcp://127.0.0.1:9997',
> send_ident='34f9ceee-cd52-4b7f-b197-88bf2f0ec378')
>
> main = Server(
> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
> ....
> recv_spec='tcp://127.0.0.1:9996',
> recv_ident=''
> )
>
> This would simplify the configuration, and internally the reloads
> wouldn't have to deal with more than one recv socket. More importantly,
> this is how things turned out to actually work, since you can pretty
> much just send to any of the SUB sockets at a server because they're all
> stateless.
+1 from me. It was always kinda weird having multiple SUB sockets *and*
having to send the server ID back with each reply. Sounds cleaner this
way.
> On Sun, May 08, 2011 at 07:27:49PM +0200, Karl Ostendorf wrote:
> >
> > So, if handlers only open a PUB socket over which to send responses,
> > how do they receive requests? Do they also open up a SUB socket on the
> > same address as the server? Confused.
>
> Handlers still open both, they just open the same PUB socket for each
> server.
I'm a little bit confused by this "each server" business Are you
talking about multiple handlers or multiple instances of mongrel2? Let
me make sure I've got it straight...
If you've got a single instance of mongrel2 talking to multiple
handlers, then the server opens a single SUB socket for replies and each
handler connects to it with a PUB socket. Like this:
mongrel2 [recv_spec:SUB] <------------ [recv_spec:PUB] handler
|
\--------- [recv_spec:PUB] handler
If you've got multiple instances of mongrel2, they each get their own
recv_spec and the handlers would have to connect their PUB socket to
each server individually. Like this:
mongrel2 [recv_spec1:SUB] <-------------- [recv_spec1:PUB
| recv_spec2:PUB] handler
mongrel2 [recv_spec2:SUB] <---/
Is this what you have in mind?
Ryan
--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
ryan@rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-09 @ 00:01
On Mon, May 09, 2011 at 07:57:26AM +1000, Ryan Kelly wrote:
> I'm a little bit confused by this "each server" business Are you
> talking about multiple handlers or multiple instances of mongrel2? Let
> me make sure I've got it straight...
>
> If you've got a single instance of mongrel2 talking to multiple
> handlers, then the server opens a single SUB socket for replies and each
> handler connects to it with a PUB socket. Like this:
>
>
> mongrel2 [recv_spec:SUB] <------------ [recv_spec:PUB] handler
> |
> \--------- [recv_spec:PUB] handler
Yes, that's right.
> If you've got multiple instances of mongrel2, they each get their own
> recv_spec and the handlers would have to connect their PUB socket to
> each server individually. Like this:
>
>
> mongrel2 [recv_spec1:SUB] <-------------- [recv_spec1:PUB
> | recv_spec2:PUB] handler
> mongrel2 [recv_spec2:SUB] <---/
Sadly, no because there's nothing in 0mq that says "connect this socket
to these three servers and figure it out". You'd need a little device
between them that accepts connections from any handlers, and then sends
them out to all three mongrel2 servers who will then sort it out.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-08 @ 17:46
Hi,
On May 8, 2011 12:39:31 PM Zed A. Shaw wrote:
> Hey Everyone,
>
> I'm going to fix up the manual today and push out a 1.6 release of
> Mongrel2. While working on this release, I realized that we could
> simplify the configuration and improve reloading if I made this change:
>
> There is just one SUB socket, defined on the Server, then each Handler
> has a PUB socket.
>
I like this. It makes a lot of sense.
> That means the config would be more like this:
>
> handler_test = Handler(send_spec='tcp://127.0.0.1:9997',
> send_ident='34f9ceee-cd52-4b7f-b197-88bf2f0ec378')
>
> main = Server(
> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
> ....
> recv_spec='tcp://127.0.0.1:9996',
> recv_ident=''
> )
>
But, I detest the variable names. Is a handler supposed to receive the
recv_spec or the send_spec? That is, should the handlers recv_spec be the
same as Mongrel2's send_spec or Mongrel2's recv_spect? Even after working
with the perl connector, I still am confused.
Could we call them something like:
handler_spec & handler_ident
mongrel2_spec & mongrel2_ident
Then it is clear that the handler_spec is the same both for the handler and
Mongrel2 configurations.
Regards,
Henry
> This would simplify the configuration, and internally the reloads
> wouldn't have to deal with more than one recv socket. More importantly,
> this is how things turned out to actually work, since you can pretty
> much just send to any of the SUB sockets at a server because they're all
> stateless.
>
> Downside is people's configurations have to change, and any frameworks
> autoloading the config out of the database would have to update (Tir) is
> like this.
>
> So, thoughts on this change?
--
Henry Baragar
Instantiated Software
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-08 @ 18:55
On Sun, May 08, 2011 at 01:46:27PM -0400, Henry Baragar wrote:
> But, I detest the variable names. Is a handler supposed to receive the
> recv_spec or the send_spec? That is, should the handlers recv_spec be the
> same as Mongrel2's send_spec or Mongrel2's recv_spect? Even after working
> with the perl connector, I still am confused.
It's like this:
[mongrel2 -> send_socket:PUSH] -> [recv_socket:PULL -> handler]
[mongrel2 <- recv_socket:SUB] <- [send_socket:PUB <- handler]
For some reason people have a hard time thinking this way in general.
You configure it in mongrel2 one way, but your handler has to do the
inverse on the other side. Even in regular networking, posix pipes, and
other stuff it's confusing. Just kind of how it goes.
> Could we call them something like:
> handler_spec & handler_ident
> mongrel2_spec & mongrel2_ident
> Then it is clear that the handler_spec is the same both for the handler and
> Mongrel2 configurations.
How about: handler_spec and server_spec instead? That makes more sense
if there's just one server socket also.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-08 @ 19:21
On May 8, 2011 02:55:48 PM Zed A. Shaw wrote:
> On Sun, May 08, 2011 at 01:46:27PM -0400, Henry Baragar wrote:
> > But, I detest the variable names. Is a handler supposed to receive the
> > recv_spec or the send_spec? That is, should the handlers recv_spec be
> > the same as Mongrel2's send_spec or Mongrel2's recv_spect? Even after
> > working with the perl connector, I still am confused.
>
> It's like this:
>
> [mongrel2 -> send_socket:PUSH] -> [recv_socket:PULL -> handler]
> [mongrel2 <- recv_socket:SUB] <- [send_socket:PUB <- handler]
>
> For some reason people have a hard time thinking this way in general.
> You configure it in mongrel2 one way, but your handler has to do the
> inverse on the other side. Even in regular networking, posix pipes, and
> other stuff it's confusing. Just kind of how it goes.
>
I just confirmed that the perl handler has this backwards (hence my
confusion).
> > Could we call them something like:
> > handler_spec & handler_ident
> > mongrel2_spec & mongrel2_ident
> > Then it is clear that the handler_spec is the same both for the handler
> > and Mongrel2 configurations.
>
> How about: handler_spec and server_spec instead? That makes more sense
> if there's just one server socket also.
This is much clearer than (send/recv), but "server" could just as well refer
to the application server behind the web server.
Other possibilities:
master/slave
dispatcher/handler
web/app
I would lean towards dispatcher/handler (or web/app if brevity was of more
importance).
Henry
--
Henry Baragar
Instantiated Software
416-907-8454 x42
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-08 @ 21:35
On Sun, May 08, 2011 at 03:21:54PM -0400, Henry Baragar wrote:
> I just confirmed that the perl handler has this backwards (hence my
> confusion).
You got a link to the perl handler code that's got it wrong?
> > How about: handler_spec and server_spec instead? That makes more sense
> > if there's just one server socket also.
>
> This is much clearer than (send/recv), but "server" could just as well refer
> to the application server behind the web server.
Actually, now that I'm playing with it just calling it the "send_addr" is
better in both side. Try it out:
Handler.send_addr == The handler will send on this address with PUB.
Server.send_addr == Mongrel2 will send on this address with PUSH.
Anyway I'll come up with something if I do this, but at a certain point
you just have to get people to read and get it right. I think you got
hit by the perl handler getting it wrong which probably confused you.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-08 @ 22:30
On May 8, 2011 05:35:36 PM Zed A. Shaw wrote:
> On Sun, May 08, 2011 at 03:21:54PM -0400, Henry Baragar wrote:
> > I just confirmed that the perl handler has this backwards (hence my
> > confusion).
>
> You got a link to the perl handler code that's got it wrong?
https://github.com/lestrrat/Plack-Handler-
Mongrel2/blob/master/lib/Plack/Handler/Mongrel2.pm
Look at lines 209 & 220.
>
> > > How about: handler_spec and server_spec instead? That makes more
> > > sense if there's just one server socket also.
> >
> > This is much clearer than (send/recv), but "server" could just as well
> > refer to the application server behind the web server.
>
> Actually, now that I'm playing with it just calling it the "send_addr" is
> better in both side. Try it out:
>
> Handler.send_addr == The handler will send on this address with PUB.
> Server.send_addr == Mongrel2 will send on this address with PUSH.
>
That works well inside the application, but not in config files.
Consider the config file for a perl application:
plackup -s Mongrel2 \
--max_workers=10 \
--max_reqs_per_child=1000 \
--send_spec=tcp://127.0.0.1:9999 \
--send_ident=D807E984-AC0B-11DF-979C-3C4975AD5E34 \
--recv_spec=tcp://127.0.0.1:9998 \
--recv_ident=E80576A8-AC0B-11DF-A841-3D4975AD5E34
Consider the following environment variables for Ruby:
RACK_MONGREL2_RECV
RACK_MONGREL2_SEND
Consider the python:
app = Brubeck((pull_addr, pub_addr), handler_tuples)
Now PHP:
public function __construct($sender_id, $sub_addr, $pub_addr)
If all one does is look at an example config file (which often is the case),
then none of these examples are very good at communicating the intent of the
connections.
Maybe we are looking at the issue from the wrong angle! Maybe they should be:
request_spec
response_spec
That is, there are two services being offered: one to get resquests and one
for the responses. I think this will be a lot more obvious to everyone
involved.
Henry
> Anyway I'll come up with something if I do this, but at a certain point
> you just have to get people to read and get it right. I think you got
> hit by the perl handler getting it wrong which probably confused you.
--
Henry Baragar
Instantiated Software
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-09 @ 00:05
On Sun, May 08, 2011 at 06:30:39PM -0400, Henry Baragar wrote:
> On May 8, 2011 05:35:36 PM Zed A. Shaw wrote:
> > On Sun, May 08, 2011 at 03:21:54PM -0400, Henry Baragar wrote:
> > > I just confirmed that the perl handler has this backwards (hence my
> > > confusion).
> Consider the config file for a perl application:
> Consider the python:
> app = Brubeck((pull_addr, pub_addr), handler_tuples)
>
> Now PHP:
> public function __construct($sender_id, $sub_addr, $pub_addr)
I think what you demonstrated is no matter what I choose people will
still get them wrong. :-)
> Maybe we are looking at the issue from the wrong angle! Maybe they should be:
> request_spec
> response_spec
Ok, pop quiz: which goes on the Handler and which goes on the Server?
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Proposed Change To Handler Config
- From:
- James Dennis
- Date:
- 2011-05-09 @ 01:04
This is a fair criticism of Brubeck. I started out thinking it would be a
ZMQ message handler, so sockets should be called by what they are to zmq.
But I've built the system to be almost entirely a Mongrel2 handler.
Brubeck((pull_addr, pub_addr), handler_tuples)
Thanks.
On Sun, May 8, 2011 at 8:05 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Sun, May 08, 2011 at 06:30:39PM -0400, Henry Baragar wrote:
> > On May 8, 2011 05:35:36 PM Zed A. Shaw wrote:
> > > On Sun, May 08, 2011 at 03:21:54PM -0400, Henry Baragar wrote:
> > > > I just confirmed that the perl handler has this backwards (hence my
> > > > confusion).
> > Consider the config file for a perl application:
>
> > Consider the python:
> > app = Brubeck((pull_addr, pub_addr), handler_tuples)
> >
> > Now PHP:
> > public function __construct($sender_id, $sub_addr, $pub_addr)
>
> I think what you demonstrated is no matter what I choose people will
> still get them wrong. :-)
>
> > Maybe we are looking at the issue from the wrong angle! Maybe they
> should be:
> > request_spec
> > response_spec
>
> Ok, pop quiz: which goes on the Handler and which goes on the Server?
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-09 @ 00:48
On May 8, 2011 08:05:42 PM Zed A. Shaw wrote:
> On Sun, May 08, 2011 at 06:30:39PM -0400, Henry Baragar wrote:
> > On May 8, 2011 05:35:36 PM Zed A. Shaw wrote:
> > > On Sun, May 08, 2011 at 03:21:54PM -0400, Henry Baragar wrote:
> > > > I just confirmed that the perl handler has this backwards (hence my
> > > > confusion).
> >
> > Consider the config file for a perl application:
> >
> > Consider the python:
> > app = Brubeck((pull_addr, pub_addr), handler_tuples)
> >
> > Now PHP:
> > public function __construct($sender_id, $sub_addr, $pub_addr)
>
> I think what you demonstrated is no matter what I choose people will
> still get them wrong. :-)
>
> > Maybe we are looking at the issue from the wrong angle! Maybe they
> > should be: request_spec
> > response_spec
>
> Ok, pop quiz: which goes on the Handler and which goes on the Server?
They both go on the mongrel2 server! Its the central place to which all
application servers connect: both to pull requests and to publish responses.
Did I pass the quiz?-)
Henry
--
Henry Baragar
Instantiated Software
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-09 @ 01:55
On Sun, May 08, 2011 at 08:48:24PM -0400, Henry Baragar wrote:
> > > Maybe we are looking at the issue from the wrong angle! Maybe they
> > > should be: request_spec
> > > response_spec
> >
> > Ok, pop quiz: which goes on the Handler and which goes on the Server?
>
> They both go on the mongrel2 server! Its the central place to which all
> application servers connect: both to pull requests and to publish responses.
>
Nah, see that's what I mean. I think you have a basic misunderstanding
of what's going on that's causing the problem with the config, not the
config itself. For example, I'd answer:
Handler.response_spec = "tcp://127.0.0.1:9998"
Server.request_spec = "tcp://127.0.0.1:9997"
And, there could be multiple handlers, but in the proposed design just
one server, like in the config file. However, your answer says that you
think there's only one handler and one server.
Let me know if I've got an understanding of your thinking since I'm
currently updating the manual and can try to fix this.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-09 @ 02:35
On May 8, 2011 09:55:52 PM Zed A. Shaw wrote:
> On Sun, May 08, 2011 at 08:48:24PM -0400, Henry Baragar wrote:
> > > > Maybe we are looking at the issue from the wrong angle! Maybe they
> > > > should be: request_spec
> > > > response_spec
> > >
> > > Ok, pop quiz: which goes on the Handler and which goes on the Server?
> >
> > They both go on the mongrel2 server! Its the central place to which all
> > application servers connect: both to pull requests and to publish
> > responses.
>
> Nah, see that's what I mean. I think you have a basic misunderstanding
> of what's going on that's causing the problem with the config, not the
> config itself. For example, I'd answer:
>
> Handler.response_spec = "tcp://127.0.0.1:9998"
> Server.request_spec = "tcp://127.0.0.1:9997"
>
> And, there could be multiple handlers, but in the proposed design just
> one server, like in the config file. However, your answer says that you
> think there's only one handler and one server.
>
Now I really am confused:-)
Does "Server" mean the mongrel2 web server or an application server? If its
the mongrel2 web server, shouldn't it be "Server.response_spec"? That is,
where to send the responses?
And does "Handler" mean something on the mongrel2 web server an application
server? In either case, shouldn't it be "Handler.request_spec"? That is,
where to get the requests?
Maybe the confusion is that I am thinking "http request" when I say "request"
and "http response" when I say "response" (i.e. not zmq ones).
> Let me know if I've got an understanding of your thinking since I'm
> currently updating the manual and can try to fix this.
Lets use a full example, so that we really get the terms and concepts clear.
Consider:
mongrel2 server on 10.0.0.1
app_1 on 10.0.1.1 and 10.0.1.2
app_2 on 10.0.2.1
I would expect the mongrel2 configuration to be:
app_1_handler = Handler (request_spec = 'tcp://10.0.0.1;9001'. ...)
app_2_handler = Handler (request_spec = 'tcp://10.0.0.1;9002'. ...)
main = Server(
uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
....
response_spec='tcp://127.0.0.1:9000',
)
where the server binds a push zmq_socket on 9001 & 9002, and binds a sub
zmq_socket on 9000.
Then environment variables for App_1 on 10.0.1.1:
REQUEST_SPEC='tcp://10.0.0.1;9001'
REQUEST_IDENT='app_1-uuid'
RESPONSE_SPEC='tcp://127.0.0.1:9000'
RESPONSE_IDENT="2f62bd5-9e59-49cd-993c-3b6013c28f05"
App_1 would connect to a pull zmq_socket specified by the $REQUEST_SPEC and
connect to a pub zmq_socket specified by the RESPONSE_SPEC.
The environment variables for App_1 on 10.0.1.2 would be same as they are on
10.0.1.1.
The script for App_2 on 10.0.2.1 would be:
plackup -s Mongrel2 \
--max_workers=10 \
--max_reqs_per_child=1000 \
--request_spec=tcp://10.0.0.1:9002 \
--request_ident='app_2-uuid' \
--response_spec=tcp://10.0.0.1:9000 \
--response_ident=2f62bd5-9e59-49cd-993c-3b6013c28f05
Is this a reasonable line of thinking?
Regards,
Henry
--
Henry Baragar
Instantiated Software
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-10 @ 19:36
On Sun, May 08, 2011 at 10:35:31PM -0400, Henry Baragar wrote:
> Does "Server" mean the mongrel2 web server or an application server? If its
> the mongrel2 web server, shouldn't it be "Server.response_spec"? That is,
> where to send the responses?
I think the problem is one of perspective. When I edit the
mongrel2.conf I'm saying this in my head:
"Time to update the Mongrel2 web server so that it knows where
everything is and can work based on what it has inside."
But it seems like when you edit mongrel2.conf you are thinking:
"Time to update the Handler configuration that Mongrel2 uses to talk to
my handlers."
I'll play with things like "request_send_spec" and "response_recv_spec"
based on this and see what I come up with. Thanks for the feedback.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-12 @ 19:37
On May 10, 2011 03:36:06 PM Zed A. Shaw wrote:
> On Sun, May 08, 2011 at 10:35:31PM -0400, Henry Baragar wrote:
> > Does "Server" mean the mongrel2 web server or an application server? If
> > its the mongrel2 web server, shouldn't it be "Server.response_spec"?
> > That is, where to send the responses?
>
> I think the problem is one of perspective.
Yes.
> When I edit the
> mongrel2.conf I'm saying this in my head:
>
> "Time to update the Mongrel2 web server so that it knows where
> everything is and can work based on what it has inside."
>
Correct me if I am wrong, but I believe that this is the perspective of the
web server developer (i.e. Zed) and of the handler developer. You are
interested in the precise details of how the information moves around. I
would hope that there are no more than a few dozen of you in the world.
> But it seems like when you edit mongrel2.conf you are thinking:
>
> "Time to update the Handler configuration that Mongrel2 uses to talk to
> my handlers."
>
And this I believe is the perspective of web application developers and system
administrators. There should be hundreds or thousands of us:-) We don't
paticularly care how the information flows, we just want to know "which end of
what gets plugged into what". We want as dumb and foolproof mechanism to plug
our applications into the web server. The simplist would be if we had the
same name on both sides: "black" connects to "black" and "white" connects to
"white" (or that "green" and "red"). We get all confused, and bad things
happen, when you give us two "male" pieces and two "female" pieces, and we are
not entirely clear where those pieces are, nor what they do, and you tell us
that we have plug one into the other:-)
> I'll play with things like "request_send_spec" and "response_recv_spec"
> based on this and see what I come up with.
How about:
http_request_queue
http_response_queue
These variables would have the same content on both the mongrel server and the
application servers. I think that this gets across the idea that we are
dealing with http requests and responses (not zmq ones), and that we are
dealing with a zmq queue (if we know that zmq is the implementation
technology).
Note that, based on the response to the question I asked on the zmq mailing,
the socket identity string does need to be unique across queues. That is, a
global "http_server_identity" variable could be used to sent the identity of
all the sockets on the mongrel2 server, simplifying the config file even
further.
> Thanks for the feedback.
You probably just got more feedback than you bargained for;-)
Cheers,
Henry
--
Henry Baragar
Instantiated Software
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-13 @ 15:27
On Thu, May 12, 2011 at 03:37:55PM -0400, Henry Baragar wrote:
> Correct me if I am wrong, but I believe that this is the perspective of the
> web server developer (i.e. Zed) and of the handler developer. You are
> interested in the precise details of how the information moves around. I
> would hope that there are no more than a few dozen of you in the world.
No, here you are wrong. When you use *any* client server system, you
need to know how to setup the server, and how to connect to it with the
client. That means, when you configure the server, you configured it as
the *server*, not as any potential clients. In this case, Mongrel2
needs to be configured from Mongrel2's perspective.
> And this I believe is the perspective of web application developers and system
> administrators.
And again, no, this perspective is just flat wrong. If you're
configuring a web server then you configure the web server, not
configure the web server like it's a browser. It has nothing to do
with exposing the internals of Mongrel2 so you have to be me. It has to
do with the server just won't work if you don't configure it right with
the OS. If you're trying to make it look like a Handler config, then
there's about 90% of the config that won't make sense at all.
Here's an example. Let's say you have 10 virtual hosts you're setting
up in Mongrel2. Alright, no one handler needs this configuration
information, so if the mongrel2.conf is configured from the handler's
viewpoint then ... uh .. ok where do you put Host routing? How about
the external port to the internet and the ipaddress to bind? Browsers
don't care about that so .. uh .. ok how do you configure internal bind
ports from a browser's perspective?
How about directories? Handlers and browsers don't care about how a URL
maps to the OS files system layout, so, again there's no way to make a
"config the dirs like it's a handler" system.
I'd also say that, the mongrel2 config file goes above and beyond the
call of duty to give you nearly this exact feature. I mean, the routing
looks exactly like every web app routing system.
At a certain point though, people just need to read the docs and get it
right. It's a web server, and you're using sockets. Trying to bikeshed
ever more clever ways to make it so programmers don't have to read a
very well written manual just isn't going to work.
Finally, I'm not saying the wording can't be improved, I'm just saying
it's stupid to change it so that it's always from the Handler's
perspective (which cuts out browsers, flash sockets, the OS, filesystem,
and Mongrel2 itself).
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Javier Guerra Giraldez
- Date:
- 2011-05-09 @ 14:39
On Sun, May 8, 2011 at 9:35 PM, Henry Baragar
<Henry.Baragar@instantiated.ca> wrote:
> Consider:
>
> mongrel2 server on 10.0.0.1
> app_1 on 10.0.1.1 and 10.0.1.2
> app_2 on 10.0.2.1
>
> I would expect the mongrel2 configuration to be:
>
> app_1_handler = Handler (request_spec = 'tcp://10.0.0.1;9001'. ...)
>
> app_2_handler = Handler (request_spec = 'tcp://10.0.0.1;9002'. ...)
>
> main = Server(
>
> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
>
> ....
>
> response_spec='tcp://127.0.0.1:9000',
>
> )
>
> where the server binds a push zmq_socket on 9001 & 9002, and binds a sub
> zmq_socket on 9000.
>
> Then environment variables for App_1 on 10.0.1.1:
>
> REQUEST_SPEC='tcp://10.0.0.1;9001'
>
> REQUEST_IDENT='app_1-uuid'
>
> RESPONSE_SPEC='tcp://127.0.0.1:9000'
>
> RESPONSE_IDENT="2f62bd5-9e59-49cd-993c-3b6013c28f05"
that's exactly how i would like it to be!
--
Javier
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Loic d'Anterroches
- Date:
- 2011-05-09 @ 14:52
On 05/09/2011 04:39 PM, Javier Guerra Giraldez wrote:
> On Sun, May 8, 2011 at 9:35 PM, Henry Baragar
> <Henry.Baragar@instantiated.ca> wrote:
>> Consider:
>>
>> mongrel2 server on 10.0.0.1
>> app_1 on 10.0.1.1 and 10.0.1.2
>> app_2 on 10.0.2.1
>>
>> I would expect the mongrel2 configuration to be:
>>
>> app_1_handler = Handler (request_spec = 'tcp://10.0.0.1;9001'. ...)
>> app_2_handler = Handler (request_spec = 'tcp://10.0.0.1;9002'. ...)
>>
>> main = Server(
>>
>> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
>>
>> ....
>>
>> response_spec='tcp://127.0.0.1:9000',
>>
>> )
>>
>> where the server binds a push zmq_socket on 9001& 9002, and binds a sub
>> zmq_socket on 9000.
>>
>> Then environment variables for App_1 on 10.0.1.1:
>>
>> REQUEST_SPEC='tcp://10.0.0.1;9001'
>>
>> REQUEST_IDENT='app_1-uuid'
>>
>> RESPONSE_SPEC='tcp://127.0.0.1:9000'
>>
>> RESPONSE_IDENT="2f62bd5-9e59-49cd-993c-3b6013c28f05"
If app1 is running on another system than Mongrel2 as per your
description, a response on 127.0.0.1 will never reach Mongrel2.
Isn't it this:
RESPONSE_SPEC='tcp://10.0.0.1:9000'
what you had in mind?
loïc
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-09 @ 16:02
On May 9, 2011 10:52:28 AM Loic d'Anterroches wrote:
> On 05/09/2011 04:39 PM, Javier Guerra Giraldez wrote:
> > On Sun, May 8, 2011 at 9:35 PM, Henry Baragar
> >
> > <Henry.Baragar@instantiated.ca> wrote:
> >> Consider:
> >>
> >> mongrel2 server on 10.0.0.1
> >> app_1 on 10.0.1.1 and 10.0.1.2
> >> app_2 on 10.0.2.1
> >>
> >> I would expect the mongrel2 configuration to be:
> >>
> >> app_1_handler = Handler (request_spec = 'tcp://10.0.0.1;9001'. ...)
> >> app_2_handler = Handler (request_spec = 'tcp://10.0.0.1;9002'. ...)
> >>
> >> main = Server(
> >>
> >> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
> >>
> >> ....
> >>
> >> response_spec='tcp://127.0.0.1:9000',
> >>
> >> )
> >>
> >> where the server binds a push zmq_socket on 9001& 9002, and binds a sub
> >> zmq_socket on 9000.
> >>
> >> Then environment variables for App_1 on 10.0.1.1:
> >>
> >> REQUEST_SPEC='tcp://10.0.0.1;9001'
> >>
> >> REQUEST_IDENT='app_1-uuid'
> >>
> >> RESPONSE_SPEC='tcp://127.0.0.1:9000'
> >>
> >> RESPONSE_IDENT="2f62bd5-9e59-49cd-993c-3b6013c28f05"
>
> If app1 is running on another system than Mongrel2 as per your
> description, a response on 127.0.0.1 will never reach Mongrel2.
>
> Isn't it this:
>
> RESPONSE_SPEC='tcp://10.0.0.1:9000'
>
> what you had in mind?
>
Yes.
> loïc
--
Henry Baragar
Instantiated Software
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Hedge Hog
- Date:
- 2011-05-09 @ 21:19
On Tue, May 10, 2011 at 2:02 AM, Henry Baragar
<Henry.Baragar@instantiated.ca> wrote:
> On May 9, 2011 10:52:28 AM Loic d'Anterroches wrote:
>
>> On 05/09/2011 04:39 PM, Javier Guerra Giraldez wrote:
>
>> > On Sun, May 8, 2011 at 9:35 PM, Henry Baragar
>
>> >
>
>> > <Henry.Baragar@instantiated.ca> wrote:
>
>> >> Consider:
>
>> >>
>
>> >> mongrel2 server on 10.0.0.1
>
>> >> app_1 on 10.0.1.1 and 10.0.1.2
>
>> >> app_2 on 10.0.2.1
>
>> >>
>
>> >> I would expect the mongrel2 configuration to be:
>
>> >>
>
>> >> app_1_handler = Handler (request_spec = 'tcp://10.0.0.1;9001'. ...)
>
>> >> app_2_handler = Handler (request_spec = 'tcp://10.0.0.1;9002'. ...)
>
>> >>
>
>> >> main = Server(
>
>> >>
>
>> >> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
>
>> >>
>
>> >> ....
>
>> >>
>
>> >> response_spec='tcp://127.0.0.1:9000',
>
>> >>
>
>> >> )
>
>> >>
>
>> >> where the server binds a push zmq_socket on 9001& 9002, and binds a sub
>
>> >> zmq_socket on 9000.
>
>> >>
>
>> >> Then environment variables for App_1 on 10.0.1.1:
>
>> >>
>
>> >> REQUEST_SPEC='tcp://10.0.0.1;9001'
>
>> >>
>
>> >> REQUEST_IDENT='app_1-uuid'
>
>> >>
>
>> >> RESPONSE_SPEC='tcp://127.0.0.1:9000'
>
>> >>
>
>> >> RESPONSE_IDENT="2f62bd5-9e59-49cd-993c-3b6013c28f05"
>
>>
>
>> If app1 is running on another system than Mongrel2 as per your
>
>> description, a response on 127.0.0.1 will never reach Mongrel2.
>
>>
>
>> Isn't it this:
>
>>
>
>> RESPONSE_SPEC='tcp://10.0.0.1:9000'
>
>>
>
>> what you had in mind?
>
>>
>
> Yes.
Have I misunderstood, but it seems in this case more
descriptive/accurate names would be:
REQUESTOR_ID
RESPONDER_ID
Possibly nitpicking:
now it is unlear to me whether the spec names should indicate that
they belong to the resquestor/responder, or the requestS/responseS.
Or are they always the same thing?
I'm pretty sure they are not one off specs, i.e. request_spec/reponse_spec
Best wishes
>
>> loïc
>
> --
>
> Henry Baragar
>
> Instantiated Software
>
--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Henry Baragar
- Date:
- 2011-05-09 @ 22:15
On May 9, 2011 05:19:22 PM Hedge Hog wrote:
> On Tue, May 10, 2011 at 2:02 AM, Henry Baragar
>
> <Henry.Baragar@instantiated.ca> wrote:
> > On May 9, 2011 10:52:28 AM Loic d'Anterroches wrote:
> >> On 05/09/2011 04:39 PM, Javier Guerra Giraldez wrote:
> >> > On Sun, May 8, 2011 at 9:35 PM, Henry Baragar
> >> >
> >> > <Henry.Baragar@instantiated.ca> wrote:
> >> >> Consider:
> >> >>
> >> >>
> >> >>
> >> >> mongrel2 server on 10.0.0.1
> >> >>
> >> >> app_1 on 10.0.1.1 and 10.0.1.2
> >> >>
> >> >> app_2 on 10.0.2.1
> >> >>
> >> >>
> >> >>
> >> >> I would expect the mongrel2 configuration to be:
> >> >>
> >> >>
> >> >>
> >> >> app_1_handler = Handler (request_spec = 'tcp://10.0.0.1;9001'. ...)
> >> >>
> >> >> app_2_handler = Handler (request_spec = 'tcp://10.0.0.1;9002'. ...)
> >> >>
> >> >>
> >> >>
> >> >> main = Server(
> >> >>
> >> >>
> >> >>
> >> >> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
> >> >>
> >> >>
> >> >>
> >> >> ....
> >> >>
> >> >>
> >> >>
> >> >> response_spec='tcp://127.0.0.1:9000',
> >> >>
> >> >>
> >> >>
> >> >> )
> >> >>
> >> >>
> >> >>
> >> >> where the server binds a push zmq_socket on 9001& 9002, and binds a
> >> >> sub
> >> >>
> >> >> zmq_socket on 9000.
> >> >>
> >> >>
> >> >>
> >> >> Then environment variables for App_1 on 10.0.1.1:
> >> >>
> >> >>
> >> >>
> >> >> REQUEST_SPEC='tcp://10.0.0.1;9001'
> >> >>
> >> >>
> >> >>
> >> >> REQUEST_IDENT='app_1-uuid'
> >> >>
> >> >>
> >> >>
> >> >> RESPONSE_SPEC='tcp://127.0.0.1:9000'
> >> >>
> >> >>
> >> >>
> >> >> RESPONSE_IDENT="2f62bd5-9e59-49cd-993c-3b6013c28f05"
> >>
> >> If app1 is running on another system than Mongrel2 as per your
> >>
> >> description, a response on 127.0.0.1 will never reach Mongrel2.
> >>
> >>
> >>
> >> Isn't it this:
> >>
> >>
> >>
> >> RESPONSE_SPEC='tcp://10.0.0.1:9000'
> >>
> >>
> >>
> >> what you had in mind?
> >
> > Yes.
>
> Have I misunderstood, but it seems in this case more
> descriptive/accurate names would be:
>
> REQUESTOR_ID
> RESPONDER_ID
>
> Possibly nitpicking:
> now it is unlear to me whether the spec names should indicate that
> they belong to the resquestor/responder, or the requestS/responseS.
> Or are they always the same thing?
> I'm pretty sure they are not one off specs, i.e. request_spec/reponse_spec
>
If I understand correctly, you are thinking in lower level zeromq terms, in
which case you would be correct.
But I am arguing that the terminology should reflect the higher level
meanings. When I write or configure an application that sits behind a
Mongrel2 server, I want to know where to get the data from an HTTP request and
where to send the data that will form the HTTP response. Hence my proposal to
use REQUEST_SPEC and RESPONSE_SPEC, respectively.
By the way, I am not sure that I understand the reason for Mongrel2 specifying
named ports. I wonder what functionality they provide over anonymous ones.
Regards,
Henry
> Best wishes
>
> >> loïc
> >
> > --
> >
> > Henry Baragar
> >
> > Instantiated Software
--
Henry Baragar
Instantiated Software
Re: [mongrel2] Proposed Change To Handler Config
- From:
- James Dennis
- Date:
- 2011-05-08 @ 22:48
I think that "request" and "response" could get confused with the zmq
req/rep socket types.
On Sunday, May 8, 2011, Henry Baragar <Henry.Baragar@instantiated.ca> wrote:
>
>
> On May 8, 2011 05:35:36 PM Zed A. Shaw wrote:
>> On Sun, May 08, 2011 at 03:21:54PM -0400, Henry Baragar wrote:
>> > I just confirmed that the perl handler has this backwards (hence my
>> > confusion).
>>
>> You got a link to the perl handler code that's got it wrong?
>
>
>
https://github.com/lestrrat/Plack-Handler-Mongrel2/blob/master/lib/Plack/Handler/Mongrel2.pm
>
>
> Look at lines 209 & 220.
>
>
>>
>> > > How about: handler_spec and server_spec instead? That makes more
>> > > sense if there's just one server socket also.
>> >
>> > This is much clearer than (send/recv), but "server" could just as well
>> > refer to the application server behind the web server.
>>
>> Actually, now that I'm playing with it just calling it the "send_addr" is
>> better in both side. Try it out:
>>
>> Handler.send_addr == The handler will send on this address with PUB.
>> Server.send_addr == Mongrel2 will send on this address with PUSH.
>>
>
>
> That works well inside the application, but not in config files.
>
>
> Consider the config file for a perl application:
> plackup -s Mongrel2 \
> --max_workers=10 \
> --max_reqs_per_child=1000 \
> --send_spec=tcp://127.0.0.1:9999 \
> --send_ident=D807E984-AC0B-11DF-979C-3C4975AD5E34 \
> --recv_spec=tcp://127.0.0.1:9998 \
> --recv_ident=E80576A8-AC0B-11DF-A841-3D4975AD5E34
>
>
> Consider the following environment variables for Ruby:
> RACK_MONGREL2_RECV
> RACK_MONGREL2_SEND
>
>
> Consider the python:
> app = Brubeck((pull_addr, pub_addr), handler_tuples)
>
>
> Now PHP:
> public function __construct($sender_id, $sub_addr, $pub_addr)
>
>
> If all one does is look at an example config file (which often is the
case), then none of these examples are very good at communicating the
intent of the connections.
>
>
> Maybe we are looking at the issue from the wrong angle! Maybe they should be:
> request_spec
> response_spec
> That is, there are two services being offered: one to get resquests and
one for the responses. I think this will be a lot more obvious to
everyone involved.
>
> Henry
>
>
>
>
>> Anyway I'll come up with something if I do this, but at a certain point
>> you just have to get people to read and get it right. I think you got
>> hit by the perl handler getting it wrong which probably confused you.
>
> --
> Henry Baragar
> Instantiated Software
>
>
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Karl Ostendorf
- Date:
- 2011-05-08 @ 17:27
Hi Zed,
So, if handlers only open a PUB socket over which to send responses,
how do they receive requests? Do they also open up a SUB socket on the
same address as the server? Confused.
Karl Ostendorf
http://ostendorf.com
On Sun, May 8, 2011 at 18:39, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> Hey Everyone,
>
> I'm going to fix up the manual today and push out a 1.6 release of
> Mongrel2. While working on this release, I realized that we could
> simplify the configuration and improve reloading if I made this change:
>
> There is just one SUB socket, defined on the Server, then each Handler
> has a PUB socket.
>
> That means the config would be more like this:
>
> handler_test = Handler(send_spec='tcp://127.0.0.1:9997',
> send_ident='34f9ceee-cd52-4b7f-b197-88bf2f0ec378')
>
> main = Server(
> uuid="2f62bd5-9e59-49cd-993c-3b6013c28f05",
> ....
> recv_spec='tcp://127.0.0.1:9996',
> recv_ident=''
> )
>
> This would simplify the configuration, and internally the reloads
> wouldn't have to deal with more than one recv socket. More importantly,
> this is how things turned out to actually work, since you can pretty
> much just send to any of the SUB sockets at a server because they're all
> stateless.
>
> Downside is people's configurations have to change, and any frameworks
> autoloading the config out of the database would have to update (Tir) is
> like this.
>
> So, thoughts on this change?
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>
Re: [mongrel2] Proposed Change To Handler Config
- From:
- Zed A. Shaw
- Date:
- 2011-05-08 @ 18:51
On Sun, May 08, 2011 at 07:27:49PM +0200, Karl Ostendorf wrote:
> Hi Zed,
>
> So, if handlers only open a PUB socket over which to send responses,
> how do they receive requests? Do they also open up a SUB socket on the
> same address as the server? Confused.
Handlers still open both, they just open the same PUB socket for each
server.
--
Zed A. Shaw
http://zedshaw.com/