Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

Hi S G,
Not something I am working on now. What I pushed was just reporter config for 
Taylor since he needed it. I do think that if default reporting works we could 
just go to the rocksdb store and ask it for the metrics there?
There are other parts of this I haven't published yet but looking to do so 
either this or next week.
Thanks,
Alessandro



On Tuesday, December 6, 2016, 11:10:57 AM CST, S G <sg.online.em...@gmail.com> 
wrote:Hey Alessandro,

Thanks for sharing.
Please share if we have plans to use the metrics-servlets from dropwizard?
(http://metrics.dropwizard.io/3.1.0/manual/servlets/#adminservlet)

I think it will be very convenient to have the metrics reported through a
REST API from every process (worker, supervisor, nimbus etc.) and in line
with most other software like Solr, ES etc. This can be achieved very
easily if we use the above metric servlets and they also provide ping,
health-check, thread dump etc which are useful too.

Please ignore if its already there in the code shared above and I could not
find it.

Thanks,
SG



On Mon, Dec 5, 2016 at 9:49 PM, Alessandro Bellina <abell...@yahoo-inc.com>
wrote:

> Hi Taylor
>
> Please see latest commit in: https://github.com/abellina/
> storm/tree/reporters
>
> Specifically inside: storm-core/src/jvm/org/apache/storm/metrics2
>
> I have a default config that sets up a couple of reporters in
> default.yaml. The format is inline with what we discussed, but updated with
> what I suggested over the weekend.
>
> This is definitely a work in progress, but you should be able to
> instantiate reporters for your purposes.
>
> Thanks,
>
> Alessandro
>
>
>
> On Monday, December 5, 2016, 1:26:41 PM CST, Alessandro Bellina <
> abell...@yahoo-inc.com.INVALID> wrote:
> Yes. Will PR this tonight Taylor. Thanks!
> On Monday, December 5, 2016, 12:37:18 PM CST, P. Taylor Goetz <
> ptgo...@gmail.com> wrote:Alessandro,
>
> Are you in a position to open a pull request against the metrics_v2
> branch? I’d like to start integrating the work I’ve been doing with the
> reporter configuration stuff you have. If what you have is incomplete/WIP,
> that’s not a big deal as the metrics_v2 branch is a feature branch and
> we’ll have plenty of opportunities to clean things up.
>
> -Taylor
>
> > On Nov 29, 2016, at 3:27 PM, Alessandro Bellina <abell...@yahoo-inc.com>
> wrote:
> >
> > Taylor,
> >
> > Ok maybe there is some effort duplication. For the config, I have the
> bare minimum to get the default reporter up. I'll focus on that since you
> could use it. Will update JIRA with more.
> >
> > Alessandro
> >
> >
> > - Forwarded Message -
> > From: P. Taylor Goetz <ptgo...@gmail.com>
> > To: "dev@storm.apache.org" <dev@storm.apache.org>
> > Cc: S G <sg.online.em...@gmail.com>; na...@narendasan.com <
> na...@narendasan.com>; Austin Chung <achun...@illinois.edu>
> > Sent: Tuesday, November 29, 2016, 1:27:58 PM CST
> > Subject: Re: Are storm metrics reported through JMX too?
> >
> > Alessandro,
> >
> > Where do you stand with the reporter configuration via the storm.yaml
> config file?
> >
> > I have metrics collection for workers and disruptor queues almost ready,
> but now I’m looking for flexible configuration (right now I have reporters
> hard coded).
> >
> > -Taylor
> >
> > > On Nov 29, 2016, at 1:57 PM, Alessandro Bellina <
> abell...@yahoo-inc.com.INVALID <mailto:abell...@yahoo-inc.com.INVALID>>
> wrote:
> > >
> > > S G,
> > > I am slowly making progress and plan to share something this week,
> specifically for hooking up a default codahale reporter to the workers.
> Also the U of I students for the open source class have made progress on
> their rocksdb implementation for the default store (the stuff I am doing
> should feed into their store). I don't think any of this is going to be in
> 1.1.0 given that it hasn't really been looked at by others, let alone
> reviewed.
> > > Thanks
> > > Alessandro
> > > On Monday, November 28, 2016, 4:51:34 PM CST, S G <
> sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> wrote:Hi,
> > >
> > > I see https://issues.apache.org/jira/browse/STORM-2153 <
> https://issues.apache.org/jira/browse/STORM-2153>being open for this
> > > and a lot of good discussion happening too.
> > > There is also a talk for releasing 1.1.0 version soon.
> > >
> > > So I just wanted to check if any metric related improvements will be
> > > available in 1.1.0.
> > > It would be great to try out these new improvemen

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

Hi Taylor
Please see latest commit in: https://github.com/abellina/storm/tree/reporters
Specifically inside: storm-core/src/jvm/org/apache/storm/metrics2
I have a default config that sets up a couple of reporters in default.yaml. The 
format is inline with what we discussed, but updated with what I suggested over 
the weekend. 
This is definitely a work in progress, but you should be able to instantiate 
reporters for your purposes.
Thanks,
Alessandro


On Monday, December 5, 2016, 1:26:41 PM CST, Alessandro Bellina 
<abell...@yahoo-inc.com.INVALID> wrote:Yes. Will PR this tonight Taylor. Thanks!
On Monday, December 5, 2016, 12:37:18 PM CST, P. Taylor Goetz 
<ptgo...@gmail.com> wrote:Alessandro,

Are you in a position to open a pull request against the metrics_v2 branch? I’d 
like to start integrating the work I’ve been doing with the reporter 
configuration stuff you have. If what you have is incomplete/WIP, that’s not a 
big deal as the metrics_v2 branch is a feature branch and we’ll have plenty of 
opportunities to clean things up.

-Taylor

> On Nov 29, 2016, at 3:27 PM, Alessandro Bellina <abell...@yahoo-inc.com> 
> wrote:
> 
> Taylor,
> 
> Ok maybe there is some effort duplication. For the config, I have the bare 
> minimum to get the default reporter up. I'll focus on that since you could 
> use it. Will update JIRA with more.
> 
> Alessandro
> 
> 
> - Forwarded Message -
> From: P. Taylor Goetz <ptgo...@gmail.com>
> To: "dev@storm.apache.org" <dev@storm.apache.org>
> Cc: S G <sg.online.em...@gmail.com>; na...@narendasan.com 
> <na...@narendasan.com>; Austin Chung <achun...@illinois.edu>
> Sent: Tuesday, November 29, 2016, 1:27:58 PM CST
> Subject: Re: Are storm metrics reported through JMX too?
> 
> Alessandro,
> 
> Where do you stand with the reporter configuration via the storm.yaml config 
> file?
> 
> I have metrics collection for workers and disruptor queues almost ready, but 
> now I’m looking for flexible configuration (right now I have reporters hard 
> coded).
> 
> -Taylor
> 
> > On Nov 29, 2016, at 1:57 PM, Alessandro Bellina 
> > <abell...@yahoo-inc.com.INVALID <mailto:abell...@yahoo-inc.com.INVALID>> 
> > wrote:
> > 
> > S G,
> > I am slowly making progress and plan to share something this week, 
> > specifically for hooking up a default codahale reporter to the workers. 
> > Also the U of I students for the open source class have made progress on 
> > their rocksdb implementation for the default store (the stuff I am doing 
> > should feed into their store). I don't think any of this is going to be in 
> > 1.1.0 given that it hasn't really been looked at by others, let alone 
> > reviewed.
> > Thanks
> > Alessandro
> > On Monday, November 28, 2016, 4:51:34 PM CST, S G 
> > <sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> wrote:Hi,
> > 
> > I see https://issues.apache.org/jira/browse/STORM-2153  
> > <https://issues.apache.org/jira/browse/STORM-2153>being open for this
> > and a lot of good discussion happening too.
> > There is also a talk for releasing 1.1.0 version soon.
> > 
> > So I just wanted to check if any metric related improvements will be
> > available in 1.1.0.
> > It would be great to try out these new improvements.
> > 
> > Thanks
> > SG
> > 
> > On Tue, Oct 18, 2016 at 8:57 PM, Abhishek Nigam <adn5...@gmail.com 
> > <mailto:adn5...@gmail.com>> wrote:
> > 
> >> Hi all,
> >> 
> >> I'm Abhishek Nigam, one of the students from the group at the University of
> >> Illinois; I'm really looking forward to working on this issue! We'll be
> >> sure to keep you all updated as to how we progress.
> >> 
> >> Cheers,
> >> --
> >> Abhishek
> >> 
> >> On Tue, Oct 18, 2016 at 1:23 PM Alessandro Bellina <abell...@yahoo-inc.com 
> >> <mailto:abell...@yahoo-inc.com>
> >>> 
> >> wrote:
> >> 
> >>> + Naren, Austin, and Abhishek, the students from the University of
> >>> Illinois Open Source class.
> >>> 
> >>> 
> >>> On Tuesday, October 11, 2016 11:48 PM, S G <sg.online.em...@gmail.com 
> >>> <mailto:sg.online.em...@gmail.com>>
> >>> wrote:
> >>> 
> >>> 
> >>> Response on this important issue is pretty good. I am happily surprised
> >> :)
> >>> 
> >>> I want to mention our strategy for extracting metrics from other
> >> products.
> >>> We use jolokia_proxy (https://

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

Yes. Will PR this tonight Taylor. Thanks!
On Monday, December 5, 2016, 12:37:18 PM CST, P. Taylor Goetz 
<ptgo...@gmail.com> wrote:Alessandro,

Are you in a position to open a pull request against the metrics_v2 branch? I’d 
like to start integrating the work I’ve been doing with the reporter 
configuration stuff you have. If what you have is incomplete/WIP, that’s not a 
big deal as the metrics_v2 branch is a feature branch and we’ll have plenty of 
opportunities to clean things up.

-Taylor

> On Nov 29, 2016, at 3:27 PM, Alessandro Bellina <abell...@yahoo-inc.com> 
> wrote:
> 
> Taylor,
> 
> Ok maybe there is some effort duplication. For the config, I have the bare 
> minimum to get the default reporter up. I'll focus on that since you could 
> use it. Will update JIRA with more.
> 
> Alessandro
> 
> 
> - Forwarded Message -
> From: P. Taylor Goetz <ptgo...@gmail.com>
> To: "dev@storm.apache.org" <dev@storm.apache.org>
> Cc: S G <sg.online.em...@gmail.com>; na...@narendasan.com 
> <na...@narendasan.com>; Austin Chung <achun...@illinois.edu>
> Sent: Tuesday, November 29, 2016, 1:27:58 PM CST
> Subject: Re: Are storm metrics reported through JMX too?
> 
> Alessandro,
> 
> Where do you stand with the reporter configuration via the storm.yaml config 
> file?
> 
> I have metrics collection for workers and disruptor queues almost ready, but 
> now I’m looking for flexible configuration (right now I have reporters hard 
> coded).
> 
> -Taylor
> 
> > On Nov 29, 2016, at 1:57 PM, Alessandro Bellina 
> > <abell...@yahoo-inc.com.INVALID <mailto:abell...@yahoo-inc.com.INVALID>> 
> > wrote:
> > 
> > S G,
> > I am slowly making progress and plan to share something this week, 
> > specifically for hooking up a default codahale reporter to the workers. 
> > Also the U of I students for the open source class have made progress on 
> > their rocksdb implementation for the default store (the stuff I am doing 
> > should feed into their store). I don't think any of this is going to be in 
> > 1.1.0 given that it hasn't really been looked at by others, let alone 
> > reviewed.
> > Thanks
> > Alessandro
> > On Monday, November 28, 2016, 4:51:34 PM CST, S G 
> > <sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> wrote:Hi,
> > 
> > I see https://issues.apache.org/jira/browse/STORM-2153  
> > <https://issues.apache.org/jira/browse/STORM-2153>being open for this
> > and a lot of good discussion happening too.
> > There is also a talk for releasing 1.1.0 version soon.
> > 
> > So I just wanted to check if any metric related improvements will be
> > available in 1.1.0.
> > It would be great to try out these new improvements.
> > 
> > Thanks
> > SG
> > 
> > On Tue, Oct 18, 2016 at 8:57 PM, Abhishek Nigam <adn5...@gmail.com 
> > <mailto:adn5...@gmail.com>> wrote:
> > 
> >> Hi all,
> >> 
> >> I'm Abhishek Nigam, one of the students from the group at the University of
> >> Illinois; I'm really looking forward to working on this issue! We'll be
> >> sure to keep you all updated as to how we progress.
> >> 
> >> Cheers,
> >> --
> >> Abhishek
> >> 
> >> On Tue, Oct 18, 2016 at 1:23 PM Alessandro Bellina <abell...@yahoo-inc.com 
> >> <mailto:abell...@yahoo-inc.com>
> >>> 
> >> wrote:
> >> 
> >>> + Naren, Austin, and Abhishek, the students from the University of
> >>> Illinois Open Source class.
> >>> 
> >>> 
> >>> On Tuesday, October 11, 2016 11:48 PM, S G <sg.online.em...@gmail.com 
> >>> <mailto:sg.online.em...@gmail.com>>
> >>> wrote:
> >>> 
> >>> 
> >>> Response on this important issue is pretty good. I am happily surprised
> >> :)
> >>> 
> >>> I want to mention our strategy for extracting metrics from other
> >> products.
> >>> We use jolokia_proxy (https://jolokia.org/features/proxy.html 
> >>> <https://jolokia.org/features/proxy.html>) to get
> >> JMX
> >>> beans from several softwares and feed them to telegraf. That way, we
> >> avoid
> >>> writing custom processors for all these different products.
> >>> 
> >>> Telegraf is quickly becoming a standard for metrics data. (Just see the
> >>> list of input plugins here:
> >>> https://github.com/influxdata/telegraf/tree/master/plugins/inputs 
> >>&

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

Taylor,
Ok maybe there is some effort duplication. For the config, I have the bare 
minimum to get the default reporter up. I'll focus on that since you could use 
it. Will update JIRA with more.
Alessandro

 - Forwarded Message -From: P. Taylor Goetz <ptgo...@gmail.com>To: 
"dev@storm.apache.org" <dev@storm.apache.org>Cc: S G 
<sg.online.em...@gmail.com>; na...@narendasan.com <na...@narendasan.com>; 
Austin Chung <achun...@illinois.edu>Sent: Tuesday, November 29, 2016, 1:27:58 
PM CST Subject: Re: Are storm metrics reported through JMX too? 
 Alessandro,

Where do you stand with the reporter configuration via the storm.yaml config 
file?

I have metrics collection for workers and disruptor queues almost ready, but 
now I’m looking for flexible configuration (right now I have reporters hard 
coded).

-Taylor

> On Nov 29, 2016, at 1:57 PM, Alessandro Bellina 
> <abell...@yahoo-inc.com.INVALID> wrote:
> 
> S G,
> I am slowly making progress and plan to share something this week, 
> specifically for hooking up a default codahale reporter to the workers. Also 
> the U of I students for the open source class have made progress on their 
> rocksdb implementation for the default store (the stuff I am doing should 
> feed into their store). I don't think any of this is going to be in 1.1.0 
> given that it hasn't really been looked at by others, let alone reviewed.
> Thanks
> Alessandro
> On Monday, November 28, 2016, 4:51:34 PM CST, S G <sg.online.em...@gmail.com> 
> wrote:Hi,
> 
> I see https://issues.apache.org/jira/browse/STORM-2153 being open for this
> and a lot of good discussion happening too.
> There is also a talk for releasing 1.1.0 version soon.
> 
> So I just wanted to check if any metric related improvements will be
> available in 1.1.0.
> It would be great to try out these new improvements.
> 
> Thanks
> SG
> 
> On Tue, Oct 18, 2016 at 8:57 PM, Abhishek Nigam <adn5...@gmail.com> wrote:
> 
>> Hi all,
>> 
>> I'm Abhishek Nigam, one of the students from the group at the University of
>> Illinois; I'm really looking forward to working on this issue! We'll be
>> sure to keep you all updated as to how we progress.
>> 
>> Cheers,
>> --
>> Abhishek
>> 
>> On Tue, Oct 18, 2016 at 1:23 PM Alessandro Bellina <abell...@yahoo-inc.com
>>> 
>> wrote:
>> 
>>> + Naren, Austin, and Abhishek, the students from the University of
>>> Illinois Open Source class.
>>> 
>>> 
>>> On Tuesday, October 11, 2016 11:48 PM, S G <sg.online.em...@gmail.com>
>>> wrote:
>>> 
>>> 
>>> Response on this important issue is pretty good. I am happily surprised
>> :)
>>> 
>>> I want to mention our strategy for extracting metrics from other
>> products.
>>> We use jolokia_proxy (https://jolokia.org/features/proxy.html) to get
>> JMX
>>> beans from several softwares and feed them to telegraf. That way, we
>> avoid
>>> writing custom processors for all these different products.
>>> 
>>> Telegraf is quickly becoming a standard for metrics data. (Just see the
>>> list of input plugins here:
>>> https://github.com/influxdata/telegraf/tree/master/plugins/inputs). And
>> it
>>> integrates well with several outputs too (
>>> https://github.com/influxdata/telegraf/tree/master/plugins/outputs).
>>> 
>>> Also since the metrics in JMX, they can be queried by jolokia-agent
>>> installed per node. This avoids the extra metrics-consumer bolt which can
>>> hit the topology throughtput too.
>>> 
>>> So I cast my vote in favor of JMX-implementation of metrics.
>>> Other approaches are welcome to be discussed.
>>> 
>>> On Tue, Oct 11, 2016 at 7:30 PM, Alessandro Bellina <
>>> abell...@yahoo-inc.com.invalid> wrote:
>>> 
>>>>  blockquote, div.yahoo_quoted { margin-left: 0 !important;
>>> border-left:1px
>>>> #715FFA solid !important; padding-left:1ex !important;
>>>> background-color:white !important; } Yeap that's a requirement from our
>>>> perspective (working through this list).
>>>> Sure I think as usual we can start with master with an eye for what
>> would
>>>> need to be back ported.
>>>> Sent from Yahoo Mail for iPhone
>>>> 
>>>> 
>>>> On Tuesday, October 11, 2016, 8:50 PM, P. Taylor Goetz <
>>> ptgo...@gmail.com>
>>>> wrote:
>>>> 
>>>> I hope I didn't come across as overly critical. You did the best with
>>> w

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

S G,
I am slowly making progress and plan to share something this week, specifically 
for hooking up a default codahale reporter to the workers. Also the U of I 
students for the open source class have made progress on their rocksdb 
implementation for the default store (the stuff I am doing should feed into 
their store). I don't think any of this is going to be in 1.1.0 given that it 
hasn't really been looked at by others, let alone reviewed.
Thanks
Alessandro
On Monday, November 28, 2016, 4:51:34 PM CST, S G <sg.online.em...@gmail.com> 
wrote:Hi,

I see https://issues.apache.org/jira/browse/STORM-2153 being open for this
and a lot of good discussion happening too.
There is also a talk for releasing 1.1.0 version soon.

So I just wanted to check if any metric related improvements will be
available in 1.1.0.
It would be great to try out these new improvements.

Thanks
SG

On Tue, Oct 18, 2016 at 8:57 PM, Abhishek Nigam <adn5...@gmail.com> wrote:

> Hi all,
>
> I'm Abhishek Nigam, one of the students from the group at the University of
> Illinois; I'm really looking forward to working on this issue! We'll be
> sure to keep you all updated as to how we progress.
>
> Cheers,
> --
> Abhishek
>
> On Tue, Oct 18, 2016 at 1:23 PM Alessandro Bellina <abell...@yahoo-inc.com
> >
> wrote:
>
> > + Naren, Austin, and Abhishek, the students from the University of
> > Illinois Open Source class.
> >
> >
> > On Tuesday, October 11, 2016 11:48 PM, S G <sg.online.em...@gmail.com>
> > wrote:
> >
> >
> > Response on this important issue is pretty good. I am happily surprised
> :)
> >
> > I want to mention our strategy for extracting metrics from other
> products.
> > We use jolokia_proxy (https://jolokia.org/features/proxy.html) to get
> JMX
> > beans from several softwares and feed them to telegraf. That way, we
> avoid
> > writing custom processors for all these different products.
> >
> > Telegraf is quickly becoming a standard for metrics data. (Just see the
> > list of input plugins here:
> > https://github.com/influxdata/telegraf/tree/master/plugins/inputs). And
> it
> > integrates well with several outputs too (
> > https://github.com/influxdata/telegraf/tree/master/plugins/outputs).
> >
> > Also since the metrics in JMX, they can be queried by jolokia-agent
> > installed per node. This avoids the extra metrics-consumer bolt which can
> > hit the topology throughtput too.
> >
> > So I cast my vote in favor of JMX-implementation of metrics.
> > Other approaches are welcome to be discussed.
> >
> > On Tue, Oct 11, 2016 at 7:30 PM, Alessandro Bellina <
> > abell...@yahoo-inc.com.invalid> wrote:
> >
> > >  blockquote, div.yahoo_quoted { margin-left: 0 !important;
> > border-left:1px
> > > #715FFA solid !important; padding-left:1ex !important;
> > > background-color:white !important; } Yeap that's a requirement from our
> > > perspective (working through this list).
> > > Sure I think as usual we can start with master with an eye for what
> would
> > > need to be back ported.
> > > Sent from Yahoo Mail for iPhone
> > >
> > >
> > > On Tuesday, October 11, 2016, 8:50 PM, P. Taylor Goetz <
> > ptgo...@gmail.com>
> > > wrote:
> > >
> > > I hope I didn't come across as overly critical. You did the best with
> > what
> > > you had to work with. Which isn't pretty.
> > >
> > > We could potentially do a parallel metrics API in 1.1, 1.2, or master
> and
> > > still stay close to semantic versioning...?
> > >
> > > -Taylor
> > >
> > > > On Oct 11, 2016, at 9:28 PM, Jungtaek Lim <kabh...@gmail.com> wrote:
> > > >
> > > > Yeah I admit that configuration flag was bad for me also, but I have
> no
> > > > alternatives. Only way to avoid struggling with design limitation is
> > > revamp
> > > > / redesign.
> > > > Thanks S G for exposing willingness of volunteer and great news
> > > Alessandro
> > > > for that project.
> > > > Alessandro, could you forward the upcoming news for the project to
> dev@
> > > > list?
> > > >
> > > > - Jungtaek Lim (HeartSaVioR)
> > > >
> > > > 2016년 10월 12일 (수) 오전 10:22, P. Taylor Goetz <ptgo...@gmail.com>님이
> 작성:
> > > >
> > > >> I was thinking on a smaller scale in terms of effort, but the more I
> > > think
> > > >> about it, the more supportive I would be of a full r

Re: Storm UI does not load

[Alessandro Bellina]

Serkan
I think the screenshot would be useful. Mind filing a JIRA with the details?
This would help:- what version of chrome/firefox?- what page(s)?- output from 
the developer console.. if you have a line number/file that is really useful
I ran 1.0.2 UI locally and submitted a topology but was not able to reproduce 
the JS error in Chrome.
Thanks
Alessandro 

On Tuesday, October 25, 2016 6:44 PM, Serkan Uzunbaz  
wrote:
 

 Storm 1.0.2.

-Serkan

On Tue, Oct 25, 2016 at 4:26 PM, P. Taylor Goetz  wrote:

> What Storm version are you on?
>
> -Taylor
>
> > On Oct 25, 2016, at 7:01 PM, Serkan Uzunbaz  wrote:
> >
> > Hi all,
> > I am having a similar issue to the one in this old thread. I am having
> the issue in Firefox and clearing the cache did not work for me. I also
> tried in Chrome and the same thing happens there too.
> >
> > The issue is intermittent but I can trigger it after a few refresh of
> the Storm UI. Restarting the ui process (core) fixes the issue temporarily,
> then after a few refresh it happens again.
> >
> > The error in the firefox dev tools console is "SyntaxError: JSON.parse:
> unexpected end of data at line 1 column 1 of the JSON data".
> >
> > I am attaching the screenshots for the stuck UI and the error I get from
> the firefox dev tools console.
> >
> > Any suggestions?
> >
> > Thanks,
> > -Serkan
> >
> >> On Fri, Sep 4, 2015 at 4:33 AM, Matthias J. Sax 
> wrote:
> >> Clearing the cache did the trick! Thanks
> >>
> >> -Matthias
> >>
> >> On 09/03/2015 11:54 PM, 임정택 wrote:
> >> > Hi, Matthias.
> >> >
> >> > Could you clear Firefox cache and try again?
> >> > I met same issue from Chrome when I switch Storm's version from
> >> > 0.10.0-beta1 to 0.9.5 or opposite, and resolved that issue by clearing
> >> > cache.
> >> > If it doesn't work, how about checking any errors from Firefox
> developer
> >> > tool or Firebug and report to dev mailing list?
> >> >
> >> > Thanks,
> >> > Jungtaek Lim (HeartSaVioR)
> >> >
> >> > 2015-09-02 20:44 GMT+09:00 Matthias J. Sax <
> mj...@informatik.hu-berlin.de>:
> >> >
> >> >> Hi,
> >> >>
> >> >> I am running Debian Jessy in my laptop. Up to now I never had
> problems
> >> >> to access Storm UI via Iceweasel (ie, Debian's Firefox). But now,
> the UI
> >> >> does not load completely. It displays "Loading summary..." and the
> >> >> background is shaded. The cluster summary on top of the page is not
> >> >> rendered correctly. See attached screenshot.
> >> >>
> >> >> The UI loads without problems using Opera.
> >> >>
> >> >> I am building Storm from the sources using the current master version
> >> >> (0.11.0-SNAPSHOT). I just rebased. The last commit is
> >> >>
> >> >>> commit 154e9ec55deb4eea8fca8554e4d3b224bf337834
> >> >>
> >> >> I am not sure what the cause of the problem might be, but I do
> install
> >> >> available OS updates regularly. I guess that an update changed
> >> >> something. (Maybe an upgrade to a new version of Iceweasel?) The
> >> >> currently installed version is 31.8.0.
> >> >>
> >> >> Maybe anyone can reproduce the problem and have a look into it? For
> now,
> >> >> I just use Opera. So for me, it's not urgent.
> >> >>
> >> >>
> >> >> -Matthias
> >> >>
> >> >
> >> >
> >> >
> >>
> >
>

   

Re: Is this the list of metrics reported by storm in JMX?

[Alessandro Bellina]

T.I.

I ran jconsole and ended up with the same result for a worker.

That said, if you turn on JMX for the daemons you end up with a new MBean 
"metrics" (as given by storm.daemon.metrics.reporter.plugin.domain).  This is 
coming from: JmxPreparableReporter.


- For nimbus I see stuff like: num-getClusterInfo-calls for thrift calls. 
- For ui, I see metrics around the REST calls.
- For supervisor, currently I only see "num-slots-used-gauge".

Someone else please correct me if I've missed something.

Thanks

Alessandro





On Friday, October 14, 2016 12:58 AM, Tech Id  wrote:
Hi,

I know there are plans to revamp the current metrics system.
But until then, I just wanted to confirm the metrics I have got through JMX
and if that is expected.

I added the following to *worker.options*:

-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=1%ID% \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false

And I used  cmdline-jmxclient
's jar file as:
java -jar /tmp/cmdline-jmxclient-0.10.3.jar -:- 127.0.0.1:16700 | grep -v log4j
| sort -u


The metrics I got were:
com.sun.management:type=DiagnosticCommand
com.sun.management:type=HotSpotDiagnostic
java.lang:name=CodeCacheManager,type=MemoryManager
java.lang:name=Code Cache,type=MemoryPool
java.lang:name=Compressed Class Space,type=MemoryPool
java.lang:name=Metaspace Manager,type=MemoryManager
java.lang:name=Metaspace,type=MemoryPool
java.lang:name=PS Eden Space,type=MemoryPool
java.lang:name=PS MarkSweep,type=GarbageCollector
java.lang:name=PS Old Gen,type=MemoryPool
java.lang:name=PS Scavenge,type=GarbageCollector
java.lang:name=PS Survivor Space,type=MemoryPool
java.lang:type=ClassLoading
java.lang:type=Compilation
java.lang:type=Memory
java.lang:type=OperatingSystem
java.lang:type=Runtime
java.lang:type=Threading
java.nio:name=direct,type=BufferPool
java.nio:name=mapped,type=BufferPool
java.util.logging:type=Logging
JMImplementation:type=MBeanServerDelegate

None of these seems to be storm-specific and that is kind of expected
because storm does not report those metrics to JMX.
Can someone confirm if those really are the metrics I should expect or are
there more I can get from JMX?

Thanks
T.I.

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; } Yeap that's a requirement from our perspective (working through 
this list).
Sure I think as usual we can start with master with an eye for what would need 
to be back ported.
Sent from Yahoo Mail for iPhone


On Tuesday, October 11, 2016, 8:50 PM, P. Taylor Goetz  
wrote:

I hope I didn't come across as overly critical. You did the best with what you 
had to work with. Which isn't pretty.

We could potentially do a parallel metrics API in 1.1, 1.2, or master and still 
stay close to semantic versioning...?

-Taylor

> On Oct 11, 2016, at 9:28 PM, Jungtaek Lim  wrote:
> 
> Yeah I admit that configuration flag was bad for me also, but I have no
> alternatives. Only way to avoid struggling with design limitation is revamp
> / redesign.
> Thanks S G for exposing willingness of volunteer and great news Alessandro
> for that project.
> Alessandro, could you forward the upcoming news for the project to dev@
> list?
> 
> - Jungtaek Lim (HeartSaVioR)
> 
> 2016년 10월 12일 (수) 오전 10:22, P. Taylor Goetz 님이 작성:
> 
>> I was thinking on a smaller scale in terms of effort, but the more I think
>> about it, the more supportive I would be of a full revamp (new API) for
>> metrics based on Coda Hale's metrics library. It's proven and stable. I've
>> used it many times. I think either approach would be roughly the same
>> amount of work.
>> 
>> Some of the metrics API improvements in the 1.1.x branch are nice, but
>> IMHO are lipstick on a pig.
>> 
>> With apologies to Jungtaek, who has done amazing work all across the
>> codebase, I'm a little squeamish about the proposed change to metrics that
>> changes the consumer API based on a configuration flag (don't know the PR
>> number offhand).
>> 
>> I'm +1 for moving in this direction (revamped metrics). Let's end the
>> metrics pain.
>> 
>> -Taylor
>> 
>>> On Oct 11, 2016, at 10:15 AM, Bobby Evans 
>> wrote:
>>> 
>>> I agree that IMetricsConsumer is not good, but the reality is that all
>> of the metrics system needs to be redone.  The problem is that we ship an
>> object as a metric.  If I get an object I have no idea what it is hand
>> hence no idea how to report it or what to do with it.  What is more the
>> common types we use in the metrics we provide are really not enough.  For
>> example CountMetric sends a Long.  Well when I get it in the metrics
>> consumer I have no idea if I should report it like a counter or if I should
>> report it like a gauge (something that every metrics system I have used
>> wants to know).  But then we support pre-aggregation of the metrics with
>> IReducer so the number I get might be an average instead of either a gauge
>> or a counter, which no good metrics system will want to collect because I
>> cannot aggregate it with anything else, the math just does not work.
>>> The proposal I have said before and I still believe is that we need to
>> put in place a parallel metrics API/system.  We will deprecate all of
>> https://git.corp.yahoo.com/storm/storm/tree/master-security/storm-core/src/jvm/backtype/storm/metric/api
>> and create a new parallel one that provides an API similar to
>> http://metrics.dropwizard.io/3.1.0/.  I would even be fine in just using
>> their API and exposing that to end users.  Dropwizard has solved all of
>> these problems already and I don't see a reason to reinvent the wheel.  I
>> don't personally see a lot of value in trying to send all of the metrics
>> through storm itslef.  I am fine if we are able to support that, but it is
>> far from a requirement. - Bobby
>>> 
>>>  On Monday, October 10, 2016 10:47 PM, S G 
>> wrote:
>>> 
>>> 
>>> +1
>>> We can probably start by opening a JIRA for this and adding a design
>>> approach for the same?
>>> I would like to help in the coding-effort for this.
>>> 
>>> -SG
>>> 
 On Mon, Oct 10, 2016 at 1:51 PM, P. Taylor Goetz 
>> wrote:
 
 I’ve been thinking about metrics lately, specifically the fact that
>> people
 tend to struggle with implementing a metrics consumer. (Like this one
>> [1]).
 
 The IMetricsConsumer interface is pretty low level, and common
 aggregations, calculations, etc. are left up to each individual
 implementation. That seems like an area where further abstraction would
 make it easier to support different back ends (Graphite, JMX, Splunk,
>> etc.).
 
 My thought is to create an abstract IMetricsConsumer implementation that
 does common aggregations and calculations, and then delegates to a
>> plugable
 “metrics sink” implementation (e.g. “IMetricsSink”, etc.). That would
 greatly simplify the effort required to integrate with various external
 metrics systems. I know of at least a few users that 

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; }  Sounds great S G. Thanks for pointers Jungtaek. 
We were approached by a group of students from the University of Illinois who 
are working on an open source class this semester. We proposed revamping stats 
to them as a project. They'll focus will be more along the lines of getting the 
out of the box metrics to work using rocks db initially, then move to remove 
stats from zookeeper if they have time. The idea being to make meaningful steps 
towards a new metrics system or parts of it. Getting help, direction, and 
working with the community is exactly the type of experience they were hoping 
to get.
I am spending time looking at the two metrics systems in storm today, jstorm's 
approach, and anything else I can get my hands on. I'm going to help mentor the 
group with the help of others at Yahoo. So I also volunteer for this task.
Thanks,
Alessandro

Sent from Yahoo Mail for iPhone


On Tuesday, October 11, 2016, 7:34 PM, S G <sg.online.em...@gmail.com> wrote:

I would like to volunteer for this (Have contributed to Solr, Avro and Hive
previously).
But I would need a little guidance initially to get started because I
haven't dug too deep in storm's code-base.

-SG



On Tue, Oct 11, 2016 at 3:52 PM, Jungtaek Lim <kabh...@gmail.com> wrote:

> Alessandro, that was before Verisign introduced storm-graphite. In result
> he
> followed Storm's metric system.
>
> I initiated the discussion around metrics several times (mostly first half
> of this year), and from many times the results were that all the metrics
> interfaces are not good and we need to rework. Finding a way with resorting
> current interface doesn't help.
> How we renew the metrics system is the matter. I was waiting on phase of
> JStorm merger so that we can evaluate JStorm's new metrics system. I guess
> adopting that is enough changes but I saw that Alibaba met memory issue.
> How they handle this seems not exposed. For me the thing is JStorm merger
> is going really slow (nearly stopped), so going to phase 2 might not happen
> on this year.
> For seeking other ways, I guess Kafka and Flink renews their metrics
> (KafkaStream for Kafka) so we may want to take a look.
>
> Anyway, someone volunteer to renew metrics system via Dropwizard or JStorm
> metrics it would be awesome. I'm focused to improve Storm SQL and there's
> no other active contributor on Storm SQL yet so I couldn't look at the
> other side.
>
> - Jungtaek Lim (HeartSaVioR)
>
> 2016년 10월 12일 (수) 오전 3:15, Alessandro Bellina
> <abell...@yahoo-inc.com.invalid>님이 작성:
>
> > sorry, hopefully the link goes through now:
> > http://www.michael-noll.com/blog/2013/11/06/sending-
> metrics-from-storm-to-graphite
> >
> >
> > Sending Metrics from Storm to Graphite - Michael G. Noll
> > By Michael G. Noll
> > Sending application-level metrics from Storm topologies to the Graphite
> > monitoring system
> >
> >
> >
> > On Tuesday, October 11, 2016 1:13 PM, Alessandro Bellina <
> > abell...@yahoo-inc.com.INVALID> wrote:
> >
> >
> >
> > I think what Bobby is referring to is that the metrics consumer is
> another
> > bolt, so stats are flowing through storm.
> > What does changing the model to polling buy us? I could see cases were
> > we'd need more error handling for instance slow/busy workers.
> > If we think that writing a new system is the way to go (say with codahale
> > throughout), would working on an abstraction layer that is used by the
> > daemons but also by end-users be a good place to start? With codahale as
> > the implementation?
> > Looks like Michael Noll has done a lot work with codahale, for instance:
> > Sending Metrics from Storm to Graphite - Michael G. Noll.
> >
> > |
> > |
> > |
> > |  |    |
> >
> >  |
> >
> >  |
> > |
> > |  |
> > Sending Metrics from Storm to Graphite - Michael G. Noll
> > By Michael G. Noll Sending application-level metrics from Storm
> topologies
> > to the Graphite monitoring system  |  |
> >
> >  |
> >
> >  |
> >
> >
> >
> > Thanks,
> > Alessandro
> >    On Tuesday, October 11, 2016 11:07 AM, S G <
> sg.online.em...@gmail.com>
> > wrote:
> >
> >
> >
> > "Dropwizard has solved all of these problems already and I don't see a
> > reason to reinvent the wheel" - I love dropwizard too and many of the
> other
> > tools have switched to using the same too.
> >
> > "I don't personally see a lot of value 

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

sorry, hopefully the link goes through now: 
http://www.michael-noll.com/blog/2013/11/06/sending-metrics-from-storm-to-graphite

   
Sending Metrics from Storm to Graphite - Michael G. Noll
By Michael G. Noll
Sending application-level metrics from Storm topologies to the Graphite 
monitoring system   



On Tuesday, October 11, 2016 1:13 PM, Alessandro Bellina 
<abell...@yahoo-inc.com.INVALID> wrote:



I think what Bobby is referring to is that the metrics consumer is another 
bolt, so stats are flowing through storm.
What does changing the model to polling buy us? I could see cases were we'd 
need more error handling for instance slow/busy workers.
If we think that writing a new system is the way to go (say with codahale 
throughout), would working on an abstraction layer that is used by the daemons 
but also by end-users be a good place to start? With codahale as the 
implementation?
Looks like Michael Noll has done a lot work with codahale, for instance: 
Sending Metrics from Storm to Graphite - Michael G. Noll.
  
|  
|  
|  
|   ||

  |

  |
|  
|   |  
Sending Metrics from Storm to Graphite - Michael G. Noll
By Michael G. Noll Sending application-level metrics from Storm topologies to 
the Graphite monitoring system  |   |

  |

  |



Thanks,
Alessandro
On Tuesday, October 11, 2016 11:07 AM, S G <sg.online.em...@gmail.com> 
wrote:



"Dropwizard has solved all of these problems already and I don't see a
reason to reinvent the wheel" - I love dropwizard too and many of the other
tools have switched to using the same too.

"I don't personally see a lot of value in trying to send all of the metrics
through storm itself" - How about every node reporting its own metrics by a
URL ? That ways there is no need for a metrics-consumer that can bottleneck
the whole topology. We can then provide a separate server that can query
all nodes to get those metrics and aggregate them. Only cluster wide
metrics should be reported by the storm-UI's REST API (assuming there are
not too many of those).

On Tue, Oct 11, 2016 at 7:15 AM, Bobby Evans <ev...@yahoo-inc.com.invalid>
wrote:

> I agree that IMetricsConsumer is not good, but the reality is that all of
> the metrics system needs to be redone.  The problem is that we ship an
> object as a metric.  If I get an object I have no idea what it is hand
> hence no idea how to report it or what to do with it.  What is more the
> common types we use in the metrics we provide are really not enough.  For
> example CountMetric sends a Long.  Well when I get it in the metrics
> consumer I have no idea if I should report it like a counter or if I should
> report it like a gauge (something that every metrics system I have used
> wants to know).  But then we support pre-aggregation of the metrics with
> IReducer so the number I get might be an average instead of either a gauge
> or a counter, which no good metrics system will want to collect because I
> cannot aggregate it with anything else, the math just does not work.
> The proposal I have said before and I still believe is that we need to put
> in place a parallel metrics API/system.  We will deprecate all of
> https://git.corp.yahoo.com/storm/storm/tree/master-
> security/storm-core/src/jvm/backtype/storm/metric/api and create a new
> parallel one that provides an API similar to http://metrics.dropwizard.
> io/3.1.0/.  I would even be fine in just using their API and exposing
> that to end users.  Dropwizard has solved all of these problems already and
> I don't see a reason to reinvent the wheel.  I don't personally see a lot
> of value in trying to send all of the metrics through storm itslef.  I am
> fine if we are able to support that, but it is far from a requirement. -
> Bobby
>
>On Monday, October 10, 2016 10:47 PM, S G <sg.online.em...@gmail.com>
> wrote:
>
>
>  +1
> We can probably start by opening a JIRA for this and adding a design
> approach for the same?
> I would like to help in the coding-effort for this.
>
> -SG
>
> On Mon, Oct 10, 2016 at 1:51 PM, P. Taylor Goetz <ptgo...@gmail.com>
> wrote:
>
> > I’ve been thinking about metrics lately, specifically the fact that
> people
> > tend to struggle with implementing a metrics consumer. (Like this one
> [1]).
> >
> > The IMetricsConsumer interface is pretty low level, and common
> > aggregations, calculations, etc. are left up to each individual
> > implementation. That seems like an area where further abstraction would
> > make it easier to support different back ends (Graphite, JMX, Splunk,
> etc.).
> >
> > My thought is to create an abstract IMetricsConsumer implementation that
> > does common aggregations and calculations, and then delegates to a
> plugable
> > “metrics sink” implementation (e.g. “IMetricsSin

Re: Are storm metrics reported through JMX too?

[Alessandro Bellina]

I think what Bobby is referring to is that the metrics consumer is another 
bolt, so stats are flowing through storm.
What does changing the model to polling buy us? I could see cases were we'd 
need more error handling for instance slow/busy workers.
If we think that writing a new system is the way to go (say with codahale 
throughout), would working on an abstraction layer that is used by the daemons 
but also by end-users be a good place to start? With codahale as the 
implementation?
Looks like Michael Noll has done a lot work with codahale, for instance: 
Sending Metrics from Storm to Graphite - Michael G. Noll.
  
|  
|  
|  
|   ||

  |

  |
|  
|   |  
Sending Metrics from Storm to Graphite - Michael G. Noll
 By Michael G. Noll Sending application-level metrics from Storm topologies to 
the Graphite monitoring system  |   |

  |

  |

 

Thanks,
Alessandro
On Tuesday, October 11, 2016 11:07 AM, S G  
wrote:
 

 "Dropwizard has solved all of these problems already and I don't see a
reason to reinvent the wheel" - I love dropwizard too and many of the other
tools have switched to using the same too.

"I don't personally see a lot of value in trying to send all of the metrics
through storm itself" - How about every node reporting its own metrics by a
URL ? That ways there is no need for a metrics-consumer that can bottleneck
the whole topology. We can then provide a separate server that can query
all nodes to get those metrics and aggregate them. Only cluster wide
metrics should be reported by the storm-UI's REST API (assuming there are
not too many of those).

On Tue, Oct 11, 2016 at 7:15 AM, Bobby Evans 
wrote:

> I agree that IMetricsConsumer is not good, but the reality is that all of
> the metrics system needs to be redone.  The problem is that we ship an
> object as a metric.  If I get an object I have no idea what it is hand
> hence no idea how to report it or what to do with it.  What is more the
> common types we use in the metrics we provide are really not enough.  For
> example CountMetric sends a Long.  Well when I get it in the metrics
> consumer I have no idea if I should report it like a counter or if I should
> report it like a gauge (something that every metrics system I have used
> wants to know).  But then we support pre-aggregation of the metrics with
> IReducer so the number I get might be an average instead of either a gauge
> or a counter, which no good metrics system will want to collect because I
> cannot aggregate it with anything else, the math just does not work.
> The proposal I have said before and I still believe is that we need to put
> in place a parallel metrics API/system.  We will deprecate all of
> https://git.corp.yahoo.com/storm/storm/tree/master-
> security/storm-core/src/jvm/backtype/storm/metric/api and create a new
> parallel one that provides an API similar to http://metrics.dropwizard.
> io/3.1.0/.  I would even be fine in just using their API and exposing
> that to end users.  Dropwizard has solved all of these problems already and
> I don't see a reason to reinvent the wheel.  I don't personally see a lot
> of value in trying to send all of the metrics through storm itslef.  I am
> fine if we are able to support that, but it is far from a requirement. -
> Bobby
>
>    On Monday, October 10, 2016 10:47 PM, S G 
> wrote:
>
>
>  +1
> We can probably start by opening a JIRA for this and adding a design
> approach for the same?
> I would like to help in the coding-effort for this.
>
> -SG
>
> On Mon, Oct 10, 2016 at 1:51 PM, P. Taylor Goetz 
> wrote:
>
> > I’ve been thinking about metrics lately, specifically the fact that
> people
> > tend to struggle with implementing a metrics consumer. (Like this one
> [1]).
> >
> > The IMetricsConsumer interface is pretty low level, and common
> > aggregations, calculations, etc. are left up to each individual
> > implementation. That seems like an area where further abstraction would
> > make it easier to support different back ends (Graphite, JMX, Splunk,
> etc.).
> >
> > My thought is to create an abstract IMetricsConsumer implementation that
> > does common aggregations and calculations, and then delegates to a
> plugable
> > “metrics sink” implementation (e.g. “IMetricsSink”, etc.). That would
> > greatly simplify the effort required to integrate with various external
> > metrics systems. I know of at least a few users that would be interested,
> > one is currently scraping the logs from LoggingMetricsConsumer and
> polling
> > the Storm REST API for their metrics.
> >
> > -Taylor
> >
> > [1] http://twocentsonsoftware.blogspot.co.il/2014/12/
> > sending-out-storm-metrics.html
> >
> >
> > > On Oct 10, 2016, at 12:14 PM, Bobby Evans  >
> > wrote:
> > >
> > > First of all the server exposes essentially the same interface that the
> > IMetricsConsumer exposes.  It mostly just adds a 

[jira] [Created] (STORM-2078) Enable paging in worker data tables

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-2078:
-

 Summary: Enable paging in worker data tables
 Key: STORM-2078
 URL: https://issues.apache.org/jira/browse/STORM-2078
 Project: Apache Storm
  Issue Type: Improvement
Reporter: Alessandro Bellina
Assignee: Alessandro Bellina
Priority: Minor


Currently worker data tables can get really long, with many workers per 
topology, or many workers per supervisor. This will enable paging to make it 
more manageable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-2066) Fix scheduler status when in isolation and running with less slots than requested

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-2066:
-

 Summary: Fix scheduler status when in isolation and running with 
less slots than requested
 Key: STORM-2066
 URL: https://issues.apache.org/jira/browse/STORM-2066
 Project: Apache Storm
  Issue Type: Bug
Reporter: Alessandro Bellina






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-2066) Fix scheduler status when in isolation and running with less slots than requested

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-2066:
-

Assignee: Alessandro Bellina

> Fix scheduler status when in isolation and running with less slots than 
> requested
> -
>
> Key: STORM-2066
> URL: https://issues.apache.org/jira/browse/STORM-2066
> Project: Apache Storm
>  Issue Type: Bug
>    Reporter: Alessandro Bellina
>        Assignee: Alessandro Bellina
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-2064) Add storm name and function, access result and function to log-thrift-access

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-2064:
-

