[Bug 58813] Incoming requests hang after a website using the ISAPI connector is restarted
https://bz.apache.org/bugzilla/show_bug.cgi?id=58813 --- Comment #8 from Christian Swoboda --- GREAT! Will there be an official release of 1.2.42 soon? Thanks a lot swobi -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60035] java.io.IOException: Too many open files
https://bz.apache.org/bugzilla/show_bug.cgi?id=60035 --- Comment #10 from Mark Thomas --- Thanks for confirming the fix. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58813] Incoming requests hang after a website using the ISAPI connector is restarted
https://bz.apache.org/bugzilla/show_bug.cgi?id=58813 --- Comment #9 from Mark Thomas --- Good question. It has been over a year since the last release. I'll start a discussion on the dev list. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat for JK 1.2.42 ?
All, It has been over 12 months since the 1.2.41 release and the changelog contains some important fixes. I think it is time to start thinking about a 1.2.42 release. I took a first pass through the open bug reports yesterday and resolved the really obvious / simple ones. Any help with the remaining bugs would be much appreciated. Would anyone like to take on the release manager role for this? As a source only release, it is fairly simple. If we want to provide the ISAPI binaries then it would be more work. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60100] Garbage appended at end of request URL
https://bz.apache.org/bugzilla/show_bug.cgi?id=60100 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Mark Thomas --- That is most strange. The sequence: %20HTTP/1.1%22%20200%20111 decodes to HTTP/1.1" 200 111 Which is the string from the end of the access log. I don't see how that ended up in the request line. The only place those values are available in that format (the decoded form) is the access log. But I cannot see how they could end up in the request line. Or even how the AccessLogValve could corrupt the value of the request line - especially with the encoding since the AccessLogValve doesn't encode anything. We are going to need more information to progress this. When the problem occurred, did all requests fail or just some. Was the a pattern? How repeatable is this? I'd like to see a tcpdump of a faulty request to confirm a=exactly what is on the wire. What is the architecture of the system. Is it multiple clients connecting directly to a single Tomcat instance or are the reverse proxies / load-balancers involved? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60100] Garbage appended at end of request URL
https://bz.apache.org/bugzilla/show_bug.cgi?id=60100
--- Comment #2 from Konstantin Kolinko ---
Are those rquests coming from valid clients? (Is value of user-agent header as
expected? Note that it can be logged with %{User-Agent}i)
Maybe some bot is reading your access logs and tries URLs that are mentioned in
them? Or some human? If browser interprets some text as url, it will
automatically encode spaces as '%20' when doing a request.
I can imagine "HTTP/1.1" being in URL if request line is parsed incorrectly (as
such characters are naturally present on the first line of HTTP request), but
seeing "200 111" there is odd. The only place where strings "HTTP/1.1" and "200
111" are near each other is your access log, and the log lines are generated on
the fly when writing the data out. Format of the log is configurable.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60126] New: The code of method invoke0(JspWriter) is exceeding the 65535 bytes limit
https://bz.apache.org/bugzilla/show_bug.cgi?id=60126 Bug ID: 60126 Summary: The code of method invoke0(JspWriter) is exceeding the 65535 bytes limit Product: Tomcat 8 Version: 8.0.37 Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: mah...@pondus.de We currently get an error with some of our JSPs with the following message: An error occurred at line: [20.607] in the generated java file: [/home/xxx/.IntelliJIdea2016.1/system/tomcat/xxx/work/Catalina/localhost/xxx/org/apache/jsp/pages/gwf/form_005flayout_jsp.java] The code of method invoke0(JspWriter) is exceeding the 65535 bytes limit The jsp form_layout.jsp uses a lot of dynamic including of other jsps but other tomcat versions before did the job (including 8.0.36). The last time I saw this error message was with tomcat 6 I think (weird regression? ;-)). TIA Björn -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60126] The code of method invoke0(JspWriter) is exceeding the 65535 bytes limit
https://bz.apache.org/bugzilla/show_bug.cgi?id=60126 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas --- I'm pretty sure this is invalid. Feel free to re-open if my explanation below proves not to be correct. The changelog for 8.0.37 mentions a number of changes in Jasper around error handling that will have increased the volume of the auto-generated code Jasper creates. If the JSPs were close to the limit in 8.0.36 it is possible this extra error handling code will have tipped them over in 8.0.37. The way to check this is to look at the generated .java code for 8.0.36 and compare it to the .java code generated for 8.0.37. If you see something other than error handling (e.g. additional try/finally blocks) then please re-open and attach the JSP source, the .java for 8.0.36 and the .java for 8.0.37 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60126] The code of method invoke0(JspWriter) is exceeding the 65535 bytes limit
https://bz.apache.org/bugzilla/show_bug.cgi?id=60126 --- Comment #2 from Björn Mahler --- Okay - so how do we know that we are close to the limit - what kind of limits in our JSP do we have to consider and how can we avoid that? But I'll check what you suggested... thanks for the quick answer. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60126] The code of method invoke0(JspWriter) is exceeding the 65535 bytes limit
https://bz.apache.org/bugzilla/show_bug.cgi?id=60126 --- Comment #3 from Mark Thomas --- What actaully matters is the size of the .class file. That has to conform to the JVM specification. There are various limits there although the method size one is the one folks tend to hit first. It should be possible to analyse you generated clss files to see how big they are. There is probably a utility for that somewhere. If not, it should be trivial to write with BCEL or similar. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Question about o.a.t.util.digester.Digester.useContextClassLoader
Hi, There are places in org.apache.tomcat.util.digester.Digester that do not consider useContextClassLoader. I would like to ask whether this is intentional or I can change that and use the provided classloader when useContextClassLoader is false. Thanks a lot, Violeta
Re: Introduce methods read/write with ByteBuffer in CoyoteInputStream/CoyoteOutputStream
Hi, 2016-08-30 15:35 GMT+03:00 Violeta Georgieva : > > Hi, > > 2016-08-24 16:44 GMT+03:00 Violeta Georgieva : > > > > Hi, > > > > Currently it is not possible to use ServletInputStream.read/ServletOutputStream.write methods with ByteBuffer. To enable such scenarios in Tomcat I would like to extend the Tomcat’s internal implementation (CoyoteInputStream/CoyoteOutputStream). I already did some refactoring in ByteChunk/CharChunk/SocketWrapperBase so that I can introduce read/write with ByteBuffer. I executed Autobahn test suite to check the performance impact after the refactoring and it showed no performance regression. If there are no objections I want to commit these changes in Tomcat 9 and Tomcat 8.5.x. > > > > I introduced CoyoteOutputStream.write(ByteBuffer) it uses new methods with ByteBuffer instead of ByteChunk. > Next step is to replace ByteChunk/CharChunk usage in CoyoteOutputStream with ByteBuffer/CharBuffer thus I will switch to the new methods and all CoyoteOutputStream.write method will use them. > I would like to back port these changes to Tomcat 8.5 if you do not have any concerns. Thanks, Violeta > Regards, > Violeta > > > Best Regards, > > Violeta
Re: Question about o.a.t.util.digester.Digester.useContextClassLoader
On 13/09/2016 17:24, Violeta Georgieva wrote: > Hi, > > There are places in org.apache.tomcat.util.digester.Digester that do not > consider useContextClassLoader. > I would like to ask whether this is intentional or I can change that and > use the provided classloader when useContextClassLoader is false. Digester has a getClassLoader() method that handles all logic. I don't see any reason not to use that everywhere. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1760598 - in /tomcat/jk/trunk: native/common/jk_connect.c xdocs/miscellaneous/changelog.xml
Author: markt
Date: Tue Sep 13 21:28:54 2016
New Revision: 1760598
URL: http://svn.apache.org/viewvc?rev=1760598&view=rev
Log:
Fix BZ 59164. Avoid crash during logging of failure to resolve worker host name.
Modified:
tomcat/jk/trunk/native/common/jk_connect.c
tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/jk/trunk/native/common/jk_connect.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_connect.c?rev=1760598&r1=1760597&r2=1760598&view=diff
==
--- tomcat/jk/trunk/native/common/jk_connect.c (original)
+++ tomcat/jk/trunk/native/common/jk_connect.c Tue Sep 13 21:28:54 2016
@@ -1285,17 +1285,22 @@ char *jk_dump_hinfo(jk_sockaddr_t *saddr
{
char pb[8];
-if (saddr->family == JK_INET) {
-inet_ntop4(saddr->ipaddr_ptr, buf, size);
-}
+if (saddr->ipaddr_ptr == NULL) {
+strcpy(buf, "UnresolvedIP");
+} else {
+if (saddr->family == JK_INET) {
+inet_ntop4(saddr->ipaddr_ptr, buf, size);
+}
#if JK_HAVE_IPV6
-else {
-inet_ntop6(saddr->ipaddr_ptr, buf, size);
-}
+else {
+inet_ntop6(saddr->ipaddr_ptr, buf, size);
+}
#endif
+}
+
sprintf(pb, ":%d", saddr->port);
-
strncat(buf, pb, size - strlen(buf) - 1);
+
return buf;
}
Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1760598&r1=1760597&r2=1760598&view=diff
==
--- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Tue Sep 13 21:28:54 2016
@@ -80,6 +80,10 @@
initialization was causing a hang on shutdown. Patch provided by
Matthew
Reiter. (markt)
+
+59164: Fix crash on first connection if a host name is
+specified for the worker that cannot be resolved to an IP address.
+(markt)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 59164] If tomcat server can not be resolved, crash occurred.
https://bz.apache.org/bugzilla/show_bug.cgi?id=59164 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas --- Thanks for the report and the back trace. This has been fixed in trunk and will be included in 1.2.42 onwards. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1760598 - in /tomcat/jk/trunk: native/common/jk_connect.c xdocs/miscellaneous/changelog.xml
On 13/09/2016 22:28, ma...@apache.org wrote:
> Author: markt
> Date: Tue Sep 13 21:28:54 2016
> New Revision: 1760598
>
> URL: http://svn.apache.org/viewvc?rev=1760598&view=rev
> Log:
> Fix BZ 59164. Avoid crash during logging of failure to resolve worker host
> name.
C not being my strong point, a review of this by those of you with
better C skills is appreciated. If you could keep an eye out for C
commits from me for the next week or two as I work on 1.2.42, that would
be great.
Mark
>
> Modified:
> tomcat/jk/trunk/native/common/jk_connect.c
> tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
>
> Modified: tomcat/jk/trunk/native/common/jk_connect.c
> URL:
> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_connect.c?rev=1760598&r1=1760597&r2=1760598&view=diff
> ==
> --- tomcat/jk/trunk/native/common/jk_connect.c (original)
> +++ tomcat/jk/trunk/native/common/jk_connect.c Tue Sep 13 21:28:54 2016
> @@ -1285,17 +1285,22 @@ char *jk_dump_hinfo(jk_sockaddr_t *saddr
> {
> char pb[8];
>
> -if (saddr->family == JK_INET) {
> -inet_ntop4(saddr->ipaddr_ptr, buf, size);
> -}
> +if (saddr->ipaddr_ptr == NULL) {
> +strcpy(buf, "UnresolvedIP");
> +} else {
> +if (saddr->family == JK_INET) {
> +inet_ntop4(saddr->ipaddr_ptr, buf, size);
> +}
> #if JK_HAVE_IPV6
> -else {
> -inet_ntop6(saddr->ipaddr_ptr, buf, size);
> -}
> +else {
> +inet_ntop6(saddr->ipaddr_ptr, buf, size);
> +}
> #endif
> +}
> +
> sprintf(pb, ":%d", saddr->port);
> -
> strncat(buf, pb, size - strlen(buf) - 1);
> +
> return buf;
> }
>
>
> Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1760598&r1=1760597&r2=1760598&view=diff
> ==
> --- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
> +++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Tue Sep 13 21:28:54 2016
> @@ -80,6 +80,10 @@
> initialization was causing a hang on shutdown. Patch provided by
> Matthew
> Reiter. (markt)
>
> +
> +59164: Fix crash on first connection if a host name is
> +specified for the worker that cannot be resolved to an IP address.
> +(markt)
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1760640 - /tomcat/trunk/java/org/apache/tomcat/util/digester/Digester.java
Author: violetagg
Date: Wed Sep 14 06:37:13 2016
New Revision: 1760640
URL: http://svn.apache.org/viewvc?rev=1760640&view=rev
Log:
Format the code. No functional changes.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/digester/Digester.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/digester/Digester.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/digester/Digester.java?rev=1760640&r1=1760639&r2=1760640&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/digester/Digester.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/digester/Digester.java Wed Sep 14
06:37:13 2016
@@ -78,10 +78,9 @@ public class Digester extends DefaultHan
// -- Static Fields
-private static class SystemPropertySource
-implements IntrospectionUtils.PropertySource {
+private static class SystemPropertySource implements
IntrospectionUtils.PropertySource {
@Override
-public String getProperty( String key ) {
+public String getProperty(String key) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
if (cl instanceof PermissionCheck) {
Permission p = new PropertyPermission(key, "read");
@@ -93,29 +92,32 @@ public class Digester extends DefaultHan
}
}
-protected static IntrospectionUtils.PropertySource source[] =
-new IntrospectionUtils.PropertySource[] { new SystemPropertySource() };
+protected static IntrospectionUtils.PropertySource source[] = new
IntrospectionUtils.PropertySource[] {
+new SystemPropertySource() };
static {
String className =
System.getProperty("org.apache.tomcat.util.digester.PROPERTY_SOURCE");
-if (className!=null) {
+if (className != null) {
IntrospectionUtils.PropertySource[] sources = new
IntrospectionUtils.PropertySource[2];
sources[1] = source[0];
-ClassLoader[] cls = new ClassLoader[]
{Digester.class.getClassLoader(),Thread.currentThread().getContextClassLoader()};
+ClassLoader[] cls = new ClassLoader[] {
Digester.class.getClassLoader(),
+Thread.currentThread().getContextClassLoader() };
boolean initialized = false;
-for (int i=0; i clazz = Class.forName(className,true,cls[i]);
-IntrospectionUtils.PropertySource src =
(IntrospectionUtils.PropertySource)clazz.newInstance();
+Class clazz = Class.forName(className, true, cls[i]);
+IntrospectionUtils.PropertySource src =
(IntrospectionUtils.PropertySource) clazz
+.newInstance();
sources[0] = src;
initialized = true;
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
-
LogFactory.getLog("org.apache.tomcat.util.digester.Digester").
-error("Unable to load property
source["+className+"].",t);
+
LogFactory.getLog("org.apache.tomcat.util.digester.Digester")
+.error("Unable to load property source[" +
className + "].", t);
}
}
-if (initialized) source = sources;
+if (initialized)
+source = sources;
}
}
@@ -171,7 +173,7 @@ public class Digester extends DefaultHan
* The URLs of entityValidator that have been registered, keyed by the
public
* identifier that corresponds.
*/
-protected HashMap entityValidator = new HashMap<>();
+protected HashMap entityValidator = new HashMap<>();
/**
@@ -212,7 +214,7 @@ public class Digester extends DefaultHan
* is required because documents can declare nested uses of the same
* prefix for different Namespace URIs).
*/
-protected HashMap> namespaces = new HashMap<>();
+protected HashMap> namespaces = new HashMap<>();
/**
@@ -289,15 +291,13 @@ public class Digester extends DefaultHan
/**
* The Log to which most logging calls will be made.
*/
-protected Log log =
-LogFactory.getLog("org.apache.tomcat.util.digester.Digester");
+protected Log log =
LogFactory.getLog("org.apache.tomcat.util.digester.Digester");
/**
* The Log to which all SAX event related logging calls will be made.
*/
-protected Log saxLog =
-LogFactory.getLog("org.apache.tomcat.util.digester.Digester.sax");
+protected Log saxLog =
LogFactory.getLog("org.apache.tomcat.util.digester.Digester.sax");
// - Properties
@@ -342,8 +342,7 @@ public class Digester extends DefaultHan
return (this.classLoader);
}
if (this.useC
