GC listener

Matt Miller matthew.miller at forgerock.com
Fri Mar 21 18:26:53 UTC 2014


This seems like a lot of work, where as instead you should probably just 
use a concurrent, low pause, GC algorithm ... (CMS? , G1 ? ) ...  and 
never have to do a long full GC anyhow.

-Matt

On 3/21/14, 2:05 PM, Krystal Mok wrote:
> Hi Peter,
>
> One of the ways I've seen people using GC notification in conjunction 
> with a load balancer is that they would set some notification 
> threshold, and possibly calculate the allocation rate so that it can 
> predict how much time there is before a full GC might occur. When a 
> full GC is predicted to happen soon, it would take itself off the load 
> balancer, do a *System.gc()*, and then attach itself back onto the 
> load balancer.
>
> That way they'd get the predicted full GC and actually see it "on 
> time", without worrying about the lack of allocations to trigger a 
> normal full GC.
>
> I'm not an advocate of this method, it's just one way it's been used 
> in the wild.
>
> - Kris
>
>
> On Fri, Mar 21, 2014 at 10:44 AM, Peter B. Kessler 
> <Peter.B.Kessler at oracle.com <mailto:Peter.B.Kessler at oracle.com>> wrote:
>
>     If you exclude yourself from the load balancer before the
>     collection, you won't get any more work, won't do any more
>     allocations, and won't cause the collection.  Wouldn't it be
>     better to tune your collector to meet your deadlines while getting
>     work done?
>
>                             ... peter
>
>
>     On 03/21/14 03:37, Milan Mimica wrote:
>
>         Hello
>
>         Would it be possible for the application to register some kind
>         of a listener to track GC activity, and that way predict when
>         Full GC is going to happen?
>         My application is a service behind a load balancer, and if it
>         could see Full GC which stops the world coming, given some
>         time to react, it could exclude itself from the balancer.
>         //
>
>         *Milan Mimica, *Software Engineer / Team Leader
>
>         Visit Infobip website <http://www.infobip.com>
>
>         Office: *Mletacka 12/III, 52100 Pula, Croatia*  |  Fax:
>         *+38552210979 <tel:%2B38552210979>*  |  Mobile: *+385993061692
>         <tel:%2B385993061692>*
>
>         Email: *Milan.Mimica at infobip.com
>         <mailto:Milan.Mimica at infobip.com>*  |  Skype: *mmimicaib*
>
>         *www.infobip.com <http://www.infobip.com>*
>         <http://www.infobip.com>/ *GSMA Associate Member*   / *Mobey
>         Forum Member*
>         This message is private and confidential. Any views or
>         opinions expressed are solely those of the author and do not
>         necessarily represent those of Infobip d.o.o. If you have
>         received this message in error, please notify us immediately
>         via email to customer.support at infobip.com
>         <mailto:customer.support at infobip.com>
>         <mailto:customer.support at infobip.com
>         <mailto:customer.support at infobip.com>>or telephone
>         +442032864235 <tel:%2B442032864235>.
>
>
>
>
>
>         _______________________________________________
>         hotspot-gc-use mailing list
>         hotspot-gc-use at openjdk.java.net
>         <mailto:hotspot-gc-use at openjdk.java.net>
>         http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>     _______________________________________________
>     hotspot-gc-use mailing list
>     hotspot-gc-use at openjdk.java.net
>     <mailto:hotspot-gc-use at openjdk.java.net>
>     http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140321/eae5d86a/attachment-0001.html>


More information about the hotspot-gc-use mailing list