[Resin-interest] Resin 4.0.5 Buffer Commit Point
We take some fairly lengthy queries (lengthy row based on row count),
and push the data into hashmaps in JSTL pages. After that sometimes we
evaluate the hashmap and sometimes have to redirect the request to
another page. In 3.0.23 it works with no problems. In 4.0.5 we get
java.lang.IllegalStateException: Can't sendRedirect() after data has
committed to the client.
The reason being, that the for loop is causing a ton of white space to
be sent to be buffered up, and at some point a buffer size limit has
been hit with only whitespace, causing Resin to then send the HTTP
headers and commit the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I can change
the buffer size globally, or do we have to go to modify all JSPs that
potentially have this problem? Was the default commit point changed
between 3.0.x and
4.0.x, or some other architecture change, as we have never seen this
until now?*
*
Thanks,
Aaron*
*
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 Buffer Commit Point
This is why you don't put application logic into the view layer. Before you
'push' your data into the view, figure out if you want to do the redirect or
not.
jon
On Thu, Mar 25, 2010 at 7:49 AM, Aaron Freeman aaron.free...@layerz.comwrote:
We take some fairly lengthy queries (lengthy row based on row count), and
push the data into hashmaps in JSTL pages. After that sometimes we evaluate
the hashmap and sometimes have to redirect the request to another page. In
3.0.23 it works with no problems. In 4.0.5 we get
java.lang.IllegalStateException: Can't sendRedirect() after data has
committed to the client.
The reason being, that the for loop is causing a ton of white space to be
sent to be buffered up, and at some point a buffer size limit has been hit
with only whitespace, causing Resin to then send the HTTP headers and commit
the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I can change the
buffer size globally, or do we have to go to modify all JSPs that
potentially have this problem? Was the default commit point changed between
3.0.x and
4.0.x, or some other architecture change, as we have never seen this until
now?*
*
Thanks,
Aaron*
*
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 Buffer Commit Point
It's not in the view layer. We segregate our controller JSPs from our
view JSPs. So you will change your argument to say that we should not
use JSPs at the control layer, and of course _most_ of our control logic
is in pure Java, but there are cases where having our controller logic
written in JSTL (and separated from other model/view JSP pages) is a
substantial advantage for us.
So the question still stands, is there a global way to change the commit
point so we don't have to constantly reset a connection to clear the buffer?
Aaron
On 3/25/2010 10:02 AM, Jon Stevens wrote:
This is why you don't put application logic into the view layer.
Before you 'push' your data into the view, figure out if you want to
do the redirect or not.
jon
On Thu, Mar 25, 2010 at 7:49 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
We take some fairly lengthy queries (lengthy row based on row
count), and push the data into hashmaps in JSTL pages. After that
sometimes we evaluate the hashmap and sometimes have to redirect
the request to another page. In 3.0.23 it works with no
problems. In 4.0.5 we get java.lang.IllegalStateException: Can't
sendRedirect() after data has committed to the client.
The reason being, that the for loop is causing a ton of white
space to be sent to be buffered up, and at some point a buffer
size limit has been hit with only whitespace, causing Resin to
then send the HTTP headers and commit the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I can
change the buffer size globally, or do we have to go to modify all
JSPs that potentially have this problem? Was the default commit
point changed between 3.0.x and
4.0.x, or some other architecture change, as we have never seen
this until now?*
*
Thanks,
Aaron*
*
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 Buffer Commit Point
I don't mind using JSP's for some of the (separated) control logic. For
example, you have a form action:
form action=email_confirm_submit.jsp
Inside of it, it looks like this:
http://code.google.com/p/subetha/source/browse/trunk/web/email_confirm_submit.jsp
That said, look at that code. The logic for determining the next page to
redirect to is either in the t:action or within the JSTL within the
email_confirm_submit.jsp. Generally, it is nice to have it in JSTL because a
UI person can change the location of the final page without having to modify
java code to do so.
The point being that by the time you get to the view layer (ie: a jsp that
doesn't have _submit.jsp at the end), you don't do a redirect. You are
depending on what is effectively a bug in Resin that has now been fixed in a
newer version. You should modify your code to change that dependency because
you can (and should) be doing it differently.
jon
On Thu, Mar 25, 2010 at 8:18 AM, Aaron Freeman aaron.free...@layerz.comwrote:
It's not in the view layer. We segregate our controller JSPs from our
view JSPs. So you will change your argument to say that we should not use
JSPs at the control layer, and of course _most_ of our control logic is in
pure Java, but there are cases where having our controller logic written in
JSTL (and separated from other model/view JSP pages) is a substantial
advantage for us.
So the question still stands, is there a global way to change the commit
point so we don't have to constantly reset a connection to clear the buffer?
Aaron
On 3/25/2010 10:02 AM, Jon Stevens wrote:
This is why you don't put application logic into the view layer. Before you
'push' your data into the view, figure out if you want to do the redirect or
not.
jon
On Thu, Mar 25, 2010 at 7:49 AM, Aaron Freeman
aaron.free...@layerz.comwrote:
We take some fairly lengthy queries (lengthy row based on row count), and
push the data into hashmaps in JSTL pages. After that sometimes we evaluate
the hashmap and sometimes have to redirect the request to another page. In
3.0.23 it works with no problems. In 4.0.5 we get
java.lang.IllegalStateException: Can't sendRedirect() after data has
committed to the client.
The reason being, that the for loop is causing a ton of white space to be
sent to be buffered up, and at some point a buffer size limit has been hit
with only whitespace, causing Resin to then send the HTTP headers and commit
the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I can change
the buffer size globally, or do we have to go to modify all JSPs that
potentially have this problem? Was the default commit point changed between
3.0.x and
4.0.x, or some other architecture change, as we have never seen this until
now?*
*
Thanks,
Aaron*
*
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] minor problem in 4.0.5 release notes
http://caucho.com/resin-4.0/changes/resin-4.0.5.xtp Under CDI and logging integration, it says ConsoleHandler and then gives an example for SocketHandler. jon ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 Buffer Commit Point
On 3/25/2010 10:31 AM, Jon Stevens wrote:
I don't mind using JSP's for some of the (separated) control logic.
For example, you have a form action:
form action=email_confirm_submit.jsp
Inside of it, it looks like this:
http://code.google.com/p/subetha/source/browse/trunk/web/email_confirm_submit.jsp
That said, look at that code. The logic for determining the next page
to redirect to is either in the t:action or within the JSTL within
the email_confirm_submit.jsp. Generally, it is nice to have it in JSTL
because a UI person can change the location of the final page without
having to modify java code to do so.
The point being that by the time you get to the view layer (ie: a jsp
that doesn't have _submit.jsp at the end), you don't do a redirect.
You are depending on what is effectively a bug in Resin that has now
been fixed in a newer version. You should modify your code to change
that dependency because you can (and should) be doing it differently.
jon
On Thu, Mar 25, 2010 at 8:18 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
It's not in the view layer. We segregate our controller JSPs from
our view JSPs. So you will change your argument to say that we
should not use JSPs at the control layer, and of course _most_ of
our control logic is in pure Java, but there are cases where
having our controller logic written in JSTL (and separated from
other model/view JSP pages) is a substantial advantage for us.
So the question still stands, is there a global way to change the
commit point so we don't have to constantly reset a connection to
clear the buffer?
Aaron
On 3/25/2010 10:02 AM, Jon Stevens wrote:
This is why you don't put application logic into the view layer.
Before you 'push' your data into the view, figure out if you want
to do the redirect or not.
jon
On Thu, Mar 25, 2010 at 7:49 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
We take some fairly lengthy queries (lengthy row based on row
count), and push the data into hashmaps in JSTL pages. After
that sometimes we evaluate the hashmap and sometimes have to
redirect the request to another page. In 3.0.23 it works
with no problems. In 4.0.5 we get
java.lang.IllegalStateException: Can't sendRedirect() after
data has committed to the client.
The reason being, that the for loop is causing a ton of white
space to be sent to be buffered up, and at some point a
buffer size limit has been hit with only whitespace, causing
Resin to then send the HTTP headers and commit the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I
can change the buffer size globally, or do we have to go to
modify all JSPs that potentially have this problem? Was the
default commit point changed between 3.0.x and
4.0.x, or some other architecture change, as we have never
seen this until now?*
*
Thanks,
Aaron*
*
So the code example, from a style stand-point, is almost spot on with
how have laid our model/view/controller JSPs. I don't know what a t:
library, is but I am sure its some custom way to call your model code.
We do a jsp:include instead, but it's stylistically the same -- the
model is separated from your example controller.
In a JSP-based controller we are parsing the results of the model data
into a hashmap and then processing the elements in the hashmap to
determine if we need to redirect before we call the view. So our
controller looks like:
jsp:include page=/model/grab-data.sql/
%-- Process the results of the model --%
c:forEach items=${requestScope.hashMap.values()} var=rewriteUrlsQuery
/c:forEach
c:choose
c:when test=${redirect == 'true'}
c:redirect ...
/c:when
c:otherwise
jsp:include page=/view/.../
/c:otherwise
/c:choose
So I am not quite tracking with you on what we need to differently in
our controller? We are trying to do a redirect before we get to the
view layer, as you suggest, and as your code is suggesting.
Right or wrong, this is a style we have used in several places, and
instead of modifying a lot of code it would be much easier if we can
simply change the buffer size commit point. We definitely didn't intend
to exploit a bug, we are just trying to follow easy to maintain good MVC
practices and ran into this hiccup.
Fortunately through all of our testing this is the only show stopper for
us from rolling out to the newest version of Resin 4.0.5 with our
existing code base.
Thanks for you help,
Aaron
Re: [Resin-interest] minor problem in 4.0.5 release notes
Jon Stevens wrote: http://caucho.com/resin-4.0/changes/resin-4.0.5.xtp Under CDI and logging integration, it says ConsoleHandler and then gives an example for SocketHandler. Thanks. After starting the example, I realized ConsoleHandler was boring. :) -- Scott jon ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin-pro-4.0.5: JSSE + cipher-suites
Is there any documentation for using the cipher-suites tag? Instead of explicitly listing ciphers we do want, is there a way to list cipher-suites you want to exclude? Google isn't helping me find such an animal, so I am guess that it's not possible? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin-pro-4.0.5: JSSE + cipher-suites
Perfect. I was able to work out what seems to be a reasonable list, if anybody here needs it for PCI compliance. It's probably not perfect, so if anyone sees any issues with it, please let me know: cipher-suitesSSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA/cipher-suites Aaron On 3/25/2010 3:59 PM, Emil Ong wrote: Hi Aaron, Not at the moment, but it's certainly possible. I filed a feature bug for it: http://bugs.caucho.com/view.php?id=3970 Thanks, Emil On Thu, Mar 25, 2010 at 02:34:33PM -0500, Aaron Freeman wrote: Is there any documentation for using the cipher-suites tag? Instead of explicitly listing ciphers we do want, is there a way to list cipher-suites you want to exclude? Google isn't helping me find such an animal, so I am guess that it's not possible? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
