Where are the dragons hiding?

[Paul Butcher]

I'm seriously considering Lift for a new project. I know what the
benefits of Scala and Lift are (that's why I'm seriously considering
this as a route forwards :-) What I'm wondering is whether there are
any lurking nasties that I should be aware of (so that I can avoid
learning about them the hard way).

Some background: Until recently I was CTO of Texperts, a UK startup.
We moved to using Ruby on Rails shortly after version 1.0 was released
(i.e. when it was at just about the same level of maturity as Lift is
now). Our experience was mostly very good - the major issues we had
were deployment problems arising from the fact that Ruby's threads
aren't really threads.

I'm now looking at a new project, a significant chunk of which will be
a webservice likely to be installed within a mobile network operator's
infrastructure. That fact is a powerful argument for writing it in
Java (MNOs all know how to run big Java app servers) but the very
thought of being stuck writing Java for the foreseeable future makes
me break out in hives :-)

So I'm considering Scala and Lift. In particular, I'm considering the
tradeoffs of Lift versus something like Spring+Scala.

I'm not too worried about problems that might bite us while we're
developing the service. I hope that we're smart enough, and the Lift
community is helpful enough, that we should be able to work our way
through those kinds of problem (although a heads-up would still be
welcome).

What I *am* worried about are problems that might bite us when we come
to install the service at an MNO. Having said "don't worry - it'll run
on your app server just fine", is there anything that might prove
problematic if we choose Lift? Is there anything we can do ahead of
time to head this kind of problem off at the pass? How should we test
to minimise the chance of problems? Would choosing Spring+Scala
decrease any of these risks?

Very many thanks in advance for any help or advice you can offer,

paul.butcher->msgCount++

[Marius]

On Nov 18, 6:31 pm, Paul Butcher <p...@paulbutcher.com> wrote:
> I'm seriously considering Lift for a new project. I know what the
> benefits of Scala and Lift are (that's why I'm seriously considering
> this as a route forwards :-) What I'm wondering is whether there are
> any lurking nasties that I should be aware of (so that I can avoid
> learning about them the hard way).

Not sure if there is any. One thing though Lift's session state is
kept in memory and not serialized in the DB. Session serialization is
a bit tricky since we keep the bound functions on the session state.
Those functions are in many cases anonymous function that may hold
other references which are not serializable. Even if everything is
serializable using Java serialization is likely suboptimal. But
keeping the sessions in memory and have a session affinity load
balancing is a very good choice from performance perspective.

>
> Some background: Until recently I was CTO of Texperts, a UK startup.
> We moved to using Ruby on Rails shortly after version 1.0 was released
> (i.e. when it was at just about the same level of maturity as Lift is
> now). Our experience was mostly very good - the major issues we had
> were deployment problems arising from the fact that Ruby's threads
> aren't really threads.
>
> I'm now looking at a new project, a significant chunk of which will be
> a webservice likely to be installed within a mobile network operator's
> infrastructure. That fact is a powerful argument for writing it in
> Java (MNOs all know how to run big Java app servers) but the very
> thought of being stuck writing Java for the foreseeable future makes
> me break out in hives :-)
>
> So I'm considering Scala and Lift. In particular, I'm considering the
> tradeoffs of Lift versus something like Spring+Scala.

IMHO there is no tradeoff. Scala's nature tremendously facilitates
things using functional composition and Spring's MVC/AOP etc. doesn;t
really bring you much benefits. Not to mention that Lift's templating
mechanism is really great.

>
> I'm not too worried about problems that might bite us while we're
> developing the service. I hope that we're smart enough, and the Lift
> community is helpful enough, that we should be able to work our way
> through those kinds of problem (although a heads-up would still be
> welcome).

I'd say that this is a safe bet.

>
> What I *am* worried about are problems that might bite us when we come
> to install the service at an MNO. Having said "don't worry - it'll run
> on your app server just fine", is there anything that might prove
> problematic if we choose Lift?

In essence Lift start as a plain servlet filter so I wouldn't expect
any incompatibilities. But I'd recommend lightweight containers with
nice non-blocking IO. Jetty looks to be a good choice. Non blocking IO
support is particularly helpful when using Comet and Lift has a built
in mechanism for that.

Is there anything we can do ahead of
> time to head this kind of problem off at the pass? How should we test
> to minimise the chance of problems? Would choosing Spring+Scala
> decrease any of these risks?

I don't see what Spring brings and Lift doesn't and how it would
minimize risks.

[harryh]

Some issues I've run into along the way that you should be aware of
(in no particular order):

- Don't use Lift with MySQL, they don't play nicely. Use PostgreSQL

- Be away that Lift webservers are stateful, so if you have more than
1 of them serving the same application you will need sticky sessions.
It can take some care to get this set up right.

- Take care to serve items that don't require session state from the
"stateless dispatch table." Further, things like static images, css,
and js files shouldn't be served by lift at all. I as running into
problems with too many single use sessions being created (from things
like web crawlers) and it causing CPU spike when the GC got
overwhelmed.

-harryh

[cody koeninger]

On Nov 18, 11:32 am, harryh <har...@gmail.com> wrote:

> - Don't use Lift with MySQL, they don't play nicely.  Use PostgreSQL
>

Can you elaborate?

[Marius]

