Re: Retrieve user's page on the site
I meant for the blocking Button, i also remember implementing this from time to time, so i wondered if there was a general solution to this. Johannes On 2019-12-31 15:48, Ernesto Reinaldo Barreiro wrote: > Do you mean for the blocker thing? Or for login errors? Or both? > > Happy new year to all. > > On Tue, Dec 31, 2019 at 4:07 PM Johannes Renoth > wrote: > >> 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 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 >> >>
Re: Retrieve user's page on the site
Do you mean for the blocker thing? Or for login errors? Or both? Happy new year to all. On Tue, Dec 31, 2019 at 4:07 PM Johannes Renoth wrote: > 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 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 > > -- Regards - Ernesto Reinaldo Barreiro
Re: Retrieve user's page on the site
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 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
Re: Retrieve user's page on the site
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
Re: Retrieve user's page on the site
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
Re: Retrieve user's page on the site
In our experience these can be a mixed bag of expired requests, expired links, incorrect back button presses (and links from stale pages), session timeouts, etc. We haven't been able to trace them either, if a solution exists, I wish it was part of wicket core. Using more human readable urls might help, identifying session and clicked button and maybe page state, which could be later backtraced to determine any inconsistencies. ** Martin ma 30. jouluk. 2019 klo 6.24 Илья Нарыжный (phan...@ydn.ru) kirjoitti: > 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 > >
