Re: ISAPI and IIS 10 Logging Issue
On 01.09.2017 22:21, Thomas, Michael wrote: All, When using the ISAPI Handler Mapping in IIS 10 on Windows 2016, the IIS logs are not identifying the URI Stem (cs-uri-stem) and URI Query (cs-uri-query) as expected. For EVERY request that the handler processes (e.g. .cfm), the cs-uri-stem records an entry as "/jakarta/isapi_redirect.dll" and the cs-uri-query is always empty. Environment Details: * IIS 10 (Windows 2016) * Tomcat 8.5.11.0 * Java 1.8.0_131 * ISAPI Connector 1.2.41 * ColdFusion 2016 For comparison, we have a similar setup on another box (IIS 8.5 Windows Server 2012 R2) and the logs are recording as expected. Any assistance would be great! Hi. If I understand this correctly, the difference between your two setups above is at the Windows/IIS level, not at the tomcat/ISAPI-redirector level. This may be naive, but isn't this a question then for the Windows/IIS people ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ISAPI and IIS 10 Logging Issue
All, When using the ISAPI Handler Mapping in IIS 10 on Windows 2016, the IIS logs are not identifying the URI Stem (cs-uri-stem) and URI Query (cs-uri-query) as expected. For EVERY request that the handler processes (e.g. .cfm), the cs-uri-stem records an entry as "/jakarta/isapi_redirect.dll" and the cs-uri-query is always empty. Environment Details: * IIS 10 (Windows 2016) * Tomcat 8.5.11.0 * Java 1.8.0_131 * ISAPI Connector 1.2.41 * ColdFusion 2016 For comparison, we have a similar setup on another box (IIS 8.5 Windows Server 2012 R2) and the logs are recording as expected. Any assistance would be great! -Mike The preceding message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2512, is intended only for the person or entity to which it is addressed, and may contain information that is confidential, protected by attorney-client or other privilege, or otherwise protected from disclosure by law. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error and destroy the original message and all copies.
Re: Apache 7.0.81 - Can no longer use non-canonical paths in extraResourcePaths of VirtualDirContext
On 31/08/17 17:03, Constantin Erckenbrecht wrote: > Hi, > > A change in 7.0.81/7.0.80 changed the File resolution in VirtualDirContext. > > In 7.0.79 and before it was possible to use paths with /../ or any other > non-canonical path. This was particularly useful when using placeholders > that are being replaced at compile time like > > extraResourcePaths="/=${project.basedir}/../some/other/dir” > > The new calls to validate(File file, boolean mustExist, String > absoluteBase) prevent this, as inside the validate method the file name is > canocialized and compared against the absoluteBase path, which is not being > canonicalized. > > Hence, when using a non-canonical path as an extraResourcePath the validate > function incorrectly assumes that the requested file is outside the > application root. > > Any chance that this can be fixed? Fixed in 7.0.x for 7.0.82 onwards. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jre leak prevention
On 01/09/17 11:25, Johan Compagner wrote: > We tested it and the winner is: > > className="org.apache.catalina.core.JreMemoryLeakPreventionListener" > urlCacheProtection="false" /> > > i had my bets on the xmlParsingProtection but that wasn't it... When I took a look through the options, urlCacheProtection looked to be the most likely. Be aware you may end up with some file locking / memory leak issues on web application reload with that disabled. The simplest solution is to restart Tomcat as part of the redeployment process. As of Java 9, there is a new API that allows more selective disabling of caching so we'll be able to disable it just for JARs when running on Java 9. Generally, we got a whole bunch of memory leak issues fixed for Java 9. Oracle were very receptive to fixing the bugs we reported. See [1] for more info. Which reminds me, we need to update the listener to use this new API when running on Java 9. Mark [1] https://github.com/markt-asf/memory-leaks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jre leak prevention
On 1 September 2017 at 11:10, Mark Thomas wrote: > On 01/09/17 10:03, Johan Compagner wrote: > > Hi, > > > > i got reports that running jasper reports is suddenly a lot slower when > > deployed.. > > (compared what he uses in developer) > > Running a report was 0-2 seconds in its developer but at least 10 seconds > > when running deployed. > > > > We tracked it down, in developer the listener: > > > > > /> > > > > > > > > > > was not in the server.xml and at deploy it is a standard latest tomcat > > install which enables that by default > > > > If i look at this, i wonder which part makes it much slower > > https://tomcat.apache.org/tomcat-8.0-doc/config/ > listeners.html#JRE_Memory_Leak_Prevention_Listener_-_ > org.apache.catalina.core.JreMemoryLeakPreventionListener > > You can disable each protection individually so you should be able to > answer that question yourself. (And the answer would be very interesting.) > We tested it and the winner is: i had my bets on the xmlParsingProtection but that wasn't it...
Re: Performance issue 8.5.20 (metaspace related?)
> Profiling the code I have been able to find the cause of the big metaspace > garbage… > Due to a bug, we were not caching remote interfaces when connecting to jboss > from the web sites. Other client kind was ok. > Fixed this problem today, it’s a few hours that the system is running fine. > It’s fast (faster than before even with a fresh tomcat); metaspace says low > and everything is fine. > That's a very good news! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jre leak prevention
On 01/09/17 10:03, Johan Compagner wrote: > Hi, > > i got reports that running jasper reports is suddenly a lot slower when > deployed.. > (compared what he uses in developer) > Running a report was 0-2 seconds in its developer but at least 10 seconds > when running deployed. > > We tracked it down, in developer the listener: > > /> > > > > > was not in the server.xml and at deploy it is a standard latest tomcat > install which enables that by default > > If i look at this, i wonder which part makes it much slower > https://tomcat.apache.org/tomcat-8.0-doc/config/listeners.html#JRE_Memory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPreventionListener You can disable each protection individually so you should be able to answer that question yourself. (And the answer would be very interesting.) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
jre leak prevention
Hi, i got reports that running jasper reports is suddenly a lot slower when deployed.. (compared what he uses in developer) Running a report was 0-2 seconds in its developer but at least 10 seconds when running deployed. We tracked it down, in developer the listener: was not in the server.xml and at deploy it is a standard latest tomcat install which enables that by default If i look at this, i wonder which part makes it much slower https://tomcat.apache.org/tomcat-8.0-doc/config/listeners.html#JRE_Memory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPreventionListener -- Johan Compagner Servoy