Assignee: Alessandro Bellina

> Add storm name and function, access result and function to log-thrift-access
> 
>
> Key: STORM-2064
> URL: https://issues.apache.org/jira/browse/STORM-2064
> Project: Apache Storm
>  Issue Type: Bug
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Improves overall usefulness of the thrift access log.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-2064) Add storm name and function, access result and function to log-thrift-access

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-2064:
-

 Summary: Add storm name and function, access result and function 
to log-thrift-access
 Key: STORM-2064
 URL: https://issues.apache.org/jira/browse/STORM-2064
 Project: Apache Storm
  Issue Type: Bug
Reporter: Alessandro Bellina
Priority: Minor


Improves overall usefulness of the thrift access log.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-2063) Add thread name in worker logs

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-2063:
-

 Summary: Add thread name in worker logs
 Key: STORM-2063
 URL: https://issues.apache.org/jira/browse/STORM-2063
 Project: Apache Storm
  Issue Type: Improvement
Reporter: Alessandro Bellina
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1949) Backpressure can cause spout to stop emitting and stall topology

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15430073#comment-15430073
 ] 

Alessandro Bellina commented on STORM-1949:
---

I replicated a halted topology using my own WordCount but the way I got it to 
halt was to set the receive buffer size to be very small 4. 

I took a heap dump of the worker that was set in the backpressure znode and 
found that one of the executors had the backpressure atomic variable set to 
true, while the disruptor queue's _throttleOn was false.

