fastcgi configuration for 3.0?

Well, with much help from you nice folks here I have my application ported over to GS/SS 3.0 (1.0-beta.6) . I have a running set of GemTools in my Pharo 1.0 image, and everything works just fine when I fire up a WAGsSwazooAdaptor.  

/seaside is a redirect handler in Seaside 3.0. just for legacy.
host/seaside will redirect to host

On Sat, May 1, 2010 at 1:47 PM, Chris Curtis <[hidden email]> wrote:

::facepalm::  Yeah, that would explain that: "/seaside" is sent to fastcgi as "/seaside" which redirects to "/" -- which doesn't go to fastcgi.

I would do proxying. It gives you more control over the url space and
its much easier to debug.

But in general... do this:

have your front end server check to see if the file exists in the file system,
if not, hand it off to your dynamic server. if dynamic server can't handle,
it should send back a 404 which at least if you are proxying, you can
intercept and deal with however you want.

Back to the debug issue with fast cgi.

If I dont know if my frontend or backend is having an issue with proxying, i can
ssh into my box and fire up lynx and point it at a backend url and see
if it works
cutting out the front end. fast cgi, that isnt anywhere near as easy.

if you want help with setting up nginx for proxying, let me know.

On Sun, May 2, 2010 at 11:38 AM, Chris Curtis <[hidden email]> wrote:

So you prefer proxying to the Swazoo adaptor rather than FastCGI? Are there any *disadvantages* to that approach? 

On Sun, May 2, 2010 at 1:31 PM, Chris Curtis <[hidden email]> wrote:
> So you prefer proxying to the Swazoo adaptor rather than FastCGI? Are there
> any *disadvantages* to that approach?

I havent really encountered any that I consider serious.
Fast cgi could be a + in certain situations where you are running
scripts that you dont want to fire up a process for each time,
but that doesnt apply in the Seaside case and even with languages
where it might, there are usually other solutions like mod_perl, mod_python etc.

That is afterall why fast cgi was developed, to cut down on the all the process
startup and shut down that was involved with cgi scripts.

Excellent... switched over to proxy/Swazoo and it's working quite well. I guess since my entire web development life has been Java-based, I've never really had to deal with CGI/FCGI, so it's good to know I still don't have to learn about it. :)

Yup. That proxies everything to seaside.

Some other settings you might be interested in:

If you want to be able to get client ip address in your seaside application
and other 'standard info'.

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;

Sets your timeout for the proxy:

proxy_read_timeout 90;

Intercept errors coming from proxy and handle in nginx:

proxy_intercept_errors on;

To remove the name of your application from uris, coming and going
if you want it to appear as the uri root:

proxy_redirect /MYAPP /;
rewrite ^/$ /MYAPP;

To serve static content from nginx while proxying to seaside:

location /
{
    try_files $uri $uri/ @MYAPP;
}

location @MYAPP
{
    proxy_pass http://gemstone;
}


On Sun, May 2, 2010 at 4:10 PM, Chris Curtis <[hidden email]> wrote:

+1. We've been reverse proxying using lighttpd for more than a year,
which has been working quite well. We've got some scripts that may
help: http://github.com/ottobehrens/gemstone-scripts

Chris,

I've attached the lighttpd.conf file that I've been using with Seaside2.8 and Seaside3.0 for awhile now (that doesn't use /seaside). The key piece is the following:

fastcgi.server    = (
        "/" =>
            (
                ("host" => "127.0.0.1","port" => 9001,"check-local" => "disable","mode" => "responder" ),
                ("host" => "127.0.0.1","port" => 9002,"check-local" => "disable","mode" => "responder" ),
                ("host" => "127.0.0.1","port" => 9003,"check-local" => "disable","mode" => "responder" ),
            ),
)

In regards to a wiki, check out:

  http://code.google.com/p/glassdb/

I've hosted the external issue-tracking for GLASS on that site for awhile, but for the imminent:) 1.0-beta.8 release, I'm breathing additional life into the site. Over the weekend I transferred a large chunk of the "Terse Guide To GemTools" to the site (with screen shots updated to match the imminent:) 1.0-beta.6 release):

  http://code.google.com/p/glassdb/wiki/GemTools

I have plans to transfer more of the documentation that is spread out over my blog to the site and I invite other folks to contribute content.

Much of the push for 1.0-beta.8 is devoted to opening up the development process (as well as the documentation) so that it is easier for developers to contribute.

Dale
----- "Chris Curtis" <[hidden email]> wrote:

| ::facepalm::  Yeah, that would explain that: "/seaside" is sent to
| fastcgi
| as "/seaside" which redirects to "/" -- which doesn't go to fastcgi.
|
| Unfortunately all the deployment examples I could find use the
| virtual
| location "/seaside" to point to the fastcgi server. Though in thinking
| about
| it, I'm not entirely clear on how that ever worked.
|
| I'm not sure it belongs solely in the GS/SS documentation, but if
| there's
| going to be a wiki page for deployment recipes I'll be glad to add my
| configuration notes for nginx, cherokee, and lighttpd. (You're on your
| own
| for apache.... )
|
| --chris