what happened when set jruby min runtime? - jruby

I am now struggle on Jruby on Rails. We did not config the min/max jruby runtime before, the portal works well.
In these days, i found that set these config will improve our portal's performance, so I decide to config it in this way:
config.webxml.jruby.min.runtimes = 2
config.webxml.jruby.max.runtimes = 4
However, we portal can not boot up after i setting this, the log continue throw the java class can not found error:
INFO: Info: received max runtimes = 4
Dec 19, 2012 1:57:18 PM org.apache.catalina.core.ApplicationContext log
INFO: Info: received min runtimes = 2
Dec 19, 2012 1:57:18 PM org.apache.catalina.core.ApplicationContext log
INFO: Info: received max runtimes = 4
Dec 19, 2012 1:57:18 PM org.apache.catalina.core.ApplicationContext log
INFO: An exception happened during JRuby-Rack startup
cannot link Java class com.portal.util.selector.SelectorUtil, probable missing dependency: Could not initialize class com.portal.util.selector.SelectorUtil
--- System
jruby 1.6.1 (ruby-1.8.7-p330) (2011-04-12 85838f6) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_35) [linux-amd64-java]
Time: Wed Dec 19 13:57:18 +0000 2012
Server: Apache Tomcat/6.0.35
jruby.home: file:/var/tomcat/webapps/ROOT/WEB-INF/lib/jruby-stdlib-1.6.1.jar!/META-INF/jruby.home
What is the difference when we set this min/max jruby runtime? Anyone can get me out of this?
Thanks in advance.

jruby thread safe comparison
in config/warbler.rb
config.webxml.jruby.min.runtimes = 1
config.webxml.jruby.max.runtimes = 1
and in config/environments/production.rb
config.threadsafe!

Related

Upgrading logback from 1.2 to 1.3 stops logging

