Hello Devs!
You're receiving this email because you are subscribed to one or more
Apache developer email lists.
I’m writing to let you know about an exciting event coming to the Chicago
area: The Apache Roadshow Chicago. It will be held May 13th and 14th at
three bars in the Logan Square
Actually the formatting code would go in InternalDistributedMember. The
JMX code already has a special method for handling that class. I was
thrown off by the reference to a non-existant getName() method in
LonerDistributionManager.
On 1/15/19 7:34 AM, Bruce Schuchardt wrote:
I think we
The plan is to use tagged metrics, so for example, you could slice metrics
on puts by region, or server, or both.
On Tue, Jan 15, 2019 at 10:06 AM Udo Kohlmeyer wrote:
> I agree with Jacob here. Great to see such great strides forward
>
> +1 deprecating old Stats APIs
>
> It would be good to
I am good with this proposal as long as it includes the deprecation of all the
current stats APIs and VSD such that Micrometer is the only go forward stats
definition and collection API in 2.0.
> On Jan 15, 2019, at 9:37 AM, Mark Hanson wrote:
>
> Hello All,
>
> I would like to propose that
I agree with Jacob here. Great to see such great strides forward
+1 deprecating old Stats APIs
It would be good to see the new Micrometer stats have a logical
grouping, that makes it easier for users to search for metrics.
Does this mean that Geode will now support fully tagged/dimension
Darrel, thank you for this.
I would like to propose a counter-proposal.
Instead of introducing another PDXInstance type, why don't we improve
the serialization framework itself? I know my proposal is most likely
going to take a little more effort than adding a new type, but I believe
it is
Yeah, let's fix this, but let's not require the toString() of an object
to never change. Let's add another method that returns a Bean
identifier and is documented to never change.
On 1/15/19 9:45 AM, Kirk Lund wrote:
Sorry about the confusion. I meant that the change of membership port
As part of GEODE-6272 we realized we need a way to use a PdxInstance as key
for a Region entry. The problem with the current PdxInstance behavior is
that in some members the key may be seen as a PdxInstance and in others
seen as an instance of a domain class. This inconsistency can lead to
I like the idea of adding support to the region configuration that lets
users control how it stores the data. But even if we did that, and you are
correct that it would be much more work, I don't think it would address
this issue or remove the value of a PdxInstance that always deserializes to
a
Yes, deprecating stats and VSD would be the direction we are heading…
> On Jan 15, 2019, at 9:43 AM, Jacob Barrett wrote:
>
> I am good with this proposal as long as it includes the deprecation of all
> the current stats APIs and VSD such that Micrometer is the only go forward
> stats
Yes, we will be working towards tagged dimensions and JMX parity as well.
> On Jan 15, 2019, at 10:06 AM, Udo Kohlmeyer wrote:
>
> I agree with Jacob here. Great to see such great strides forward
>
> +1 deprecating old Stats APIs
>
> It would be good to see the new Micrometer stats have a
Hello!
I've noticed that there is no mechanism in which we prevent new PRs from
introduce new build warnings. In our PR template we ask people to self
report that they have a "clean build" but nothing more to ensure we're not
adding new warnings.
Has there been an initiative to address this in
Hello All,
I would like to propose that we incorporate Micrometer into Geode to allow us
to collect statistics and make them more easily available to external services
should someone chose to implement support for that.
In some basic testing, it does not appear to have a significant impact on
Sorry about the confusion. I meant that the change of membership port
results in DistributedMember returning a different string from its
getName() method.
We discovered this because the JMX layer has some error handling that
results in suppressing this failure, so the failure was being hidden. We
I suspect Udo is remembering something we both had to deal with, which is
that the lack of values to get/put PDXInstances on Regions make some
patterns difficult. In internal code, we have to set some thread-locals to
get serialized values out, and in general, I think that setting
Hi Udo and all,
> On Jan 15, 2019, at 10:06 AM, Udo Kohlmeyer wrote:
>
> It would be good to see the new Micrometer stats have a logical grouping,
> that makes it easier for users to search for metrics.
Do you know of any useful guidelines or conventions for creating a hierarchy of
metrics,
Dan, we still want a "class name" but it no longer has to be an actual name
of a java class.
It can now be just a logical "type name". For two PdxInstances to be equal
they need to have the same class name.
So we really do just want a flag that says: never deserialize this
PdxInstance.
Anil
I'm for failing CI on warnings. It would be nice to reduce or eliminate our
existing build warnings as well.
Thanks,
Galen
On Tue, Jan 15, 2019 at 12:33 PM Peter Tran wrote:
> Hello!
>
> I've noticed that there is no mechanism in which we prevent new PRs from
> introduce new build warnings.
Even before the JSON pdx support we had internal support for a PdxInstance
that deserializes as a PdxInstance.
This is just adding an external api for that already existing internal
feature. So it is pretty simple to do if we can figure out how to name it.
On Tue, Jan 15, 2019 at 11:18 AM Galen
+1 Micrometer looks awesome.
I'd love to see more details on how this will work. How will you hook
micrometer in? Will all of the stats that are currently exposed in VSD be
exposed in micrometer, or just some subset? How does a user configure which
monitoring system(s) micrometer is sending data
Sounds good. +1 to failing the build if new warnings are introduced.
-Dan
On Tue, Jan 15, 2019 at 12:59 PM Galen O'Sullivan
wrote:
> I'm for failing CI on warnings. It would be nice to reduce or eliminate our
> existing build warnings as well.
>
> Thanks,
> Galen
>
>
> On Tue, Jan 15, 2019 at
Darrel to better understand what you are asking for:
I understand that you want the following:
byte[] -> PdxInstance
and not
byte[] -> PdxInstance -> Pojo
The `read-serialized=true` flag is a single flag that "rules them all"
which does not make sense anymore and something that is seemingly
So, to reduce the number of new warnings, are we then going to
standardize on JDK versions? i.e, we only build with JDK 8 build 192 and
JDK11 build 03, because changes in JDK can introduce warnings.
I'm all for reducing warnings, but they are warnings. Don't think we
need to error, or break
If I understand this right, you are talking about a way to create a
PdxInstance that has no corresponding java class. How about just a
RegionService.createPdxInstanceFactory() method that doesn't take a
classname, and therefore has no corresponding java class? It seems a
PdxInstances without a
So...
imo, what is a dimension and what is a metric.
well to me a metric is a value that we want to measure on across all the
different permutations of that metric. The metric has to be generic in
the sense that it exposes no detail about the value it is measuring.
Metrics are like dry oats.
While I like the idea of a non-static & more flexible serialization
service I don't think it's reasonable to foist that onto Darrel because
it's a great deal of work.
On 1/15/19 2:29 PM, Darrel Schneider wrote:
Dan, we still want a "class name" but it no longer has to be an actual name
of a
Bruce, this was not aimed at Darrel to do. I was just counter-proposing
that I prefer a different approach to solving the problem.
And yes, all new features are starting to become big changes. I still
think that the proposal that Darrel has made, could be a byproduct of a
"Serialization
I think we could solve this by either moving the ID formatting code to
the DistributionManager implementations & having
LonerDistributionManager omit the port number or modify the
client/server handshake to not install a port number when connecting to
a remote GatewayReceiver. I guess the
28 matches
Mail list logo
