[Glass] Explanation to "too many failed pom_gen scavenges" in this context??

[Dale Henrichs via Glass]

In 3.3, instead of returning an Array of Associations, the report is 
written to the gem log ... you are using 3.2.9?

Dale

On 03/07/2016 12:39 PM, Mariano Martinez Peck wrote:
> Also...I do not get the instance count written neither in object log 
> (could be the bug I mentioned in previous email), nor in the gem file 
> log...shouldn't I get that? At least I remember getting that once upon 
> a time.
>
> Thanks!
>
> On Mon, Mar 7, 2016 at 5:11 PM, Mariano Martinez Peck 
> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>
>     BTW Dale.... I think the line of "System *_vmInstanceCounts:* 3"
>      in #installAlmostOutOfMemoryStaticHandler: is wrong and instead
>     it should be (System *_vmInstanceCountsReport:* 3)  and it also
>     will fail the
>
>       sort: [ :a :b | (a value at: 2) > (b value at: 2) ]
>
>     Was this fixed somewhere after 3.2.9 ???
>
>
>     Cheers,
>
>
>
>
>     On Mon, Mar 7, 2016 at 4:57 PM, Mariano Martinez Peck
>     <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>
>
>
>         On Mon, Mar 7, 2016 at 3:18 PM, Dale Henrichs via Glass
>         <glass at lists.gemtalksystems.com
>         <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>             Mariano,
>
>             The handler for AlmostOutOfMemory relies on being able to
>             resume after a successful commit, but a GemStone vm will
>             sometimes cross the threshol in the middle of a "random C
>             code" called by a primitive ... in these cases we have to
>             defer the signalling of AlmostOutOfMemory until we reach a
>             point where we can safely resume .... The implication is
>             that depending upon the details of your call it is
>             possible to physically run out of memory before the
>             deferred signaling can take place ...
>
>             If you lower the threshold, you should be able to find a
>             limit that gives you room to finish the memory hungry
>             primitive call and get the deferred AlmostOfOfMemory
>             exception signalled.
>
>
>         Yes,*but I am already running the threshold with 10% with a
>         700MB temp space*... how less than that should it be? mmmm
>
>             It is also possible that your temp obj cache is filling
>             with objects that have not yet been connected to the
>             persistent root ...
>
>
>         mmm OK  I will check this. But now I get this same error in
>         another cron job. Both were running correctly a few
>         weeks/months ago.
>
>             If you want to see what's happening with respect to the
>             exceptions that are being signaleed, you could add logging
>             to MCPlatformSupport
>             class>>installAlmostOutOfMemoryStaticHandler: ...
>
>
>         mmmm I am a bit lost there. Which kind of log could I add?
>
>         Thanks in advance,
>
>
>
>             Dale
>
>
>
>             On 03/07/2016 08:35 AM, Mariano Martinez Peck via Glass wrote:
>>             Hi guys,
>>
>>             I am running some code that processes a huge csv file and
>>             inserts persistent data to gemstone. This is a GemStone
>>             3.2.9 with 1GB of SPC, GEM_TEMPOBJ_CACHE_SIZE of 700MB
>>             and GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE  at 100.
>>
>>             What is funny is that my code runs inside commitOnAlmost...
>>
>>             I have this method:
>>
>>             FAGemStoneCompatibility >>
>>             commitOnAlmostOutOfMemoryDuring: aBlock threshold: aThreshold
>>               [
>>               MCPlatformSupport
>>             installAlmostOutOfMemoryStaticHandler: aThreshold.
>>               aBlock value ]
>>                 ensure: [ MCPlatformSupport
>>             uninstallAlmostOutOfMemoryStaticHandler ]
>>
>>             And this is how I use it:
>>
>>              System commitTransaction.
>>             FACompatibilityUtils current
>>             commitOnAlmostOutOfMemoryDuring: [
>>             *WhateverClass whateverThingThatNeedsMemory.*
>>                 ]
>>                 threshold: 10.
>>             System commitTransaction.
>>
>>
>>             And even with a threshold of 10...  I am getting a
>>             *
>>             *
>>             *VM temporary object memory is full *
>>             *, too many failed pom_gen scavenges*
>>
>>
>>             Any idea what could be going on?
>>
>>             Thanks in advance,
>>
>>             -- 
>>             Mariano
>>             http://marianopeck.wordpress.com
>>
>>
>>             _______________________________________________
>>             Glass mailing list
>>             Glass at lists.gemtalksystems.com
>>             <mailto:Glass at lists.gemtalksystems.com>
>>             http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>             _______________________________________________
>             Glass mailing list
>             Glass at lists.gemtalksystems.com
>             <mailto:Glass at lists.gemtalksystems.com>
>             http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
>         -- 
>         Mariano
>         http://marianopeck.wordpress.com
>
>
>
>
>     -- 
>     Mariano
>     http://marianopeck.wordpress.com
>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160307/fedb36d0/attachment-0001.html>