[infinispan-dev] Infinispan embedded off-heap cache

[cotton-ben]

/> As Tristan hinted, can share (worse case privately) the reasons that lead
to that horrific experience?/

Thank you for this question.

The answer is simple: managed run-time Garbage Collection -  despite its
elegances, many recent advances, and real potential and promise - has
/consistently/ betrayed us (and at the most in-opportune times) with regard
to our SLA to deliver to our bank stakeholders the capability to render and
aggregate real-time liquidity risk.

Without going into details, to do this in /real-time/ is a hard problem to
solve.  But it is a problem that we are not only committed to solving ... it
is a problem that /is/ going to be solved.

The resources we have to empower to us to solve this are ... well ... they
are /nice./ (240 CPU 3TB/RAM Linux Supercomputer, onto which we deploy a
90-node  ISPN 5.3 DIST_SYNC data grid, to which we dispatch M-R quantitative
SCENARIOxSTRESS "risk search" algorithms (using ISPN's lovely
DistributedExecutorService,NotifyingFuture APIs) that empower us to always
accurately answer this primordial question="what is our Liquidity Risk
indicator (LRI) wrt to Position (P) on AssetClass(A) at Time(T)"?).

These resources do empower us to solve this problem ... except in the
case... and only in this case ... whenever any part of the grid (for any
reason) endures a STW GC event.  In those cases, this platform fails to
solve this problem.

>From our view, this is the fault of Java's run-time necessarily requiring us
to endure its GC priority.  We don't want it!!  We know it is elegant and
impressive, but WE DON'T WANT IT.  *We want to sacrifice elegance for
capability.*  

Now, we love Java, we love Infinispan, etc. etc.  And we know that our
intolerance for any GC event "totally messes us up" is a very rare use-case
-- rare enought that some Java solution providers would consider it not
worth the bother to accommodate us.

So that's our story.  We crave going off-heap in as elegant a way as
possible.  We are very hopeful that you guys @ISPN can feel our pain and
have interest in considering accommodating us (w your unmistakable ambition
to be the  leading /community-driven/ Java solution provider).




--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-Infinispan-embedded-off-heap-cache-tp4026102p4028653.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.