Mario,
Yes, you're right. The GatewaySender case does not log that warning if the
alert-threshold is set. I updated the ticket with the behavior I see.
Thanks,
Barry Oglesby
On Thu, Jul 11, 2019 at 10:20 AM Mario Ivanac wrote:
> Description from documentation
>
>
> --alert-threshold
> Maximu
Hello All,
Since there is no one disagreeing, we are going to start moving forward with
this.
Thanks,
Mark
> On Jul 11, 2019, at 10:33 AM, Darrel Schneider wrote:
>
> Originally we just had a single instance of CachePerfStats per jvm. So all
> the region related stats were always rolled up o
One thing I will mention regarding DATA:READ:RegionName allowing query
behavior is that we have been asked by some users already to separate
DATA:READ:RegionName from DATA:QUERY:RegionName. This request is to protect
against arbitrary query execution by administrators that can cause huge
resource c
My personal thinking was:
Step 1: fix the object structure this round, and try to keep the data output
the same. The downside here is that a chunk of stuff from CachePerfStats would
then be duplicated into
RegionPerfStats directly where it was there effectively. This also means that
Partitione
Originally we just had a single instance of CachePerfStats per jvm. So all
the region related stats were always rolled up onto the single
CachePerfStats. Later we added RegionPerfStats so that users could see what
was happening on a per region basis. When RegionPerfStats was added it was
made to ex
I would recommend doing a spike for this refactoring before trying to
provide a class diagram -- I would personally learn a lot that would have a
major effect on the resulting class design that I can only guess about up
front.
Another major challenge is in trying to keep the resulting .gfs file
un
Description from documentation
--alert-threshold
Maximum number of milliseconds that a region event can remain in the gateway
sender queue before Geode logs an alert.
Šalje: Mario Ivanac
Poslano: 8. srpnja 2019. 10:52:20
Prima: dev@geode.apache.org
Predmet: Ga
See my comments inline..
> On Jul 11, 2019, at 9:36 AM, Darrel Schneider wrote:
>
> Currently we do not make visible per bucket stats. Is the above proposal
> just to change the internal implementation but the stats visible in tools
> like vsd are unchanged?
>
As with my previous e-mail exchang
I accept that point. I would certainly like to minimize the work and per bucket
status would seem undesirable. I can totally agree to back burner that until
some point in the future at which point we agree to move forward on it. I was
just anticipating that would fall out necessarily. That said
Currently we do not make visible per bucket stats. Is the above proposal
just to change the internal implementation but the stats visible in tools
like vsd are unchanged?
Currently we have an internal CachePerfStats which the internal
RegionPerfStats extends. Does your CacheStats replace CachePerf
So is the root of this proposal really about expanding our current stats
collection to include per-bucket stats. If not I would really separate these
two ideas. First focus on refactoring these stats classes to be more manageable
and readable. Then propose adding per-bucket stats as a thing sepa
It depends to be honest. This is just a plan. I would hope to roll them up, but
I can see a case where you have buckets on different servers, that would seem
to necessitate that.
> On Jul 11, 2019, at 9:26 AM, Jacob Barrett wrote:
>
> There isn’t currently a partition stat instance per bucket.
There isn’t currently a partition stat instance per bucket. Are you saying
you’re making that a thing now?
> On Jul 11, 2019, at 9:24 AM, Mark Hanson wrote:
>
> Correct.
>
>> On Jul 11, 2019, at 9:23 AM, Darrel Schneider wrote:
>>
>> Why would a PartitionedRegionStatsImpl contain more than o
Correct.
> On Jul 11, 2019, at 9:23 AM, Darrel Schneider wrote:
>
> Why would a PartitionedRegionStatsImpl contain more than one RegionStats?
> Are these representing the local buckets?
>
> On Wed, Jul 10, 2019 at 4:57 PM Mark Hanson wrote:
>
>> PartitionRegionStatsImpl can contain one to man
Why would a PartitionedRegionStatsImpl contain more than one RegionStats?
Are these representing the local buckets?
On Wed, Jul 10, 2019 at 4:57 PM Mark Hanson wrote:
> PartitionRegionStatsImpl can contain one to many RegionStats
>
> > On Jul 10, 2019, at 4:53 PM, Dan Smith wrote:
> >
> > Seems
They will be public API, currently, mainly used by the
ClusterManagementServivice to configure the cluster.
On Wed, Jul 10, 2019 at 9:06 PM Jacob Barrett wrote:
> Are these new objects public API or internal?
>
> > On Jul 10, 2019, at 1:16 PM, Jinmei Liao wrote:
> >
> > We've been working on a
Hello all,
Friendly reminder regarding the deadline to rise concerns and/or objections
regarding the *OQL Method InvocationSecurity Proposal [1]*, I'll go ahead
and move it to *Development* on July 13th.
Best regards.
[1]:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Se
17 matches
Mail list logo
