Tomcat/Apache ESME: Shutdown Problems

Dick Hirsch

unread,

Feb 3, 2010, 1:12:39 PM2/3/10

to Lift

A developer using ESME has a problem.

After he shuts down Tomcat, he sees that there are exceptions in the
log file. Derby is also not getting shutdown correctly. Next time,
when he restarts Tomcat, ESME fails to load and he gets all kinds of
exception in the browser.

Once he manually kils ( with -9) the java process then everything
works fine.

Here is (partial) stack trace from the log file is below.

I haven't seen this problem in jetty.

I was assuming that lift closed the DB connections / sessions
implicitly. Now I'm not so sure.

Does anyone know what the problem might be?

Here is a link to our Boot.scala file.
http://svn.apache.org/viewvc/incubator/esme/trunk/server/src/main/scala/bootstrap/liftweb/Boot.scala?view=markup

Thanks,

Dick

================
SEVERE:
A web application created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@13f79f7]) and a
value of type [org.apache.derby.iapi.services.context.ContextManager]
(value [org.apache.derby.iapi.services.context.ContextManager@b52a28])
but failed to remove it when the web application was stopped. To
prevent a memory leak, the ThreadLocal has been forcibly removed.
Feb 3, 2010 7:04:57 AM
org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Exception in thread "pool-2-thread-14" java.lang.NullPointerException
at scala.runtime.BoxesRunTime.boxToLong(Unknown Source)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$wrapQuery
$1.apply(S.scala:972)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$wrapQuery
$1.apply(S.scala:972)
at scala.List.foreach(List.scala:841)
at net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:972)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit
$1$$anonfun$apply$25.apply(S.scala:1109)
at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:906)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$doAround$1.apply
(S.scala:907)
at
net.liftweb.mapper.MetaProtoExtendedSession$myWrapper$.apply
(ProtoExtendedSession.scala:80)
at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:907)

David Pollak

unread,

Feb 3, 2010, 2:30:38 PM2/3/10

to lif...@googlegroups.com

On Wed, Feb 3, 2010 at 10:12 AM, Dick Hirsch <hirsc...@gmail.com> wrote:

A developer using ESME has a problem.

After he shuts down Tomcat, he sees that there are exceptions in the
log file. Derby is also not getting shutdown correctly. Next time,
when he restarts Tomcat, ESME fails to load and he gets all kinds of
exception in the browser.

Once he manually kils ( with -9) the java process then everything
works fine.

Here is (partial) stack trace from the log file is below.

I haven't seen this problem in jetty.

I was assuming that lift closed the DB connections / sessions
implicitly. Now I'm not so sure.

Dick,

Are you sure the Tomcat process is actually shut down? Just the brief look at the stack trace, it's looking like the JVM process didn't get killed and there's cruft on the local thread.

You might also consider using the new net.liftweb.mapper.StandardDBVendor rather than the roll-your-own DB vendor in Boot. I'll add a ticket to make sure that StandardDBVendor registers with the container shutdown so it correctly closes all connections.

Thanks,

David

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

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

Dick Hirsch

unread,

Feb 3, 2010, 2:58:14 PM2/3/10

to Lift

David,

Thanks.

Is the new StandardDBVendor just available the 2.0 Snapshot?

Do you have a link to a description of the StandardDBVendor,

D.

On Feb 3, 8:30 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote:

> On Wed, Feb 3, 2010 at 10:12 AM, Dick Hirsch <hirsch.d...@gmail.com> wrote:
> > A developer using ESME has a problem.
>
> > After he shuts down Tomcat, he sees that there are exceptions in the
> > log file. Derby is also not getting shutdown correctly. Next time,
> > when he restarts Tomcat, ESME fails to load and he gets all kinds of
> > exception in the browser.
>
> > Once he manually kils ( with -9) the java process then everything
> > works fine.
>
> > Here is (partial) stack trace from the log file is below.
>
> > I haven't seen this problem in jetty.
>
> > I was assuming that lift closed the DB connections / sessions
> > implicitly. Now I'm not so sure.
>
> Dick,
>
> Are you sure the Tomcat process is actually shut down? Just the brief look
> at the stack trace, it's looking like the JVM process didn't get killed and
> there's cruft on the local thread.
>
> You might also consider using the new net.liftweb.mapper.StandardDBVendor
> rather than the roll-your-own DB vendor in Boot. I'll add a ticket to make
> sure that StandardDBVendor registers with the container shutdown so it
> correctly closes all connections.
>
> Thanks,
>
> David
>
>
>
>
>
> > Does anyone know what the problem might be?
>
> > Here is a link to our Boot.scala file.
>

> >http://svn.apache.org/viewvc/incubator/esme/trunk/server/src/main/sca...

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

David Pollak

unread,

Feb 3, 2010, 3:06:07 PM2/3/10

to lif...@googlegroups.com

On Wed, Feb 3, 2010 at 11:58 AM, Dick Hirsch <hirsc...@gmail.com> wrote:

David,

Thanks.

Is the new StandardDBVendor just available the 2.0 Snapshot?

It's been around since 1.1-M7 I think.

Do you have a link to a description of the StandardDBVendor,

/**
* The standard DB vendor.
* @param driverName the name of the database driver
* @param dbUrl the URL for the JDBC data connection
* @param dbUser the optional username
* @param dbPassword the optional db password
*/
class StandardDBVendor(driverName: String,
                       dbUrl: String,
                       dbUser: Box[String],
                       dbPassword: Box[String]) extends ProtoDBVendor {

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.

--

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

Beginning Scala http://www.apress.com/book/view/1430219890

Timothy Perrett

unread,

Feb 3, 2010, 3:10:33 PM2/3/10

to lif...@googlegroups.com

See: http://is.gd/7Dzv4

Cheers, Tim

> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

Dick Hirsch

unread,

Feb 3, 2010, 10:37:16 PM2/3/10

to Lift

I talked to the user and he says that Tomcat didn't shutdown. He had
to kill -9 the process.

We'll move to

On Feb 3, 9:10 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> See:http://is.gd/7Dzv4

Thanks for the link. We'll move to the StandardDBVendor in our next
release.

David Pollak

unread,

Feb 3, 2010, 10:46:17 PM2/3/10

to lif...@googlegroups.com

You can also add to Boot.scala (given that the StandardDBVendor is called dbVendor):

LiftRules.unloadHooks.append(() => dbVendor.closeAllConnections_!())

What this will do is close all the DB connections when the context is unloaded.

Additionally, you can switch to H2 which is generally more stable than Derby in my experience.

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

Beginning Scala http://www.apress.com/book/view/1430219890

aw

unread,

Feb 4, 2010, 2:08:27 AM2/4/10

to Lift

I don't think this issue is related to Derby because I am seeing this
problem too -- but I am not using Derby.

What version of Tomcat are you using? I am using 6.0.24 on either
Windows or Solaris 10 and see these errors too, like: