+1 I agree.
I think we have been considering that the clojure migration/JStorm merge would
become 2.0. Maybe we should reconsider that in order to allow major version
bumps and closer adherence to semantic versioning. I can also think of a few
areas where I’d like to see some backward-incompati
Yes, so what I would propose is...
If we add in a new dependency to the storm lib directory that is not shaded, or
decide to stop shading a dependency it should at least be a minor version bump,
but I would prefer a major version bump (potentially binary incompatible
change).If we bump a versi
But if we shade a dependency, are’t we effectively making it *private*, in
which case a minor revision bump would be unnecessary? I would think using the
shaded/private versions of storm’s dependencies should be done at one’s own
risk, i.e. knowing they are subject to change.
-Taylor
> On May
We almost never add new dependencies to storm-core without shading first. I
don't think it will be an explosion in minor revisions, but that is just me.
- Bobby
On Wednesday, May 18, 2016 4:58 PM, P. Taylor Goetz
wrote:
Good point.
I guess the problem is that we have no way of knowi
Abhishek,
The information about what your company is facing is in fact what I really
wanted to hear from community. Thanks for providing these in detail.
For me I didn't face something directly, but heard that attaching metrics
consumer incurred huge degradation of performance of whole topology.
Good point.
I guess the problem is that we have no way of knowing what dependencies a user
could potentially use in their topologies. Semantic versioning can't really
help with that without a potential explosions of minor revisions. Maybe the
best option is to document such dependency changes i
But adding something that was not there before is just the same thing. If I
have a topology that is using guava, and storm adds in a dependency with a
different version to the classpath without shading it, I just broke that
topology.
- Bobby
On Wednesday, May 18, 2016 2:26 PM, P. Taylor
> On May 18, 2016, at 2:46 PM, Bobby Evans wrote:
>
> If this is for 1.x then we might want to go to 1.1, not sure what the policy
> is for adding something new to the classpath.
> - Bobby
There was a discussion thread around this. My feeling is that for 1.x, since we
are adding APIs we shoul
I disagree. If I have something that uses guava x.y and storm moves to guava
y.z now my topology will no longer run. It is not that minor of a change.
- Bobby
On Wednesday, May 18, 2016 2:01 PM, P. Taylor Goetz
wrote:
On May 18, 2016, at 2:46 PM, Bobby Evans wrote:
If this is for
Yes it is shaded, but it dosn't have to be. It was shaded, because it is not
user facing, and so adding it to the classpath potentially could cause some
issues. If we standardize on it then we would want to stop shading it, or we
could put in a small shim layer in front of it so we could swap
I remember from a previous discussion that codahale metrics are shaded
inside storm-core and that breaks compatibility with any existing
plugins/reporters. Will it not be a problem here? And btw does it need to
be shaded?
@Jungteek - Exactly what are the core issues you have run into w.r.t
metrics
+1 for standardizing on drop wizard/Coda Hale’s metrics library. It’s a solid
library that’s widely used and understood.
-Taylor
> On May 18, 2016, at 10:22 AM, Bobby Evans wrote:
>
> There are a lot of things that I dislike about IMetric. It provides too much
> flexibility and at the same
Yes totally agreed with you.
For me, getValueAndReset() itself is more painful to modify anything
regarding metrics.
I feel that getValueAndReset() was born with precondition that caller
should ensure thread-safe. At least kinds of implementation of IMetric what
Storm provides now are NOT thread-s
There are a lot of things that I dislike about IMetric. It provides too much
flexibility and at the same time not enough information/conventions to be able
to interpret the numbers it returns correctly. We recently had a case where
someone was trying to compute an average using a ReducedMetric
Hi devs,
Since IMetric#getValueAndReset doesn't restrict return type, it gives us
flexibility but metrics consumer should parse the value without context
(having just some assumptions).
I've look into some open source metrics consumers, and many of them support
Number, Map, and one of them suppor
15 matches
Mail list logo
