http socket port auto-assignment is broken and attempts to actually use :0 or 0.0.0.0:0

[gdahlm]

In at least the latest commit 8e3c127e0944d8d133eaba46fe9c7c9a23731a59 port auto-assignment no longer works for http protocol sockets but works for uwsgi sockets. This was functional in 2.0.7 and I am sorry but my C is too rusty to help find the source of the issue.

http = 0.0.0.0:0
http = :0

Both report the following in the logs.

Thu Oct  2 22:52:19 2014 - uWSGI http bound on 0.0.0.0:0 fd 6
Thu Oct  2 23:04:30 2014 - uWSGI http bound on :0 fd 5

uwsgi sockets still function as expected.

socket = 0.0.0.0:0
socket = :0

Thu Oct  2 22:54:09 2014 - uwsgi socket 0 bound to TCP address 0.0.0.0:34590 (port auto-assigned) fd 3
Thu Oct  2 23:01:52 2014 - uwsgi socket 0 bound to TCP address :41117 (port auto-assigned) fd 3

[unbit]

Unless i am missing something, the http router has no explicit support for random ports (it does not make too much sense). The http native support (--http-socket) should work as expected

[gdahlm]

It is useful when you are using http-subscription-server for named environments inside vassals though native HTTP. It is also the only way to get around #618 which will cause 513 response errors with rails session bootstrapping POSTs.

• Emperor

  • HTTP Router :8080 --http-subscription-server :3030
  • QA Env * http :0

       + app-less http route to qa.domain.com `--subscribe2 = server=127.0.0.1:3030`
       + app-less http route to css.domain.com `--subscribe2 = server=127.0.0.1:3030`

  • Dev Env * http :0

       + app-less http route to qa.domain.com `--subscribe2 = server=127.0.0.1:3030`
       + app-less http route to css.domain.com `--subscribe2 = server=127.0.0.1:3030`

Those vassals, which an be served behind the main http router may need the http router process to perform routing for those apps, but by allowing the use of random ports there removes the need to have a complex known port allocation system across CI/CD sites as they just subscribe.

[unbit]

So you have a three level proxy ?

http-router -> another http-router -> uwsgi instances ?

[gdahlm]

Kind of:

Basically fastrouter mount points are the end goal, but we are using the rados plugin for objects while using the same control point to point at both skinning asset (.css/.js) servers and an application cluster.

env.domain.com /app -> pool of external tomcat application servers. (served through an external load balancer until I can figure out url based persistence in uwsgi) /site -> www.domain.com site running drupal for skinning .css|.js|html assets /images -> uwsgi rados object store.

The need for the nested routers is to support dev and qa environments while taking advantage of the automatic port mapping of the subscription server.

Or in sudo code, per sub site:

route = ^/site http:%(asset.host):80/site,www.domain.com
route = ^/images uwsgi:,28,0
route = .* http:192.168.1.55:80,app.domain.com

[rdeioris]

So your need for the additional http router is for having "mountpoint subscriptions". The ideal setup would be:

HTTP router on port 8080, fastrouters subscribe to it with the domain as the key, each app subscribe to the fastrouter for a specific mountpoint (/app, /images and so on...).

The problem is that you cannot subscribe your fastrouter (or currently, the http router) with a random port.

Am i right ?

In addition to this, i am pretty sure this cannot work in 2.0 too, while in your opening message you said the opposite.

Regarding tomcat load balancing, what you mean for url-based persistence ? AFAIK for supporting the session subsystem of J2EE a iphash algorithm is the best (or better, working) approach