[Glass] out of memory error

Wed Feb 2 11:10:09 PST 2022

In order to arrange for AlmostOutOfMemory to be handled in Seaside, you
should add the exception to GRGemStonePlatform>>gemstoneExceptionSelector
which is sent by WAGemStoneWalkbackErrorHandler in the WAExceptionHandler
hierarchy.  You would then edit WAErrorHandler>>handleGemStoneException: to
add the logic for handling the AlmostOutOfMemory and in your handler you
want to reenable AlmostOutOfMemory ... when you start your Seaside gem you
will also have to enable AlmostOutOfMemory ...

The way that AlmostOutOfMemory events occur, it is possible to run out of
memory in a section of code or process that is not protected by the
AlmostOutOfMemory handler and if that is the case, you would need to resort
to a static handler to be able to record a stack ...

Dale

On Wed, Feb 2, 2022 at 10:05 AM Bill Erickson via Glass <
glass at lists.gemtalksystems.com> wrote:

> Otto,
>
> > The class name seems to be AlmostOutOfMemory in 3.4.1 and was perhaps
> renamed to AlmostOutOfMemoryError
> >  (I suppose in 3.6 also sunglasses from error). Is this correct?
>
> Yes.
>
> > I am able to call AlmostOutOfMemory addDefaultHandler: in 3.4.1.
> > Should I rather use AlmostOutOfMemory enable vs. System
> enableAlmostOutOfMemoryError?
>
> Either way is fine.  More details are available on page 276 section
> "Signal on low memory condition" in the 3.4 version of the Programming
> Guide.
>
> > Secondly, my code snippet for #handleException: is in the Seaside
> WAExceptionHandler hierarchy.
> > There is a structure to filter exceptions by "kind". How will I get
> #addDefaultHandler: to work with this?
>
> Default exception handlers are asynchronous and work outside of the normal
> exception hierarchy.  There's no real way to coordinate the two.
>
> ------------------------------------------------------------------------
> Bill Erickson
> GemTalk Systems Engineering
> 15220 NW Greenbrier Parkway #240, Beaverton OR 97006
> ------------------------------------------------------------------------
>
>
> On Wed, Feb 2, 2022 at 6:39 AM Otto Behrens <otto at finworks.biz> wrote:
>
>> Thanks for the reply, Bill.
>>
>> Firstly, I'm using 3.4.1. The class name seems to be AlmostOutOfMemory in
>> 3.4.1 and was perhaps renamed to AlmostOutOfMemoryError (I suppose in 3.6
>> also sunglasses from error). Is this correct?
>>
>> I am able to call AlmostOutOfMemory addDefaultHandler: in 3.4.1. Should I
>> rather use AlmostOutOfMemory enable vs. System enableAlmostOutOfMemoryError?
>>
>> Secondly, my code snippet for #handleException: is in the
>> Seaside WAExceptionHandler hierarchy. There is a structure to filter
>> exceptions by "kind". How will I get #addDefaultHandler: to work with this?
>>
>> Regards
>>
>> Otto Behrens
>>
>> +27 82 809 2375
>> [image: FINWorks]
>> [image: FINWorks] <http://za.linkedin.com/in/waltherbehrens>
>> www.finworks.biz
>>
>> Disclaimer & Confidentiality Note: This email is intended solely for the
>> use of the individual or entity named above as it may contain information
>> that is confidential and privileged. If you are not the intended recipient,
>> be advised that any dissemination, distribution or copying of this email is
>> strictly prohibited. FINWorks cannot be held liable by any person other
>> than the addressee in respect of any opinions, conclusions, advice or other
>> information contained in this email.
>>
>>
>> On Wed, Feb 2, 2022 at 4:20 PM Bill Erickson <
>> bill.erickson at gemtalksystems.com> wrote:
>>
>>> Try setting up a default handler as explained on page 264-265 of the 3.6
>>> Programming Guide (section titled "Default Handlers"), using something like:
>>>
>>> AlmostOutOfMemoryError addDefaultHandler: [:ex |
>>>      < your code here >
>>>      AlmostOutOfMemoryError enable.
>>>      ex resume].
>>> AlmostOutOfMemoryError enable.
>>>
>>> ------------------------------------------------------------------------
>>> Bill Erickson
>>> GemTalk Systems Engineering
>>> 15220 NW Greenbrier Parkway #240, Beaverton OR 97006
>>> ------------------------------------------------------------------------
>>>
>>>
>>> On Wed, Feb 2, 2022 at 5:17 AM Otto Behrens via Glass <
>>> glass at lists.gemtalksystems.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> We are getting OutOfMemory errors in a seaside request handler because
>>>> we are doing something ridiculous. We will fix that problem, but I'd like
>>>> to handle the out of memory situation better because currently our sessions
>>>> do not report that it did go out of memory, because it is unable to, for
>>>> obvious reasons.
>>>>
>>>> I was thinking of enabling AlmostOutOfMemory and then report the error
>>>> like we do with other exceptions: write a stack trace to the logs, send an
>>>> email message and then redirect to an error page.
>>>>
>>>> I called
>>>> System enableAlmostOutOfMemoryError
>>>> in my Seaside application initialization, which did not work.
>>>> I then tried it in my session startup script (similar to the
>>>> seaside/bin/startSeaside_FastCGI script) and it also did not work.
>>>>
>>>> I just get the same old OutOfMemory fatal error.
>>>>
>>>> I tried adding this to my error handler:
>>>> handleException: anException
>>>> ^ (AlmostOutOfMemory handles: anException)
>>>> ifTrue: [ System enableAlmostOutOfMemoryError.
>>>> self handleError: anException ]
>>>> ifFalse: [ (Notification handles: anException)
>>>> ifTrue: [ super handleException: anException ]
>>>> ifFalse: [ self handleError: anException ] ]
>>>>
>>>> Any ideas?
>>>>
>>>> Kind regards
>>>>
>>>> Otto Behrens
>>>>
>>>> +27 82 809 2375
>>>> [image: FINWorks]
>>>> [image: FINWorks] <http://za.linkedin.com/in/waltherbehrens>
>>>> www.finworks.biz
>>>>
>>>> Disclaimer & Confidentiality Note: This email is intended solely for
>>>> the use of the individual or entity named above as it may contain
>>>> information that is confidential and privileged. If you are not the
>>>> intended recipient, be advised that any dissemination, distribution or
>>>> copying of this email is strictly prohibited. FINWorks cannot be held
>>>> liable by any person other than the addressee in respect of any opinions,
>>>> conclusions, advice or other information contained in this email.
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20220202/e4c27df1/attachment-0001.htm>