> From: Jason Huynh [jhu...@pivotal.io]
> > Received: Wednesday, 21 Feb 2018, 20:54
> > To: dev@geode.apache.org [dev@geode.apache.org]
> > CC: u...@geode.apache.org [u...@geode.apache.org]
> > Subject: Re: [Proposal] Thread monitoring mechanism
> >
> > I am
t;
> -Original Message-
> From: Jason Huynh [jhu...@pivotal.io]
> Received: Wednesday, 21 Feb 2018, 20:54
> To: dev@geode.apache.org [dev@geode.apache.org]
> CC: u...@geode.apache.org [u...@geode.apache.org]
> Subject: Re: [Proposal] Thread monitoring mechanism
>
> I am
I am assuming this would be for all thread/thread pools and not specific to
Function threads. I wonder what the impact would be for put/get operations
or are we going to target specific operations.
On Tue, Feb 20, 2018 at 1:04 AM Gregory Vortman
wrote:
> Hello team,
> One of the most severe i
[dev@geode.apache.org]
CC: u...@geode.apache.org [u...@geode.apache.org]
Subject: Re: [Proposal] Thread monitoring mechanism
I am assuming this would be for all thread/thread pools and not specific to
Function threads. I wonder what the impact would be for put/get operations or
are we going to t
Hello team,
One of the most severe issues hitting our real time application is thread stuck
for multiple reasons, such as long lasting locks, deadlocks, threads which wait
for reply forever in case of packet drop issue etc...
Such kind of stuck are under Radar of the existing system health check