I tried running the same topology with the executor-specific change in 
https://github.com/apache/storm/pull/1632, and it didn't halt. That change 
removes the backpressure atomic variable, in favor of the disruptor's 
_throttleOn. However, this needs more testing. I'll try other things tomorrow 
and comment here.

> Backpressure can cause spout to stop emitting and stall topology
> 
>
> Key: STORM-1949
> URL: https://issues.apache.org/jira/browse/STORM-1949
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Roshan Naik
>    Assignee: Alessandro Bellina
> Attachments: 1.x-branch-works-perfect.png
>
>
> Problem can be reproduced by this [Word count 
> topology|https://github.com/hortonworks/storm/blob/perftopos1.x/examples/storm-starter/src/jvm/org/apache/storm/starter/perf/FileReadWordCountTopo.java]
> within a IDE.
> I ran it with 1 spout instance, 2 splitter bolt instances, 2 counter bolt 
> instances.
> The problem is more easily reproduced with WC topology as it causes an 
> explosion of tuples due to splitting a sentence tuple into word tuples. As 
> the bolts have to process more tuples than the  spout is producing, spout 
> needs to operate slower.
> The amount of time it takes for the topology to stall can vary.. but 
> typically under 10 mins. 
> *My theory:*  I suspect there is a race condition in the way ZK is being 
> utilized to enable/disable back pressure. When congested (i.e pressure 
> exceeds high water mark), the bolt's worker records this congested situation 
> in ZK by creating a node. Once the congestion is reduced below the low water 
> mark, it deletes this node. 
> The spout's worker has setup a watch on the parent node, expecting a callback 
> whenever there is change in the child nodes. On receiving the callback the 
> spout's worker lists the parent node to check if there are 0 or more child 
> nodes it is essentially trying to figure out the nature of state change 
> in ZK to determine whether to throttle or not. Subsequently  it setsup 
> another watch in ZK to keep an eye on future changes.
> When there are multiple bolts, there can be rapid creation/deletion of these 
> ZK nodes. Between the time the worker receives a callback and sets up the 
> next watch.. many changes may have undergone in ZK which will go unnoticed by 
> the spout. 
> The condition that the bolts are no longer congested may not get noticed as a 
> result of this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-1949) Backpressure can cause spout to stop emitting and stall topology

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-1949:
-

