[Glass] Nginx , FastCGI and GLASS problem
Mariano Martinez Peck
marianopeck at gmail.com
Mon Nov 25 18:55:09 PST 2013
Thanks John,
Yes, I saw his post. I am using a similar configuration. Just a few minutes
ago, I shut down GemStone, start everything again from scratch and somehow
it seems to work correct now.
So I don't know what happened hahhaa.
btw... I noticed these lines:
location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|svg)$ {
add_header Access-Control-Allow-Origin "*";
expires max;
add_header Cache-Control "public, must-revalidate,
proxy-revalidate";
add_header Pragma public;
}
I wanted to add that but there is a problem...if the file (say a css) is
not found in the server (try_files failes), then the request is not
forwarded to fast_cgi so the file is not loaded at all.
Is there a way to fallback to /files and use FileLibraries in case those
fails? or is it better for production systems to remove the app under
/files and be sure everything is served by the web server?
Thanks!
On Mon, Nov 25, 2013 at 11:18 PM, John McIntosh <
johnmci at smalltalkconsulting.com> wrote:
> Ok well Paul had this which is different from your setup.
> I've an apache setup, but going to migrate to nginx as we use it
> everywhere else.
>
>
> upstream seaside {
> server localhost:9001;
> server localhost:9002;
> server localhost:9003;
> }
>
>
> server {
> listen 80 default_server;
> server_name www.example.com example.com;
> root /var/www/www.example.com;
>
> gzip on;
> gzip_disable "msie6";
> gzip_static on;
> gzip_vary on;
> gzip_proxied any;
> gzip_comp_level 6;
> gzip_buffers 16 8k;
> gzip_http_version 1.1;
> gzip_types text/plain text/css application/json
> application/x-javascript text/xml application/xml application/xml+rss
> text/javascript image/svg+xml;
>
>
>
> location @fastCgi {
> include fastcgi_params;
> fastcgi_pass seaside;
> }
>
> location / {
> try_files $uri @fastCgi;
> }
>
> location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|svg)$ {
> add_header Access-Control-Allow-Origin
> http://www.example.com <http://www.getcooperation.com/> ;
> expires max;
> add_header Cache-Control "public, must-revalidate,
> proxy-revalidate";
> add_header Pragma public;
> }
> }
>
>
> On Mon, Nov 25, 2013 at 8:46 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> HI john,
>>
>> Thanks for the suggestion. I have commented those lines but still same
>> problem :(
>>
>> I attach an screenshot of the web developer. As you can see, there is a
>> GET and a POST. The post takes always 1 minute.
>>
>> Sometimes the delay is in a GET, not a POST....
>>
>>
>>
>>
>> On Mon, Nov 25, 2013 at 10:02 PM, John McIntosh <
>> johnmci at smalltalkconsulting.com> wrote:
>>
>>>
>>> Ok well maybe it's the compression bug?
>>>
>>>
>>> WAFastCGIAdaptor>>responseFrom: ....
>>>
>>> -- comment out the Content-length attribute...
>>>
>>> "*** FastCGI 2.4.4 and 2.4.6 have a bug in which Content-length for
>>> compressed data
>>> is reported at the uncompressed length. This often causes significant
>>> delays while
>>> the client browser waits to get the remaining data. Although
>>> content-length should
>>> be supplied by the HTTP server to the client, the FastCGI solution is to
>>> drop it!
>>> See
>>> http://mailman.archlinux.org/pipermail/arch-commits/2009-September/061891.html
>>> .
>>> nextPutAll: 'Content-length: ';
>>> nextPutAll: contents size printString;
>>> nextPutAll: crlf;"
>>>
>>>
>>>
>>> On Mon, Nov 25, 2013 at 6:33 PM, Mariano Martinez Peck <
>>> marianopeck at gmail.com> wrote:
>>>
>>>> Also, when I see that 1-minute request in the browser development
>>>> tools, it appears like 2ms receiving, 1 minute waiting...weird!
>>>>
>>>>
>>>> On Mon, Nov 25, 2013 at 8:26 PM, Mariano Martinez Peck <
>>>> marianopeck at gmail.com> wrote:
>>>>
>>>>> HI guys. This is the first time I am trying to use FastCGI. For some
>>>>> reason, i have a timeout with fastCGI.
>>>>> I started the Gems either with:
>>>>>
>>>>>
>>>>> WAGemStoneRunSeasideGems default
>>>>> name: 'FastCGI';
>>>>> adaptorClass: WAFastCGIAdaptor;
>>>>> ports: #(9001 9002 9003).
>>>>> WAGemStoneRunSeasideGems restartGems.
>>>>>
>>>>> (from GemTools) or from command line:
>>>>>
>>>>> ./startSeaside_FastCGI 9001
>>>>>
>>>>> In either case, what happens is that I can browse my app
>>>>> http:localhost:9001/dp (and 9002 and 9003). But when I do a request to the
>>>>> server trough my FastCGI, it takes ONE MINUTE to load the page. I am using
>>>>> Nginx in the backend with this configuration:
>>>>>
>>>>> upstream seaside
>>>>> {
>>>>> server localhost:9001;
>>>>> server localhost:9002;
>>>>> server localhost:9003;
>>>>> }
>>>>>
>>>>> server
>>>>> {
>>>>>
>>>>> listen 33300;
>>>>> server_name localhost;
>>>>> root /var/www/glass/;
>>>>>
>>>>>
>>>>> access_log /var/log/nginx/fastCGI.log;
>>>>> error_log /var/log/nginx/error.log info;
>>>>>
>>>>> location /
>>>>> {
>>>>> try_files $uri @seaside;
>>>>> # error_page 403 404 = @seaside;
>>>>> }
>>>>>
>>>>> location @seaside
>>>>> {
>>>>> include fastcgi_params;
>>>>> fastcgi_pass seaside;
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> Using the webtools of the browser, I see that each time I go to a
>>>>> page, there is either a GET or a POST that takes exactly 1 minute. I
>>>>> mean...nothing happens, until one minute passes and then the page is
>>>>> rendered. The requests are small. And in fact, browsing directly to
>>>>> 9001/2/3 works perfectly. So I guess this is a one minute timeout of
>>>>> something.
>>>>>
>>>>> For what I can see, it could be related to the
>>>>>
>>>>> keepalive_timeout 65;
>>>>>
>>>>> And in nginx error.log I see something like:
>>>>>
>>>>> 2013/11/25 17:38:18 [error] 22835#0: *73 upstream timed out (60:
>>>>> Operation timed out) while reading response header from upstream, client:
>>>>> 127.0.0.1, server: localhost, request: "GET /dp HTTP/1.1", upstream:
>>>>> "fastcgi://127.0.0.1:9001", host: "localhost:33300"
>>>>> 2013/11/25 17:38:18 [info] 22835#0: *73 kevent() reported that client
>>>>> 127.0.0.1 closed keepalive connection
>>>>>
>>>>> Any ideas what could be wrong?
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> ===========================================================================
>>> John M. McIntosh <johnmci at smalltalkconsulting.com>
>>> Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
>>>
>>> ===========================================================================
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
> ===========================================================================
>
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131126/87513cf0/attachment-0001.html>
More information about the Glass
mailing list