Logging of AJAX function removal by garbage collector

[Sergey Trofimov]

Hello lifters.

I have an issue with AJAX in my application (lift version 2.5-M4) which looks like AJAX call for function GUID which is removed at server side (no server-side code running, empty response body and so on). So I try to investigate the problem.

My questions are following:

1. Can I write to log an information about function GUIDs marked for removal by garbage collector?

2. Can I log an error when client makes an AJAX call for the function which is already removed on the server side?

Thank you.

[Diego Medina]

Hi,

I don't know if you could log the functions that are marked for
removal, but it would be great if you could put together a sample app
that shows this issue. A coworker saw this same issue last week but as
far as I know, we haven;t tracked it down (but were also thinking it
may be related to the functions being garbage collected)


https://www.assembla.com/wiki/show/liftweb/Posting_example_code

Thanks

Diego

> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to liftweb+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://fmpwizard.telegr.am

[Sergey Trofimov]

I'm not sure that I am ready to prepare sample application.

Because I thought logically and understood why my functions are garbage collected and it was correct assumption.

But it would be really helpful to get error in log when client make AJAX call for functions with GUIDs which are not found on the server. Because now I can only rely on people complain that application does not work as expected sometimes, and such situations are not easily to reproduce.

--
Sergey Trofimov

[Antonio Salazar Cardozo]

Yes, I agree, having run into this issue before. If you can open a ticket on that, I'll try and get to it sometime in the next month or two (long timeline, I know). I've been spelunking in that code a couple of times, so it shouldn't be super-difficult to drop at least a debug- or info-level log message when we can't find a function-level id.

Unless there are concerns from another committer around doing that?

Thanks,

Antonio

[Sergey Trofimov]

Hello, Antonio.

The issue is created https://github.com/lift/framework/issues/1427.

[Jeppe Nejsum Madsen]

On Thu, Mar 28, 2013 at 3:08 PM, Antonio Salazar Cardozo <savedf...@gmail.com> wrote:

Yes, I agree, having run into this issue before. If you can open a ticket on that, I'll try and get to it sometime in the next month or two (long timeline, I know). I've been spelunking in that code a couple of times, so it shouldn't be super-difficult to drop at least a debug- or info-level log message when we can't find a function-level id.

Unless there are concerns from another committer around doing that?

Thanks,

Antonio

Makes sense to me. Lets log at either debug or trace level

/Jeppe

 

[Antonio Salazar Cardozo]

Sweet, thanks! I'll try and get to it as soon as possible :)

Thanks,

Antonio

[Sergey Trofimov]

Lets log at either debug or trace level

I still prefer the error one.

Or a customizable function which I can provide by my own.

--
Sergey Trofimov

[Jeppe Nejsum Madsen]

On Fri, Mar 29, 2013 at 11:27 PM, Sergey Trofimov <sergey....@gmail.com> wrote:

Lets log at either debug or trace level

I still prefer the error one.

Or a customizable function which I can provide by my own.

Imo, error level is for truly catastrophic things which will get you paged in the middle of the night.

I also think adding a customizable is function is overkill. Not sure what you would do besides logging the fact?

/Jeppe

[Antonio Salazar Cardozo]

Yeah, I don't think I'll put it at the error level. I was actually considering making it a customizable function, though, because logging is one thing but if the user's losing functions you may want to do something more intensive like reload the page or attempt to rehydrate the functions somehow (in fact, I'd like it if Lift attempted to do that by default, but I'm not there yet).

Thanks,

Antonio

[Sergey Trofimov]

Imo, error level is for truly catastrophic things which will get you paged in the middle of the night.

Not sure what you would do besides logging the fact?

My use-case below:

1. Debug log is off in production.

2. Such cases like garbage-collected AJAX handlers are rarely occurred in development.

3. Application users will not care about request to support about non-working AJAX calls in my application, they just have bad feeling about our product. Even if they file a ticket, the case is hard to reproduce and investigate.

4. I analyze application error logs periodically or by demand. This helps me to detect application bugs which were not obvious during development stage.

--
Sergey Trofimov

--

[Sergey Trofimov]

I was actually considering making it a customizable function

The approach similar to LiftRules.localizationLookupFailureNotice would be consistent and sufficient as I think.

--
Sergey Trofimov

--

[Antonio Salazar Cardozo]

Just added some code for this to branch log-uknown-guids; PR at https://github.com/lift/framework/pull/1427 .

This logs on any request, but tries to recognize Lift functions with the very simple heuristic of looking for initial Fs in the parameter names.

Note that this is configured by a FactoryMaker LiftRule, so you can customize it per request or per session as well as globally. The default logs Lift-like parameter names (start with an F) that are not mapped to a function, at the WARN level.

Thanks,

Antonio