>-----Original Message----- >From: Ryan J Baxter [mailto:rjbax...@us.ibm.com] >Sent: Friday, December 02, 2011 3:44 PM >To: dev@shindig.apache.org >Subject: RE: Bug With The ConcatProxyServlet > >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?
Ah -- ok -- that makes sense. One other possible solution might be to: -- pull the code that creates the right ConcatOutputStream out of doFetchConcatResources and drop it into its own private method -- make the doFetchConcatResources method take the ConcatOutputStream as a parameter and remove the close call on it from the method completely -- inside of doGet call the new method to fetch the right ConcatOutputStream, pass it to doFetchConcatResources and then evaluate the return from doFetchConcatResources and set the proper response code before closing the ConcatOutputStream (which writes the response to the client) > >-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 > > >
