Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
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 wrote: > On Fri, Jun 21, 2013 at 12:29 PM, Marios Skounakis > 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 > >wrote: > > > > > On Fri, Jun 21, 2013 at 11:44 AM, Marios Skounakis > > > 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 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 wi
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
On Fri, Jun 21, 2013 at 12:29 PM, Marios Skounakis 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 >wrote: > > > On Fri, Jun 21, 2013 at 11:44 AM, Marios Skounakis > > 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 > > > > > 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 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
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 wrote: > On Fri, Jun 21, 2013 at 11:44 AM, Marios Skounakis > 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 > >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 > > > 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 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 > > > > > > > > > > > > > > > > > > > > >
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
On Fri, Jun 21, 2013 at 11:44 AM, Marios Skounakis 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 >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 > > 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 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 > > > > > 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 > > > > > > > > > > > > > > >
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
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? On Fri, Jun 21, 2013 at 12:32 PM, Martin Grigorov 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 > 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 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 > >wrote: > > > > > Hi, > > > > > > > > > On Thu, Jun 20, 2013 at 10:11 PM, Marios Skounakis > > > 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 > > > > > > > > > >
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
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 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 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 >wrote: > > > Hi, > > > > > > On Thu, Jun 20, 2013 at 10:11 PM, Marios Skounakis > > 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 > > > > > >
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
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 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 wrote: > Hi, > > > On Thu, Jun 20, 2013 at 10:11 PM, Marios Skounakis > 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 > > >
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
Hi, On Thu, Jun 20, 2013 at 10:11 PM, Marios Skounakis 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 >
Re: Ajax form submit and Tomcat maxPostSize/connectionTimeout
Blank form prob means empty model objects. Start Wicket in DEVELOPMENT mode: https://cwiki.apache.org/WICKET/faqs.html#FAQs-Myapplicationsays%2522DEVELOPMENTMODE%2522%252ChowdoIswitchtoproduction%253F Add the DebugBar to your page: http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/devutils/debugbar/DebugBar.html Then analyze the output in the AjaxConsole (lower right corner of your screen). You should see all the AJAX replies from the server to your browser. You can also use breakpoints and figure out what's going on in your Java code on the server side. Read up on Wicket and AJAX in chapter 16 of the Wicket Free Guide at: http://wicket.apache.org/learn/books/ Have a great day, Paul Bors On Jun 20, 2013, at 4:54 PM, Paul Bors wrote: > Stack trace? > > -Original Message- > From: Marios Skounakis [mailto:msc...@gmail.com] > Sent: Thursday, June 20, 2013 4:12 PM > To: users@wicket.apache.org > Subject: Ajax form submit and Tomcat maxPostSize/connectionTimeout > > 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. > > Has anyone else seen this behavior? Why is there no exception? > > Thanks > Marios >
RE: Ajax form submit and Tomcat maxPostSize/connectionTimeout
Stack trace? -Original Message- From: Marios Skounakis [mailto:msc...@gmail.com] Sent: Thursday, June 20, 2013 4:12 PM To: users@wicket.apache.org Subject: Ajax form submit and Tomcat maxPostSize/connectionTimeout 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. Has anyone else seen this behavior? Why is there no exception? Thanks Marios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Ajax form submit and Tomcat maxPostSize/connectionTimeout
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. Has anyone else seen this behavior? Why is there no exception? Thanks Marios