Assignee: Alessandro Bellina

> Backpressure can cause spout to stop emitting and stall topology
> 
>
> Key: STORM-1949
> URL: https://issues.apache.org/jira/browse/STORM-1949
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Roshan Naik
>    Assignee: Alessandro Bellina
> Attachments: 1.x-branch-works-perfect.png
>
>
> Problem can be reproduced by this [Word count 
> topology|https://github.com/hortonworks/storm/blob/perftopos1.x/examples/storm-starter/src/jvm/org/apache/storm/starter/perf/FileReadWordCountTopo.java]
> within a IDE.
> I ran it with 1 spout instance, 2 splitter bolt instances, 2 counter bolt 
> instances.
> The problem is more easily reproduced with WC topology as it causes an 
> explosion of tuples due to splitting a sentence tuple into word tuples. As 
> the bolts have to process more tuples than the  spout is producing, spout 
> needs to operate slower.
> The amount of time it takes for the topology to stall can vary.. but 
> typically under 10 mins. 
> *My theory:*  I suspect there is a race condition in the way ZK is being 
> utilized to enable/disable back pressure. When congested (i.e pressure 
> exceeds high water mark), the bolt's worker records this congested situation 
> in ZK by creating a node. Once the congestion is reduced below the low water 
> mark, it deletes this node. 
> The spout's worker has setup a watch on the parent node, expecting a callback 
> whenever there is change in the child nodes. On receiving the callback the 
> spout's worker lists the parent node to check if there are 0 or more child 
> nodes it is essentially trying to figure out the nature of state change 
> in ZK to determine whether to throttle or not. Subsequently  it setsup 
> another watch in ZK to keep an eye on future changes.
> When there are multiple bolts, there can be rapid creation/deletion of these 
> ZK nodes. Between the time the worker receives a callback and sets up the 
> next watch.. many changes may have undergone in ZK which will go unnoticed by 
> the spout. 
> The condition that the bolts are no longer congested may not get noticed as a 
> result of this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1949) Backpressure can cause spout to stop emitting and stall topology

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429427#comment-15429427
 ] 

