Tomcat Native with APR/SSL
Hi, For 2 or 3 days , I've had a problem with tomcat native.I installed apr 1.4..6 , apr-util 1.5.2 and openssl 1.1.1e then tomcat native 1.1.27. When starting tomcat 7.0.40 , I've had this error : INFO: Loaded APR based Apache Tomcat Native library 1.1.27 using APR version 1.4.6. mai 31, 2013 9:35:22 AM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. mai 31,2013 9:35:22 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent SEVERE: Failed to initialize the SSLEngine. org.apache.tomcat.jni.Error: 70023: This function has not been implemented on this platform at org.apache.tomcat.jni.SSL.initialize(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:259) at org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:110) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99) at org.apache.catalina.startup.Catalina.load(Catalina.java:633) at org.apache.catalina.startup.Catalina.load(Catalina.java:658) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455) Do you have an workaround for this problem please? Thanks Best regards, Derri Anass
Re: Tomcat Native with APR/SSL
I've found error . It was just wrong path to certificate and key. Thx at all. - Mail original - De: de...@cines.fr À: users@tomcat.apache.org Envoyé: Mardi 4 Juin 2013 10:35:40 Objet: Tomcat Native with APR/SSL Hi, For 2 or 3 days , I've had a problem with tomcat native.I installed apr 1.4..6 , apr-util 1.5.2 and openssl 1.1.1e then tomcat native 1.1.27. When starting tomcat 7.0.40 , I've had this error : INFO: Loaded APR based Apache Tomcat Native library 1.1.27 using APR version 1.4.6. mai 31, 2013 9:35:22 AM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. mai 31,2013 9:35:22 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent SEVERE: Failed to initialize the SSLEngine. org.apache.tomcat.jni.Error: 70023: This function has not been implemented on this platform at org.apache.tomcat.jni.SSL.initialize(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:259) at org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:110) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:99) at org.apache.catalina.startup.Catalina.load(Catalina.java:633) at org.apache.catalina.startup.Catalina.load(Catalina.java:658) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455) Do you have an workaround for this problem please? Thanks Best regards, Derri Anass
SlowQueryReport
Dear Users,
Please help to me:
How to get SlowQueryReport statistics?
I tried:
Map map =
SlowQueryReport.getPoolStats("java:comp/env/jdbc/xxx");
and
Map map =
SlowQueryReport.getPoolStats("xxx");
The result in both case was a null map.
Thanks,
Ferenc
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: IE 8 and before refusing to download files (I hate IE)
2013/6/4 Jeffrey Janner : >> -Original Message- >> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] >> Sent: Monday, June 03, 2013 3:39 PM >> To: 'Tomcat Users List'; 'verlag.preis...@t-online.de' >> Subject: RE: IE 8 and before refusing to download files (I hate IE) >> >> > -Original Message- >> > From: verlag.preis...@t-online.de [mailto:verlag.preisser@t- >> online.de] >> > Sent: Monday, June 03, 2013 1:28 PM >> > To: Tomcat Users List >> > Subject: Re: IE 8 and before refusing to download files (I hate IE) >> > >> > Hi, >> > >> > -Original-Nachricht- >> > > Von: Jeffrey Janner >> > > An: 'Tomcat Users List' >> > >> > > Ran into an interesting problem today. It seems that IE8 and >> before >> > > no longer likes how we are sending BLOB files. >> > > >> > > Worked last week as far as we can tell. Works fine for IE9+ and >> > other >> > > browsers, but IE8 is suddenly giving us an error message, as though >> > it >> > > is ignoring the response headers. >> > > >> > > I'm not going to completely rule out the possibility it is in our >> > code >> > > somewhere, but we haven't found it yet. We did also upgrade out >> app >> > > over the weekend, but the problem didn't show up in our test >> > > environment (as far as we can tell). >> > > >> > > Here is the relevant code: >> > > >> > [...] >> > > >> > > Works great if the MimeType is text/html, but anything else >> > > generates an error. >> > > >> > > The getContent routine reads from the BLOB and copies it to the >> > > response output stream. >> > > >> > > None of this code has changed, and the access log shows a 200 >> > response >> > > and the full number of bytes of the file. >> > > >> > > Anybody have any ideas? >> > > >> > > Server1 specs: Tomcat 6.0.33/Java 1.6.0_33/Windows 2003 SP2 >> > > Server2 specs: Tomcat 6.0.36/Java 1.6.0_34/Windows 2008 R2/SP1 >> > >> > >> > can you give an example of the actual HTTP response headers that are >> > sent to the client? >> > >> > I just tested that the following response works with IE8 on WinXP and >> > IE10 using its IE8-Mode on WIndows 8: >> > >> > HTTP/1.1 200 OK >> > Transfer-Encoding: chunked >> > Content-Type: application/x-zip-compressed >> > Server: Microsoft-IIS/7.5 >> > Content-Disposition: attachment; filename=Portal.zip >> > Date: Mon, 03 Jun 2013 18:14:14 GMT >> > >> > [...] >> > >> > This is generated by a Servlet on Tomcat 7.0.40 that sets the >> Content- >> > Type and Content-Disposition headers and then writes bytes to the >> > respone's OutputStream (the response is served by IIS/7.5 using ISAPI >> > Redirector). For Content-Disposition, I'm using >> > javax.mail.internet.ContentDisposition which should automatically add >> > necessary escaping and quoting to the "filename:" part. >> > >> > I also tested with IE10's IE7-Mode that is used when activating >> > Compatibility View and no X-UA-Compatible header is present that >> tells >> > IE to use it's highest browser mode (like "X-UA-Compatible: >> IE=Edge"). >> > >> > (As an aside, for my websites I don't support any IE below IE9... ;-) >> > However, I use the "X-UA-Compatible: IE=Edge" header to prevent IE to >> > use the compatibility mode, which can happen if Microsoft suddenly >> > decides to add your site to its "compatibility view list", or >> > sometimes if IE is embedded as ActiveX control etc...) >> > >> > >> > Regards, >> > Konstantin Preißer >> > >> >> The error presented is "Internet Explorer cannot download from >> from . Internet Explorer was unable to open this >> Internet site. The request site is either unavailable for cannot be >> found. Please try again later." >> >> But figured it just now. >> I had removed the line >> > securePagesWithPragma="false" /> from my context files as it >> wasn't supposed to be needed, since we don't do SSL Authentication for >> logins. >> However, apparently it is setting something in the response header that >> matters as a side effect of being there. >> Now I just need to find out what so I can duplicate it with a filter. >> >> Jeff >> > > For those who might be interested, here are the two header sets returned: > > Without SSLAuthenticator: > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Pragma: No-cache > Cache-Control: no-cache > Expires: Wed, 31 Dec 1969 18:00:00 CST > Content-Disposition: attachment; > filename=SITE_VIEW_COST_SAVING_PART_NUMBER_%26QUOT%3BQUOTES_IN_PROJ_SV%26QUOT%3B_20130603.xls; > Content-Type: application/vnd.ms-excel > Transfer-Encoding: chunked > Date: Mon, 03 Jun 2013 22:34:41 GMT > > With SSLAuthenticator: > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Cache-Control: private > Expires: Wed, 31 Dec 1969 18:00:00 CST > Content-Disposition: attachment; > filename=SITE_VIEW_COST_SAVING_PART_NUMBER_%26QUOT%3BQUOTES_IN_PROJ_SV%26QUOT%3B_20130603.xls; > Content-Type: application/vnd.ms-excel > Transfer-Encoding: chunked > Date: Mon, 03 Jun 2013 22:29:41 GMT > > Note the only real difference is the addition of a Pragma head
Re: .net web service client calling Tomcat 7
Is there a RFC that describes best behaviour of server and client in this situation? On my opinion Tomcat behaves correctly. If client doesn't send proper credentials it is dangerous and useless to read all input data. I've switched off the connection keep alive at Connector config. And now client doesn't suffer by closing a socket. So this is a solution for "bad" .net client. Jan. When client sends a request there are written 2 lines at tomcat access log: 192.168.1.211 - - [03/Jun/2013:16:02:24 +0200] "POST /ades-server/adesOperationsWebService HTTP/1.1" 401 951 192.168.1.211 - - [01/Jan/1970:00:59:59 +0100] "http://schemas.xmlsoap.org/soap/envelope/";> I can't offer an answer, but sympathy and a workaround: We ran into this exact same issue when we moved to Apache httpd webservers. We opted to disable keepalive for "MS Web Services" clients with: BrowserMatch "MS Web Services" nokeepalive rather than fighting an RFC interpretation battle... It looks like similar could be done in tomcat with "restrictedUserAgents" option on the http connector: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html -- Bill - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SlowQueryReport
On Jun 4, 2013, at 6:26 AM, Lutischán Ferenc wrote:
> Dear Users,
>
> Please help to me:
> How to get SlowQueryReport statistics?
Usually these are logged as WARN messages. Unless you use SlowQueryReportJmx
and then they are logged and sent as JMX notifications.
>
> I tried:
>
> Map map =
> SlowQueryReport.getPoolStats("java:comp/env/jdbc/xxx");
> and
> Map map =
> SlowQueryReport.getPoolStats("xxx");
>
> The result in both case was a null map.
Can you elaborate on what you are trying to do here?
Are you using Tomcat?
If so…
1.) What version are you using?
2.) How do you have your data source configured? Please include the resource
tag.
If not…
1.) Are you using the Tomcat's jdbc-pool directly?
2.) How are you setting it up?
3.) How is it configured?
4.) What version are you using?
Dan
>
>
> Thanks,
> Ferenc
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: IE 8 and before refusing to download files (I hate IE)
> -Original Message- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > Sent: Tuesday, June 04, 2013 5:51 AM > To: Tomcat Users List > Subject: Re: IE 8 and before refusing to download files (I hate IE) > > 2013/6/4 Jeffrey Janner : > >> -Original Message- > >> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > >> Sent: Monday, June 03, 2013 3:39 PM > >> To: 'Tomcat Users List'; 'verlag.preis...@t-online.de' > >> Subject: RE: IE 8 and before refusing to download files (I hate IE) > >> > >> > -Original Message- > >> > From: verlag.preis...@t-online.de [mailto:verlag.preisser@t- > >> online.de] > >> > Sent: Monday, June 03, 2013 1:28 PM > >> > To: Tomcat Users List > >> > Subject: Re: IE 8 and before refusing to download files (I hate > IE) > >> > > >> > Hi, > >> > > >> > -Original-Nachricht- > >> > > Von: Jeffrey Janner > >> > > An: 'Tomcat Users List' > >> > > >> > > Ran into an interesting problem today. It seems that IE8 and > >> before > >> > > no longer likes how we are sending BLOB files. > >> > > > >> > > Worked last week as far as we can tell. Works fine for IE9+ and > >> > other > >> > > browsers, but IE8 is suddenly giving us an error message, as > >> > > though > >> > it > >> > > is ignoring the response headers. > >> > > > >> > > I'm not going to completely rule out the possibility it is in > our > >> > code > >> > > somewhere, but we haven't found it yet. We did also upgrade out > >> app > >> > > over the weekend, but the problem didn't show up in our test > >> > > environment (as far as we can tell). > >> > > > >> > > Here is the relevant code: > >> > > > >> > [...] > >> > > > >> > > Works great if the MimeType is text/html, but anything else > >> > > generates an error. > >> > > > >> > > The getContent routine reads from the BLOB and copies it to the > >> > > response output stream. > >> > > > >> > > None of this code has changed, and the access log shows a 200 > >> > response > >> > > and the full number of bytes of the file. > >> > > > >> > > Anybody have any ideas? > >> > > > >> > > Server1 specs: Tomcat 6.0.33/Java 1.6.0_33/Windows 2003 SP2 > >> > > Server2 specs: Tomcat 6.0.36/Java 1.6.0_34/Windows 2008 R2/SP1 > >> > > >> > > >> > can you give an example of the actual HTTP response headers that > >> > are sent to the client? > >> > > >> > I just tested that the following response works with IE8 on WinXP > >> > and > >> > IE10 using its IE8-Mode on WIndows 8: > >> > > >> > HTTP/1.1 200 OK > >> > Transfer-Encoding: chunked > >> > Content-Type: application/x-zip-compressed > >> > Server: Microsoft-IIS/7.5 > >> > Content-Disposition: attachment; filename=Portal.zip > >> > Date: Mon, 03 Jun 2013 18:14:14 GMT > >> > > >> > [...] > >> > > >> > This is generated by a Servlet on Tomcat 7.0.40 that sets the > >> Content- > >> > Type and Content-Disposition headers and then writes bytes to the > >> > respone's OutputStream (the response is served by IIS/7.5 using > >> > ISAPI Redirector). For Content-Disposition, I'm using > >> > javax.mail.internet.ContentDisposition which should automatically > >> > add necessary escaping and quoting to the "filename:" part. > >> > > >> > I also tested with IE10's IE7-Mode that is used when activating > >> > Compatibility View and no X-UA-Compatible header is present that > >> tells > >> > IE to use it's highest browser mode (like "X-UA-Compatible: > >> IE=Edge"). > >> > > >> > (As an aside, for my websites I don't support any IE below IE9... > >> > ;-) However, I use the "X-UA-Compatible: IE=Edge" header to > prevent > >> > IE to use the compatibility mode, which can happen if Microsoft > >> > suddenly decides to add your site to its "compatibility view > list", > >> > or sometimes if IE is embedded as ActiveX control etc...) > >> > > >> > > >> > Regards, > >> > Konstantin Preißer > >> > > >> > >> The error presented is "Internet Explorer cannot download from > >> from . Internet Explorer was unable to open > this > >> Internet site. The request site is either unavailable for cannot be > >> found. Please try again later." > >> > >> But figured it just now. > >> I had removed the line > >>className="org.apache.catalina.authenticator.SSLAuthenticator" > >> securePagesWithPragma="false" /> from my context files as it > >> wasn't supposed to be needed, since we don't do SSL Authentication > >> for logins. > >> However, apparently it is setting something in the response header > >> that matters as a side effect of being there. > >> Now I just need to find out what so I can duplicate it with a > filter. > >> > >> Jeff > >> > > > > For those who might be interested, here are the two header sets > returned: > > > > Without SSLAuthenticator: > > HTTP/1.1 200 OK > > Server: Apache-Coyote/1.1 > > Pragma: No-cache > > Cache-Control: no-cache > > Expires: Wed, 31 Dec 1969 18:00:00 CST > > Content-Disposition: attachment; > > > filename=SITE_VIEW_COST_SAVING_PART_NUMBER_%26QUOT%3BQUOTES_IN_PROJ_SV > > %26Q
RE: .net web service client calling Tomcat 7
> Is there a RFC that describes best behaviour of server and client in this > situation? My guess is that the disagreement comes somewhere in RFC 2616 section 8.2.3 - Use of the 100 (Continue) Status. http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html > On my opinion Tomcat behaves correctly. If client doesn't send proper > credentials it is dangerous and useless to read all input data. That was our opinion for httpd as well. > I've switched off the connection keep alive at Connector config. And now > client doesn't suffer by closing a socket. So this is a solution for "bad" > .net client. > Jan. Glad to hear! -- Bill - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Best practices for shared classloader use?
I am considering using the Tomcat 7 shared classloader to reduce the memory footprint of my web apps. But, I'm afraid that loading my application jar files into a single classloader will cause lots of problems. I'm aware that the shared classpath should not specify multiple versions of the same class. But I suspect, for example, that classes that have static properties must not be shared. Am I correct in thinking this? Are there other problems that I should anticipate? Thanks!
Re: Best practices for shared classloader use?
Hi Don! You can try to move only common libs shared by all yor different webapps to the shared classloader but leave the application core in seperate war files? Jens Sent from my iPhone On 04.06.2013, at 17:36, Don Asper wrote: > I am considering using the Tomcat 7 shared classloader to reduce the memory > footprint of my web apps. But, I'm afraid that loading my application jar > files into a single classloader will cause lots of problems. I'm aware that > the shared classpath should not specify multiple versions of the same class. > But I suspect, for example, that classes that have static properties must not > be shared. Am I correct in thinking this? Are there other problems that I > should anticipate? Thanks! > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Best practices for shared classloader use?
Sorry, I was not clear in my first post. I want to load the jars containing functionality that is common to my web apps using the shared classloader. I anticipate that there can be problems if different versions of the same class are on the shared classpath. I also suspect that any common jars or classes will cause a problem if they contain static fields. Am I correct in this? Are there other problems that typically occur when attempting to share classes? What should I watch out for when trying to share functionality between my web apps? Thanks.
Re: Best practices for shared classloader use?
Hi Don! Usually each Webapp has its own classloader thus two webapps can have different versions of the same class. Classloaders are chained so if a class is not found search continues in the next classloader. Shared just means one classloader is used by different webapps thus you may run into trouble if each webapp requires a different class version (changed method signature) as you can not predict which version you get. As long you can align the shared libs across all webapps this is not an issue. I do not see your static field problem, though? Share functionality like using the same jars? If all use the same version you can push it to the shared imho. Jens Sent from my iPhone On 04.06.2013, at 18:03, Don Asper wrote: > Sorry, I was not clear in my first post. I want to load the jars containing > functionality that is common to my web apps using the shared classloader. I > anticipate that there can be problems if different versions of the same class > are on the shared classpath. I also suspect that any common jars or classes > will cause a problem if they contain static fields. Am I correct in this? > Are there other problems that typically occur when attempting to share > classes? What should I watch out for when trying to share functionality > between my web apps? Thanks. > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Best practices for shared classloader use?
On Jun 4, 2013, at 11:36 AM, Don Asper wrote: > I am considering using the Tomcat 7 shared classloader to reduce the memory > footprint of my web apps. IMHO, don't do this unless… 1.) You are very, very sure what you are doing 2.) You've analyzed the memory savings that you'll achieve by doing this and you are sure that it is significant compared to the cost of your time if you need to debug a problem. > But, I'm afraid that loading my application jar files into a single > classloader will cause lots of problems. I'm aware that the shared classpath > should not specify multiple versions of the same class. But I suspect, for > example, that classes that have static properties must not be shared. Am I > correct in thinking this? Are there other problems that I should anticipate? > Thanks! In my experience, errors of this nature are typically subtle and difficult to debug, another reason why I'd recommend against this. My personal favorite error is the ClassCastExceptions that say something like "cannot cast classX to classX" that occurs when classX from one class loader is attempted to be cast to classX from another class loader. There are others, you can probably find some more good examples by looking back through the list archives. My advice is to follow the kiss principle and just put your JAR files in with your web application. Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Best practices for shared classloader use?
Thanks for your example and advice, Daniel. -Original Message- From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Sent: Tuesday, June 04, 2013 12:45 PM To: Tomcat Users List Subject: Re: Best practices for shared classloader use? On Jun 4, 2013, at 11:36 AM, Don Asper wrote: > I am considering using the Tomcat 7 shared classloader to reduce the memory > footprint of my web apps. IMHO, don't do this unless... 1.) You are very, very sure what you are doing 2.) You've analyzed the memory savings that you'll achieve by doing this and you are sure that it is significant compared to the cost of your time if you need to debug a problem. > But, I'm afraid that loading my application jar files into a single > classloader will cause lots of problems. I'm aware that the shared classpath > should not specify multiple versions of the same class. But I suspect, for > example, that classes that have static properties must not be shared. Am I > correct in thinking this? Are there other problems that I should anticipate? > Thanks! In my experience, errors of this nature are typically subtle and difficult to debug, another reason why I'd recommend against this. My personal favorite error is the ClassCastExceptions that say something like "cannot cast classX to classX" that occurs when classX from one class loader is attempted to be cast to classX from another class loader. There are others, you can probably find some more good examples by looking back through the list archives. My advice is to follow the kiss principle and just put your JAR files in with your web application. Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Best practices for shared classloader use?
> I am considering using the Tomcat 7 shared classloader to reduce the memory > footprint of my web apps. Can you provide some approximate numbers as to what the current memory footprint is? Also some details of how many tomcat instances you have running and/or how many versions of the application you have running? So for example if your war file has 10mb of class files, and you have five concurrent versions of the war running, your reasoning is that by using a shared class loader, you can reduce the memory foot print from 50mb to 10mb? Thanks Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Best practices for shared classloader use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 6/4/13 12:44 PM, Daniel Mikusa wrote: > On Jun 4, 2013, at 11:36 AM, Don Asper wrote: > >> I am considering using the Tomcat 7 shared classloader to reduce >> the memory footprint of my web apps. > > IMHO, don't do this unless… > > 1.) You are very, very sure what you are doing 2.) You've analyzed > the memory savings that you'll achieve by doing this and you are > sure that it is significant compared to the cost of your time if > you need to debug a problem. +1 You're only saving the cost of classes actually loaded, and then only the memory used by the java.lang.Class files (plus some housekeeping for them). It's not like you are going to save GiBs of heap space by using a shared ClassLoader. >> But, I'm afraid that loading my application jar files into a >> single classloader will cause lots of problems. I'm aware that >> the shared classpath should not specify multiple versions of the >> same class. But I suspect, for example, that classes that have >> static properties must not be shared. Am I correct in thinking >> this? Are there other problems that I should anticipate? >> Thanks!> > > In my experience, errors of this nature are typically subtle and > difficult to debug, another reason why I'd recommend against this. > > My personal favorite error is the ClassCastExceptions that say > something like "cannot cast classX to classX" that occurs when > classX from one class loader is attempted to be cast to classX from > another class loader. There are others, you can probably find some > more good examples by looking back through the list archives. > > My advice is to follow the kiss principle and just put your JAR > files in with your web application. +1 You also get the flexibility of being able to use different versions with different webapps ... plus no nasty surprises when some data ends up being shared and shouldn't be. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRriyrAAoJEBzwKT+lPKRYNtIQAKsecIe7MnzD5M4Ep25oFP8f B8k+WHOEeDOe6T36j7Dxx+2IGwBwBIYcoQ0pQ4r0Rs2XEAtTJgIWVhwRtvxtoXy0 aDowU6NCoZVqQXo99ansTjFjyUm4eRGWKvG5vNSyuT8flOGCEgYHmr5m0hQj3CjE NMKAAkk2Yv1XuV7SQoGiA4DxjAtXPGcIwMR0zjdsbb8xiayiFip0qYC83t9EaKW7 Ng+GtmjhtFGS0YM4OiQmsNBuTGf/KNr//9a4Fdf+XpZvwto40A6JB3Zn3XcVk6A8 Gs3pfkjWF3+3tW08l3lekEdVs9LnzDYqaCSB4KMhoFcZx9a0Mz5I/plprfblXXaR t7PwCmjSLKg4TjYd1Gmd9jrKZkusTk8KxSdVm7arQEzCx+L3kM8qzJ3gqGcmx0jk m1z7q0rNde/B2QbwUsoep1I8gI8owful5LgYX78xfYZH1Axklyn6F9zyxvOQ0Dj+ K2941EVoKcu43RCkrDzV/jE6aDUcbd4yIbBI0oNJbODoFCJi2qtIqzaUq0YzG1qF KlU5A7m6ZEH08RM8VkA3QtPA6u93LXp2aaFlvxpUlPi6Yu0xVFCJcFvQku9ZSO0Y RbRsU6YlCCq1qYISpJbsKohOgOmNSQJqbBWyi+1xv+//fJxwAVkl6ki/FXqdvIay VX0ZIm0tZZweilyddbDk =fPda -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Best practices for shared classloader use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 6/4/13 12:56 PM, chris derham wrote: >> I am considering using the Tomcat 7 shared classloader to reduce >> the memory footprint of my web apps. > > Can you provide some approximate numbers as to what the current > memory footprint is? Also some details of how many tomcat instances > you have running and/or how many versions of the application you > have running? > > So for example if your war file has 10mb of class files, and you > have five concurrent versions of the war running, your reasoning is > that by using a shared class loader, you can reduce the memory foot > print from 50mb to 10mb? Your next step will be to point out that the size of the class file is only somewhat relevant for estimating actual memory usage, right? The JVM doesn't load the method bytecode into heap space (which is one of the reasons Java-only programmers don't understand why their JVM with a 1GiB heap actually takes 2GiB (or whatever) of real memory. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRri1QAAoJEBzwKT+lPKRYehUQAME8i3tW2JfZO6FXwjb0Wgp+ MoFi5AnwtzeeQ1hoU8ZiL84nmKZuwwSegN0HKmSWdKrrdav3v9/rKQpz3lXKMkqQ pnCgcn83ag7rmTR+8D12iTBfTAZC49M4Y6l+Mg8Jz3a0em9LOd7peWujt5GsIvPt Mn9FpOr8kb3qfiPLsbQFoH2NH9Qk8QXoljGHc7dM6kx/CDBU2e91hILnBkFoIez5 AEy0G9YZV2D9BVxIBHE+rkGN6yo8qmCGhZFlGcWKLY8/FxP7uhjVRa5K24tezjEG tYby5VFlq4yRR4DcoeGWT6UUj9NWCn55sPC//lSh4DyjAWNXKxOJ4SDijEiRMRbE nfGilnaxV3By/HzlIzYBj0QQ+KUR0HfOQfHnL+F62M4zbPhPsSonNHk8hgnZ+dGe mYaQssS1hdQtFuL7mN5luLo5rzdorqBaTKHlgodt1kXksxOHxA7XUZ4noDuUfQgv Vl60ntu6eHyt8fy/jo5Q1RmKk06U2wKffipnpCa5l53V/i1ETJj7PGYddtHYRfP3 a+fvr5XBXRt6/pF5qGs31NF/prIW8wYAVIFhHKSi+n3MEF/cYFD1mvCr5KOuG/6v WqpC6TMPNIUNKLmSgAsnw0tNXqN8UX6y8gIT5xVP9rTHFL1lBeb7+YdqqauGCh/9 ZkFHB62VTiJU28UifBOw =3Vg/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
