[ANNOUNCE] uWSGI Go support

[Roberto De Ioris]

Hi everyone, the uWSGI support for the Go platform is available:

https://github.com/unbit/uwsgi-docs/blob/master/Go.rst

Docs are in a preliminary form, as the plugin exposes a lot of features that need to be tested.

Linux i386/x86_64 and OSX are supported while goroutines are (currently) supported only on Linux
(i am investigating why OSX explodes with them)

The relevant integration code is here:

https://github.com/unbit/uwsgi/blob/master/plugins/go/src/uwsgi/uwsgi.go

There are a bunch of different coding styles as i am just learning the language (i have spent weeks only on the implementation)
and i am trying to experiment a lot (so, sorry if something looks cryptic)

As suggested in this list, the default behaviour is using the http.DefaultServeMux handler, but you can override that
pretty easily.

A bunch of tests/examples are available here:

https://github.com/unbit/uwsgi/tree/master/t/go

I have not made relevant benchmarks as performances should not be touched by the presence (or non-presence) of the uWSGI stack, but i have done
a lot of profiling about memory usage (and that's why the docs kindly suggest you can run hundreds of goroutines per-process)

Suggestions are obviously wellcomed

Sorry for the noise ;)

--
Roberto De Ioris
http://unbit.it
JID: rob...@jabber.unbit.it

[Kevin Gillette]

In the docs, you list:

func main() {
        http.HandleFunc("/one/", oneHandler)
        http.HandleFunc("/two/", twoHandler)
        var u uwsgi.App
        uwsgi.Run(&u)
}

What's the use of uwsgi.App here? It doesn't seem to be given any configuration that could affect uwsgi, but rather just seems to be a token value you need to pass to satisfy the API. If that's true, and since uwsgi.Run takes a pointer or interface (I haven't yet looked into which -- doesn't really matter here, though), you may consider accepting nil for the common case.

[Roberto De Ioris]

I think i can completely get rid of that object/struct and simply export
the api as uwsgi package functions.

Regarding hooks i can move from defining a method of that object to
mapping a func as hook.

So instead of

func (app *App) PostFork() {
...
}

a user can do

func foobar() {
...
}

uwsgi.PostFork(foobar)

[Roberto De Ioris]

> Interesting, but not sure why I would step outside of net/http. To date,
I've found it surprisingly easy to work with.
>
> Not trying to nay-say, just at a loss on uwsgi's benefits. From a
gaining traction perspective, you might want to address the value-adds
learning and
> committing to uwsgi brings.

net/http is a simple http gateway to your app, it is not a so-called
application container.

uWSGI monitors your app, add realtime statistics, manages bad behaving
workers, external processes, advanced logging, offloading and so on...

just a simple example: how do you manage graceful reloads of your code
with net/http ?

[Roberto De Ioris]

Ok, i have extremely simplified the uwsgi.go package and uwsgi api access.

I have updated docs and examples too. Basically you now only need to call
uwsgi.Run() and if you want to access uwsgi api you just call uwsgi.*
functions, like uwsgi.CacheGet("foobar")

Many thanks for your advices

[Levi Cook]

Cool, that starts to clarify things. Can you point me towards a feature list for uWSGI? I probably just need to review it from a higher level than the code.

[Roberto De Ioris]

> Cool, that starts to clarify things. Can you point me towards a feature
> list for uWSGI? I probably just need to review it from a higher level than
> the code.
>
>

Currently we are porting all of the docs to readthedocs, so resources are
splitted. This is a list of (more or less) useful links (the first two are
the homepages)

https://uwsgi-docs.readthedocs.org/en/latest/index.html
http://projects.unbit.it/uwsgi/
http://projects.unbit.it/uwsgi/wiki/StatsServer
https://uwsgi-docs.readthedocs.org/en/latest/AlarmSubsystem.html
https://uwsgi-docs.readthedocs.org/en/latest/AttachingDaemons.html
http://projects.unbit.it/uwsgi/wiki/InternalRouting
https://uwsgi-docs.readthedocs.org/en/latest/Zerg.html

The logging docs has been practically destroyed during the porting so this
is a random list of some of the available loggers:

http://projects.unbit.it/uwsgi/wiki/SocketLogging
http://projects.unbit.it/uwsgi/wiki/ZeroMQLogging
http://projects.unbit.it/uwsgi/wiki/RedisLogging
http://projects.unbit.it/uwsgi/wiki/MongoDBLogging

I hope it is enough to attract you ;)

[André Moraes]

From your doc's, you don't have a way to pass a specifc handler to the
uwsgi app, and then you must always use the http.DefaultServeMux.

Allowing the user to pass an specific handler would be more in-line
with the CGI and FCGI implementation from the std-lib.

http://golang.org/pkg/net/http/fcgi/ for some inpiration.

--
André Moraes
http://amoraes.info

[Roberto De Ioris]

You can set it using

uwsgi.RequestHandler(func)

but i do not know if it is go-friendly

[Aram Hăvărneanu]

> just a simple example: how do you manage graceful reloads of your code
> with net/http ?

Pass a file descriptor between the old and new instance of your
process or use a proxy server in front.

--
Aram Hăvărneanu

[Roberto De Ioris]

Am i wrong, or is it something you have to develop in your code ?

Even the proxy 'technique' requires backend to graceful wait for running
requests and it has to not enqueue requests in the 'going down socket'
(and this is hard to obtain, even with advanced proxies like nginx, infact
uWSGI can use another level of proxy with a 'subscription system' to
bypass such a problem)

File descriptor passing (named Zerg-mode in uWSGI), is the solution i like
most, again something you get for free.

This is only a couple of example of the usage of an appplication server
container, but just to clarify things, it is not something everyone needs,
for simpler setups/deployment 'gateways' solutions are more than enough
(taking in account that Go has not all of the performance/slow startup
time
problems present in the other platforms)

[Aram Hăvărneanu]

> Am i wrong, or is it something you have to develop in your code ?

Yes, reusing a file descriptor from the old process require the code
was written with that in mind. The code is simple, though.

--
Aram Hăvărneanu

[André Moraes]

>
> uwsgi.RequestHandler(func)

If you change the type of the parameter to accept a http.Handler
instead of http.HandlerFunc it will work just like the std lib
CGI/FCGI packages.

Then, if the user want to pass a function, he just need to convert
using http.HandlerFunc(func)

[Roberto De Ioris]

Il giorno 07/nov/2012, alle ore 15:38, André Moraes <and...@gmail.com> ha scritto:

>>
>> uwsgi.RequestHandler(func)
>
> If you change the type of the parameter to accept a http.Handler
> instead of http.HandlerFunc it will work just like the std lib
> CGI/FCGI packages.
>
> Then, if the user want to pass a function, he just need to convert
> using http.HandlerFunc(func)
>

ok, i have added uwsgi.Handler(http.Handler)

(RequestHandler() takes the old form)

Thanks again

--
Roberto De Ioris
http://unbit.it

JID: rob...@jabber.unbit.it