Re: ISAPI and IIS 10 Logging Issue

[tomcat]

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

[Thomas, Michael]

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

[Mark Thomas]

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

[Mark Thomas]

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

[Johan Compagner]

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

[Suvendu Sekhar Mondal]

> 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

[Mark Thomas]

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

[Johan Compagner]

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