buildDeferredFunction, OfflineRequestSnapshot and serverPort.

[Bhashit Parikh]

Hello everyone,

I have a piece of code where the snippet just puts a comet on the page, and then the rest of the work is carried out using Futures. When those Futures complete, the results are sent to the page via the comet-actor.

Now, here's the problem I am facing.

1. I am using LiftSession#buildDeferredFunction in order to be able to execute my async code in context of the original request. 
2. buildDeferredFunction() snapshots the current request, along with a lot of other stuff. As a result, an instance of net.liftweb.http.provider.servlet.OfflineRequestSnapshot is created. 
3. In this instance, all the details of the original request are stored using vals. However, only the serverPort is specifed as a lazy val. This serverPort val refers to a org.eclipse.jetty.server.Request, which happens to be mutable.
   
4. Now, in my Future code, when I need to get the serverPort, my OfflineRequestSnapshot tried to get it by accessing the jetty Request instance which it has a reference to. 
5. However, there seems to be a race-condition and, intermittently, the jetty Request instance gets changed in the middle (Jetty is reusing it?) and the details get lost, including the uri (which is set as a _uri field in that class).

Now, I can of course, get the server-port in the snippet, and pass it to the Future, along with the comet-name. However, I think I don't understand a couple of things.

1. Why is only the serverPort is declared a lazy val?
2. This is not really related to Lift, but why does jetty reset the uri field in the Request instance. I am guessing that it does so when the task on the request thread (my snippet code) returns.

Can you guys shed some light on this? Or suggest a workaround so that I don't need to pass on the server-port too? 

Thanks for reading.

[Antonio Salazar Cardozo]

Jetty Request objects are either reused or invalidated when the request

they're associated with is no longer in use.

I'm not 100% sure why David made `serverPort` a `lazy val` when he added

X-SSL understanding to it, but I'm guessing it was to minimize the performance

impact of doing the X-SSL checking every time a snapshot was taken. I think

we can probably solve this without eliminating that optimization. Can you file

an issue?

In the meantime, accessing the `serverPort` is probably something you should

do outside of your deferred function and somehow get to the deferred functions

(whether via closure or via parameter), unfortunately.

Thanks,

Antonio

[Bhashit Parikh]

Thanks Antonio. 

I'll file an issue. Not sure how to do it yet, but will find out.

Bhashit

[Bhashit Parikh]

Issue created https://github.com/lift/framework/issues/1794

[Antonio Salazar Cardozo]

Thanks!