Re: Tomcat Unix daemon (jsvc) - problem with compilation
Hello. To Chris: Thank you very much for your comments. Is there anyone who knows why Tomcat 7.0.25 (commons-daemon-1.0.8-native-src) started to use jni_md.h which is not part of IBM Java? I didn't encounter any problem with compilation of Tomcat Unix daemon (jsvc) until version Tomcat 7.0.23 (commons-daemon-1.0.7-native-src). Is it bug or intention? Thank you very much for your help. Best regards, J. Fikker. = As for the configure script, it seems like it is a bug to look for jni_md.h, as it's not an official part of JNI. configure seems to go through great pains to determine the value of JAVA_OS (which is the platform-specific subdirectory for header files) and then completely ignores the value of JAVA_OS. Honestly, I think it should probably be removed, but I'd like to hear a comment from someone more well-versed in jsvc. If you are having a problem with actually running jscv, please start a new thread with a new subject for a separate question. - -chris = Hello everybody. I encountered a problem with compilation of Unix daemon (jsvc) against IBM Java from Tomcat 7.0.40. I used these commands: cd /opt/tomcat/bin tar xvfz commons-daemon-native.tar.gz cd commons-daemon-1.0.x-native-src/unix /configure and I got this output: *** Current host *** checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib checking for strip... strip *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for JDK os include directory... Cannot find jni_md.h in /usr/lib/jvm/java-1.6.0-ibm.x86_64/ configure: error: You should retry --with-os-type=SUBDIR I found information that the reason is: IBM java uses $JAVA_HOME/include/jniport.h instead of $JAVA_HOME/include/jni_md.h in Oracle java. When I created a link jni_md.h to jniport.h I can successfully compile jsvc but when I try to start Tomcat server I have a problem with class loading (Java class not found). Is there some fix or recommendation for compilation Tomcat Unix daemon with IBM Java? Thank you very much for your help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Exeptions after upgrading to tomcat 7
> From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] > Subject: Re: Exeptions after upgrading to tomcat 7 > First we are talking about a ThreadLocal, not Thread. Read the logs again; besides the ThreadLocal abuse, there are two threads left lying around: > > SEVERE: The web application [/solr] appears to have started a thread named > > [localhost-startStop-1-SendThread(zookeeper2:2181)] but has failed to stop > > it. This is very likely to create a memory leak. > > SEVERE: The web application [/solr] appears to have started a thread named > > [localhost-startStop-1-EventThread] but has failed to stop it. This is very > > likely to create a memory leak. > Maybe I'm missing something here, but I never seen how ThreadLocal does > real harm, neither I can imagine it, please enlighten me ;-) Abusing ThreadLocal (which is what's going on here) can have very serious side effects, depending on what's stored via the reference. For example, if something specific to the request or session is kept in the ThreadLocal and not refreshed on the next unrelated request, inadvertent data sharing and potential corruption can occur. During one of the Tomcat get-togethers, we had discussed associating ThreadLocal instances with sessions rather than Threads, but that would have been a good bit of work. We settled on just purging such threads from the pool. Libraries written for non-thread-pool environments should be documented as such, and used only with great caution in server environments. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exeptions after upgrading to tomcat 7
On Sun, May 26, 2013 at 3:14 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] > > Subject: Re: Exeptions after upgrading to tomcat 7 > > > Remove following lines from server.xml: > > > >> className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> > >> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> > > This is akin to burying one's head in the sand. It would be much better > to fix the actual problem by shutting down the auxiliary thread with an > appropriate listener. Sloppy programming should not be encouraged. > Chuck, with all respect, this is easier said than done. First we are talking about a ThreadLocal, not Thread. It's tomcat who shuts the threads done due to shutdown, not the app and not the library. Now what is the negative impact of leaving a not-cleaned-up ThreadLocal? - Memory footprint? Well, we are talking about few small objects, if the app has millions of threads it probably has other problems. - Garbage? Yes, but not more than any other Thread variable, it will be collected by the GC once the Thread is collected. - Reentrance? Any lib or code that uses ThreadLocals should initialize them properly. On the other hand efforts to clean it up. You have to provide your own mechanism to clean up ThreadLocals someone else created, because most libs aren't written for redeployment and simple don't care. If they did, they would provide cleanup interfaces to their libs, making them harder to use, but what for? Cleaning ThreadLocals up is a bit like writing destructors. Further, where is the safe place to actually clean up a ThreadLocal The same you created it? So if you want to ensure that you have your threadlocal where you need it, you would set it up in filter, before chain.doFilter() and clean it up in the finally block? Wait, what about forwarded calls? They do not pass a filter, so your code would have to care how it's been called. So RequestListener remains and it will surely have it gotcha's too ;-) All in one, a lot of hustle and bustle, and what for? To clean up 200 bytes faster? Maybe I'm missing something here, but I never seen how ThreadLocal does real harm, neither I can imagine it, please enlighten me ;-) regards Leon > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail and > its attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: Exeptions after upgrading to tomcat 7
> From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com] > Subject: Re: Exeptions after upgrading to tomcat 7 > Remove following lines from server.xml: > >className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> >className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> This is akin to burying one's head in the sand. It would be much better to fix the actual problem by shutting down the auxiliary thread with an appropriate listener. Sloppy programming should not be encouraged. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exeptions after upgrading to tomcat 7
Hello Manuel, On Sat, May 25, 2013 at 10:41 PM, Manuel LeNormand < manuel.lenorm...@gmail.com> wrote: > Hello all, > I have a Solr instance running on a Tomcat 6 servlet, everything worked > fine. > While upgrading to Tomcat 7.0.34, I get exceptions I'm having a hard time > to deal with. > Two kind of exceptions occur on shutdown of service: > 1. Memory leak due to threads that do not close - I understand it is not > severe, and maybe on previous version was not monitored. Still, is there > anything that is done on the servlet side that might resolve it, and what > might be sides effects of this? > Remove following lines from server.xml: They do no good unless you are hotdeploying new versions of wars in running production servers, and no one does that ;-) regards Leon > 2. Instance of MBeans that cannot be destroyed - btw, the MBean instance > is initiated under CATALINA_OPTS. > > Thanks in advance, > Manuel > > Here are the LOGS: > INFO: A valid shutdown command was received via the shutdown port. Stopping > the Server instance. > May 13, 2013 4:22:32 PM org.apache.coyote.AbstractProtocol pause > INFO: Pausing ProtocolHandler ["http-bio-8080"] > May 13, 2013 4:22:32 PM org.apache.coyote.AbstractProtocol pause > INFO: Pausing ProtocolHandler ["ajp-bio-8009"] > May 13, 2013 4:22:32 PM org.apache.catalina.core.StandardService > stopInternal > INFO: Stopping service Catalina > May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/solr] appears to have started a thread named > [localhost-startStop-1-SendThread(zookeeper2:2181)] but has failed to stop > it. This is very likely to create a memory leak. > May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/solr] appears to have started a thread named > [localhost-startStop-1-EventThread] but has failed to stop it. This is very > likely to create a memory leak. > May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader > checkThreadLocalMapForLeaks > SEVERE: The web application [/solr] created a ThreadLocal with key of type > [org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value > [org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0]) and a > value of type [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat] > (value > [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a]) > but failed to remove it when the web application was stopped. Threads are > going to be renewed over time to try and avoid a probable memory leak. > May 13, 2013 4:22:35 PM org.apache.catalina.loader.WebappClassLoader > checkThreadLocalMapForLeaks > SEVERE: The web application [/solr] created a ThreadLocal with key of type > [org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value > [org.apache.solr.schema.DateField$ThreadLocalDateFormat@19c212b0]) and a > value of type [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat] > (value > [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a]) > but failed to remove it when the web application was stopped. Threads are > going to be renewed over time to try and avoid a probable memory leak. > May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol stop > INFO: Stopping ProtocolHandler ["http-bio-8080"] > May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol stop > INFO: Stopping ProtocolHandler ["ajp-bio-8009"] > May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol destroy > INFO: Destroying ProtocolHandler ["http-bio-8080"] > May 13, 2013 4:22:35 PM org.apache.coyote.AbstractProtocol destroy > INFO: Destroying ProtocolHandler ["ajp-bio-8009"] > May 13, 2013 4:22:35 PM org.apache.catalina.util.LifecycleMBeanBase > unregister > WARNING: Failed to unregister MBean with name > [Catalina:type=Executor,name=tomcatThreadPool] during component destruction > javax.management.InstanceNotFoundException: > Catalina:type=Executor,name=tomcatThreadPool > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(Unknown > Source) > at > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(Unknown > Source) > at > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(Unknown > Source) > at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(Unknown > Source) > at > > org.apache.catalina.util.LifecycleMBeanBase.unregister(LifecycleMBeanBase.java:194) > at > > org.apache.catalina.util.LifecycleMBeanBase.destroyInternal(LifecycleMBeanBase.java:73) > at > > org.apache.catalina.core.StandardThreadExecutor.destroyInternal(StandardThreadExecutor.java:150) > at > org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:305) > at > > org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:589) > at > org.apache.catalina.util.LifecycleBase.d
