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-
reference
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. wrote:
>
> In short the current Lift GC is:
>
> 1. Each page has an ID
> 2. Each map
Please see LiftSession.
On May 7, 1:41 pm, Oliver Lambert 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. wrote:
Ah, you mean messageCallback - The joys of private variables.
thanks again
Ol
On Thu, May 7, 2009 at 9:55 PM, marius d. wrote:
>
> Please see LiftSession.
>
> On May 7, 1:41 pm, Oliver Lambert wrote:
> > Thanks for this. I would like to look at the code that actually holds the
> > storage conta
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 wrote:
> Ah, you mean messageCallback - T
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. wrote:
>
> Just FYI ...
>
> Things in this area are may change a bit once JQuery fixes the bug
>
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,
M
On Fri, May 8, 2009 at 6:51 AM, marius d. 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 pro
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
On Fri, May 8, 2009 at 12:49 AM, Oliver Lambert wrote:
>
>
> On Fri, May 8, 2009 at 6:51 AM, marius d. 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.
>>
>
On Fri, May 8, 2009 at 10:51 PM, David Pollak wrote:
>
>
> On Fri, May 8, 2009 at 12:49 AM, Oliver Lambert wrote:
>
>>
>>
>> On Fri, May 8, 2009 at 6:51 AM, marius d. wrote:
>>
>>>
>>> Personally I'd be very reluctant exposing that to applications as this
>>> is Lift implementation specific and e
11 matches
Mail list logo
