GC listener

[Krystal Mok]

Exactly.
BTW, Zing's C4 collector is another alternative in the concurrent realm ;-)

- Kris


On Fri, Mar 21, 2014 at 11:26 AM, Matt Miller
<matthew.miller at forgerock.com>wrote:

>  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> 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*
>>>  |  Mobile: *+385993061692*
>>>
>>> Email: *Milan.Mimica at infobip.com*  |  Skype: *mmimicaib*
>>>
>>> *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>or telephone +442032864235.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hotspot-gc-use mailing list
>>> 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
>>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://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/a9d16b45/attachment.html>