[Lift] Re: garbage collection
On Fri, May 8, 2009 at 6:51 AM, marius d. marius.dan...@gmail.com wrote: Personally I'd be very reluctant exposing that to applications as this is Lift implementation specific and exposing an API tight to that leads to unnecessary coupling. While I don't like unnecessary coupling, either, I do like simple profiling. But why do you really need this? ... just for statistical purposes? ... I'm not sure about the relevance of such number. I want to get an idea about the growth of functions stored in the session. I have a idea that might cut the number of functions, under certain circumstances. Br's, Marius On May 7, 10:22 pm, Oliver Lambert olambo...@gmail.com wrote: Any chance of exposing a getter on messageCallback that would return some statistics (the number of functions being stored would be a good starting point)? On Thu, May 7, 2009 at 11:21 PM, marius d. marius.dan...@gmail.com wrote: Just FYI ... Things in this area are may change a bit once JQuery fixes the bug related with namespaces.This was the main reason why we had to deviate from Dave's original idea of using lift:gc attributes. Br's, Marius On May 7, 3:47 pm, Oliver Lambert olambo...@gmail.com wrote: Ah, you mean messageCallback - The joys of private variables. thanks again Ol On Thu, May 7, 2009 at 9:55 PM, marius d. marius.dan...@gmail.com wrote: Please see LiftSession. On May 7, 1:41 pm, Oliver Lambert olambo...@gmail.com wrote: Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
Can't you use a regular Java profiler to determine this? Perhaps would be beneficial to start thinking of a generic enough stats module that would reveal information like that to the lift applications. I guess we need to see what the general consensus is and take it from there. Br's, Marius On May 8, 10:49 am, Oliver Lambert olambo...@gmail.com wrote: On Fri, May 8, 2009 at 6:51 AM, marius d. marius.dan...@gmail.com wrote: Personally I'd be very reluctant exposing that to applications as this is Lift implementation specific and exposing an API tight to that leads to unnecessary coupling. While I don't like unnecessary coupling, either, I do like simple profiling. But why do you really need this? ... just for statistical purposes? ... I'm not sure about the relevance of such number. I want to get an idea about the growth of functions stored in the session. I have a idea that might cut the number of functions, under certain circumstances. Br's, Marius On May 7, 10:22 pm, Oliver Lambert olambo...@gmail.com wrote: Any chance of exposing a getter on messageCallback that would return some statistics (the number of functions being stored would be a good starting point)? On Thu, May 7, 2009 at 11:21 PM, marius d. marius.dan...@gmail.com wrote: Just FYI ... Things in this area are may change a bit once JQuery fixes the bug related with namespaces.This was the main reason why we had to deviate from Dave's original idea of using lift:gc attributes. Br's, Marius On May 7, 3:47 pm, Oliver Lambert olambo...@gmail.com wrote: Ah, you mean messageCallback - The joys of private variables. thanks again Ol On Thu, May 7, 2009 at 9:55 PM, marius d. marius.dan...@gmail.com wrote: Please see LiftSession. On May 7, 1:41 pm, Oliver Lambert olambo...@gmail.com wrote: Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
On Fri, May 8, 2009 at 12:49 AM, Oliver Lambert olambo...@gmail.com wrote: On Fri, May 8, 2009 at 6:51 AM, marius d. marius.dan...@gmail.com wrote: Personally I'd be very reluctant exposing that to applications as this is Lift implementation specific and exposing an API tight to that leads to unnecessary coupling. While I don't like unnecessary coupling, either, I do like simple profiling. We have a Map of names and functions and the functions can be associated with particular pages and they have a last seen time. What kind of information do you want? The issue is that the page association part of the data structure will likely change. The storage mechanism will likely change. Do you want a call (which will be somewhat expensive) to get a list of functions, their opaque ID, and their expected expiration date? But why do you really need this? ... just for statistical purposes? ... I'm not sure about the relevance of such number. I want to get an idea about the growth of functions stored in the session. I have a idea that might cut the number of functions, under certain circumstances. Br's, Marius On May 7, 10:22 pm, Oliver Lambert olambo...@gmail.com wrote: Any chance of exposing a getter on messageCallback that would return some statistics (the number of functions being stored would be a good starting point)? On Thu, May 7, 2009 at 11:21 PM, marius d. marius.dan...@gmail.com wrote: Just FYI ... Things in this area are may change a bit once JQuery fixes the bug related with namespaces.This was the main reason why we had to deviate from Dave's original idea of using lift:gc attributes. Br's, Marius On May 7, 3:47 pm, Oliver Lambert olambo...@gmail.com wrote: Ah, you mean messageCallback - The joys of private variables. thanks again Ol On Thu, May 7, 2009 at 9:55 PM, marius d. marius.dan...@gmail.com wrote: Please see LiftSession. On May 7, 1:41 pm, Oliver Lambert olambo...@gmail.com wrote: Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
Please see LiftSession. On May 7, 1:41 pm, Oliver Lambert olambo...@gmail.com wrote: Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
Ah, you mean messageCallback - The joys of private variables. thanks again Ol On Thu, May 7, 2009 at 9:55 PM, marius d. marius.dan...@gmail.com wrote: Please see LiftSession. On May 7, 1:41 pm, Oliver Lambert olambo...@gmail.com wrote: Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
Just FYI ... Things in this area are may change a bit once JQuery fixes the bug related with namespaces.This was the main reason why we had to deviate from Dave's original idea of using lift:gc attributes. Br's, Marius On May 7, 3:47 pm, Oliver Lambert olambo...@gmail.com wrote: Ah, you mean messageCallback - The joys of private variables. thanks again Ol On Thu, May 7, 2009 at 9:55 PM, marius d. marius.dan...@gmail.com wrote: Please see LiftSession. On May 7, 1:41 pm, Oliver Lambert olambo...@gmail.com wrote: Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: garbage collection
Personally I'd be very reluctant exposing that to applications as this is Lift implementation specific and exposing an API tight to that leads to unnecessary coupling. But why do you really need this? ... just for statistical purposes? ... I'm not sure about the relevance of such number. Br's, Marius On May 7, 10:22 pm, Oliver Lambert olambo...@gmail.com wrote: Any chance of exposing a getter on messageCallback that would return some statistics (the number of functions being stored would be a good starting point)? On Thu, May 7, 2009 at 11:21 PM, marius d. marius.dan...@gmail.com wrote: Just FYI ... Things in this area are may change a bit once JQuery fixes the bug related with namespaces.This was the main reason why we had to deviate from Dave's original idea of using lift:gc attributes. Br's, Marius On May 7, 3:47 pm, Oliver Lambert olambo...@gmail.com wrote: Ah, you mean messageCallback - The joys of private variables. thanks again Ol On Thu, May 7, 2009 at 9:55 PM, marius d. marius.dan...@gmail.com wrote: Please see LiftSession. On May 7, 1:41 pm, Oliver Lambert olambo...@gmail.com wrote: Thanks for this. I would like to look at the code that actually holds the storage container and profile it. Any pointers on which class to look at s a starting point? Ol On Thu, May 7, 2009 at 7:17 PM, marius d. marius.dan...@gmail.com wrote: In short the current Lift GC is: 1. Each page has an ID 2. Each mapped function is associated with the page ID 3. There are periodical Ajax request sent from the page that are refreshing the timestamps on the mapped functions 4. Mapped functions that exceeded the expiration time are de- referenced hence become eligible for garbage collector. Br's, Marius On May 7, 10:15 am, Oliver Lambert olambo...@gmail.com wrote: I'm trying to get an understanding how garbage collection is implemented in Lift. Any pointers on what scala classes do the actual work? While I'm at it, S.functionMap appears to only return functions that were recently bound. Does S._functionMap, contain the functions being garbage collected? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