If I may .. this statement is confusing leading to incorrect
interpretation. Lift works with MySQL as ANY Java application. Harry
may have referred to Lift's Mapper framework which for MySql may be
some problems that I'm not aware of. But if MySQL becomes critical for
you I'm sure things can be prioritized.

[harryh]

See this thread:

http://groups.google.com/group/liftweb/browse_thread/thread/4a174ecf34873967/

In which we discuss how certain queries generated by Mapper perform
very poorly on MySQL. Certainly this problem could be addressed, but
until it is using Mapper with MySQL will be problematic.

-harryh

[Eros Candelaresi]

Hi,

Marius wrote:

On Nov 18, 6:31 pm, Paul Butcher <p...@paulbutcher.com> wrote:
  

I'm seriously considering Lift for a new project. I know what the
benefits of Scala and Lift are (that's why I'm seriously considering
this as a route forwards :-) What I'm wondering is whether there are
any lurking nasties that I should be aware of (so that I can avoid
learning about them the hard way).
    

Not sure if there is any. One thing though Lift's session state is
kept in memory and not serialized in the DB. Session serialization is
a bit tricky since we keep the bound functions on the session state.
Those functions are in many cases anonymous function that may hold
other references which are not serializable. Even if everything is
serializable using Java serialization is likely suboptimal. But
keeping the sessions in memory and have a session affinity load
balancing is a very good choice from performance perspective.

  

There are people playing around with Terracotta (http://www.terracotta.org/web/display/orgsite/Platform) and Lift. There seems to be some success regarding actors running on a cluster. No idea if Terracotta plays well with Lift session handling. There's only an unanswered post in the ML archive on that.

Regards,
Eros

[Paul Butcher]

Thanks everyone - that's exactly the kind of information that I was
looking for.

Now all I need to do is persuade my colleagues that selecting a young
technology (again) is a good idea ;-)

Thanks again,

paul.butcher->msgCount++

[David Pollak]

Paul,

I think this thread contains the key dragons in Lift.  Basically, it boils down to: Lift is highly stateful... that has its pluses and minuses.  We're working on mitigating the minuses (session replication and persistence).

But one of the key things to keep in mind regarding Lift is how we as a community handle problems.  One of the biggest, nastiest bugs in Lift-land crept into the code in the last few days: http://groups.google.com/group/liftweb/browse_thread/thread/558280f51666972f/0291e1224f0f0ce8?hl=en#0291e1224f0f0ce8.  Sessions were getting destroyed seemingly randomly.  Please look at how the problem was dealt with.  There will be bugs in Lift in the future.  You can expect that they will be dealt with in the future in the same way.  What you will hear from the Lift developers is that we stand behind Lift and when there are problems, we stand behind fixing them.  In terms of Scala the language, EPFL has a very similar attitude.  We will do what it takes to support the folks who bet their careers and companies on Lift right on down to the JVM.

Thanks,

David

paul.butcher->msgCount++

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Paul Butcher]

On Nov 19, 12:37 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> But one of the key things to keep in mind regarding Lift is how we as a
> community handle problems.  One of the biggest, nastiest bugs in Lift-land

> crept into the code in the last few days:http://groups.google.com/group/liftweb/browse_thread/thread/558280f51....

> Sessions were getting destroyed seemingly randomly.  Please look at how the
> problem was dealt with.  There will be bugs in Lift in the future.  You can
> expect that they will be dealt with in the future in the same way.  What you
> will hear from the Lift developers is that we stand behind Lift and when
> there are problems, we stand behind fixing them.  In terms of Scala the
> language, EPFL has a very similar attitude.  We will do what it takes to
> support the folks who bet their careers and companies on Lift right on down
> to the JVM.

Good to know - thanks David.

I'm sure that I will have reason to call on that support, so thanks in
advance :-)

paul.butcher->msgCount++

[ngocdaothanh]

Is Lift suitable for web for mobiles?

Generally web for mobiles (especially in Japan) has some
characteristics:
* No JavaScript support
* No cookie support
* Non standard HTML tags

Thanks

[Marius]

It should be just fine.

You can tell lift to not use Ajax or any JS at all. There are some
flags in LiftRules to do that.

LiftRules.setAutoIncludeComet = false;
LiftRules.setAutoIncludeAjax = false;


Besides that just don't use JS in your markup or don't use Lift's ajax
stuff.

Lift works with no cookies. Turning off cookies from container would
automatically make Lift to use url-rewriting and put jsessionid in
urls.

You should be able to use XHTML MP with no problems.

Br's,
Marius

[Jeppe Nejsum Madsen]

Marius <marius...@gmail.com> writes:

> It should be just fine.
>
> You can tell lift to not use Ajax or any JS at all. There are some
> flags in LiftRules to do that.
>
> LiftRules.setAutoIncludeComet = false;
> LiftRules.setAutoIncludeAjax = false;
>
>
> Besides that just don't use JS in your markup or don't use Lift's ajax
> stuff.

Even if you don't explicitly use any Ajax, I believe Lift will store
callback mappings in the session? How does Lift's GC work if there's no
JS support?

/Jeppe

[David Pollak]

The functions are retained for the duration of the session.  This will not likely cause an issue on mobiles and the usage is not likely to produce a lot of pages/forms during a given session.
 

/Jeppe

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=.