Internal Server Error when Seaside request takes too long?
Locked
Internal Server Error when Seaside request takes too long?
 
|
Hi Everybody!
I'm new at GLASS and I'm starting to face some newbie problems :P So here I'm am with some newbie questions. One of the sections of the Seaside application I'm working on is supposed to show an anual report (imagine... the amount of money a person earns each month of the year). This anual report may be short or longer depending on how many persons I want to see on it (imagine this anual report repeated for person A, B, C, etc.), therefore, the Seaside request to show it can take more or less time to respond.
The thing is that unless it's really short (just applied to one person), I always get Internal Server Error. It's not a logic / modelling problem, I discarded that. If I put a halt after the rendering of each person report and resume, the report gets to the end and it's shown entirely. So I think it may be a GLASS configuration issue that doesn't let me have long requests or something like that. Does that make sense?
The GLASS gems and stone have the default configuration. In the logs I see nothing that could help me. Esteban told me that maybe changing Hyper to FastCGI could help, but before I try that I wanted to know if there is an easier / shorter way to solve this, maybe changing some parameters of a configuration. Does anyone have any advice on this?
Thanks in advance! Carla
|
Re: Internal Server Error when Seaside request takes too long?
|
|
How long can a request before you get the Internal Server Error?
What if anything is in the webserver logs? On Tue, Feb 23, 2010 at 1:09 PM, Carla F. Griggio <[hidden email]> wrote: > Hi Everybody! > I'm new at GLASS and I'm starting to face some newbie problems :P So here > I'm am with some newbie questions. > One of the sections of the Seaside application I'm working on is supposed to > show an anual report (imagine... the amount of money a person earns each > month of the year). This anual report may be short or longer depending on > how many persons I want to see on it (imagine this anual report repeated for > person A, B, C, etc.), therefore, the Seaside request to show it can take > more or less time to respond. > The thing is that unless it's really short (just applied to one person), I > always get Internal Server Error. > It's not a logic / modelling problem, I discarded that. If I put a halt > after the rendering of each person report and resume, the report gets to the > end and it's shown entirely. So I think it may be a GLASS configuration > issue that doesn't let me have long requests or something like that. Does > that make sense? > The GLASS gems and stone have the default configuration. In the logs I see > nothing that could help me. > Esteban told me that maybe changing Hyper to FastCGI could help, but before > I try that I wanted to know if there is an easier / shorter way to solve > this, maybe changing some parameters of a configuration. Does anyone have > any advice on this? > Thanks in advance! > Carla |
Re: Internal Server Error when Seaside request takes too long?
|
|
Between 25 and 50 seconds (I counted lots of times :S mostly it takes
around 50 seconds). By webserver you mean the apache? I checked seaside.log, nothing there. On Tuesday, February 23, 2010, Sean Allen <[hidden email]> wrote: > How long can a request before you get the Internal Server Error? > > What if anything is in the webserver logs? > > > On Tue, Feb 23, 2010 at 1:09 PM, Carla F. Griggio > <[hidden email]> wrote: >> Hi Everybody! >> I'm new at GLASS and I'm starting to face some newbie problems :P So here >> I'm am with some newbie questions. >> One of the sections of the Seaside application I'm working on is supposed to >> show an anual report (imagine... the amount of money a person earns each >> month of the year). This anual report may be short or longer depending on >> how many persons I want to see on it (imagine this anual report repeated for >> person A, B, C, etc.), therefore, the Seaside request to show it can take >> more or less time to respond. >> The thing is that unless it's really short (just applied to one person), I >> always get Internal Server Error. >> It's not a logic / modelling problem, I discarded that. If I put a halt >> after the rendering of each person report and resume, the report gets to the >> end and it's shown entirely. So I think it may be a GLASS configuration >> issue that doesn't let me have long requests or something like that. Does >> that make sense? >> The GLASS gems and stone have the default configuration. In the logs I see >> nothing that could help me. >> Esteban told me that maybe changing Hyper to FastCGI could help, but before >> I try that I wanted to know if there is an easier / shorter way to solve >> this, maybe changing some parameters of a configuration. Does anyone have >> any advice on this? >> Thanks in advance! >> Carla > |
Re: Internal Server Error when Seaside request takes too long?
|
|
Such long requests should run as a background job
e.g. using a topaz script. If the job has finished you could automatically provide a link to get report. Gerhard On Wed, Feb 24, 2010 at 3:36 AM, Carla F. Griggio <[hidden email]> wrote: Between 25 and 50 seconds (I counted lots of times :S mostly it takes |
Re: Internal Server Error when Seaside request takes too long?
|
|
In reply to this post by Carla F. Griggio
On Tue, Feb 23, 2010 at 9:36 PM, Carla F. Griggio
<[hidden email]> wrote: > Between 25 and 50 seconds (I counted lots of times :S mostly it takes > around 50 seconds). > That is a fairly short period of time. > By webserver you mean the apache? depends on your particular setup. > > I checked seaside.log, nothing there. Is the internal server error from apache or from hyper? I'm assuming apache in which case, there would be a record of it in the logs. |
Re: Internal Server Error when Seaside request takes too long?
|
|
On Wed, Feb 24, 2010 at 6:40 AM, Sean Allen <[hidden email]> wrote:
> On Tue, Feb 23, 2010 at 9:36 PM, Carla F. Griggio > <[hidden email]> wrote: >> Between 25 and 50 seconds (I counted lots of times :S mostly it takes >> around 50 seconds). >> > > That is a fairly short period of time. > additional question, is this in testing with a single user or in a live multiple user environment? |
Re: Internal Server Error when Seaside request takes too long?
|
|
Single user.
The error in the Apache logs seems to look like this: glass-error.log: [Tue Feb 23 21:14:49 2010] [info] [client 192.168.167.1] (32)Broken pipe: core_output_filter: writing data to the network
glass-vhost-8081-error.log: [Tue Feb 23 21:51:41 2010] [error] [client 127.0.0.1] (111)Connection refused: FastCGI: failed to connect to server "/opt/gemstone/apache/htdocs/glass1/seaside": connect() failed, referer: http://192.168.167.130/seaside/SueldosEducacionGlass?_s=vHYcSpqBdfb3ZhLg&_k=jVw14Q6V
[Tue Feb 23 21:51:41 2010] [error] [client 127.0.0.1] FastCGI: incomplete headers (0 bytes) received from server "/opt/gemstone/apache/htdocs/glass1/seaside", referer: http://192.168.167.130/seaside/SueldosEducacionGlass?_s=vHYcSpqBdfb3ZhLg&_k=jVw14Q6V
[Tue Feb 23 22:19:06 2010] [error] [client 127.0.0.1] FastCGI: comm with server "/opt/gemstone/apache/htdocs/glass1/seaside" aborted: idle timeout (30 sec), referer: http://192.168.167.130/seaside/SueldosEducacionGlass?_s=Cxhix2uB8TJJjMoN&_k=k8sVurOP
[Tue Feb 23 22:19:06 2010] [error] [client 127.0.0.1] FastCGI: incomplete headers (0 bytes) received from server "/opt/gemstone/apache/htdocs/glass1/seaside", referer: http://192.168.167.130/seaside/SueldosEducacionGlass?_s=Cxhix2uB8TJJjMoN&_k=k8sVurOP
Gerhard, thanks for the suggestion, but though its a report-like page, users will use it a lot and it will change very often, so I think it would be very unconfortable to do this with a background job.
If it helps, I can tell you that this didn't take this long when it was running on Pharo (we've been porting this from Pharo to GLASS for about a month). I think it took about 5 seconds to render the page, not much longer than that.
On Wed, Feb 24, 2010 at 9:41 AM, Sean Allen <[hidden email]> wrote:
|
Re: Internal Server Error when Seaside request takes too long?
|
|
On Wed, Feb 24, 2010 at 8:03 AM, Carla F. Griggio
<[hidden email]> wrote: > Single user. > The error in the Apache logs seems to look like this: > glass-error.log: > [Tue Feb 23 21:14:49 2010] [info] [client 192.168.167.1] (32)Broken pipe: > core_output_filter: writing data to the network > glass-vhost-8081-error.log: > [Tue Feb 23 21:51:41 2010] [error] [client 127.0.0.1] (111)Connection > refused: FastCGI: failed to connect to server > "/opt/gemstone/apache/htdocs/glass1/seaside": connect() failed, referer: > http://192.168.167.130/seaside/SueldosEducacionGlass?_s=vHYcSpqBdfb3ZhLg&_k=jVw14Q6V > [Tue Feb 23 21:51:41 2010] [error] [client 127.0.0.1] FastCGI: incomplete > headers (0 bytes) received from server > "/opt/gemstone/apache/htdocs/glass1/seaside", referer: > http://192.168.167.130/seaside/SueldosEducacionGlass?_s=vHYcSpqBdfb3ZhLg&_k=jVw14Q6V > [Tue Feb 23 22:19:06 2010] [error] [client 127.0.0.1] FastCGI: comm with > server "/opt/gemstone/apache/htdocs/glass1/seaside" aborted: idle timeout > (30 sec), referer: > http://192.168.167.130/seaside/SueldosEducacionGlass?_s=Cxhix2uB8TJJjMoN&_k=k8sVurOP > [Tue Feb 23 22:19:06 2010] [error] [client 127.0.0.1] FastCGI: incomplete > headers (0 bytes) received from server > "/opt/gemstone/apache/htdocs/glass1/seaside", referer: > http://192.168.167.130/seaside/SueldosEducacionGlass?_s=Cxhix2uB8TJJjMoN&_k=k8sVurOP Start by raising your fast cgi timeout which looks to be set at about 30 seconds right now. Set to say, 180 seconds. If the problem persists, post another log entry. |
|
|
In reply to this post by Carla F. Griggio
This problem happened to me a time ago... but what was in fact happening was: my app had an error somewhere, and that raises and exception, who also raises an exception (for a reason I don't remember), and therefore, the renderer was failing because it found an error when dispatching an error.
So, the problem is not the time the operation takes, but the error raised and a problem handling it. What I think you should try is to put a breakpoint on the error manager (I don't remember the class name, but Dale or James can help here :) ), and see what is the real error. Hope this helps... Cheers, Esteban pd: I'm sorry being so imprecise, but this happened time ago and I didn't take notes :(
El 24/02/2010, a las 10:03a.m., Carla F. Griggio escribió: Single user. |
Re: Internal Server Error when Seaside request takes too long?
|
|
Sean,
I don't know if I'm doing this right (sorry for my newbieness!), but this is what I've tried: I added FastCgiConfig -idle-timeout 180 in /opt/gemstone/apache/glass.conf, now it looks like this:
<IfModule mod_fastcgi.c> FastCgiExternalServer /opt/gemstone/apache/htdocs/glass1/seaside -host localhost:9001 -pass-header Authorization FastCgiExternalServer /opt/gemstone/apache/htdocs/glass2/seaside -host localhost:9002 -pass-header Authorization FastCgiExternalServer /opt/gemstone/apache/htdocs/glass3/seaside -host localhost:9003 -pass-header Authorization FastCgiConfig -idle-timeout 180 </IfModule> I restarted Apache, tried again and the exact same error still occurs, even the same logs saying "idle timeout 30 sec".
Esteban, as soon as I find where to put the breakpoint, I'll try that :P Thanks! On Wed, Feb 24, 2010 at 11:27 AM, Esteban Lorenzano <[hidden email]> wrote:
|
Re: Internal Server Error when Seaside request takes too long?
|
|
Well, apparently it was a problem of timeout.
The configuration of the fastcgi module in /opt/gemstone/apache/glass.conf worked this way: FastCgiExternalServer /opt/gemstone/apache/htdocs/glass1/seaside -host localhost:9001 -idle-timeout 300 -pass-header Authorization FastCgiExternalServer /opt/gemstone/apache/htdocs/glass2/seaside -host localhost:9002 -idle-timeout 300 -pass-header Authorization FastCgiExternalServer /opt/gemstone/apache/htdocs/glass3/seaside -host localhost:9003 -idle-timeout 300 -pass-header Authorization FastCgiConfig -idle-timeout 180 </IfModule> (I don't know if FastCgiConfig -idle-timeout 180 actually helped... I'll check that later). As I explained before, this was a report page where the same report-table was applied to several persons. Until 10 minutes ago it only worked for one person at a time, now it works with at least 5... but... it took 3:32 minutes to render. I think this page won't be used to look at more than 4 or 5 reports at a time, but... it's still quite a lot of time.
I think I'll try to optimize this anyway, as part of the Pharo-to-Glass port, so... be prepared for more newbie questions :P Thank you so so much!
Carla On Wed, Feb 24, 2010 at 12:57 PM, Carla F. Griggio <[hidden email]> wrote: Sean, |
|
|
Carla,
You might want to checkout James' post: http://programminggems.wordpress.com/2010/01/11/fastcgi-3/ There is a bug in Apache fastcgi that might be affecting you. Anyway, James' has patched the GLASS FastCGI package... Dale ----- "Carla F. Griggio" <[hidden email]> wrote: | Well, apparently it was a problem of timeout. | | The configuration of the fastcgi module in | /opt/gemstone/apache/glass.conf | worked this way: | | <IfModule mod_fastcgi.c> | FastCgiExternalServer /opt/gemstone/apache/htdocs/glass1/seaside | -host | localhost:9001 *-idle-timeout 300 *-pass-header Authorization | FastCgiExternalServer /opt/gemstone/apache/htdocs/glass2/seaside | -host | localhost:9002 *-idle-timeout 300* -pass-header Authorization | FastCgiExternalServer /opt/gemstone/apache/htdocs/glass3/seaside | -host | localhost:9003 *-idle-timeout 300 *-pass-header Authorization | FastCgiConfig -idle-timeout 180 | </IfModule> | | (I don't know if FastCgiConfig -idle-timeout 180 actually helped... | I'll | check that later). | | As I explained before, this was a report page where the same | report-table | was applied to several persons. Until 10 minutes ago it only worked | for one | person at a time, now it works with at least 5... but... it took 3:32 | minutes to render. I think this page won't be used to look at more | than 4 or | 5 reports at a time, but... it's still quite a lot of time. | | I think I'll try to optimize this anyway, as part of the | Pharo-to-Glass | port, so... be prepared for more newbie questions :P | | Thank you so so much! | | Carla | | | On Wed, Feb 24, 2010 at 12:57 PM, Carla F. Griggio | <[hidden email]>wrote: | | > Sean, | > | > I don't know if I'm doing this right (sorry for my *newbieness*!), | but | > this is what I've tried: | > | > I added FastCgiConfig -idle-timeout 180 in | > /opt/gemstone/apache/glass.conf, now it looks like this: | > | > <IfModule mod_fastcgi.c> | > FastCgiExternalServer | /opt/gemstone/apache/htdocs/glass1/seaside | > -host localhost:9001 -pass-header Authorization | > FastCgiExternalServer | /opt/gemstone/apache/htdocs/glass2/seaside | > -host localhost:9002 -pass-header Authorization | > FastCgiExternalServer | /opt/gemstone/apache/htdocs/glass3/seaside | > -host localhost:9003 -pass-header Authorization | > * FastCgiConfig -idle-timeout 180* | > </IfModule> | > | > I restarted Apache, tried again and the exact same error still | occurs, even | > the same logs saying "idle timeout 30 sec". | > | > Esteban, as soon as I find where to put the breakpoint, I'll try | that :P | > | > Thanks! | > | > On Wed, Feb 24, 2010 at 11:27 AM, Esteban Lorenzano | <[hidden email]>wrote: | > | >> This problem happened to me a time ago... but what was in fact | happening | >> was: my app had an error somewhere, and that raises and exception, | who also | >> raises an exception (for a reason I don't remember), and therefore, | the | >> renderer was failing because it found an error when dispatching an | error. | >> So, the problem is not the time the operation takes, but the error | raised | >> and a problem handling it. | >> What I think you should try is to put a breakpoint on the error | manager (I | >> don't remember the class name, but Dale or James can help here :) | ), and | >> see what is the real error. | >> Hope this helps... | >> | >> Cheers, | >> Esteban | >> | >> pd: I'm sorry being so imprecise, but this happened time ago and I | didn't | >> take notes :( | >> | >> El 24/02/2010, a las 10:03a.m., Carla F. Griggio escribió: | >> | >> Single user. | >> | >> The error in the Apache logs seems to look like this: | >> | >> *glass-error.log:* | >> [Tue Feb 23 21:14:49 2010] [info] [client 192.168.167.1] (32)Broken | pipe: | >> core_output_filter: writing data to the network | >> | >> *glass-vhost-8081-error.log:* | >> [Tue Feb 23 21:51:41 2010] [error] [client 127.0.0.1] | (111)Connection | >> refused: FastCGI: failed to connect to server | >> "/opt/gemstone/apache/htdocs/glass1/seaside": connect() failed, | referer: | >> | http://192.168.167.130/seaside/SueldosEducacionGlass?_s=vHYcSpqBdfb3ZhLg&_k=jVw14Q6V | >> [Tue Feb 23 21:51:41 2010] [error] [client 127.0.0.1] FastCGI: | incomplete | >> headers (0 bytes) received from server | >> "/opt/gemstone/apache/htdocs/glass1/seaside", referer: | >> | http://192.168.167.130/seaside/SueldosEducacionGlass?_s=vHYcSpqBdfb3ZhLg&_k=jVw14Q6V | >> | >> [Tue Feb 23 22:19:06 2010] [error] [client 127.0.0.1] FastCGI: comm | with | >> server "/opt/gemstone/apache/htdocs/glass1/seaside" aborted: idle | timeout | >> (30 sec), referer: | >> | http://192.168.167.130/seaside/SueldosEducacionGlass?_s=Cxhix2uB8TJJjMoN&_k=k8sVurOP | >> [Tue Feb 23 22:19:06 2010] [error] [client 127.0.0.1] FastCGI: | incomplete | >> headers (0 bytes) received from server | >> "/opt/gemstone/apache/htdocs/glass1/seaside", referer: | >> | http://192.168.167.130/seaside/SueldosEducacionGlass?_s=Cxhix2uB8TJJjMoN&_k=k8sVurOP | >> | >> | >> | >> | >> Gerhard, thanks for the suggestion, but though its a report-like | page, | >> users will use it a lot and it will change very often, so I think | it would | >> be very unconfortable to do this with a background job. | >> | >> If it helps, I can tell you that this didn't take this long when it | was | >> running on Pharo (we've been porting this from Pharo to GLASS for | about a | >> month). I think it took about 5 seconds to render the page, not | much longer | >> than that. | >> | >> | >> | >> On Wed, Feb 24, 2010 at 9:41 AM, Sean Allen | <[hidden email]>wrote: | >> | >>> On Wed, Feb 24, 2010 at 6:40 AM, Sean Allen | <[hidden email]> | >>> wrote: | >>> > On Tue, Feb 23, 2010 at 9:36 PM, Carla F. Griggio | >>> > <[hidden email]> wrote: | >>> >> Between 25 and 50 seconds (I counted lots of times :S mostly it | takes | >>> >> around 50 seconds). | >>> >> | >>> > | >>> > That is a fairly short period of time. | >>> > | >>> | >>> additional question, is this in testing with a single user or in | a | >>> live multiple user environment? | >>> | >> | >> | >> | > |
Re: Internal Server Error when Seaside request takes too long?
|
|
Thanks Dale! I had alredy read that post and gave a chance to the FastCGI update. The entire application felt 'lighter', but it didn't solve the problem. Then I changed that apache configuration and for the moment it works. Slow, but it works.
On Wed, Feb 24, 2010 at 4:36 PM, Dale Henrichs <[hidden email]> wrote: Carla, |
Re: Internal Server Error when Seaside request takes too long?
|
|
On Wed, Feb 24, 2010 at 9:34 PM, Carla F. Griggio
<[hidden email]> wrote: > Thanks Dale! I had alredy read that post and gave a chance to the FastCGI > update. The entire application felt 'lighter', but it didn't solve the > problem. Then I changed that apache configuration and for the moment it > works. Slow, but it works. > If you can't speed up the reporting and you can't increase the timeout ( most browsers will timeout on their own at around 180 seconds ), you either need to move to a queue, run and inform model, inform could either be email with url or a comet or ajax polling scenario. |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |