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?

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 <mgrigo...@apache.org>wrote:

> On Fri, Jun 21, 2013 at 11:44 AM, Marios Skounakis <msc...@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 <mgrigo...@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 <msc...@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 <
> > mgrigo...@apache.org
> > > > >wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > > On Thu, Jun 20, 2013 at 10:11 PM, Marios Skounakis <
> msc...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to