[Glass] out of memory error

Otto Behrens otto at finworks.biz
Thu Feb 3 06:20:25 PST 2022


Thanks, Dale

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 9:10 PM Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> 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/20220203/53b3df98/attachment.htm>


More information about the Glass mailing list