I've started to test using Vaadin for consideration as a replacement technology for an existing system. As a test, I've tried connecting to the existing database, and for some of the tables it works without issue. The problem is that for some of the other tables, in this case the most important one, it chokes on certain rows of the database. The issue is, how do I either a) identify the problem row based on the error message given or b) find a way to make the system identify the problem row and move over it without completely crashing in response?
This is the error message here (note that CPI Entry Not Found is actually a value within the table and so not the cause of the error):
java.sql.SQLException: Value '5952182111120050000000û0100100000ûRoad - Base
Brush RoadDouglas Line - Hubbard Line101.000ûû002012-05-21 22:16:59
2012-05-21support300ûû3688.47014531.53
0000-00-0003
2013-12-3117CPI Entry Not Found1
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1078)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:989)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:975)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:920)
at com.mysql.jdbc.ResultSetRow.getDateFast(ResultSetRow.java:141)
at com.mysql.jdbc.BufferRow.getDateFast(BufferRow.java:707)
at com.mysql.jdbc.ResultSetImpl.getDate(ResultSetImpl.java:2211)
at com.mysql.jdbc.ResultSetImpl.getDate(ResultSetImpl.java:2173)
at com.mysql.jdbc.ResultSetImpl.getObject(ResultSetImpl.java:5052)
at com.vaadin.data.util.sqlcontainer.SQLContainer.getPropertyIds(SQLContainer.java:1168)
at com.vaadin.data.util.sqlcontainer.SQLContainer.<init>(SQLContainer.java:131)
at com.example.testproject.DBTest.init(DBTest.java:36)
at com.vaadin.ui.UI.doInit(UI.java:529)
at com.vaadin.server.AbstractCommunicationManager.getBrowserDetailsUI(AbstractCommunicationManager.java:2468)
at com.vaadin.server.AbstractCommunicationManager.handleBrowserDetailsRequest(AbstractCommunicationManager.java:2362)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:325)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:201)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
And here is the relevant code, where the error is thrown on the second line:
TableQuery tq = new TableQuery("v3_audits", pool);
SQLContainer container = new SQLContainer(tq);
EDIT: Per André's suggestion, I took a look at the database. The indicated row is the first row of the table; deleting it then has the error thrown at the second row. This suggests to me that the database itself is having issues with JDBC as he said--although what that issue might be is hard to guess right now.
Related
i am working in a java project, where we are using oracle as a database and we have two schema, for every schema we are creating saprate connections in connection pool.
its working fine if we hit max 2 request at a time from the client for the data from a table but at every third time its getting java.sql.SQLException: ORA-00942: table or view does not exist exception.
i want to understand why its happening and what would be the possible the reason? Please help me.
Full Stacktrace:
java.sql.SQLException: ORA-00942: table or view does not exist
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:111)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:330)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:287)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:742)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:212)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:795)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1030)
at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:835)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1123)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3284)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3328)
at DLRecordSetSQL.DLRecordSetSQL.setRecordCount(DLRecordSetSQL.java:3622)
at DLRecordSetSQL.DLRecordSetSQL.open(DLRecordSetSQL.java:3124)
at DLRecordSetSQL.DLRecordSetSQL.open(DLRecordSetSQL.java:3207)
at com.utility.queryManager.util.MetadataManager.init(MetadataManager.java:79)
at com.utility.queryManager.util.MetadataManager.<init>(MetadataManager.java:65)
at com.utility.queryManager.processor.UtilityManagerRequestProcessor.selectCommandRequestProcessor(UtilityManagerRequestProcessor.java:187)
at com.utility.queryManager.processor.UtilityManagerRequestProcessor.UtilityRequestProcessor(UtilityManagerRequestProcessor.java:77)
at com.utility.queryManager.servlet.UtilityManagerServlet.doPost(UtilityManagerServlet.java:36)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
I think your db is being run out of available connections.
You can set initial pool size 5. as it is default to 0.
For more, you can go through this tutorial: Setting Connection Pool Properties in Oracle
As Avi stated the issue as below
Oracle database connections are not multi-threaded. If two or more
threads simultaneously try to access the same connection, one of them
will block until the other one finishes interacting with the
connection.
So I guess you should try to verify whether your code exhibits this
behaviour trying to access the same database connection from multiple
threads at the same time.
I am trying to print reports using the Crystal Report API based on this example.
reportClientDoc.open(reportpath+reportName, 0);
//Create and set print options.
PrintReportOptions printOptions = new PrintReportOptions();
printOptions.setPrinterName(printerName); //Note: Printer 'printername' must already be configured at Operating system level.
printOptions.setJobTitle(reportName); // job title by the report file name
printOptions.setPrinterDuplex(PrinterDuplex.simplex);
printOptions.setPaperSource(PaperSource.auto);
printOptions.setPaperSize(PaperSize.paperA4);
printOptions.setNumberOfCopies(1);
printOptions.setCollated(false);
reportClientDoc.getPrintOutputController().printReport(printOptions);
But I can't get it working, I receive a java.util.concurrent.CancellationException:
java.util.concurrent.CancellationException
at com.businessobjects.crystalreports.printer.bean.Printer.X(Unknown Source)
at com.businessobjects.crystalreports.printer.bean.ReportPrinter.print(Unknown Source)
at com.businessobjects.crystalreports.printer.bean.ReportPrinter.print(Unknown Source)
at com.crystaldecisions.sdk.occa.report.application.PrintOutputController.printReport(SourceFile:742)
at my.test.crystal.GenerateReport.doGet(GenerateReport.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.awt.print.PrinterAbortException
at com.businessobjects.crystalreports.viewer.core.ReportPagePrinter.print(Unknown Source)
at sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:1936)
at sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1431)
at com.businessobjects.crystalreports.viewer.core.ReportPagePrinter.print(Unknown Source)
The very strange thing is that the example worked previously in another project, but no longer on my local environment! I probably changed something but I can't figure out what :(
I tried with several printers (local and network) but the scenario is always the same: I can see the job during a very short time in printer job list but after less than 1 second, it vanishes and I receive the exception.
I am using Tomcat 7 and I tried with JDK1.6 and 1.7 (thinking about a JDK issue?) but there's no change.
If someone can give me some leads because currently, I am totally stuck.
Thx
Make sure you add ReportViewer.jar to your libraries.
For code completion, this doesn't seem necessary, but it is for printing.
I ran three thread dumps, 10 seconds apart, on a production server running Tomcat. I found that the same thread (same thread id) appears in all three thread dumps and is doing exactly the same thing - processing a JSP page. Does this mean it is stuck? Or could it be that the same thread from the Tomcat thread pool keeps getting assigned the same task over and over again.
This is a moderately big application and has a lot of servlets/JSP pages, business logic and a database. Also, it is fairly busy (around 20 requests per second). Tomcat is running standalone (not behind Apache).
Edit 1 (additional info): The home page normally takes significantly less than 10 seconds to render, so this can't be a typical single request to the home page.
Edit 2: I took another thread dump hours later (but without restarting Tomcat) and this specific thread was doing something else. Does this CONCLUSIVELY mean that the thread was not stuck?
Here is the the section of the thread dump for that specific thread (only one is listed as the other two are exactly the same):
"http-bio-8080-exec-220" daemon prio=10 tid=0x00007f5c801de800 nid=0x3151 runnable [0x00007f5c74d28000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:215)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:366)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:240)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:119)
at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:192)
at org.apache.coyote.Response.doWrite(Response.java:517)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:408)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480)
at org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:487)
at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:312)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:528)
at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:152)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:336)
at java.io.Writer.write(Writer.java:157)
at org.apache.jasper.runtime.JspWriterImpl.print(JspWriterImpl.java:473)
at org.apache.taglibs.standard.tag.common.core.UrlSupport.doEndTag(UrlSupport.java:127)
at org.apache.jsp.WEB_002dINF.jsp.site.home_jsp._jspx_meth_c_005furl_005f22(home_jsp.java:1172)
at org.apache.jsp.WEB_002dINF.jsp.site.home_jsp._jspx_meth_c_005fif_005f2(home_jsp.java:1141)
at org.apache.jsp.WEB_002dINF.jsp.site.home_jsp._jspx_meth_c_005fforEach_005f1(home_jsp.java:1102)
at org.apache.jsp.WEB_002dINF.jsp.site.home_jsp._jspService(home_jsp.java:308)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
at inspirasites.servlets.HomeServlet.doGet(HomeServlet.java:102)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at inspirasites.filters.CharEncodingFilter.doFilter(CharEncodingFilter.java:23)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at inspirasites.filters.SiteFilter.doFilter(SiteFilter.java:45)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
- locked <0x00000000e12fb330> (a org.apache.tomcat.util.net.SocketWrapper)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
I have recently seen the exact same behaviour in our application and was able to reproduce it. It can be caused by a mis-behaving client that sends a request but does not consume the response data. In this case the socket will block, see the answers for this question: Is an OutputStream in Java blocking? (Sockets)
My service functions as a proxy server that will send GET requests using a proxy, add some info into the header, and return this to the client. But sometimes I get this error when I'm writing the extra headers:
org.apache.coyote.http11.HeadersTooLargeException: An attempt was made to write more data to the response headers than there was room available in the buffer. Increase maxHttpHeaderSize on the connector or write less data into the response headers.
at org.apache.coyote.http11.AbstractOutputBuffer.checkLengthBeforeWrite(AbstractOutputBuffer.java:546)
at org.apache.coyote.http11.AbstractOutputBuffer.write(AbstractOutputBuffer.java:510)
at org.apache.coyote.http11.AbstractOutputBuffer.write(AbstractOutputBuffer.java:427)
at org.apache.coyote.http11.AbstractOutputBuffer.sendHeader(AbstractOutputBuffer.java:393)
at org.apache.coyote.http11.AbstractHttp11Processor.prepareResponse(AbstractHttp11Processor.java:1468)
at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:764)
at org.apache.coyote.Response.action(Response.java:172)
at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:185)
at org.apache.coyote.Response.doWrite(Response.java:504)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:383)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:342)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:413)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:401)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:91)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:135)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
at java.io.Writer.write(Writer.java:157)
at org.springframework.util.StreamUtils.copy(StreamUtils.java:106)
at org.springframework.http.converter.StringHttpMessageConverter.writeInternal(StringHttpMessageConverter.java:106)
at org.springframework.http.converter.StringHttpMessageConverter.writeInternal(StringHttpMessageConverter.java:40)
at org.springframework.http.converter.AbstractHttpMessageConverter.write(AbstractHttpMessageConverter.java:179)
at org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor.writeWithMessageConverters(AbstractMessageConverterMethodProcessor.java:148)
at org.springframework.web.servlet.mvc.method.annotation.HttpEntityMethodProcessor.handleReturnValue(HttpEntityMethodProcessor.java:124)
at org.springframework.web.method.support.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:69)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:122)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:745)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:686)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:80)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:936)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:827)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:812)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
I find this strange because the only thing I add into the header is {"proxy_error":"false"}. Did I just happen to send a GET to a website that returned so many headers that I couldn't write another one in? Or am I somehow causing the buffer to get too big by never clearing it (I'm sending thousands of GET requests to random urls, each time I am copying over their headers).
#RequestMapping(value = {"/hi"}, method = RequestMethod.GET)
#ResponseBody
public String test(final String url, HttpServletResponse response) {
CloseableHttpResponse httpResponse = sendGetRequest(url);
response.setHeader(PROXY_ERROR_KEY, "false");
// Copy the fetched headers
for (Header header : httpResponse.getAllHeaders()) {
response.addHeader(header.getName(), header.getValue());
}
response.setStatus(httpResponse.getStatusLine().getStatusCode());
return "hello";
}
Happened to me as well, in Jersey. I set a breakpoint on Exception, waited for Eclipse to break on it, walked through the stack and parameters and found:
I had enabled Jersey tracing which outputs debugging info into the headers. It can be quite a lot of data, no surprise I got this error.
I am accessing an Oracle 9 database using Java, in a Tomcat 7 environment.
In context.xml I have
<Resource type="javax.sql.DataSource" auth="Container"
name="jdbc/myDB"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:#localhost:1521:db" maxwait="10000"
username="temp" password="temp" maxActive="20" maxIdle="10"/>
My java code works most of the time, but sometimes randomly I get the Stream Closed exception. I suspect this may be if the user presses the buttons in the application too fast, thus starting one query before finishing another query.
This exception is caused by the doEndTag function in the following code.
public class SQLIteratorTag extends BodyTagSupport
{
public SQLIteratorTag()
{
query = "";
rs = null;
stmt = null;
rsmd = null;
dbConn = null;
con = null;
}
public int doStartTag()
throws JspTagException
{
String fieldName = "";
try
{
DBConnection d=DBConnection.getInstance();
con = d.getConnection();
...
public int doAfterBody()
throws JspException
{
try
{
....
public int doEndTag()
throws JspException
{
try
{
if(bodyContent != null)
{
bodyContent.writeOut(bodyContent.getEnclosingWriter());
}
}
catch(IOException ex)
{
Log.getIns
I do not want to post too much code, but I may have posted too little. I have no idea where the problem may lie, but I will update the question if necessary.
The exception itself is:
SEVERE: Servlet.service() for servlet [jsp] in context with path [/charm] threw exception [javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Stream closed] with root cause
javax.servlet.jsp.JspTagException: Stream closed
at c.tags.sql.SQLIteratorTag.doEndTag(SQLIteratorTag.java:218)
at org.apache.jsp.comp_005fpara_jsp._jspService(comp_005fpara_jsp.java:708)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at com.jspbook.GZIPFilter.doFilter(Unknown Source)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
From the stack trace, this doesn't appear to be anything to do with the database connection, but does look related to the user submitting two requests from the back end. I've changed the tags, but you might want to rephrase the question a bit and change the title to get more attention.
Essentially your application receives two requests, and processes them both. It's a while since I've seen this but as far as I can remember the first one gets this error because the browser has closed the TCP/IP connection in order to open a new one for the second request. (That's probably a bit simplistic with HTTP/1.1 as it reuses connections).
I think we worked around this by hiding a unique identifier on the page as it was generated, and then detecting if we got a second POST request on the same session with that UID - indicating they'd submitted twice. It was a while ago though so I'm rather hazy on exactly what we did, and how we stopped it being visible to the user; I do recall that we wrapped the HttpServletRequest for the second request in a HttpServletRequestWrapper that appeared to change the request from a POST to a GET, but I'd have to do some digging to figure what was going on.
Edit: This link is quite old but seems to have a better way to deal with it than anything ancient I can drag up (which seems to be essentially option 2 in that post). There are probably several common ways to deal with this.