Activity log for bug #660998

Date Who What changed Old value New value Message
2010-10-15 08:11:18 Tatjana bug added bug
2010-10-20 09:50:40 Stephane Mikaty (eCircle AG) description In our testlab we almost always get the exception "java.net.SocketException: SOCKS: Connection refused" Althogh our test is pass, we get after two hours alarms saying "java.net.SocketException: SOCKS: Connection refused" 00000281-01 NOTICE Sending SOAP Request... 00000282-01 RAWGETREQUEST http://cust1327.com/eCMessageService/ HTTPRequest: POST /httpTemp1287068521949.html Test Execution Trace: Run: seq.Test 1 = 1 Pass + 0 Skip + 0 Fail Recurse: 1 = 1 Pass + 0 Skip + 0 Fail Child:seq.notice._check_soap_notices Pass !!! Warning Count: 3 Finished. When debugging the problem, we found out the following problem: com.domeus.messaging.TransportException: java.io.EOFException: Premature EOF encountered at com.domeus.messaging.HttpTransport.send(HttpTransport.java:98) at com.domeus.messaging.HttpTransport.send(HttpTransport.java:42) at com.domeus.job.SendXmlReportJob.send(SendXmlReportJob.java:254) at com.domeus.job.SendXmlReportJob.doProcess(SendXmlReportJob.java:174) at com.domeus.job.RetryingJob.process(RetryingJob.java:47) at com.domeus.jmf.JobProcessor$Poller$2.execute(JobProcessor.java:939) at com.domeus.jmf.JobProcessor$Poller$2.execute(JobProcessor.java:933) at com.domeus.dao.DAO.doScoped(DAO.java:698) at com.domeus.jmf.JobProcessor$Poller.processJobInDAOContext(JobProcessor.java:954) at com.domeus.jmf.JobProcessor$Poller.accept(JobProcessor.java:859) at com.domeus.jmf.JobProcessor$Poller.dequeAndProcessNextJob(JobProcessor.java:692) at com.domeus.jmf.JobProcessor$Poller.runInDAOContext(JobProcessor.java:650) at com.domeus.jmf.JobProcessor$Poller.access$200(JobProcessor.java:591) at com.domeus.jmf.JobProcessor$Poller$1.execute(JobProcessor.java:634) at com.domeus.dao.DAO.doScoped(DAO.java:698) at com.domeus.jmf.JobProcessor$Poller.run(JobProcessor.java:631) Caused by: java.io.EOFException: Premature EOF encountered at HTTPClient.StreamDemultiplexor.read(StreamDemultiplexor.java:275) at HTTPClient.RespInputStream.read(RespInputStream.java:155) at HTTPClient.RespInputStream.read(RespInputStream.java:115) at HTTPClient.Response.readResponseHeaders(Response.java:971) at HTTPClient.Response.getHeaders(Response.java:693) at HTTPClient.Response.getStatusCode(Response.java:263) at HTTPClient.RetryModule.responsePhase1Handler(RetryModule.java:83) at HTTPClient.HTTPResponse.handleResponse(HTTPResponse.java:724) at HTTPClient.HTTPResponse.getStatusCode(HTTPResponse.java:190) at com.domeus.messaging.HttpTransport.sendRequest(HttpTransport.java:114) at com.domeus.messaging.HttpTransport.send(HttpTransport.java:81) ... 15 more It seems that the connection gets closed to early. ECM doesn't get information it needs to mark the job as COMPLETE. Stephane assumes that the suggestion below could be a solution for the problem. ################################ _ClientServer.java ############################################# if( targetObj.redirect != null ) { response.setHeader("Location", targetObj.redirect ); } else if( !targetObj.dynamic ) { //we can't use the default server since it won't allow overrriding *anything* (like content-type) byte[] bytes = StreamUtil.loadBytes( new FileInputStream( targetObj.content ) ); response.setContentLength( bytes.length ); response.getOutputStream().write( bytes ); >>>>>>>>>>>>>>> response.getOutputStream().flush(); <<<<<<<<<<<<<<<<<<<<<<<<< Stephane: This could be a fix to resolve this issue } ################################################################################################ (Stephane Mikaty:2010-10-20 This is not related to HTTPClient, HTTPClient only *points* to the problem. The problem has to do with unit.server.http._ClientServer, which does not flush or otherwise close the OutputStream to which it is writing. It only calls write(), but leaves it up to the Jetty servlet engine to decide when to flush, which does not seem to always happen, Jetty seems to close the connection forcibly without flushing buffers... ) In our testlab we almost always get the exception "java.net.SocketException: SOCKS: Connection refused" Althogh our test is pass, we get after two hours alarms saying "java.net.SocketException: SOCKS: Connection refused" 00000281-01 NOTICE Sending SOAP Request... 00000282-01 RAWGETREQUEST http://cust1327.com/eCMessageService/ HTTPRequest: POST /httpTemp1287068521949.html Test Execution Trace:         Run: seq.Test 1 = 1 Pass + 0 Skip + 0 Fail         Recurse: 1 = 1 Pass + 0 Skip + 0 Fail                 Child:seq.notice._check_soap_notices Pass !!! Warning Count: 3 Finished. When debugging the problem, we found out the following problem: com.domeus.messaging.TransportException: java.io.EOFException: Premature EOF encountered  at com.domeus.messaging.HttpTransport.send(HttpTransport.java:98)  at com.domeus.messaging.HttpTransport.send(HttpTransport.java:42)  at com.domeus.job.SendXmlReportJob.send(SendXmlReportJob.java:254)  at com.domeus.job.SendXmlReportJob.doProcess(SendXmlReportJob.java:174)  at com.domeus.job.RetryingJob.process(RetryingJob.java:47)  at com.domeus.jmf.JobProcessor$Poller$2.execute(JobProcessor.java:939)  at com.domeus.jmf.JobProcessor$Poller$2.execute(JobProcessor.java:933)  at com.domeus.dao.DAO.doScoped(DAO.java:698)  at com.domeus.jmf.JobProcessor$Poller.processJobInDAOContext(JobProcessor.java:954)  at com.domeus.jmf.JobProcessor$Poller.accept(JobProcessor.java:859)  at com.domeus.jmf.JobProcessor$Poller.dequeAndProcessNextJob(JobProcessor.java:692)  at com.domeus.jmf.JobProcessor$Poller.runInDAOContext(JobProcessor.java:650)  at com.domeus.jmf.JobProcessor$Poller.access$200(JobProcessor.java:591)  at com.domeus.jmf.JobProcessor$Poller$1.execute(JobProcessor.java:634)  at com.domeus.dao.DAO.doScoped(DAO.java:698)  at com.domeus.jmf.JobProcessor$Poller.run(JobProcessor.java:631) Caused by: java.io.EOFException: Premature EOF encountered  at HTTPClient.StreamDemultiplexor.read(StreamDemultiplexor.java:275)  at HTTPClient.RespInputStream.read(RespInputStream.java:155)  at HTTPClient.RespInputStream.read(RespInputStream.java:115)  at HTTPClient.Response.readResponseHeaders(Response.java:971)  at HTTPClient.Response.getHeaders(Response.java:693)  at HTTPClient.Response.getStatusCode(Response.java:263)  at HTTPClient.RetryModule.responsePhase1Handler(RetryModule.java:83)  at HTTPClient.HTTPResponse.handleResponse(HTTPResponse.java:724)  at HTTPClient.HTTPResponse.getStatusCode(HTTPResponse.java:190)  at com.domeus.messaging.HttpTransport.sendRequest(HttpTransport.java:114)  at com.domeus.messaging.HttpTransport.send(HttpTransport.java:81)  ... 15 more It seems that the connection gets closed to early. ECM doesn't get information it needs to mark the job as COMPLETE. Stephane assumes that the suggestion below could be a solution for the problem. ################################ _ClientServer.java #############################################      if( targetObj.redirect != null ) {       response.setHeader("Location", targetObj.redirect );      } else if( !targetObj.dynamic ) {       //we can't use the default server since it won't allow overrriding *anything* (like content-type)       byte[] bytes = StreamUtil.loadBytes( new FileInputStream( targetObj.content ) );       response.setContentLength( bytes.length );       response.getOutputStream().write( bytes ); >>>>>>>>>>>>>>> response.getOutputStream().flush(); <<<<<<<<<<<<<<<<<<<<<<<<< Stephane: This could be a fix to resolve this issue      } ################################################################################################
2010-11-04 11:20:59 Stephane Mikaty (eCircle AG) summary HTTPClient seems to get closed the connection a bit early Premature EOF caused by Jetty ResourceHandler OutputStream seemingly not being flushed consistently by Jetty
2010-11-04 11:26:29 Launchpad Janitor branch linked lp:testplan