Hi,
One thing I immediately do for any wicket application is rolling a blocker
DIV preventing users to double click on AJAX links: Situation? User clicks
in some AJAX link and meanwhile request is being processed the user clicks
on something "that will not be there" when AJAX request finishes. This
blocking logic can be added globally and it is also easy to mark "request
and don't show blocker". In my current customer's main application rolling
out such a solution drastically reduced the number of such errors.
For other application, a side project, I remember rolling out a
IRequestCycleListener
that logged details from errors into some external storage so I had not
fight with logs (and there you can store the precise info you need to track
user's actions).
On Mon, Dec 30, 2019 at 5:03 PM Bas Gooren wrote:
> Hi!
>
> We see these typos of errors every now and then too. It’s usually people
> navigating to old pages, double clicking on links etc.
>
> Nevertheless, in our logs these are relatively easy to find: we send out
> e-mail notifications when such errors occur, and the e-mail includes quite
> some details (page, component, session id, logged in user etc, user ip);
> So far, I have always been able to trace the user’s steps by simply
> grepping the access logs for their IP around the time of the exception.
>
> Should you not be able to do that, I guess it would be relatively simple to
> track user actions (e.g. the last 10 actions) yourself in the user session.
> Simply write a request cycle listener, and get some meaningful information
> from the next handler to be executed.
>
> E.g. override onRequestHandlerScheduled() and deduct the action from the
> request handler;
>
> ListenerRequestHandler: component or behavior invoked
> etc.
>
> Store the actions as strings (e.g. “render pageX(pageParams=XYZ)”, “Click
> on link a.b.c in PageX”, “Submit form path.to.component in PageX”).
>
> If you have an app where users are logged in, you can track the last X
> actions in the user’s session; Otherwise you could externalize this (either
> in-memory by IP, or some other backing store).
> When an exception occurs, you can catch it in your request cycle listener
> and fetch the last user actions. Together, these should provide a better
> trail of actions leading up to the exceptions.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 30 december 2019 bij 05:24:19, Илья Нарыжный (phan...@ydn.ru) schreef:
>
> Hello,
>
> We have pretty widely used software with thousands of visits per day.
> And from time to time we observe pretty weird Wicket related errors
> in logs. Commonly it's something about components structure: no such
> child, there is already such element and etc. But the problem is that
> commonly we can't reproduce the problem right away: page is working as
> expected. So such mysterious problems just lie in logs and not being
> fixed.
> And here is the question: is there some good way to retrieve and log
> previous user actions and etc.? Theoretically everything should be in
> PageStore. What can you recommend to handle such problems properly?
>
> P.S. To be able to catch such problems we even build a system for
> gathering all logs on a central server and correlate them with each
> other according to some correlation logic. But still - no big luck -
> so we really believe that problem is in fact that we know only current
> user page/location and do not know historical aspect.
>
> 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
>
--
Regards - Ernesto Reinaldo Barreiro
