wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marios Skounakis <msc...@gmail.com>
Subject Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
Date Fri, 21 Jun 2013 12:14:50 GMT
Martin,

Thank you for your replies. You are right that using
MultipartServletWebRequestImpl you can set the max size and handle the
error.

Cheers
Marios


On Fri, Jun 21, 2013 at 2:09 PM, Martin Grigorov <mgrigorov@apache.org>wrote:

> On Fri, Jun 21, 2013 at 12:29 PM, Marios Skounakis <mscoon@gmail.com>
> wrote:
>
> > Looking at tomcat sources it seems tomcat does not throw an exception bug
> > simply logs a debug message!
> >
> > Regarding wicket now, setting Form#setMaxSize seems to have no effect
> > unless there is a file upload involved. My case has just lots of
> textareas
> > with lots of text content... Can you please confirm this?
> >
>
> Hm, yes and no.
> By default ServletWebRequest is used in WebApplication#newWebRequest().
> When there is FileUpload (multi part data) Wicket automatically switches to
> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequestImpl (see
>
> org.apache.wicket.protocol.http.servlet.ServletWebRequest#newMultipartWebRequest).
> This request impl
> uses
> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequestImpl.CountingInputStream
> to count *all* bytes. So it should work. Just setup MSWRI to be the default
> instead of SWR.
>
>
> >
> > So it seems there is no way to detect if the user has exceeded the max
> post
> > size. If they do, you get empty post data...
> >
> > I have considered a workaround: use a hidden field with a preset value,
> on
> > postback check that the post parameters include this preset value, throw
> > exception otherwise. What do you think?
> >
> >
> >
> > On Fri, Jun 21, 2013 at 12:48 PM, Martin Grigorov <mgrigorov@apache.org
> > >wrote:
> >
> > > On Fri, Jun 21, 2013 at 11:44 AM, Marios Skounakis <mscoon@gmail.com>
> > > wrote:
> > >
> > > > Actually I want to read the whole input, and increasing tomcat
> > > maxPostSize
> > > > is the solution.
> > > >
> > > > But I was puzzled by the fact that I got no exception and instead I
> got
> > > > this weird behavior. Is there something that wicket does that keeps
> > > tomcat
> > > > from throwing the exception?
> > > >
> > >
> > > No. As you see Wicket just tries to read the parameters map and it is
> > > empty.
> > > I guess there is Tomcat property that switches its behavior when
> reading
> > > huge POST data.
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jun 21, 2013 at 12:32 PM, Martin Grigorov <
> > mgrigorov@apache.org
> > > > >wrote:
> > > >
> > > > > You can use Wicket API to set the maxSize -
> > > > > org.apache.wicket.markup.html.form.Form#setMaxSize
> > > > > This way Tomcat will read the whole input and Wicket will report
> the
> > > > error.
> > > > >
> > > > > But maybe reading the whole input is what you try to avoid.
> > > > >
> > > > >
> > > > > On Fri, Jun 21, 2013 at 11:24 AM, Marios Skounakis <
> mscoon@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Some more info after further investigation:
> > > > > >
> > > > > > The problem is definitely related to tomcat maxPostSize
> parameter.
> > I
> > > > have
> > > > > > set this to a very small value (100) and the problem is occurring
> > > even
> > > > in
> > > > > > very small regular (non ajax) form posts.
> > > > > >
> > > > > > Debugging this I found that
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> org.apache.wicket.protocol.http.servlet.ServletWebRequest.generatePostParameters
> > > > > >
> > > > > > calls
> > > > > > Map<String, String[]> params =
> > > getContainerRequest().getParameterMap();
> > > > > > and gets a blank params map.
> > > > > >
> > > > > > This explains the fact that the form is normally processed and
> > > rendered
> > > > > > with null component values.
> > > > > >
> > > > > > I am not sure how I can investigate this further.
> > > getContainerRequest()
> > > > > is
> > > > > > a tomcat RequestFacade object so this is where I stopped tracing
> > the
> > > > > > execution. Perhaps it's a tomcat bug. I'll go ahead and try
with
> > > > > different
> > > > > > tomcat versions.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 21, 2013 at 10:40 AM, Martin Grigorov <
> > > > mgrigorov@apache.org
> > > > > > >wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 20, 2013 at 10:11 PM, Marios Skounakis <
> > > mscoon@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I have the following problem:
> > > > > > > > - User submits form with lots of textareas via ajax
> > > > > > > > - User gets a blank page
> > > > > > > >
> > > > > > > > I think (but I'm not quite sure yet) this happens
when the
> > > > textareas
> > > > > > > > contain so much text that either maxPostSize or
> > connectionTimeout
> > > > > > (submit
> > > > > > > > tries to store to db as well) are exceeded.
> > > > > > > >
> > > > > > > > The weird thing is that there is no exception. The
form comes
> > > back
> > > > > > after
> > > > > > > > the ajax request with blank components.
> > > > > > > >
> > > > > > >
> > > > > > > So is it a blank page or just form elements without values
?
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Has anyone else seen this behavior? Why is there no
> exception?
> > > > > > > >
> > > > > > >
> > > > > > > If the problem is maxSize then there must be an exception.
This
> > > will
> > > > > lead
> > > > > > > to onFailure() call executed in Ajax request.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Marios
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message