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 <[email protected]>wrote: > On Fri, Jun 21, 2013 at 12:29 PM, Marios Skounakis <[email protected]> > 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 <[email protected] > > >wrote: > > > > > On Fri, Jun 21, 2013 at 11:44 AM, Marios Skounakis <[email protected]> > > > 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 < > > [email protected] > > > > >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 < > [email protected] > > > > > > > > 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 < > > > > [email protected] > > > > > > >wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 20, 2013 at 10:11 PM, Marios Skounakis < > > > [email protected] > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