Alessandro Bellina commented on STORM-1949:
---

[~roshan_naik] I was going to run your example to reproduce but the link 
doesn't work anymore. Can you provide an updated link?

> Backpressure can cause spout to stop emitting and stall topology
> 
>
> Key: STORM-1949
> URL: https://issues.apache.org/jira/browse/STORM-1949
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Roshan Naik
> Attachments: 1.x-branch-works-perfect.png
>
>
> Problem can be reproduced by this [Word count 
> topology|https://github.com/hortonworks/storm/blob/perftopos1.x/examples/storm-starter/src/jvm/org/apache/storm/starter/perf/FileReadWordCountTopo.java]
> within a IDE.
> I ran it with 1 spout instance, 2 splitter bolt instances, 2 counter bolt 
> instances.
> The problem is more easily reproduced with WC topology as it causes an 
> explosion of tuples due to splitting a sentence tuple into word tuples. As 
> the bolts have to process more tuples than the  spout is producing, spout 
> needs to operate slower.
> The amount of time it takes for the topology to stall can vary.. but 
> typically under 10 mins. 
> *My theory:*  I suspect there is a race condition in the way ZK is being 
> utilized to enable/disable back pressure. When congested (i.e pressure 
> exceeds high water mark), the bolt's worker records this congested situation 
> in ZK by creating a node. Once the congestion is reduced below the low water 
> mark, it deletes this node. 
> The spout's worker has setup a watch on the parent node, expecting a callback 
> whenever there is change in the child nodes. On receiving the callback the 
> spout's worker lists the parent node to check if there are 0 or more child 
> nodes it is essentially trying to figure out the nature of state change 
> in ZK to determine whether to throttle or not. Subsequently  it setsup 
> another watch in ZK to keep an eye on future changes.
> When there are multiple bolts, there can be rapid creation/deletion of these 
> ZK nodes. Between the time the worker receives a callback and sets up the 
> next watch.. many changes may have undergone in ZK which will go unnoticed by 
> the spout. 
> The condition that the bolts are no longer congested may not get noticed as a 
> result of this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Discussion] Stopping feature development for storm-core on 1.x-branch

