[Bug 55603] Printing from servlet causes endles spoolling
https://issues.apache.org/bugzilla/show_bug.cgi?id=55603 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INVALID --- Comment #6 from Mark Thomas --- There is no Tomcat bug here. The threads are hanging in native code provided by the JRE. While this isn't a Tomcat issue, the users list is usually pretty good at helping folks figure out these sorts of problems. -- 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: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
Hi Chris, On 28.09.2013 01:49, Christopher Schultz wrote: > All, > > I know Mark and Rainer are working on trying to avoid corruption of what > looks like pollset counts or whatever, but I wanted to know if anyone > can help me decode the cause of the null-dereference that's occurring. > > Obviously bandaging the symptom is not the best solution, but keeping > the JVM up and running is a nice feature to have and, since I have no > understanding of APR polling, I can at least modify tcnative to throw an > exception instead of bombing the JVM. > > I can't seem to reproduce the problem using an APR connector on Linux: > reports seems to indicate that trivially accessing Tomcat via an HTTP > APR connector will cause a crash, and I was able to run the following > command without bringing down my instance: > > $ ab -n 1 -c 50 http://localhost:28215/my-webapp/index.html Did not yet try, but without "-k" ab doesn't use HTTP Keep-Alive, and I think the reports mentioned that connectionTimeout influenced things. So all test scenarios should probably include HTTP Keep-Alive. Try with "ab -k ..."? Still the whole poll stuff is platform dependent, so it might be you will not be able to reproduce the Windows crash even when the test scenario is exactly the same as there. > ... where localhost:28215 is bound to an > org.apache.coyote.http11.Http11AprProtocol connector. > > So, I need help decoding the tcnative-1.dll+0x7e23 pointer, which is > obviously a code pointer, but I have no idea how far into tcnative.dll > 0x7e23 points. It's obviously in ..._jni_Poll_poll() but I'm not sure > which pointer is likely to be null. > > Can anyone point me in the right direction? I currently can not really investigate in Windows, sorry. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55603] Printing from servlet causes endles spoolling
https://issues.apache.org/bugzilla/show_bug.cgi?id=55603 --- Comment #7 from Jodgi --- Well... tomcat must have its own share of responsability, because everything works perfectly in the CLI. However, you are the experts here, this not being a bug is a great help, because now I will look somewhere else! I believe that tomcat (or JRE on tomcat ?!?!) messes up things with printing. Did you know that the default printer is ignored when printing from servlet ? (it just prints to the first printer listed) But this is a bug on its own. -- 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: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
On 09/28/2013 12:25 PM, Rainer Jung wrote: I can't seem to reproduce the problem using an APR connector on Linux: reports seems to indicate that trivially accessing Tomcat via an HTTP APR connector will cause a crash, and I was able to run the following command without bringing down my instance: $ ab -n 1 -c 50 http://localhost:28215/my-webapp/index.html Still the whole poll stuff is platform dependent, so it might be you will not be able to reproduce the Windows crash even when the test scenario is exactly the same as there. Almost every APR crash error is related to reusing closed object/descriptor/pointer. Eg, crashing inside poll can be caused by closing the socket that is inside poller. The fact that it doesn't crash on linux might be just because of "close" order. Even on the same OS it doesn't have to crash all the time. Anyhow, I'll try to check the 8-RC3 with the latest native on windows. Seems there are some conceptual problem used inside TC8 probably with async sockets and double close. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Possible IIS SPDY Redirector for Tomcat
Hi all, about a year ago, I wrote about an IIS SPDY/3 Redirector written in C# that could be used to redirect requests from IIS to Tomcat, Jetty, or other servers with SPDY/3 support; as an alternative to the ISAPI redirector that uses AJP - see [1]. It uses the new managed module pipeline that is available since IIS 7.0. However, currently it is simply a request forwarder that forwards every request over a SPDY. It does not have load-balancing or similar features. At that time, I could test the redirector with Jetty, but not with Tomcat as it only had support for SPDY/2. However, I don't know what the current state of the SPDY/3 implementation in Tomcat is (I saw E-Mails from Costin that he wanted to update Tomcat for SPDY/3, but I don't know if it is finished). Maybe someone has information about that? In my initial mail, I wrote about how to test the redirector with Google's web server. That required an Java NPN tunnel do to this. However, there is a simpler way to test the Redirector e.g. with IIS 8.0 Express (so you don't need a Server OS; just a normal client Windows) and Jetty (using a non-SSL SPDY connector). That way you can test the redirector just like if it would forward the requests to Tomcat. Below is a guide how to set up IIS 8.0 express and Jetty to test the SPDY redirector. I think that when comparing an SPDY redirector (C#) to the existing ISAPI redirector (C), there are advantages and disadvantages: Pro: - Because the code is using managed C# instead of native C(++), just like with Java it is easier to use advanced features like threading etc., and it should be easier to maintain. E.g. you can program the same way that you would with a Servlet for reading requests and writing responses. Also e.g. if an error occurs, you will get an exception instead of a crash. - It is easier to install in IIS: You don't need to add a virtual directory (and don't forget to set execute permissions for the DLL file etc) - you just add a reference in the web.config file. - SPDY should allow for forwarding WebSocket connections (available with IIS 8.0+), which AJP doesn't. However, I do not yet have looked how to use WebSockets with IIS 8 and over SPDY. - IIS (7+) seems to enable buffering of response bodies when using the ISAPI redirector. This means, if you produce 100 MB of data in your servlet, then IIS will cache as much data as possible before it starts the response. This can be a problem if you need the response to be immediately started, e.g. for a IP camera which uses MJPEG streaming. It is however possible to change this behavior in IIS. The SPDY redirector is configured to flush each data packet so that the response body is sent immediately to the client. Contra: - Worse performance than the native ISAPI redirector. I made a test by a Servlet that produces 700 MB of random data, and on a separate machine I used a program to make a HTTP request and read the data. The average transfer speed was ~ 98 MByte/s, and the IIS worker process had around 50% CPU usage, whereas Jetty had only 12 %. Now, to test the SPDY redirector, you can use IIS 8.0 Express that can be installed on any current Windows OS like Win8, Win7 and WinVista. Alternatively, if you have Visual Studio 2012 you can also create an empty ASP.Net Web Application and test it with the integrated IIS 8.0 Express. The following is an updated guide for how to build the SPDY redirector, install IIS 8.0 Express and Jetty and configure the IIS web application to use the SPDY redirector on Windows (it uses Windows 7 64-bit as example). TOC: A) Build the SPDY Redirector with MSBuild tool B) Install IIS 8.0 Express and create a Web Application having the SPDY Redirector C) Install Jetty 8 and configure it for SPDY/3 D) Test if Jetty and the SPDY redirector is working A) Build the SPDY Redirector with MSBuild tool The sources of the SPDY Redirector are available at this SVN repository: https://kinderbasar-luhe.de:8543/svn/PreisserNormaleProjekte/SpdyConnector/ 1) Install the .Net Framework 4.5 SDK which is included in the Windows 8 SDK. You can get it here: http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx When selecting the features to install, the only one you need to select is ".Net Framework 4.5 Software Development Kit". 2) After checking out the sources, run the MSBuild tool. To do this, open the command prompt and change to the directory of the checked out sources where the file "SPDY_Redirector.csproj" is located (SVN location: https://kinderbasar-luhe.de:8543/svn/PreisserNormaleProjekte/SpdyConnector/.Net/SPDY-Redirector/SPDY_Redirector/ ). Then, run MSBuild by typing "%windir%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe". The result of the build (SpdyRedirector.dll) will be in "bin\Debug" folder. B) Install IIS 8.0 Express and create a Web Application having the SPDY Redirector 1) Install IIS 8.0 Express. You can get it here: http://www.microsoft.com/en-us/
[Bug 55608] New: fmt:bundle tag unnecessarily buffers body content
https://issues.apache.org/bugzilla/show_bug.cgi?id=55608
Bug ID: 55608
Summary: fmt:bundle tag unnecessarily buffers body content
Product: Taglibs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Standard Taglib
Assignee: dev@tomcat.apache.org
Reporter: supp...@aoindustries.com
The fmt:bundle tag buffers its body content and then simply writes it all on
doEnd. This causes both unnecessary heap space consumption, and can cause out
of memory conditions on large pages where:
1) The page is surrounded by a single large ...
tag.
2) The body generates a large amount of content.
With buffer="X" and autoFlush="true", the JSP developer expects the body to be
flushed when the buffer becomes X in size. The fmt:bundle tag has a unbounded
buffer and thus this expectation is not meet.
The patch for JSTL 1.1.2 is:
In org/apache/taglibs/standard/tag/common/fmt/BundleSupport.java:
public int doStartTag() throws JspException {
locCtxt = getLocalizationContext(pageContext, basename);
// Begin removed by AO Industries, Inc.
//return EVAL_BODY_BUFFERED;
// End removed by AO Industries, Inc.
// Begin added by AO Industries, Inc.
// No need to buffer our body since it is just written in full on doEndTag.
return EVAL_BODY_INCLUDE;
// End added by AO Industries, Inc.
}
public int doEndTag() throws JspException {
// Begin removed by AO Industries, Inc.
//if (bodyContent != null) {
//try {
//pageContext.getOut().print(bodyContent.getString());
//} catch (IOException ioe) {
//throw new JspTagException(ioe.toString(), ioe);
//}
//}
// End removed by AO Industries, Inc.
return EVAL_PAGE;
}
Please include this in future releases of the taglib. It will help us work
with large sets of data using the comfortable and productive JSP environment.
--
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 55609] New: c:forEach loop on integer range consumes unnecessary heap space in proportion to value for "end"
https://issues.apache.org/bugzilla/show_bug.cgi?id=55609
Bug ID: 55609
Summary: c:forEach loop on integer range consumes unnecessary
heap space in proportion to value for "end"
Product: Taglibs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Standard Taglib
Assignee: dev@tomcat.apache.org
Reporter: supp...@aoindustries.com
The implementation of iteration for a forEach tag over an integer range builds
an array of all the Integer objects in the range, and then obtains an iterator
via Arrays.asList(...).iterator(). The unnecessarily consumes a large amount
of heap space when the value of "end" is large.
The method in this comment about performance is basically correct from a *time*
perspective, but completely ignores *space* considerations.
The patch to iterate over an integer range without undue heap space follows.
For JSTL 1.1.1 in
src/org/apache/taglibs/standard/tag/common/core/ForEachSupport.java:
// Begin added by AO Industries, Inc.
import java.util.NoSuchElementException;
// End added by AO Industries, Inc.
private ForEachIterator beginEndForEachIterator() {
// Begin removed by AO Industries, Inc.
///*
// * To plug into existing support, we need to keep 'begin', 'end',
// * and 'step' as they are. So we'll simply create an Integer[]
// * from 0 to 'end', inclusive, and let the existing implementation
// * handle the subsetting and stepping operations. (Other than
// * localizing the cost of creating this Integer[] to the start
// * of the operation instead of spreading it out over the lifetime
// * of the iteration, this implementation isn't worse than one that
// * created new Integers() as needed from next(). Such an adapter
// * to ForEachIterator could easily be written but, like I said,
// * wouldn't provide much benefit.)
// */
//Integer[] ia = new Integer[end + 1];
//for (int i = 0; i <= end; i++)
//ia[i] = new Integer(i);
//return new SimpleForEachIterator(Arrays.asList(ia).iterator());
// End removed by AO Industries, Inc.
// Begin added by AO Industries, Inc.
// This implementation does not require heap space in proportion to the
number of iterations.
return new SimpleForEachIterator(
new Iterator() {
private final int end = ForEachSupport.this.end;
private int next = 0;
public boolean hasNext() {
return next <= end;
}
public Object next() {
if(next > end) throw new NoSuchElementException();
return Integer.valueOf(next++);
}
public void remove() {
throw new UnsupportedOperationException();
}
}
);
// End added by AO Industries, Inc.
}
--
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 55609] c:forEach loop on integer range consumes unnecessary heap space in proportion to value for "end"
https://issues.apache.org/bugzilla/show_bug.cgi?id=55609 --- Comment #1 from Dan Armstrong --- One observation: Integer.valueOf was added in Java 1.5, so we'll need to stick with new Integer(next++) in the iterator. - Thanks!!! -- 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 55609] c:forEach loop on integer range consumes unnecessary heap space in proportion to value for "end"
https://issues.apache.org/bugzilla/show_bug.cgi?id=55609 --- Comment #2 from Dan Armstrong --- I've been looking into this further. This enhancement has already been made in the 1.2 series of standard taglib. I hope you will still add it to any future release of the 1.1 series. -- 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 55608] fmt:bundle tag unnecessarily buffers body content
https://issues.apache.org/bugzilla/show_bug.cgi?id=55608 --- Comment #1 from Dan Armstrong --- FYI: I have confirmed this unnecessary buffering remains in the most recent 1.2 branch in SVN. -- 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
