Shutting down a Lift app in an embedded Jetty
69 views
Skip to first unread message
elsten software
Jul 22, 2011, 9:23:52 AM7/22/11
to Lift
Hey all. My app embeds Jetty, in which a Lift application is running.
I wanted to implement a Windows Service for my app, so I used WinRun4J
to create all the necessary bits.
When you write a service with WinRun4J you write a
serviceMain(String[] args), analogous to a main(String[] args). When
the serviceMain exits the service terminates. It is shutting down the
service that I am having problems with. (If I don't start the Lift app
then shutdown works fine, so I know it's caused by something going on
in there).
If I do a thread dump I see a "Lift scheduler" thread and a lot of
"pool-x-thread-y" threads. The latter are not daemon threads; my
theory is that these are stopping the shutdown.
If I debug what is happening, these threads seem to be created when a
message called CheckAndPurge is sent to the SessionMaster. Leaving the
app running past 30mins still didn't show a shutdown (I wondered if it
was related to HTTP session timeout).
I make extensive use of actors (well, there are four of them...). I
have made sure they are not re-scheduling work with ActorPing or
whatever.
I'm running on Lift 2.4M3, embedded Jetty with continuations turned on.
I wanted to implement a Windows Service for my app, so I used WinRun4J
to create all the necessary bits.
When you write a service with WinRun4J you write a
serviceMain(String[] args), analogous to a main(String[] args). When
the serviceMain exits the service terminates. It is shutting down the
service that I am having problems with. (If I don't start the Lift app
then shutdown works fine, so I know it's caused by something going on
in there).
If I do a thread dump I see a "Lift scheduler" thread and a lot of
"pool-x-thread-y" threads. The latter are not daemon threads; my
theory is that these are stopping the shutdown.
If I debug what is happening, these threads seem to be created when a
message called CheckAndPurge is sent to the SessionMaster. Leaving the
app running past 30mins still didn't show a shutdown (I wondered if it
was related to HTTP session timeout).
I make extensive use of actors (well, there are four of them...). I
have made sure they are not re-scheduling work with ActorPing or
whatever.
I'm running on Lift 2.4M3, embedded Jetty with continuations turned on.
elsten software
Jul 22, 2011, 9:49:35 AM7/22/11
to Lift
Sorry, I forgot to say that I am stopping Jetty using the simple
Server.stop() method. After the Server has been stopped I can no
longer connect to the Lift app through the browser, but the process
continues with those pool-x-thread-y the only non-daemon threads
(other than DestroyJavaVM et al).
Server.stop() method. After the Server has been stopped I can no
longer connect to the Lift app through the browser, but the process
continues with those pool-x-thread-y the only non-daemon threads
(other than DestroyJavaVM et al).
Naftoli Gugenheim
Jul 22, 2011, 5:32:19 PM7/22/11
to lif...@googlegroups.com
Are they LiftActors, CometActors, or what?
--
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=en.
elsten software
Jul 23, 2011, 6:45:41 AM7/23/11
to Lift
They are all CometActors.
So, intrigued by your question, I setup a page with no actors, visit
it when the app is running, and when shutdown comes the app shuts down
gracefully and successfully, exhibiting the behaviour I want.
I tried adding lifespans to my actors but that didn't help.
I do override localShutdown but I made sure I called
super.localShutdown() on shutdown. localShutdown() is correctly called
when Jetty stops.
Should I move to LiftActors? I didn't think they were oriented toward
page rendering - e.g. how to get the nested template for binds?
Why else might the session still be open and sending these
CheckAndPurge messages? As I said, once shutdown it's no longer
possible to connect to the web app, so it can't be messages from the
browser keeping it alive can it?
Dan
So, intrigued by your question, I setup a page with no actors, visit
it when the app is running, and when shutdown comes the app shuts down
gracefully and successfully, exhibiting the behaviour I want.
I tried adding lifespans to my actors but that didn't help.
I do override localShutdown but I made sure I called
super.localShutdown() on shutdown. localShutdown() is correctly called
when Jetty stops.
Should I move to LiftActors? I didn't think they were oriented toward
page rendering - e.g. how to get the nested template for binds?
Why else might the session still be open and sending these
CheckAndPurge messages? As I said, once shutdown it's no longer
possible to connect to the web app, so it can't be messages from the
browser keeping it alive can it?
Dan
Naftoli Gugenheim
Jul 23, 2011, 11:21:59 PM7/23/11
to lif...@googlegroups.com
On Sat, Jul 23, 2011 at 6:45 AM, elsten software <elstens...@googlemail.com> wrote:
Should I move to LiftActors?
No, LiftActors don't do comet. I think lift's comet actors extend LiftActor.
e.g. how to get the nested template for binds?
Just to be clear, you're using comet to push content from the server subsequent to the initial rendering, right? (Just wondering why "getting the nested template" is your concern.)
elsten software
Jul 25, 2011, 8:16:00 AM7/25/11
to Lift
Yep, via partialUpdate.
By 'nested template' I mean the html between the <lift:comet/> tags.
Apologies for any confusion. This is also useful for binding in the
initial render. I prefer to have the html in the .html files... just
makes styling easier.
Dan
On Jul 24, 4:21 am, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> On Sat, Jul 23, 2011 at 6:45 AM, elsten software <
>
By 'nested template' I mean the html between the <lift:comet/> tags.
Apologies for any confusion. This is also useful for binding in the
initial render. I prefer to have the html in the .html files... just
makes styling easier.
Dan
On Jul 24, 4:21 am, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> On Sat, Jul 23, 2011 at 6:45 AM, elsten software <
>
Reply all
Reply to author
Forward
0 new messages