[Glass] out of memory error

[Bill Erickson]

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20220202/b9521d0d/attachment.htm>