one gem is shutdown

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

one gem is shutdown

Juan-2
Folks

When I call my application one of the gems stops working , the gem in
the status screen is called 9001.
The aplication start , but call the component fail.

 the browser displays the following error.
"Internal Server Error

The server encountered an internal error or misconfiguration and was
unable to complete your request.

Please contact the server administrator, [no address given] and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.

More information about this error may be available in the server error log.
Apache/2.2.4 (Ubuntu) mod_fastcgi/2.4.2 mod_python/3.3.1 Python/2.5.1
Server at localhost Port 8082"

 which is the way to debug this?
there is any log file that is meaningful?
 which file?
 where is located?
 I am using the appliance glass.
any ideas will be appreciated
best regards

MDC
Reply | Threaded
Open this post in threaded view
|

Re: one gem is shutdown

James Foster
On Feb 9, 2010, at 9:00 AM, Juan wrote:

> When I call my application one of the gems stops working , the gem in
> the status screen is called 9001.
> The aplication start , but call the component fail.
> ...
> which is the way to debug this?
> there is any log file that is meaningful?
> which file?
> where is located?
> I am using the appliance glass. ...

Juan,

In the appliance there is a directory '/opt/gemstone/log' that contains various log files, including 'FastCGI_server-9001.log'. Open that file in a text editor and start looking through it. (You might look first at the 9002 file to see what one looks like that does not have an error.) Search through the file for the last 'successful login' and then read from there.

In general, the framework attempts to trap errors and report them without crashing. There are, however, a few errors that can't be caught—including 'out-of-memory' errors. In the most recent example someone asked about (yesterday!), it turns out that the user entered a bad query and the application found 24,000 records. Seaside ran out of memory trying to display the results. The fix was to limit the displayed results to the first 100 found. With that, no more out-of-memory errors!

James
Reply | Threaded
Open this post in threaded view
|

Re: one gem is shutdown

Juan-2
thanks a take a look and report.
best
mdc



On Tue, Feb 9, 2010 at 2:17 PM, James Foster <[hidden email]> wrote:

> On Feb 9, 2010, at 9:00 AM, Juan wrote:
>
>> When I call my application one of the gems stops working , the gem in
>> the status screen is called 9001.
>> The aplication start , but call the component fail.
>> ...
>> which is the way to debug this?
>> there is any log file that is meaningful?
>> which file?
>> where is located?
>> I am using the appliance glass. ...
>
> Juan,
>
> In the appliance there is a directory '/opt/gemstone/log' that contains various log files, including 'FastCGI_server-9001.log'. Open that file in a text editor and start looking through it. (You might look first at the 9002 file to see what one looks like that does not have an error.) Search through the file for the last 'successful login' and then read from there.
>
> In general, the framework attempts to trap errors and report them without crashing. There are, however, a few errors that can't be caught—including 'out-of-memory' errors. In the most recent example someone asked about (yesterday!), it turns out that the user entered a bad query and the application found 24,000 records. Seaside ran out of memory trying to display the results. The fix was to limit the displayed results to the first 100 found. With that, no more out-of-memory errors!
>
> James
Reply | Threaded
Open this post in threaded view
|

Re: one gem is shutdown

Juan-2
James

Thansks a lot problem solved,
there one recursive loop in my silly code.
thanks the loop is visible into gem log.
great job!
best regard
MDC

On Tue, Feb 9, 2010 at 2:26 PM, Juan <[hidden email]> wrote:

> thanks a take a look and report.
> best
> mdc
>
>
>
> On Tue, Feb 9, 2010 at 2:17 PM, James Foster <[hidden email]> wrote:
>> On Feb 9, 2010, at 9:00 AM, Juan wrote:
>>
>>> When I call my application one of the gems stops working , the gem in
>>> the status screen is called 9001.
>>> The aplication start , but call the component fail.
>>> ...
>>> which is the way to debug this?
>>> there is any log file that is meaningful?
>>> which file?
>>> where is located?
>>> I am using the appliance glass. ...
>>
>> Juan,
>>
>> In the appliance there is a directory '/opt/gemstone/log' that contains various log files, including 'FastCGI_server-9001.log'. Open that file in a text editor and start looking through it. (You might look first at the 9002 file to see what one looks like that does not have an error.) Search through the file for the last 'successful login' and then read from there.
>>
>> In general, the framework attempts to trap errors and report them without crashing. There are, however, a few errors that can't be caught—including 'out-of-memory' errors. In the most recent example someone asked about (yesterday!), it turns out that the user entered a bad query and the application found 24,000 records. Seaside ran out of memory trying to display the results. The fix was to limit the displayed results to the first 100 found. With that, no more out-of-memory errors!
>>
>> James
>