[Alessandro Bellina]

Just a contributors point of view..
I think the idea to reclaim jiras that are assigned but without progress is a 
good one. After that is done, in order to not end up in the same place, I think 
after a task gets assigned it needs to be given a due date (something sane), 
and updated periodically if it is a long task (e.g. port nimbus). The policy 
being that if after the due date not meaningful progress is made, then the 
assignment should be given away to someone else or put back in the unassigned 
pile. 
Port/merge issues which are assigned, but don't have "ASF GitHub" watching them 
(so no PR it looks like):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20in%20(java-migration%2C%20jstorm-merger)%20AND%20assignee%20!%3D%20EMPTY%20and%20watcher%20not%20in%20(%22ASF%20GitHub%20Bot%22)
I think freezing feature development in master is too extreme. Instead, I think 
that as part of the code review checks, if we see changes to a file and it is 
currently under a port task which isn't past due or stalled, then the PR should 
be held back and submitter informed that the file they are modifying is truly 
being ported. This, in turn, puts the ball back on the court of the person 
doing the porting, as it should, and hopefully gives the submitter a due date 
after which they can PR a ported change. If the porting task is stalled, I see 
no reason why the PR shouldn't be considered immediately. That said, something 
tells me this is hard to implement.
Thanks,
Alessandro


On Wednesday, August 17, 2016 8:54 PM, Jungtaek Lim  
wrote:
 

 I'm OK to stop feature dev. for storm-core on 1.x branch. As Taylor said
that was the original plan, and we broke it.
We even might need to stop feature development for storm-core on 'master'
if it touches un-ported files, but it would tend to break so I couldn't
claim that.

Moreover, I propose unassigning all issues regarding port if pull request
is not open, and go on with 'no assignee' or 'competitive assignee' for
porting related issues. We had been set assignee for the issues, and
assignee holds it even though he/she can't or don't work on that for a long
time.

Before stopping, I'd like to include STORM-2016
 to 1.x version line.
(target for 1.1.0)

- This will heavily affect to upcoming storm-sql improvements (I'd say that
without STORM-2016 we even have very hard time to launch storm-sql runner)
- This will help avoiding to copy libraries (and its transitive
dependencies) to extlib directory when it's necessary for only some of
topologies. Clear example is STORM-1881
.
- This will give great flexibility to configure user topology jar and
submit topology.

Thanks,
Jungtaek Lim (HeartSaVioR)

2016년 8월 17일 (수) 오후 11:58, P. Taylor Goetz 님이 작성:

> I agree, and that was the original plan.
>
> However, the clojure to java migration stalled for a number of reasons
> (peoples’ $dayjob responsibilities can change often and affect the amount
> of time they have to contribute to the project — this is to be expected and
> not considered a problem.). Prior to “feature freezing” the 1.x line, I
> think we should get 1.1.0 released. In my opinion the only remaining issue
> for the release is a resolution to STORM-2006, particularly adding an
> interface for aggregated metrics.
>
> I don’t have a good feel for how long it will take to get the master
> branch (aka “2.0”) in a releasable state (again it comes down to
> contributor $dayjobs, which are largely out of anyone’s control). So I
> think we should plan on supporting 1.x for a while.
>
> -Taylor
>
> > On Aug 16, 2016, at 10:40 PM, Harsha Chintalapani 
> wrote:
> >
> > Hi All,
> >          Currently we are undertaken JStorm merger and ongoing migration
> > of existing Clojure code. I am proposing that we should stop any feature
> > development for 1.x branch so that we can make progress on java migration
> > and get it done before adding any further features. If any one interested
> > adding features they can do so on master for 2.0.
> >            This will give us time to complete the migration and keeps the
> > core code more or less the same . Adding more code to core makes the
> > migration that much harder.
> > We should be ok on adding any connectors or so as that can be independent
> > of core and can be easily added to master.
> >            What you think?
> >
> > Thanks,
> > Harsha
>
>

  

[jira] [Assigned] (STORM-2039) Backpressure refactoring in worker and executor

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-2039:
-

Assignee: Alessandro Bellina

> Backpressure refactoring in worker and executor
> ---
>
> Key: STORM-2039
> URL: https://issues.apache.org/jira/browse/STORM-2039
> Project: Apache Storm
>  Issue Type: Story
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
>
> * Use backpressure flags directly from disruptor queue instead of in the 
> disruptor-backpressure-handlers in worker and executor
> * Other minor refactoring (eliminate redundant function)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-2035) Surface supervisor configs to nimbus for serving to UI

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-2035:
-

 Summary: Surface supervisor configs to nimbus for serving to UI
 Key: STORM-2035
 URL: https://issues.apache.org/jira/browse/STORM-2035
 Project: Apache Storm
  Issue Type: Improvement
Reporter: Alessandro Bellina
Priority: Minor


The idea for this came from [~kabhwan] in PR 
https://github.com/apache/storm/pull/1592.

It is to show in the supervisor page the host's config. This is not available 
to the UI backend or to nimbus right now, so it would mean a new communication 
path to obtain the configs.

Should this be stored in ZK? It is the only link currently, so either 
supervisor adds a new link or ZK gets the config.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-2034) Remove Show System Stats button and refactor UI accordingly

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-2034:
-

 Summary: Remove Show System Stats button and refactor UI 
accordingly
 Key: STORM-2034
 URL: https://issues.apache.org/jira/browse/STORM-2034
 Project: Apache Storm
  Issue Type: Improvement
Reporter: Alessandro Bellina
Priority: Minor


Removing the button and instead refactoring UI to distinguish between system 
vs. user stats gets us:

# no need to switch back and forth between showing or hiding system stats, it 
is all in one screen at all the time.
# less logic in core and stats dealing with the sys filtering
# consistency fixes that will come as a result of this (at times we hide system 
workers, but we don't hide system executors, etc.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-2024) Add local store autocomplete to the logger name input field as a convenience (dynamic log level settings)

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-2024:
-

 Summary: Add local store autocomplete to the logger name input 
field as a convenience (dynamic log level settings)
 Key: STORM-2024
 URL: https://issues.apache.org/jira/browse/STORM-2024
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-ui
Reporter: Alessandro Bellina
Priority: Minor


The UI should remember previous logger names I use when setting dynamic log 
levels, much like on form submit when the input fields are autocompleted by 
browsers.

In order to implement this in Storm UI, we'd have to use an autocomplete input 
field like Selectize, and store previous entries in Local Storage. These would 
trigger on the dynamic log level action (Add) so that when you add something, 
the value gets cached.

We'd then take that and prepulate the Selectize control as a convenience.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Question about Storm UI

[Alessandro Bellina]

Sorry about that, attached on this email. The chart is pretty simple/bare 
bones. 

On Sunday, July 31, 2016 5:25 PM, Jungtaek Lim <kabh...@gmail.com> wrote:
 

 Inline image seems broken. Could you make it available?
Regarding internal storage, below is what I observed from other projects while 
working with metrics.JStorm is using RocksDB in Nimbus to store metrics 
internally (only given time frame), and provide plugin to store metrics to 
external storages. That said, all metrics are in result sent to Nimbus and 
handled, which is different from Storm metrics feature.And Heron runs separate 
process, Metrics Manager, which stores topology's metrics via in memory, and 
expose REST APIs to query. But it seems limited to serve only recent 3 hours. 
For longer data Heron also exposes metrics sink (like a metrics consumer) to 
store metrics to external storages. 
For external storages I think it should be selectable since it requires users 
to set up. We just have to think about how to store metrics without installing 
external things (having limitations are fine), and how to represent them.
For UI perspective, linking to Grafana is what Heron is providing. I didn't 
give it a try but it might be better to take a look at. 
Btw, IMO, if we can show dashboards without dependencies that would be amazing, 
and having some dependencies which are easy to install and maintain would be 
still nice.
Thanks,Jungtaek Lim (HeartSaVioR)

2016년 8월 1일 (월) 오전 1:43, Alessandro Bellina <abell...@yahoo-inc.com.invalid>님이 
작성:


HeartSaVIoR
This is different than STORM-1994. By the way added some screenshots there to 
clarify.
I agree it would be good to reorganize the statistics shown in the UI. Perhaps 
having two parts to this, one goes to a dashboard like Grafana, while the 
simpler metrics (snapshots, or aggregations) go to the regular Storm UI. The 
reason for some of them going to the Storm UI is that I think that having some 
stats next to the place where actions can be performed on a topology is 
beneficial (as they currently are).
With regards to Jerry's suggestion, we tried a simple test using MySQL just as 
a PoC and c3/d3 as the charting library. The choices were made purely because 
we wanted to see the charts quickly, so not suggesting we use MySQL for time 
series data. We know probably storing in Druid or another time series database 
would be ideal, but harder to set up. Here is a screenshot showing average user 
cpu time (ms) per minute for each worker:


We could probably then turn around and request data from Druid (or more 
generally, the "metrics store") and show in the Storm UI. Additionally, Grafana 
looks like it can read from Druid, so folks could use that as a front end for 
detailed dashboards. That said, perhaps some version of this in the Topology 
page at a coarser resolution would be beneficial for a quick glimpse, linking 
to the detailed dashboard.
Thanks,
Alessandro
 

On Sunday, July 31, 2016 1:23 AM, Jungtaek Lim <kabh...@gmail.com> wrote:
 

 Hi Boyang,

AFAIK, there's no discussion on Storm UI yet. Could you share your sketched
UI for this?
And is it on top of STORM-1994
<https://issues.apache.org/jira/browse/STORM-1994>? I mean what Alessandro
submitted.

A random thought from myself is that we shows too many numbers even
topology info page, which is not intuitive at a glance. It might be better
to show them to graph or at least more abstracted from overview page, and
show details on other pages. (component detail page, or another)

It might be also better to show graph of values for time-series manner (I
think dashboard like Grafana is the best way to show numbers as intuitive
way), but it requires metrics to be stored and served to time-series
manner, so it's not a near-future goal.

Thanks,
Jungtaek Lim (HeartSaVIoR)

2016년 7월 30일 (토) 오전 12:19, Boyang(Jerry) Peng
<jerryp...@yahoo-inc.com.invalid>님이 작성:

> Hello Everyone,
> I would like to make enhancements on the UI by adding dynamic graphs to
> display stats of a topology.  For example, it would be nice to see
> performance and resource usage metrics be displayed in a graph on a per
> worker basis.  I know JStorm's UI has graphs but I am not sure to what
> kind.  What are our plans to improve storm UI?  What portions of JStorm's
> UI might we use?
> Best,
> Jerry




  

Re: Question about Storm UI

[Alessandro Bellina]

