[GitHub] storm issue #2591: STORM-2979: WorkerHooks EOFException during run_worker_sh...

[hummelm]

Github user hummelm commented on the issue:

https://github.com/apache/storm/pull/2591
  
After some tests I can say that the issue also affects:
1.1.X
1.2.X

I'm pretty sure that master branch (2.X)  is also affected but the worker 
code have been rewritten in java.
I can easily create a patch for this branch if needed.


---

Re: New Metrics Reporting API - for 2.0.0

[P. Taylor Goetz]

It’s currently in progress.

Aaron, if you want to help let me know and we can set up,a feature branch for 
collaboration.

-Taylor

> On Mar 13, 2018, at 4:25 PM, Jungtaek Lim  wrote:
> 
> Aaron,
> 
> please feel free to take up STORM-2908 and STORM-2909 as well. I'd be much
> appreciated. I asked Taylor to take them up but didn't work.
> They're coupled with Storm 2.0.0 release so sooner is better, but no hard
> due date for now.
> 
> -Jungtaek Lim (HeartSaVioR)
> 
> 2018년 3월 14일 (수) 오전 12:35, Aaron Gresch 님이 작성:
> 
>> I was wondering what the plan/timeline is for STORM-2909 for the Storm 2
>> release.
>> 
>> If I can help, please let me know.
>> 
>> Thanks,
>> Aaron
>> 

Re: New Metrics Reporting API - for 2.0.0

[Jungtaek Lim]

Aaron,

please feel free to take up STORM-2908 and STORM-2909 as well. I'd be much
appreciated. I asked Taylor to take them up but didn't work.
They're coupled with Storm 2.0.0 release so sooner is better, but no hard
due date for now.

-Jungtaek Lim (HeartSaVioR)

2018년 3월 14일 (수) 오전 12:35, Aaron Gresch 님이 작성:

> I was wondering what the plan/timeline is for STORM-2909 for the Storm 2
> release.
>
> If I can help, please let me know.
>
> Thanks,
> Aaron
>

[GitHub] storm issue #459: avoiding rawtypes in IBold.prepare in order to allow usage...

[knusbaum]

Github user knusbaum commented on the issue:

https://github.com/apache/storm/pull/459
  
@krichter722 Yes, these maps are vestiges of the old clojure code. It would 
probably be preferable to do as you suggest, but I'm not sure how much work 
there is to do there. IIRC, the config objects are pretty well spread and used 
throughout the code, and there's some other support code, tests, validation, 
etc. That may have to be significantly changed. I think it's definitely worth 
consideration, though. Maybe a dev list email would be a good place to get 
opinions.


---

[GitHub] storm issue #459: avoiding rawtypes in IBold.prepare in order to allow usage...

[krichter722]

Github user krichter722 commented on the issue:

https://github.com/apache/storm/pull/459
  
> I checked a few of these, and it seems they have already been modified to 
avoid the compile errors.

I seems like `IBolt.prepare`'s `topoConf` has been changed to `Map` everywhere which is a good idea (and a better idea than ``). Now 
that the interface is improved in puncto type safety, the generic types should 
be used everywhere they're encountered/used anyway, but just not passed down or 
up the hierarchy. This applies to all topology configuration, metadata and 
authentication maps since they're using `` at some point in the 
hierarchy or in a relationship.

I pushed those changes to the generics branch. Since this issue is about 
`IBolt` I can open a new PR, but it's very similar.

I don't seem to be able to figure out the necessary type for 
`IScheduler.config` which is sometimes `Map` and `Map` which is possible in a non-type safe 
environment, but unnecessarily hard to understand. So, I let it untouched.

There're a lot of usages of the idiom

Map someMap;
Map nestedMap = (Map) 
someMap.get("someLiteral");

which should imo be encapsulated in a configuration class since the map 
should contain nothing more complex than wrappers, maybe a single valued 
collection (list or set), but a map in a map value might cause problems at some 
point (and probably only does not now because of the excellent test coverage). 
Also, `"someLiteral"` is the [magic-number 
anti-pattern](https://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constants).

> Yes, I'll retracting my -1. Sorry for letting this one languish.

No problem. I'm aware that some of the changes do not introduce improvement 
immediately because Storm serializes and deserializes a lot, but the changes 
allow to discover design flaws and to fail earlier in case of a type mismatch.


---

[GitHub] storm pull request #2433: [STORM-2693] Heartbeats and assignments promotion ...

[danny0405]

Github user danny0405 commented on a diff in the pull request:

https://github.com/apache/storm/pull/2433#discussion_r174188374
  
--- Diff: 
storm-client/src/jvm/org/apache/storm/cluster/IStormClusterState.java ---
@@ -233,23 +249,11 @@
  * @return the id of the topology or null if it is not alive.
  */
 default Optional getTopoId(final String topologyName) {
--- End diff --

It's a wrapper func which change the result to be of an `Option` type.


---

[GitHub] storm issue #2433: [STORM-2693] Heartbeats and assignments promotion for sto...

[danny0405]

Github user danny0405 commented on the issue:

https://github.com/apache/storm/pull/2433
  
@revans2
I have fixed the nits problems and merge your patch in.


---

New Metrics Reporting API - for 2.0.0

[Aaron Gresch]

I was wondering what the plan/timeline is for STORM-2909 for the Storm 2
release.

If I can help, please let me know.

Thanks,
Aaron

[GitHub] storm pull request #2565: STORM-2954 add HBase metricstore implementation

[agresch]

Github user agresch closed the pull request at:

https://github.com/apache/storm/pull/2565


---