Hi Ernesto Reinaldo Barreiro , Can you provide example code for a solution? Since this is a general Problem, maybe it would be helpful to add it to the wicket core libaries.
Have a happy new year, Johannes Renoth On 2019-12-30 16:52, Ernesto Reinaldo Barreiro wrote: > 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 <b...@iswd.nl> 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
