https://bz.apache.org/bugzilla/show_bug.cgi?id=65448
--- Comment #6 from Roman <ro...@auxilii.com> ---
I will hopefully be able to answer your questions later today. This is
happening on a customer site and working remotely is quite...painful.
What I can answer at the moment:
1, 3, 4, 5. Will have to check later.
2. The problem occurs with no obvious pattern.
Yesterday, I was able to reproduce it almost always. Today, when I retried, it
took 5-10 tries to reproduce it. The Windows env was not rebooted, but I
restarted Tomcat to add some debug information myself.
6. Yes, this is the main essence of the code (I stripped away all things not
related to the actual problem):
import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ServletForAsf extends HttpServlet {
private static final long serialVersionUID = 3266630280219605924L;
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
String resourcePath = request.getPathInfo();
File resourceFile = new File(resourcePath);
ServletOutputStream outputStream = response.getOutputStream();
int bufferSize = 1 << 16;
try (InputStream in = new BufferedInputStream(new
FileInputStream(resourceFile), bufferSize)) {
final byte[] buffer = new byte[bufferSize];
int count;
long totalCount = 0;
while ((count = in.read(buffer)) != -1) {
try {
outputStream.write(buffer, 0, count);
} catch (Exception e) {
throw new IOException("Error while
transfering data. Data transferred so far: " + totalCount + ". Current buffer
size: " + count, e);
}
totalCount += count;
}
outputStream.flush();
}
}
}
7. Yes, testing a custom Tomcat would be possible. Fortunately, the environment
where this is happening is a test env and the customer is rather friendly.
In the meantime, the comment about the DefaultServlet made me think (and
debug).
It seems that the DefaultServlet does not take the same route as our Servlet
does.
When the DefaultServlet serves a file, it is not done within the Servlet
directly (as far as I can tell) but rather in
Http11Processor.processSendfile(SocketWrapperBase<?>) line: 1359
The main thing is that this eventually calls
sd.fchannel.close();
When I follow the path of our servlet, I was not able to actually find an
actual flush() call on the underlying socket.
So, my current thinking is that the data is not flushed to the client
successfully and that is why it needs to wait for the connection timeout.
--
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