HeartSaVIoR
This is different than STORM-1994. By the way added some screenshots there to 
clarify.
I agree it would be good to reorganize the statistics shown in the UI. Perhaps 
having two parts to this, one goes to a dashboard like Grafana, while the 
simpler metrics (snapshots, or aggregations) go to the regular Storm UI. The 
reason for some of them going to the Storm UI is that I think that having some 
stats next to the place where actions can be performed on a topology is 
beneficial (as they currently are).
With regards to Jerry's suggestion, we tried a simple test using MySQL just as 
a PoC and c3/d3 as the charting library. The choices were made purely because 
we wanted to see the charts quickly, so not suggesting we use MySQL for time 
series data. We know probably storing in Druid or another time series database 
would be ideal, but harder to set up. Here is a screenshot showing average user 
cpu time (ms) per minute for each worker:


We could probably then turn around and request data from Druid (or more 
generally, the "metrics store") and show in the Storm UI. Additionally, Grafana 
looks like it can read from Druid, so folks could use that as a front end for 
detailed dashboards. That said, perhaps some version of this in the Topology 
page at a coarser resolution would be beneficial for a quick glimpse, linking 
to the detailed dashboard.
Thanks,
Alessandro
 

On Sunday, July 31, 2016 1:23 AM, Jungtaek Lim  wrote:
 

 Hi Boyang,

AFAIK, there's no discussion on Storm UI yet. Could you share your sketched
UI for this?
And is it on top of STORM-1994
? I mean what Alessandro
submitted.

A random thought from myself is that we shows too many numbers even
topology info page, which is not intuitive at a glance. It might be better
to show them to graph or at least more abstracted from overview page, and
show details on other pages. (component detail page, or another)

It might be also better to show graph of values for time-series manner (I
think dashboard like Grafana is the best way to show numbers as intuitive
way), but it requires metrics to be stored and served to time-series
manner, so it's not a near-future goal.

Thanks,
Jungtaek Lim (HeartSaVIoR)

2016년 7월 30일 (토) 오전 12:19, Boyang(Jerry) Peng
님이 작성:

> Hello Everyone,
> I would like to make enhancements on the UI by adding dynamic graphs to
> display stats of a topology.  For example, it would be nice to see
> performance and resource usage metrics be displayed in a graph on a per
> worker basis.  I know JStorm's UI has graphs but I am not sure to what
> kind.  What are our plans to improve storm UI?  What portions of JStorm's
> UI might we use?
> Best,
> Jerry

  

[jira] [Comment Edited] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15401199#comment-15401199
 ] 

Alessandro Bellina edited comment on STORM-1994 at 7/31/16 4:01 PM:


I added a screenshot of the new supervisor page with the worker/component 
table. Also added one for the topology page counterpart.


was (Author: abellina):
I added a screenshot of the new supervisor page with the worker/component table.

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
> Attachments: supervisor_page_worker_table.png, 
> topology_page_worker_table.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1994:
--
Attachment: topology_page_worker_table.png

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
> Attachments: supervisor_page_worker_table.png, 
> topology_page_worker_table.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1994:
--
Attachment: supervisor_page_worker_table.png

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
> Attachments: supervisor_page_worker_table.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1994:
--
Attachment: (was: screenshot-1.png)

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
> Attachments: supervisor_page_worker_table.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15401199#comment-15401199
 ] 

Alessandro Bellina commented on STORM-1994:
---

I added a screenshot of the new supervisor page with the worker/component table.

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
> Attachments: screenshot-1.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1994:
--
Attachment: screenshot-1.png

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
> Attachments: screenshot-1.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1994:
--
Attachment: (was: supervisor-page.png)

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1994:
--
Attachment: supervisor-page.png

> Add table with per-topology & worker resource usage and components in (new) 
> supervisor and topology pages
> -
>
> Key: STORM-1994
> URL: https://issues.apache.org/jira/browse/STORM-1994
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core, storm-ui
>    Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
> Attachments: supervisor-page.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1995) downloadChunk in nimbus.clj should close the input stream

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1995:
-

 Summary: downloadChunk in nimbus.clj should close the input stream
 Key: STORM-1995
 URL: https://issues.apache.org/jira/browse/STORM-1995
 Project: Apache Storm
  Issue Type: Bug
Affects Versions: 0.10.0, 1.0.0, 2.0.0
Reporter: Alessandro Bellina
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1994) Add table with per-topology & worker resource usage and components in (new) supervisor and topology pages

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1994:
-

 Summary: Add table with per-topology & worker resource usage and 
components in (new) supervisor and topology pages
 Key: STORM-1994
 URL: https://issues.apache.org/jira/browse/STORM-1994
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-core, storm-ui
Reporter: Alessandro Bellina
Assignee: Alessandro Bellina
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (STORM-1889) Datatables error message displayed when viewing UI

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387030#comment-15387030
 ] 

Alessandro Bellina edited comment on STORM-1889 at 7/21/16 2:32 AM:


The caching issue is being addressed in a PR I put up: 
https://github.com/apache/storm/pull/1536

It adds cache busting such that with a new deployment of Storm, the UI will 
know to re-fetch resources like the script.js, and others.



was (Author: abellina):
The caching issue is being addressed in a PR I put up: 
https://github.com/apache/storm/pull/1536

It adds cache busting such that with a new deployment of Stomr, the UI will 
know to re-fetch resources like the script.js, and others.


> Datatables error message displayed when viewing UI
> --
>
> Key: STORM-1889
> URL: https://issues.apache.org/jira/browse/STORM-1889
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-ui
>Affects Versions: 1.0.1
>Reporter: Simon Whittemore
>
> Updating to storm 1.0.1, running on Windows 7, I receive error messages from 
> Datatables.
> This occurs on the Topology Summary as well as the Component Summary for a 
> spout/bolt
> Example error: DataTables warning: table id=executor-stats-table - Requested 
> unknown parameter '9' for row 0. For more information about this error, 
> please see http://datatables.net/tn/4
> If I edit index.html to remove the type: num targets, the errors go away.
> For example.
>   $.getJSON("/api/v1/topology/summary",function(response,status,jqXHR) {
>   $.get("/templates/index-page-template.html", function(template) {
>   
> topologySummary.append(Mustache.render($(template).filter("#topology-summary-template").html(),response));
>   //name, owner, status, uptime, num workers, num executors, num 
> tasks, replication count, assigned total mem, assigned total cpu, scheduler 
> info
>   dtAutoPage("#topology-summary-table", {
> columnDefs: [
>   //{type: "num", targets: [4, 5, 6, 7, 8, 9]},
> {type: "num", targets: []},
>   {type: "time-str", targets: [3]}
> ]
>   });
>   $('#topology-summary [data-toggle="tooltip"]').tooltip();
>   });



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1889) Datatables error message displayed when viewing UI

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387030#comment-15387030
 ] 

Alessandro Bellina commented on STORM-1889:
---

The caching issue is being addressed in a PR I put up: 
https://github.com/apache/storm/pull/1536

It adds cache busting such that with a new deployment of Stomr, the UI will 
know to re-fetch resources like the script.js, and others.


> Datatables error message displayed when viewing UI
> --
>
> Key: STORM-1889
> URL: https://issues.apache.org/jira/browse/STORM-1889
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-ui
>Affects Versions: 1.0.1
>Reporter: Simon Whittemore
>
> Updating to storm 1.0.1, running on Windows 7, I receive error messages from 
> Datatables.
> This occurs on the Topology Summary as well as the Component Summary for a 
> spout/bolt
> Example error: DataTables warning: table id=executor-stats-table - Requested 
> unknown parameter '9' for row 0. For more information about this error, 
> please see http://datatables.net/tn/4
> If I edit index.html to remove the type: num targets, the errors go away.
> For example.
>   $.getJSON("/api/v1/topology/summary",function(response,status,jqXHR) {
>   $.get("/templates/index-page-template.html", function(template) {
>   
> topologySummary.append(Mustache.render($(template).filter("#topology-summary-template").html(),response));
>   //name, owner, status, uptime, num workers, num executors, num 
> tasks, replication count, assigned total mem, assigned total cpu, scheduler 
> info
>   dtAutoPage("#topology-summary-table", {
> columnDefs: [
>   //{type: "num", targets: [4, 5, 6, 7, 8, 9]},
> {type: "num", targets: []},
>   {type: "time-str", targets: [3]}
> ]
>   });
>   $('#topology-summary [data-toggle="tooltip"]').tooltip();
>   });



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-1942) Extra closing div tag in topology.html

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-1942:
-

Assignee: Alessandro Bellina

> Extra closing div tag in topology.html
> --
>
> Key: STORM-1942
> URL: https://issues.apache.org/jira/browse/STORM-1942
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-ui
>Affects Versions: 2.0.0
>        Reporter: Alessandro Bellina
>    Assignee: Alessandro Bellina
>Priority: Minor
>
> Extra  in topology.html causing styling to be strage. Appears to have 
> been introduced in STORM-1136.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-1890:
-

Assignee: Alessandro Bellina

> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>    Reporter: Alessandro Bellina
>Assignee: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow for cache busting 
> whenever storm is packaged (mvn package). A more complicated method is 
> versioning the files (we'd need to specify them in the pom.xml individually 
> using the assembly plugin, unless we use some other plugin). The first method 
> is (was?) considered less effective, since some CDNs/browsers can decide not 
> to cache the query parameter.
> I'd like to go with the simpler method, unless there are strong opinions to 
> changing file names (this means we need to specify files in the assembly 
> pom.xml). Also, going this route we don't need any new plugins, and the 
> assembly build can just be changed to export a variable. We would modify 
> calls to include a value that changes on mvn package:
> {code}
>  
> {code}
> instead of:
> {code}
> 
> {code}
> Where $\{timestamp\} will be replaced at assembly time by maven. This would 
> be the time when the assembly build started.
> The templates will also have the extra parameter. I think providing this to 
> ajaxSetup will do the trick. For example:
> {code}
> $.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359583#comment-15359583
 ] 

Alessandro Bellina commented on STORM-1890:
---

See: https://github.com/apache/storm/pull/1536

> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>    Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow for cache busting 
> whenever storm is packaged (mvn package). A more complicated method is 
> versioning the files (we'd need to specify them in the pom.xml individually 
> using the assembly plugin, unless we use some other plugin). The first method 
> is (was?) considered less effective, since some CDNs/browsers can decide not 
> to cache the query parameter.
> I'd like to go with the simpler method, unless there are strong opinions to 
> changing file names (this means we need to specify files in the assembly 
> pom.xml). Also, going this route we don't need any new plugins, and the 
> assembly build can just be changed to export a variable. We would modify 
> calls to include a value that changes on mvn package:
> {code}
>  
> {code}
> instead of:
> {code}
> 
> {code}
> Where $\{timestamp\} will be replaced at assembly time by maven. This would 
> be the time when the assembly build started.
> The templates will also have the extra parameter. I think providing this to 
> ajaxSetup will do the trick. For example:
> {code}
> $.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1942) Extra closing div tag in topology.html

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1942:
-

 Summary: Extra closing div tag in topology.html
 Key: STORM-1942
 URL: https://issues.apache.org/jira/browse/STORM-1942
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-ui
Affects Versions: 2.0.0
Reporter: Alessandro Bellina
Priority: Minor