If I use any 1.3.x or 1.4.x logback-classic version, my application stops logging.
The logback.xml file maybe isn't even loaded (if I insert invalid xml or delete it, I get no errors).
It works fine with logback 1.2.11.
I'm using gradle automatic dependency resolution so I shouldn't have messed them.
This works:
logback-classic-1.2.11.jar + logback-core-1.2.11.jar + slf4j-api-1.7.32.jar
This doesn't work:
logback-classic-1.3.3.jar + logback-core-1.3.3.jar + slf4j-api-2.0.1.jar
java 8 on windows 10 in Eclipse 2022-09 (4.25.0)
My classpath:
activation-1.1.jar
annotations-13.0.jar
antlr-2.7.7.jar
attoparser-2.0.5.RELEASE.jar
byte-buddy-1.10.22.jar
checker-compat-qual-2.5.5.jar
checkout-sdk-1.0.5.jar
classmate-1.5.1.jar
commons-beanutils-1.9.4.jar
commons-codec-1.11.jar
commons-collections-3.2.2.jar
commons-configuration2-2.8.0.jar
commons-exec-1.3.jar
commons-fileupload-1.3.3.jar
commons-io-2.11.0.jar
commons-jxpath-1.3.jar
commons-lang3-3.12.0.jar
commons-logging-1.2.jar
commons-text-1.9.jar
concurrentlinkedhashmap-lru-1.4.2.jar
error_prone_annotations-2.5.1.jar
failureaccess-1.0.1.jar
FastInfoset-1.2.15.jar
flyway-core-5.0.5.jar
google-api-client-1.32.1.jar
google-api-client-jackson2-1.32.1.jar
google-http-client-1.39.2.jar
google-http-client-apache-v2-1.39.2.jar
google-http-client-gson-1.39.2.jar
google-oauth-client-1.31.5.jar
grpc-context-1.27.2.jar
gson-2.8.6.jar
guava-30.1.1-android.jar
hamcrest-core-1.3.jar
hibernate-commons-annotations-5.1.2.Final.jar
hibernate-core-5.5.0.Final.jar
hibernate-entitymanager-5.5.0.Final.jar
hibernate-validator-5.4.2.Final.jar
httpclient-4.5.13.jar
httpcore-4.4.14.jar
istack-commons-runtime-3.0.7.jar
j2objc-annotations-1.3.jar
jackson-annotations-2.12.7.jar
jackson-core-2.12.7.jar
jackson-databind-2.12.7.jar
jandex-2.2.3.Final.jar
javassist-3.27.0-GA.jar
javax.activation-api-1.2.0.jar
javax.inject-1.jar
javax.mail-1.6.2.jar
javax.persistence-api-2.2.jar
jaxb-api-2.3.1.jar
jaxb-runtime-2.3.1.jar
jboss-logging-3.4.2.Final.jar
jboss-transaction-api_1.2_spec-1.1.1.Final.jar
jsoup-1.9.2.jar
jsr305-3.0.2.jar
junit-4.13.2.jar
kotlin-stdlib-1.5.0.jar
kotlin-stdlib-common-1.5.0.jar
kotlin-stdlib-jdk7-1.5.0.jar
kotlin-stdlib-jdk8-1.5.0.jar
listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
logback-classic-1.3.3.jar
logback-core-1.3.3.jar
metadata-extractor-2.16.0.jar
mysql-connector-java-8.0.25.jar
mysql-connector-java-8.0.30.jar
opencensus-api-0.28.0.jar
opencensus-contrib-http-util-0.28.0.jar
paypalhttp-1.0.3.jar
protobuf-java-3.11.4.jar
protobuf-java-3.19.4.jar
selenium-api-3.8.1.jar
selenium-chrome-driver-3.8.1.jar
selenium-firefox-driver-3.8.1.jar
selenium-remote-driver-3.8.1.jar
selenium-support-3.8.1.jar
slf4j-api-2.0.1.jar
spring-aop-5.3.18.jar
spring-beans-5.3.18.jar
spring-context-5.3.18.jar
spring-context-support-5.3.18.jar
spring-core-5.3.18.jar
spring-expression-5.3.18.jar
spring-jcl-5.3.18.jar
spring-jdbc-5.3.18.jar
spring-orm-5.3.18.jar
spring-security-config-5.5.0.jar
spring-security-core-5.5.0.jar
spring-security-crypto-5.5.0.jar
spring-security-web-5.5.0.jar
spring-social-config-1.1.4.RELEASE.jar
spring-social-core-1.1.4.RELEASE.jar
spring-social-facebook-2.0.3.RELEASE.jar
spring-social-web-1.1.4.RELEASE.jar
spring-tx-5.3.18.jar
spring-web-5.3.18.jar
spring-webmvc-5.3.18.jar
stax-ex-1.8.jar
thymeleaf-3.0.15.RELEASE.jar
thymeleaf-extras-springsecurity5-3.0.4.RELEASE.jar
thymeleaf-spring5-3.0.15.RELEASE.jar
tomcat-annotations-api-8.5.82.jar
tomcat-embed-core-8.5.82.jar
tomcat-servlet-api-8.0.48.jar
tomcat-servlet-api-8.5.82.jar
txw2-2.3.1.jar
unbescape-1.1.6.RELEASE.jar
validation-api-1.1.0.Final.jar
vibur-dbcp-25.0.jar
vibur-object-pool-25.0.jar
xmpcore-6.1.11.jar
EDIT:
These few lines in build.gradle make the difference between working and not working:
implementation('ch.qos.logback:logback-classic') {
version {
strictly '1.2.11'
}
}
EDIT:
This is the console output. None of it is logged by me. The "!!!!!" line is printed with System.out.println() as suggested and is black, all the rest is red:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
nov 16, 2022 7:05:18 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-nio-8080"]
nov 16, 2022 7:05:18 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-nio-0.0.0.0-8009"]
nov 16, 2022 7:05:18 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["https-jsse-nio-8443"]
nov 16, 2022 7:05:19 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service [Tomcat]
nov 16, 2022 7:05:19 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet engine: [Apache Tomcat/8.5.83]
nov 16, 2022 7:05:19 PM org.apache.catalina.startup.ContextConfig getDefaultWebXmlFragment
INFO: No global web.xml found
nov 16, 2022 7:05:24 PM org.apache.catalina.core.ApplicationContext log
INFO: 2 Spring WebApplicationInitializers detected on classpath
nov 16, 2022 7:05:24 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder".
SLF4J: Defaulting to no-operation MDCAdapter implementation.
SLF4J: See http://www.slf4j.org/codes.html#no_static_mdc_binder for further details.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
nov 16, 2022 7:05:35 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring DispatcherServlet 'dispatcher'
nov 16, 2022 7:05:36 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-nio-8080"]
nov 16, 2022 7:05:36 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-nio-0.0.0.0-8009"]
nov 16, 2022 7:05:36 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["https-jsse-nio-8443"]
TLDR: Eclipse was adding slf4j-api-1.7.25 to the classpath because thymeleaf-3.0.15.RELEASE depended on it, ignoring the forced upgrade to slf4j-api-2.0.1.jar required by logback-classic:1.3.3. Fixed by updating to thymeleaf-3.1.0.RELEASE
There must be some bug in the Gradle dependency resolution used by Eclipse because the dependency of thymeleaf-3.0.15.RELEASE from slf4j-api-1.7.25 was not "totally" upgraded to slf4j-api-2.0.1.jar contrary to what is shown both by the Eclipse "Project and External Dependencies" tree and the manual gradle dependencyInsight command:
org.slf4j:slf4j-api:1.7.25 -> 2.0.1
+--- org.thymeleaf:thymeleaf:3.0.15.RELEASE
| \--- org.thymeleaf:thymeleaf-spring5:3.0.15.RELEASE
| \--- compileClasspath
In reality slf4j-api-1.7.25.jar was still used together with slf4j-api-2.0.1.jar but was visible only on the command line that you can get from the Eclipse "Run Configurations" > "Show Command Line" button.
This failure to upgrade a dependency doesn't always happen. In my case I had a ProjectMain depending on a ProjectLib and while both used thymeleaf-3.0.15.RELEASE just the former had a dependency on logback-classic:1.3.3 that was upgrading slf4j-api-1.7.25.jar to slf4j-api-2.0.1.jar.
EDIT:
Forcing the use of slf4j-api-2.0.1.jar on the main project doesn't prevent Eclipse from adding the old jar on the command line if the lib project still depends on it:
implementation('org.slf4j:slf4j-api') {
version {
strictly '2.0.1'
}
}
My two cents: are you using nested appenders in your configuration? If yes, this construct is not supported anymore since Logback 1.3 and your appenders may simply not be initialized. See LOGBACK-1674 for more information.

