Google and DevUtils Inspector Page can kill your WebApp

2019-09-11 Thread Илья Нарыжный
Hello,

This is real-life story. It started a relatively long time ago: our
demo server from time to time had OurOfMemory condition. It was
strange because the solution itself is very well "stress volume
tested". So we were just rebooting demo server after such incidents.
But it started to happen more frequently and we performed an
investigation with interesting results which can be used as Best
Practice and/or one more issue for Wicket.

1) We have found that most memory-consuming objects where java
Threads. Specifically for InspectorPage from Wicket devutils.
2) Our applications pages don't have memory leakage condition. But
there is one trick: some of our pages are built dynamically and
depends on a data model. Sometimes data model might be recurrent, so
without special treatment - Wicket will render that forever. We have
this protection on our pages, but that was a main root-cause
component: InspectorPage during inspecting of our pages for some
reason doesn't see that actually recurrent elements are cut during
rendering.
3) But how someone gets into InspectorPage? Apparently that was Google
- it was trying to index our demo site and there is no protection from
following to InspectorPage in DevUtils panel.

So, some lessons learned items and comments:
1) If it's possible - do not deploy DevUtils - use them during actual
development.
2) It will be good to investigate InspectorPage - why it's trying to
build structure infinitely disregard of the fact that on real page
it's actually cut off.
3) It might make sense to include such utils and etc into /robots.txt
to protect from indexing
4) Also, it might make sense to add "nofollow" to a link in DevUtils
panel which leads to InspectorPage

Thanks,
Ilia

-
Orienteer(http://orienteer.org) - open source Business Application Platform

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket Kendo UI - Grid/Chart datasources not cleaned up

2019-09-11 Thread Manfred Bergmann
Thank you guys.


Manfred

--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Wicket Kendo UI - Grid/Chart datasources not cleaned up

2019-09-11 Thread Sebastien
Hi Manfred,

Alternatively, you can have a look at KendoDestroyListener, Initializer,
and classes implementing IDestroyable in Wicket jQuery UI...

Thanks and best regards,
Sebastien


Re: Wicket Kendo UI - Grid/Chart datasources not cleaned up

2019-09-11 Thread Martin Grigorov
Hi Manfred,

See org.apache.wicket.protocol.http.AjaxEnclosureListener for inspiration.
You'll need to do something similar - check whether any of the components
in the passed Map is a parent of a Grid or Chart and destroy it so it
cleans the DOM.

On Tue, Sep 10, 2019 at 6:15 PM Manfred Bergmann 
wrote:

> OK, maybe it's better to follow up on this while it hot.
>
> I'm not entirely certain what to do and where.
> I'd assume that when a user clicks elsewhere, which raises an
> AjaxRequestTarget I'll have to add a functionality to destroy the
> chart/grid
> as part of the AjaxRequestTarget.
> But since the click can be anywhere, should this listener be part of the
> Grid/Chart component?
> Can you briefly guide me on what to do?
>
>
> Manfred
>
>
>
> Manfred Bergmann wrote
> > Hi Martin.
> >
> > OK, thanks. That looks like a doable solution.
> > I'd go for the Listener but I'll probably have to ask some more when I'm
> > going to implement it.
> >
> >
> > Manfred
> >
> >
> >
> > Martin Grigorov-4 wrote
> >> Hi Manfred,
> >>
> >> The #refresh(PartialPageUpdateHandler) methods are useful if you update
> >> the
> >> specific component.
> >> They do not help if you repaint a parent of such a component.
> >> In your case you will need to destroy the component (grid, chart) in
> your
> >> action callback (e.g. onUpdate(), onClick()).
> >> You can do this in your code or with AjaxRequestTarget.Listener. If you
> >> do
> >> the Listener then you can donate it to Wicket JQuery UI project.
> >>
> >> On Tue, Sep 10, 2019 at 10:52 AM Manfred Bergmann 
> >
> >> mb@
> >
> >> 
> >> wrote:
> >>
> >>> Hi Sebastian.
> >>>
> >>> Thanks for the additional explanation.
> >>> But I'm not fully sure for how this is supposed to work in my case
> given
> >>> this structure/hierarchy:
> >>> page -> panel(a) -> panel(b) -> grid/chart
> >>>
> >>> Where panel (a) is replaced. Any instance of panel (b) can have a
> >>> grid/chart
> >>> but it can also host something else (depends on what is being
> >>> displayed).
> >>> I understand that when panel (a) is replaced it is garbage collected
> and
> >>> all
> >>> content on it as well in which case a reload for the grid/chart on
> >>> panel(b)
> >>> won't work?
> >>>
> >>>
> >>> Regards,
> >>> Manfred
> >>>
> >>>
> >>>
> >>>
> >>> Sebastien wrote
> >>> > Hi Manfred,
> >>> >
> >>> > Sorry, my previous answer was incomplete.
> >>> > Kendo components do usually have two methods for ajax, #reload and
> >>> > #refresh.
> >>> > Reload aims to reload the component (ie reattach to the dom) while
> >>> refresh
> >>> > aim to refresh the data only.
> >>> > IIRC, grid and chart are different in the sense that grid does have
> >>> its
> >>> > datasource aware of the request cycle so it is safe to
> reattach/reload
> >>> the
> >>> > component, the datasource will be destroyed from the dom. That's
> >>> > unfortunately not the case of the chart (you can open an issue, I can
> >>> try
> >>> > to figure out if it's achievable).
> >>> > One nice way to refresh the data without having the reload/reattach
> >>> the
> >>> > component is to use the event bus. Your master page/component will
> >>> > send/broadcast a RefreshEvent or RefreshChatEvent that will be
> catched
> >>> by
> >>> > the component hosting the chart (or the chart itself if you have
> >>> overriden
> >>> > it). Then just call refesh...
> >>> >
> >>> > Thanks and best regards,
> >>> > Sebastien
> >>> >
> >>> >
> >>> > On Mon, Sep 9, 2019, 23:29 Manfred Bergmann 
> >>>
> >>> > mb@
> >>>
> >>> >  wrote:
> >>> >
> >>> >> Hi Sebastian.
> >>> >>
> >>> >> OK, but I don't really see how reusing instances of a Kendo Grid
> >>> really
> >>> >> works in a component based design where the parents of where the
> >>> Grids
> >>> >> are
> >>> >> placed are replaced on the page.
> >>> >>
> >>> >> In particular we have a three panes border layout, kind of a
> >>> >> 'master-detail'
> >>> >> plus a tree on the left side.
> >>> >> The right most pane is the 'detail' pane where panels are replaced
> >>> >> depending
> >>> >> on selection on the 'master' pane. Those panels can contain Kendo
> >>> Grid
> >>> >> but
> >>> >> some do not. So I have no other chance of creating new instances of
> >>> Kendo
> >>> >> Grids (DataTable).
> >>> >> So switching through the 'master' selections creates new Kendo
> Grids,
> >>> or
> >>> >> Charts adding up datasources on the DOM root.
> >>> >>
> >>> >> I don't see how just using Chart/DataTable#refresh really should
> >>> work?
> >>> >>
> >>> >>
> >>> >> Manfred
> >>> >>
> >>> >>
> >>> >>
> >>> >> Sebastien wrote
> >>> >> > Hi Manfred,
> >>> >> >
> >>> >> > The recommended way to refresh kendo ui components - those bound
> to
> >>> a
> >>> >> > datasource - is to read from the datasource.
> >>> >> >
> >>> >> > See Chart#refresh, it should solve the problem.
> >>> >> >
> >>> >> > Thanks and best regards,
> >>> >> > Sébastien
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Sent from:
> >>> >>
>