Benefits for Lift apps from running in a servlet container

[Alex Kotchnev]

I'm trying to figure out what the benefits are for a Lift as a web
framework to be running in a servlet container. I understand that
being able to support deployment into a "legacy" environment where an
operations group is comfortable with deploying web apps into java ee
servlet containers. At the same token, I keep wondering why that is
necessary - it does seem like lift has a solid request processing
pipeline , and stores the response generating functions in memory (so,
it really isn't dependent on servlet sessions).

Anyway, just a point of curiosity . This is to some extent coming from
a comparison with Play2 that ended up just discarding all of the
legacy deployment methods and handles everything w/o an app server.

I would appreciate your thoughts on the subject.

Cheers - Alex K

[Tim Nelson]

Hi Alex,

Lift is built on servlets, so there's really no option to run it without a servlet container. There was some work done to support Netty, but I don't think that was ever finished.

The benefits are, like you said, that it's been around for a long time and therefore it's robust and people are used to it.

You can embed Jetty into your app so you don't have to install anything but a JVM on the server. This is the way I do it and would recommend if you don't need/want to install a servlet container on the server.

Tim

[Alex Kotchnev]

Tim,
thanks a lot for sharing your perspective on this. I understand and
appreciate the benefits of running inside a well proven technology
stack, and in the past being able to run inside a servlet container
has certainly been an important differentiator for a web framework. I
just wonder if that requirement is still an advantage for the
framework, or if it's something that's holding it back.

In any case, if it's not broken, there is no need to fix it. Like I
said before, it was mostly a curiosity item.

Cheers - Alex K

> --
> --
> 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/d/optout.

[Diego Medina]

Besides the response from Tim, I would add that relaying on a container saves us development time. When SPDY came out, we didn't have to do anything in Lift to support it, I just had to use the right jetty version, maybe make a few config changes and it worked. I haven't try but I'm pretty sure the same is true for http2.

And finally, I haven't run into any issues **because** Lift needs a servlet.

Thanks

Diego

> email to liftweb+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

[Alex Kotchnev]

Diego,
thanks for the clarification. Doesn't the servlet API pre-suppose a
specific threading model - e.g. a new thread handling each incoming
http connection ? For example, I recall that a tomcat configuration
has some explicit settings for the thread pools that handle incoming
requests. So, when Lift runs inside a servlet container, one has to
contend both with the servlet container's preference on how to
allocate threads and handle incoming requests, and with how Lift wants
to deal with them (e.g. actors)

Anyway, I'm curious to understand how Lift deals with this - a
per-thread model for handling requests on the front of request
handling, and a more asynchronous (e.g. actor based) model for
handling the responses in the back.

Cheers - Alex K

>> > email to liftweb+u...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> --
>> 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/d/optout.
>
>
>
>
> --
> Diego Medina
> Lift/Scala Consultant
> di...@fmpwizard.com
> https://blog.fmpwizard.com/
>

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

[Diego Medina]

Hi Alex,

I'm going to let others give you a proper answer there. Lift has been working very well for us on production using jetty for over 4 years that I haven't had to dig deep to see how the plumbing works.

What I do remember is that if you are using Lift as a rest api, you can use the servlet continuation feature, (you may already know this but...) which basically puts the thread back in the pool ready to handle new incoming http requests, and while that happens, Lift can handle the actual gathering of data/etc to respond, once the response is ready, Lift picks a thread back from the pool (could be the same, could be a different one, doesn't matter), and the response is sent to the client.

Regards,

Diego

>> > email to liftweb+unsubscribe@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> --
>> 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+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Diego Medina
> Lift/Scala Consultant
> di...@fmpwizard.com
> https://blog.fmpwizard.com/
>
> --
> --
> 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+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Antonio Salazar Cardozo]

Net-net---servlet containers do presuppose a certain threading model, but they

can use threads efficiently as Diego pointed out. Lift aggressively uses these

newer features.

Developing our own HTTP layer is certainly a path we can take, but is a pretty

large distraction from developing the rest of the framework on top of a variety

of proven HTTP layers, which is what servlets provide. Reusing another one, like

netty, is a potential option, but would require some work. There was work put

towards this, including by StackMob, a company that used Lift and was acquired

by eBay a few years ago, but it was never merged into the mainline and I believe

was never fully completed.

A customary reminder that there are no Lift developers who are paid to work full-

time on Lift, so we have to more aggressively reuse code in cases where writing

our own doesn't meaningfully contribute to the framework's overall goals and feel.

None of us has considered it a priority to not use servlets (including those of us who

use Lift in production and see relatively few serious issues from doing so), but I

don't know that we'd be unreceptive to work that would seek to make that more

adaptable, if it were comprehensive across Lift's feature set.

Thanks,

Antonio

[David Pollak]

A couple of things...

Lift is *not* one thread per request. Lift automatically determines the capabilities of the servlet container that it's running in and if that container supports asynchronous request/response cycles, Lift will use these. Specifics of Lift using Jetty and newer Tomcat async code includes Comet/Long Polling as well as Lift 3's RESTHelper returning Futures.

Lift is *not* tied to the container. There are a couple of repos laying around that are "Lift on Netty" without all the servlet container stuff. But, at the end of the day, nobody really cares... if they did, there'd be more demand to include the "Lift on Netty" code in the Lift repos.

So...

If you've got a compelling reason to use Lift as java -jar my_lift_app.jar, please let us know.

But for all my stuff, I like the benefits of dropping Lift into Jetty and getting all the Jetty goodness. Just like I don't have a reason to link my Lift app into Nginx, I don't really have a reason to link the HTTP serving portion of the app into my Lift app.

Twitter: http://twitter.com/dpp

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

Blog: http://goodstuff.im