IBM APIC starting loopback

I am new to API Connect, and I have installed npm, node and apic in my local MacBook. Now I have created a loopback directory and trying to run the loopback application using apic Start. However, I am not understanding the error received from the logs:
MacBook-Pro-2:socialreviews Work$ apic start
Error: Service socialreviews started but did not initialize within the timeout period. Dumping log buffer.
[Tue Apr 30 12:02:42 2019] com.ibm.diagnostics.healthcenter.loader INFO: Node Application Metrics 3.1.3.201810251210 (Agent Core 3.2.6)
[Tue Apr 30 12:02:42 2019] com.ibm.diagnostics.healthcenter.mqtt INFO: Connecting to broker localhost:1883
strong-supervisor attaching dashboard at /appmetrics-dash
2019-04-30T09:02:42.694Z pid:44844 worker:0 INFO supervisor starting (pid 44844)
2019-04-30T09:02:42.697Z pid:44844 worker:0 INFO supervisor reporting metrics to internal:
2019-04-30T09:02:42.709Z pid:44844 worker:0 INFO supervisor size set to undefined
2019-04-30T09:02:42.905Z pid:44848 worker:1 [Tue Apr 30 12:02:42 2019] com.ibm.diagnostics.healthcenter.loader INFO: Node Application Metrics 3.1.3.201810251210 (Agent Core 3.2.6)
2019-04-30T09:02:42.959Z pid:44848 worker:1 [Tue Apr 30 12:02:42 2019] com.ibm.diagnostics.healthcenter.mqtt INFO: Connecting to broker localhost:1883
2019-04-30T09:02:42.995Z pid:44848 worker:1 strong-supervisor attaching dashboard at /appmetrics-dash
2019-04-30T09:02:45.017Z pid:44848 worker:1 Web server listening at: http://0.0.0.0:4004
2019-04-30T09:24:29.148Z pid:44844 worker:0 WARN received SIGTERM, shutting down
2019-04-30T09:24:29.148Z pid:44844 worker:0 INFO supervisor size set to undefined
2019-04-30T09:24:29.148Z pid:44844 worker:0 INFO supervisor stopped
Can someone help me with this issue please?
This issue is solved, however I am not 100% sure what was the exact issue. What I have done is ran apic edit command then when clicking on start it suddenly asked me to install docker. I have done so, then I started to have readable errors of some packages not installed. So I used npm commands to install them and my issue is fixed now! :)

Failed to run MSBuild.exe

