No that is what I am seeing but after we return from doFetchConcatResources(..) we set the status in doGet. So lets say we return false from doFetchConcatResources and the content written to the response was bigger than the buffer. This means we will flush the buffer and set the status to the OK status then write the rest of the content and set the status to bad request, but it will be to late we already set the status to OK. Make sense? -Ryan
Email: rjbax...@us.ibm.com Phone: 978-899-3041 developerWorks Profile From: "Ciancetta, Jesse E." <jc...@mitre.org> To: "dev@shindig.apache.org" <dev@shindig.apache.org>, Date: 12/02/2011 03:34 PM Subject: RE: Bug With The ConcatProxyServlet Hmm -- I'm not seeing the case where what your describing could happen. If I understand what you're saying -- it sounds like content is being written directly to the response object, and if an exception is thrown after the response buffer has already been flushed then at that point it's too late to change the response code. But I don't see any cases in ConcatProxyServlet where content is being written directly to the client response when looping over the concat fetch responses. It doesn't looks like the code inside of the doFetchConcatResources(...) method does any work that writes to the actual response until line 247 where cos.close() is called which takes the content of a stringbuilder and flushes it to the response. All the other work in that method is calling methods on cos that just write to the stringbuilder (cos.output, cos.outputError, ...). Are you seeing something different? >-----Original Message----- >From: Ryan J Baxter [mailto:rjbax...@us.ibm.com] >Sent: Thursday, December 01, 2011 6:20 PM >To: dev@shindig.apache.org >Subject: Bug With The ConcatProxyServlet > >I am noticing a small problem with the ConcatProxyServlet in Shindig, >mainly when the content of the data being concatenated is greater than >response buffer size and there is a failure with one of the requests being >made. In this case the way the ConcateProxyServlet is currently written >it is possible that we should return an error status but instead we will >have an OK status. This is because once the response has to flush the >buffer, because the content is bigger than the buffer size, the responses >status if set to the OK status and cannot be changed again after it is >set. The only way I can think of fixing this problem in the concat >servlet is to loop through the requests once making sure there are no >internal errors. If there are errors we set the error status and return. >If there are not any errors we loop through the requests again and this >time write out the content to the response. I hope that makes sense to >everyone, what do others think? > >-Ryan > >Email: rjbax...@us.ibm.com >Phone: 978-899-3041 >developerWorks Profile
