possible issue with IdMemoize and RequestVar in 2.5-M2

[pelagic]

I've been working with 2.5-M2 and noticed an interesting thing with idMemoize and RequestVars.

I have a snippet like this:

object Count extends RequestVar[Int](0)

object Memoize {

  def incrementCount = {
    val count = Count.is
    Count.set(count + 1)
  }

  def render = {
    "div" #> SHtml.idMemoize(in => {
      "@count *" #> Text(Count.is.toString) &
      "@refresh [onclick]" #> SHtml.ajaxInvoke(() => {
        incrementCount
        in.setHtml()
      })
    })
  }
}

The first time refresh is clicked a 1 is displayed in count, as you would expect. However, the second time it's clicked a 1 is still displayed, not what you would expect. The third time it displays a 2. This doesn't happen in 2.5-M1. Maybe I'm missing something ...

My use case for doing this type of thing is putting the IdMemoizeTransform into a RequestVar so I can share it across Snippets.

Here is a sample project to run the example:

https://github.com/kaiserpelagic/lift-example

[David Whittaker]

Thanks for the example.  I can definitely replicate it, and it doesn't seem to be proper behavior.  As far as I can tell, CoreRequestVarHandler.vals is either not saved after the first update, or not restored prior to the next Ajax request, but after that it works fine.  I wonder if this could possibly be related to the new Ajax de-duping code?

--
--
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
 
 
 

[Torsten Uhlmann]

I observe something similar with the latest 2.5 (M2, Snapshot) that worked with M1. in conjunction with Reactive Web.

I described the problem here: https://groups.google.com/forum/?fromgroups=#!searchin/liftweb/Torsten$20Uhlmann%7Csort:date/liftweb/wIvmaz7EGy0/1NL0Oy75K7MJ

The only libraries that changed are Lift's. I ran my code with old (around M1) snapshots and it worked, with new Snapshots it reacts only on the second click.

Torsten.

[David Whittaker]

I've been trying to track this down and I could definitely use a little help from anyone more familiar with the snapshotting of RequestVars.  Here's what I'm seeing.

- On initial page load, snapshots are made with a call to RequestVarHandler.generateSnapshotRestorer from S.PageStateHolder, which is triggered by LiftSession.processTemplate.

- The first time the ajax is triggered, the snapshot is not restored.  This seems to be because LiftServlet.handleAjax doesn't find any AjaxVersionInfo associated with the request.

- Subsequent ajax requests _do_ have AjaxVersionInfo associated with them, so snapshots are restored.

So I'm still thinking this may have something to do with the new ajax de-duping code.  I'll ping Antonio and see if he can shed any light.

[David Pollak]

Antonio made these changes... I'll pester him about them... ;-)

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Antonio Salazar Cardozo]

Yep, consider me pestered. I'll have a look at this sometime today.

--

Antonio Salazar Cardozo

Director of Engineering @ OpenStudy

On twitter @lightfiend

[Diego Medina]

Not to add pressure or anything, but another case where a first ajax
call doesn;t behave the same as a second call on 2.5-M2 (but works as
expected on 2.5-M1) is when calling

calcDefaultHref on a Menu.param

(I'll keep this code around so I can test the fix)

Thanks

Diego

Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Antonio Salazar Cardozo]

Not 100% sure if it's the same bug that's causing both of these, but I believe I've tracked down the source of this one. It looks like when we don't have a sequence number, we don't set the page render version, which breaks things a bit.

That said, both the first and second AJAX calls *should* be carrying sequence numbers. Any chance the two of you could collaborate on creating a sample project that shows the two misbehaviors while I fix the render version fix? Even if this fix takes care of those problems, I feel like something is malfunctioning, as by my understanding, the only way we should be seeing an ajax request without a version number should be Lift GC calls.

Thanks,

Antonio

[Antonio Salazar Cardozo]

Zoinks! Notably, it's highly likely this was resulting in a complete failure of the Lift function GC mechanism. The miracle here is that we didn't notice it, as we've been running this code in production for a couple of weeks now and haven't been running into unusual function cleanup issues.

Anyway, I've fixed the RenderVersion problem in pull request https://github.com/lift/framework/pull/1344 . Let me know if that works for you guys, and either way if you can create a project or two that make these issues obvious so I can play with it, that would be awesome.

Thanks,

Antonio

[Torsten Uhlmann]

Awesome, thank you!

I can't currently check it out, will do so at the week end.

I'm currently strolling around the Negev desert and Eilat beach...

Thanks,

Torsten

[pelagic]

Thanks for the support here everyone. Antonio, I have a sample project at the top of the thread that demonstrates the issue, if you want to test something.

[Antonio Salazar Cardozo]

… Heh. Fail on me for skimming. Okay, I'll try and build that project later today and see (a) if your issue is fixed and (b) if I can figure out the weirdness with sequence numbers.

Thanks!

Antonio

[Diego Medina]

Your fix, well, fixed my issue, where calling calcDefaultHref on a
menu.param was returning empty on the first call. This snippet was
inside an form:ajax.
I'll try to put together a simple app, and maybe this app could turn
into something like a test app, to test changes against regressions,
etc (for the cases where unit tests are not possible.

Thanks

Diego

On Tue, Oct 30, 2012 at 1:20 PM, Antonio Salazar Cardozo

[Jeppe Nejsum Madsen]

Diego Medina <di...@fmpwizard.com> writes:

> Your fix, well, fixed my issue, where calling calcDefaultHref on a
> menu.param was returning empty on the first call. This snippet was
> inside an form:ajax.
> I'll try to put together a simple app, and maybe this app could turn
> into something like a test app, to test changes against regressions,
> etc (for the cases where unit tests are not possible.

Would be very nice to have some test coverage of the request handling internals.

But preferrably automated :-) Not sure how hard it would be to create a
unit test for these things.

/Jeppe

[Antonio Salazar Cardozo]

Ok, just checked and this now works correctly.

I also tracked down the source of the original issue (the lack of versioning on the first request on a page), and it turns out to have been a super-n00b JavaScript mistake in the ajax code which I'll be correcting momentarily. That said, now that I've fixed the PageVersion issues, the only thing you lose is that the first request on the page will not get retried properly by the client (with properly meaning in a way that doesn't repeat the request in the event of a long server response time).

You should be able to use 2.5-SNAPSHOT to see the correctly working AJAX behavior for the page, and whenever it gets updated with the changes I'm about to make tonight, SNAPSHOT should also properly version the first request.

Sorry for the messiness!

Thanks,

Antonio

[AGYNAMIX Torsten Uhlmann]

I can confirm that it's working again in my app.

I removed my .ivy2 cache completely to ensure I get everything fresh and it's working again…

Thanks for fixing,

Torsten.

[pelagic]

Works for my app as well. Thanks!!!

Greg

[Antonio Salazar Cardozo]

Awesome, great to hear that from both of you. Sorry for the initial breakage.

Thanks,

Antonio