Extra  in topology.html causing styling to be strage. Appears to have 
been introduced in STORM-1136.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320848#comment-15320848
 ] 

Alessandro Bellina commented on STORM-1890:
---

There is a flag in jquery (cache:false) but it's not available for $.get. The 
ajax calls through getJSON get extra "don't cache me" headers as they should:

https://github.com/apache/storm/blob/ab66003c18fe4f8c0926b3219408b735b2ce2adf/storm-core/src/jvm/org/apache/storm/ui/UIHelpers.java#L241.

The templates are not going through the code above, and their headers are the 
same as that of script.js or style.css. I have reproduced the issue by making a 
change to one of the templates, then touching with a date far in the back. 
After that gets cached, the browser won't fetch the new version when I go to 
the affected page just by hitting enter in the URL bar. On refresh it does 
reload (this is for Chrome specifically). 

After thinking about it more, I think having a getStatic method that adds the 
url query param is the way to go, instead of setting the option globally.

> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow for cache busting 
> whenever storm is packaged (mvn package). A more complicated method is 
> versioning the files (we'd need to specify them in the pom.xml individually 
> using the assembly plugin, unless we use some other plugin). The first method 
> is (was?) considered less effective, since some CDNs/browsers can decide not 
> to cache the query parameter.
> I'd like to go with the simpler method, unless there are strong opinions to 
> changing file names (this means we need to specify files in the assembly 
> pom.xml). Also, going this route we don't need any new plugins, and the 
> assembly build can just be changed to export a variable. We would modify 
> calls to include a value that changes on mvn package:
> {code}
>  
> {code}
> instead of:
> {code}
> 
> {code}
> Where $\{timestamp\} will be replaced at assembly time by maven. This would 
> be the time when the assembly build started.
> The templates will also have the extra parameter. I think providing this to 
> ajaxSetup will do the trick. For example:
> {code}
> $.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where $\{timestamp\} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({ data: {"_ts" : "$\{timestamp\}"}});
{code}

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where $\{timestamp\} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup(\{ data: \{"_ts" : "$\{timestamp\}"\}\});
{code}


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url p

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where $\{timestamp\} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
{code}

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where $\{timestamp\} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({ data: {"_ts" : "$\{timestamp\}"}});
{code}


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where $\{timestamp\} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup(\{ data: \{"_ts" : "$\{timestamp\}"\}\});

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({ data: {"_ts" : "${timestamp}" } });


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow for cache busting 
&

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where $\{timestamp\} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup(\{ data: \{"_ts" : "$\{timestamp\}"\}\});
{code}

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where $\{timestamp\} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup(\{ data: \{"_ts" : "$\{timestamp\}"\}\});


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({ data: {"_ts" : "${timestamp}" } });

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({ data: {"_ts" : "${timestamp}"}});


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow for cache busting 
> wheneve

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{/code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url p

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{/code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

```
 
```

instead of:

```

```

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

```
$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});
```


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url p

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
{code}

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({ data: {"_ts" : "${timestamp}"}});

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
{code}


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow for cache busti

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

```
 
```

instead of:

```

```

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

```
$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});
```

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});
{code}


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url p

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});
{code}

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});

{code}


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approac

[jira] [Updated] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--
Description: 
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

{code}
 
{code}

instead of:

{code}

{code}

Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

{code}
$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});

{code}

  was:
Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

 

instead of:



Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});


> Employ cache-busting method to ensure newly deployed UI forces browsers to 
> refetch scripts, templates, and CSS
> --
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>Affects Versions: 2.0.0, 1.1.0
>Reporter: Alessandro Bellina
>Priority: Minor
>
> Currently we don't employ cache busting techniques in the Storm UI while 
> fetching script.js, CSS and templates. Ring is providing the Last-Modified 
> header, but browsers implement a heuristic to when they deem a resource stale 
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This 
> means that as the Last-Modified for a resource is further away in the past, 
> the longer the browsers are going to wait until they refetch. It looks like 
> 10% padding is common, so if script.js was last modified 100 days ago, the 
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow

[jira] [Created] (STORM-1890) Employ cache-busting method to ensure newly deployed UI forces browsers to refetch scripts, templates, and CSS

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1890:
-

 Summary: Employ cache-busting method to ensure newly deployed UI 
forces browsers to refetch scripts, templates, and CSS
 Key: STORM-1890
 URL: https://issues.apache.org/jira/browse/STORM-1890
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-ui
Affects Versions: 2.0.0, 1.1.0
Reporter: Alessandro Bellina
Priority: Minor


Currently we don't employ cache busting techniques in the Storm UI while 
fetching script.js, CSS and templates. Ring is providing the Last-Modified 
header, but browsers implement a heuristic to when they deem a resource stale 
(https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This means 
that as the Last-Modified for a resource is further away in the past, the 
longer the browsers are going to wait until they refetch. It looks like 10% 
padding is common, so if script.js was last modified 100 days ago, the browser 
will not fetch it until 10 days after the time it was cached.

An easy approach is to add a url parameter to allow for cache busting whenever 
storm is packaged (mvn package). A more complicated method is versioning the 
files (we'd need to specify them in the pom.xml individually using the assembly 
plugin, unless we use some other plugin). The first method is (was?) considered 
less effective, since some CDNs/browsers can decide not to cache the query 
parameter.

I'd like to go with the simpler method, unless there are strong opinions to 
changing file names (this means we need to specify files in the assembly 
pom.xml). Also, going this route we don't need any new plugins, and the 
assembly build can just be changed to export a variable. We would modify calls 
to include a value that changes on mvn package:

 

instead of:



Where ${timestamp} will be replaced at assembly time by maven. This would be 
the time when the assembly build started.

The templates will also have the extra parameter. I think providing this to 
ajaxSetup will do the trick. For example:

$.ajaxSetup({
data: {
"_ts" : "${timestamp}"
}
});



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1648) DRPCSpout should attempt reconnect if on fail it cannot reach client

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1648:
-

 Summary: DRPCSpout should attempt reconnect if on fail it cannot 
reach client
 Key: STORM-1648
 URL: https://issues.apache.org/jira/browse/STORM-1648
 Project: Apache Storm
  Issue Type: Bug
Reporter: Alessandro Bellina
Assignee: Alessandro Bellina
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1641) Inconsistency when creating backpressure znode subtree

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1641:
-

 Summary: Inconsistency when creating backpressure znode subtree
 Key: STORM-1641
 URL: https://issues.apache.org/jira/browse/STORM-1641
 Project: Apache Storm
  Issue Type: Bug
Reporter: Alessandro Bellina
Assignee: Alessandro Bellina
Priority: Trivial


In STORM-1614 I added the creation of the backpressure znode subtree, but 
instead of using BACKPRESSURE-SUBTREE it was using BACKPRESSURE-ROOT. This 
doesn't appear to make a difference, but it is inconsistent with the other 
subtrees.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1231) port backtype.storm.scheduler.EvenScheduler to java

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191400#comment-15191400
 ] 

Alessandro Bellina commented on STORM-1231:
---

Xin, are you currently working on this, or could I pick it up?

> port backtype.storm.scheduler.EvenScheduler to java
> ---
>
> Key: STORM-1231
> URL: https://issues.apache.org/jira/browse/STORM-1231
> Project: Apache Storm
>  Issue Type: New Feature
>Reporter: Robert Joseph Evans
>Assignee: Xin Wang
>  Labels: java-migration, jstorm-merger
>
> Port the even scheduler to java.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1614) Clean backpressure zk node in do-cleanup

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1614:
-

 Summary: Clean backpressure zk node in do-cleanup
 Key: STORM-1614
 URL: https://issues.apache.org/jira/browse/STORM-1614
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Reporter: Alessandro Bellina
Assignee: Alessandro Bellina
Priority: Minor


Currently the backpressure node is being removed in killTopologyWithOpts in 
nimbus. Remove instead like the other ZK nodes in do-cleanup for inactive topos.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1594) org.apache.storm.tuple.Fields can throw NPE if given invalid field in selector

[Alessandro Bellina (JIRA)]

Alessandro Bellina created STORM-1594:
-

 Summary: org.apache.storm.tuple.Fields can throw NPE if given 
invalid field in selector
 Key: STORM-1594
 URL: https://issues.apache.org/jira/browse/STORM-1594
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Reporter: Alessandro Bellina
Priority: Minor


In class org.apache.storm.tuple.Fields, the select method gets the index of the 
field to select from the first argument (selector) by using .get. It doesn't 
set this result to an Integer and check for null (Map.get returns null if the 
key is not found).

When tuple.get happens, the parameter for tuple.get is an unboxed integer. The 
null cannot be unboxed to integer, causing an NPE. There is another method in 
Fields called fieldIndex which will throw an IllegalArgumentException in the 
case that the field in the selector isn't in the _index. 

{code}
public List select(Fields selector, List tuple) {
List ret = new ArrayList<>(selector.size());
for(String s: selector) {
ret.add(tuple.get(_index.get(s)));  
}
return ret;
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-1228) port backtype.storm.fields-test to java

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-1228:
-

Assignee: Alessandro Bellina  (was: Jark Wu)

> port  backtype.storm.fields-test to java
> 
>
> Key: STORM-1228
> URL: https://issues.apache.org/jira/browse/STORM-1228
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>        Assignee: Alessandro Bellina
>  Labels: java-migration, jstorm-merger
>
> This is a test that should be simple to move to JUnit



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1228) port backtype.storm.fields-test to java

[Alessandro Bellina (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167108#comment-15167108
 ] 

Alessandro Bellina commented on STORM-1228:
---

Hi Jark, I am. I have the clojure->java translation already and was going to 
see about adding more tests. I should be able to PR today or tomorrow.

> port  backtype.storm.fields-test to java
> 
>
> Key: STORM-1228
> URL: https://issues.apache.org/jira/browse/STORM-1228
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>Assignee: Jark Wu
>  Labels: java-migration, jstorm-merger
>
> This is a test that should be simple to move to JUnit



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-1228) port backtype.storm.fields-test to java

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-1228:
-

Assignee: Alessandro Bellina

> port  backtype.storm.fields-test to java
> 
>
> Key: STORM-1228
> URL: https://issues.apache.org/jira/browse/STORM-1228
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>        Assignee: Alessandro Bellina
>  Labels: java-migration, jstorm-merger
>
> This is a test that should be simple to move to JUnit



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (STORM-1255) port backtype.storm.utils-test to java

[Alessandro Bellina (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina reassigned STORM-1255:
-

Assignee: Alessandro Bellina

> port backtype.storm.utils-test to java
> --
>
> Key: STORM-1255
> URL: https://issues.apache.org/jira/browse/STORM-1255
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: rm-core, storm-core
>Reporter: Robert Joseph Evans
>        Assignee: Alessandro Bellina
>  Labels: java-migration, jstorm-merger
>
> junit test migration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)