I am trying to install CAFFE for Python 3.5 in windows 10. I follow the instructions in https://github.com/BVLC/caffe/tree/windows, and set With_Ninja=0; I get the following error when executing "scripts\build_win.cmd" in command prompt. (I am running visual studio 15 2017)
c:\projects\caffe>scripts\build_win.cmd
The system cannot find the drive specified.
The system cannot find the drive specified.
INFO: ============================================================
INFO: Summary:
INFO: ============================================================
INFO: MSVC_VERSION = 14
INFO: WITH_NINJA = 0
INFO: CMAKE_GENERATOR = "Visual Studio 14 2015 Win64"
INFO: CPU_ONLY = 0
INFO: CUDA_ARCH_NAME = Auto
INFO: CMAKE_CONFIG = Release
INFO: USE_NCCL = 0
INFO: CMAKE_BUILD_SHARED_LIBS = 0
INFO: PYTHON_VERSION = 2
INFO: BUILD_PYTHON = 1
INFO: BUILD_PYTHON_LAYER = 1
INFO: BUILD_MATLAB = 0
INFO: PYTHON_EXE = "python"
INFO: RUN_TESTS = 0
INFO: RUN_LINT = 0
INFO: RUN_INSTALL = 0
INFO: ============================================================
The system cannot find the path specified.
CMake Error at CMakeLists.txt:18 (project):
Failed to run MSBuild command:
MSBuild.exe
to get the value of VCTargetsPath:
The system cannot find the file specified
-- Configuring incomplete, errors occurred!
See also "C:/projects/caffe/build/CMakeFiles/CMakeOutput.log".
ERROR: Configure failed
your version of VS doesn't match with the required version. See:
I am running visual studio 15 2017
and,
INFO: CMAKE_GENERATOR = "Visual Studio 14 2015 Win64"
Now, you should change your version to VS 15 but as I recall VS 15 won't support "caffe" and/or will be buggy. Therefore, you should get VS 14 (Visual Studio 2015).
In fact, you don't even need to install the whole thing, install MSBuild.exe (a.k.a Build Tools) for 2015 version, add the path of .exe to system variables if it's not done automatically. The path should probably be C:\Program Files (x86)\MSBuild\14.0\Bin and that should be enough to fix the issue.
P.S. Additionally, change
INFO: PYTHON_VERSION = 2
to,
INFO: PYTHON_VERSION = 3
because you are using Python 3.5
P.P.S. If you didn't follow the instructions for GPU support, you're gonna need to go back and do or change
INFO: CPU_ONLY = 0
to,
INFO: CPU_ONLY = 1
Good luck.

Tomcat stops responding and fails to shutdown

for the last four days i am facing a problem on my production server where Tomcat stops responding, and when i try to shut it down via shutdow.sh tomcat process stays alive. i will have to kill the process and start it again.
the below stack is logged directly before tomcat crashes and stops responding. i did lots of research but couldn't solve the problem just yet.
any help is appreciated
there are two SEVERE web application errors
Jun 9, 2012 4:50:08 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/beta] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Jun 9, 2012 4:50:08 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/beta] appears to have started a thread named [MultiThreadedHttpConnectionManager cleanup] but has failed to stop it. This is very likely to create a memory leak.
and one MySQL error
INFO: Illegal access: this web application instance has been stopped already. Could not load com.mysql.jdbc.SQLError. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1587)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3358)
at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:1695)
at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4388)
at com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1368)
at com.mysql.jdbc.ConnectionImpl.finalize(ConnectionImpl.java:2737)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
full stack below
INFO: Destroying Spring FrameworkServlet 'springMvcServlet'
Jun 9, 2012 4:50:08 PM org.apache.catalina.core.ApplicationContext log
INFO: Closing Spring root WebApplicationContext
Jun 9, 2012 4:50:08 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/beta] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Jun 9, 2012 4:50:08 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/beta] appears to have started a thread named [MultiThreadedHttpConnectionManager cleanup] but has failed to stop it. This is very likely to create a memory leak.
Jun 9, 2012 4:50:09 PM org.apache.catalina.loader.WebappClassLoader validateJarFile
INFO: validateJarFile(/home/bratecp/public_html/beta/WEB-INF/lib/ImageEditor.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
Jun 9, 2012 4:50:09 PM org.apache.catalina.loader.WebappClassLoader validateJarFile
INFO: validateJarFile(/home/bratecp/public_html/beta/WEB-INF/lib/gwt-user.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
Jun 9, 2012 4:50:09 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
Jun 9, 2012 4:50:11 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load com.mysql.jdbc.SQLError. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1587)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3358)
at com.mysql.jdbc.MysqlIO.quit(MysqlIO.java:1695)
at com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4388)
at com.mysql.jdbc.ConnectionImpl.cleanup(ConnectionImpl.java:1368)
at com.mysql.jdbc.ConnectionImpl.finalize(ConnectionImpl.java:2737)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
Jun 9, 2012 4:58:44 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/jdk1.6.0_29/jre/lib/amd64/server:/usr/local/jdk1.6.0_29/jre/lib/amd64:/usr/local/jdk1.6.0_29/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Jun 9, 2012 4:58:44 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'compression' to 'on' did not find a matching property.
Jun 9, 2012 4:58:44 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'compressionMinSize' to '2048' did not find a matching property.
Jun 9, 2012 4:58:44 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'noCompressionUserAgents' to 'gozilla, traviata' did not find a matching property.
Jun 9, 2012 4:58:44 PM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'compressableMimeType' to 'text/xml,text/plain,application/json,application/javascript,text/css' did not find a matching property.
Jun 9, 2012 4:58:44 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'debug' to '1' did not find a matching property.
Jun 9, 2012 4:58:44 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'debug' to '0' did not find a matching property.
Jun 9, 2012 4:58:44 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting property 'debug' to '1' did not find a matching property.
Jun 9, 2012 4:58:45 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Jun 9, 2012 4:58:45 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Jun 9, 2012 4:58:45 PM org.apache.catalina.startup.Catalina load
There are at least two problems occurring simultaneously:
You are registering a JDBC driver that is being loaded from within your webapp's WEB-INF/lib directory and failing to deregister the driver when your webapp shuts down. You can deregister a JDBC driver easily using java.sql.DriverManager.deregisterDriver() from a ServletContextListener.
You (likely) have a non-daemon thread outliving your webapp. The only way to determine what is going on here is to take a thread dump to find out which thread is still alive (after you run shutdown.sh and wait maybe 5 seconds for everything to settle down) and where it may have come from. Basically, anywhere you start a thread in your webapp needs to have a symmetrical stop-thread when your webapp shuts down. Remember that certain operations start threads without you realizing it (for instance, creating a TimerTask, performing certain AWT-related operations, etc.).
You probably want to fix both of these problems to improve the stability of your application server.
In your stack trace above, it's a Connection finalizer that is trying to "really" close the connection to the database. I wonder if you aren't properly shutting-down your Connection objects (or a connection pool) before your webapp shuts down, and so the Connection finalizers are running after they can actually accomplish their goals (after the ClassLoader is dead).

