You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ryan J Baxter <rj...@us.ibm.com> on 2011/12/02 00:20:09 UTC
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
RE: Bug With The ConcatProxyServlet
Posted by Ryan J Baxter <rj...@us.ibm.com>.
I like your solution better :) I will write that up this weekend/Monday.
Thanks Jesse.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: "Ciancetta, Jesse E." <jc...@mitre.org>
To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
Date: 12/02/2011 04:10 PM
Subject: RE: Bug With The ConcatProxyServlet
>-----Original Message-----
>From: Ryan J Baxter [mailto:rjbaxter@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: rjbaxter@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile
>
>
>
>From: "Ciancetta, Jesse E." <jc...@mitre.org>
>To: "dev@shindig.apache.org" <de...@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:rjbaxter@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: rjbaxter@us.ibm.com
>>Phone: 978-899-3041
>>developerWorks Profile
>
>
>
RE: Bug With The ConcatProxyServlet
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>-----Original Message-----
>From: Ryan J Baxter [mailto:rjbaxter@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: rjbaxter@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile
>
>
>
>From: "Ciancetta, Jesse E." <jc...@mitre.org>
>To: "dev@shindig.apache.org" <de...@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:rjbaxter@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: rjbaxter@us.ibm.com
>>Phone: 978-899-3041
>>developerWorks Profile
>
>
>
RE: Bug With The ConcatProxyServlet
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: "Ciancetta, Jesse E." <jc...@mitre.org>
To: "dev@shindig.apache.org" <de...@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:rjbaxter@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: rjbaxter@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile
RE: Bug With The ConcatProxyServlet
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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:rjbaxter@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: rjbaxter@us.ibm.com
>Phone: 978-899-3041
>developerWorks Profile