Django + OS X + MySQL + first session variable retrieval = crash

Am experienced with Django, Apache, WSGI, MySql, etc. and have this environment setup and working fine on another OS X computer running Lion. Django session backend is db, session middleware and app are both enabled properly in settings. During first request of site view, we set a request.session key/value, which this first time thru works fine. On subsequent view though when we check if the key/value exists, we get a server-level 500 error that even with Debug mode on doesn't make it to the python interpreter to generate a full stack trace exception. The apache log generates the following messages...
[Mon Apr 16 14:26:22 2012] [notice] Apache/2.2.21 (Unix) DAV/2 mod_wsgi/3.3 Python/2.7.1 mod_ssl/2.2.21 OpenSSL/0.9.8r configured -- resuming normal operations
[Mon Apr 16 14:26:27 2012] [info] mod_wsgi (pid=2362): Create interpreter 'snap.joe|'.
[Mon Apr 16 14:26:27 2012] [info] [client 127.0.0.1] mod_wsgi (pid=2362, process='snap', application='snap.joe|'): Loading WSGI script '/var/www/venvs/snap_env/snap/wsgi/wsgi.py'.
[Mon Apr 16 14:26:32 2012] [error] [client 127.0.0.1] Premature end of script headers: wsgi.py
[Mon Apr 16 14:26:33 2012] [notice] child pid 2362 exit signal Bus error (10)
Have checked that a MySQL db table django_session row is added properly with session_data and also the cookie set in the browser after the first request contains the proper/matching session_id. If I add a simple request.session.flush() just before the existing session code, we can bypass the error obviously because there is never anything in the session. One more thing, the value we are adding to the session key/value store is a Django QuerySet object. Again, this is working on a live CentOS server, and also another Mac OS X Lion machine (albeit running Python 2.6 instead of 2.7).
Any ideas folks? Many thanks!
See documented reasons at:
http://code.google.com/p/modwsgi/wiki/FrequentlyAskedQuestions#Apache_Process_Crashes
and follow further links for possible workarounds.
In short, can be shared library version conflict, using mod_python at same time, or extension module for Python that doesn't work with sub interpreter.
If this is only Python site on that Apache, set:
WSGIApplicationGroup %{GLOBAL}
for one potential quick solution.
A few thoughts:
1) are you running the same versions of modules? Django just recently updated (1.4), so if you did a pip install and didn't specify a version your production might have an older version while your development has the newer one.
2) Can you test this using just the manage.py runserver? My suspicions are that it's something to do with the apache config (so if it works fine in runserver, that means the issue is with apache).