Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 4.0
-
Labels:
Description
In jetty.xml, the cofiguration to set the maximum form content size does not work, because jetty contextHandler reads System property org.eclipse.jetty.server.Request.maxFormContentSize.
In CotextHandler.java line 137, the method call "Integer.getInteger("org.eclipse.jetty.server.Request.maxFormContentSize",200000).intValue();" returns always the default value 200000 regardless what is set below.
So instead of:
<Call name="setAttribute">
<Arg>org.eclipse.jetty.server.Request.maxFormContentSize</Arg>
<Arg>400000</Arg>
</Call>
Replace with:
<Call class="java.lang.System" name="setProperty">
<Arg>org.eclipse.jetty.server.Request.maxFormContentSize</Arg>
<Arg>400000</Arg>
</Call>
PS:
There are other ways to set this config limit in commandline like -Dorg.eclipse.jetty.server.Request.maxFormContentSize=700000 or in web-jetty.xml which works fine.
Issue Links
- is superceded by
-
SOLR-4265
Fix decoding of GET/POST parameters for servlet containers with non-UTF-8 URL parsing (Tomcat)
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Just received an email from eclipse bugzilla - a fix for the jetty bug will be in 8.1.9.
[branch_4x commit] Shalin Shekhar Mangar
http://svn.apache.org/viewvc?view=revision&revision=1425684
SOLR-4223: "maxFormContentSize" in jetty.xml is not picked up by jetty 8
so set it via solr webapp context file
Committed Hoss's patch in trunk and branch_4x.
[trunk commit] Shalin Shekhar Mangar
http://svn.apache.org/viewvc?view=revision&revision=1425683
SOLR-4223: "maxFormContentSize" in jetty.xml is not picked up by jetty 8
so set it via solr webapp context file
I filed a matching bug against the jetty project.
As noted in SOLR-3159, we're already using hte jetty recommended method for "Changing the Maximum Form Size for All Apps on a Server" – except that apparently that doesn't actually work.
The attached patch seems to fix this by setting it in the solr context file – i was hoping to write a junit test to sanity check it moving forward, but all the solr example tests use the "JettySolrRunner" to test out hte solr example configs in a jetty instance wired via java – they weren't designed to test the example jetty configs.
Running a very recent branch_4x. I have this in jetty.xml:
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<!-- Increase the maximum POST size to 1 MB to be able to handle large shard requests -->
<Call name="setAttribute">
<Arg>org.eclipse.jetty.server.Request.maxFormContentSize</Arg>
<Arg>1048576</Arg>
</Call>
By artificially making my code add 200000 spaces to a deleteByQuery, I duplicated this issue:
ERROR - 2012-12-21 02:29:00.108; org.apache.solr.common.SolrException; null:java.lang.IllegalStateException: Form too large200077>200000
at org.eclipse.jetty.server.Request.extractParameters(Request.java:326)
As nathan says we are seeing errors in Solr, such as:
05:53:44 newssolr:ERROR o.a.solr.servlet.SolrDispatchFilter - null:java.lang.IllegalStateException: Form too large348594>200000 05:53:44 newssolr:~at org.eclipse.jetty.server.Request.extractParameters(Request.java:285) 05:53:44 newssolr:~at org.eclipse.jetty.server.Request.getParameterMap(Request.java:711) 05:53:44 newssolr:~at org.apache.solr.request.ServletSolrParams.<init>(ServletSolrParams.java:29) 05:53:44 newssolr:~at org.apache.solr.servlet.StandardRequestParser.parseParamsAndFillStreams(SolrRequestParsers.java:394) 05:53:44 newssolr:~at org.apache.solr.servlet.SolrRequestParsers.parse(SolrRequestParsers.java:115) 05:53:44 newssolr:~at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260) 05:53:44 newssolr:~at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307) 05:53:44 newssolr:~at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453) 05:53:44 newssolr:~at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) 05:53:44 newssolr:~at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:559) 05:53:44 newssolr:~at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) 05:53:44 newssolr:~at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072) 05:53:44 newssolr:~at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382) 05:53:44 newssolr:~at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) 05:53:44 newssolr:~at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006) 05:53:44 newssolr:~at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) 05:53:44 newssolr:~at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) 05:53:44 newssolr:~at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) 05:53:44 newssolr:~at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) 05:53:44 newssolr:~at org.eclipse.jetty.server.Server.handle(Server.java:365) 05:53:44 newssolr:~at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485) 05:53:44 newssolr:~at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) 05:53:44 newssolr:~at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926) 05:53:44 newssolr:~at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988) 05:53:44 newssolr:~at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:642) 05:53:44 newssolr:~at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) 05:53:44 newssolr:~at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) 05:53:44 newssolr:~at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) 05:53:44 newssolr:~at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) 05:53:44 newssolr:~at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) 05:53:44 newssolr:~at java.lang.Thread.run(Thread.java:619)
We have very long queries (we are testing the XML parser) so we POST data instead of GET.
This happens when I submit a query
curl -X POST -d @query.txt http://localhost:8787/solr/select
query.txt is the file containg the query
Why do we need to set this at all?
We read POST content by an InputStream, but we are never interested in the contents interpreted as form-content at all?
It does not work in jetty.xml.
<Call name="setMaxFormContentSize">
<Arg>400000</Arg>
</Call>
No method called setMaxFormContentSize is found in class org.eclipse.jetty.server.Server
But you can do
<Configure class="org.eclipse.jetty.webapp.WebAppContext"> <Set name="maxFormContentSize">400000</Set> </Configure>
in web-jetty.xml. But this is a setting file in WEB-INF folder which can override the settings mentioned in jetty.xml.
This should also work.
<Call name="setMaxFormContentSize">
<Arg>400000</Arg>
</Call>
Can you verify?
This has been already raised in the comments of https://issues.apache.org/jira/browse/SOLR-3159
But still unresolved.
Hi,
I am not sure, but this problem was fixed in Solr by my commit yesterday:
SOLR-4265(solr no longer uses ServletRequest.getParameter*() at all, it parses the POST contents by itsself using an own UTF-8 compatible parser). The above settings are affecting POST, right? Because GET URLs are still limited to maximum URL length, right?The maximum length inside the default Solr config file for formdata sent through POST is now 2048 KiB ! You can raise it easily using solrconfig.xml. There is no config needed anymore in Solr's web.xml/jetty config, I did not know there were changes in Solr's web.xml about this. We should remove them now.
See also CHANGES.txt and Solr Wiki about Tomcat configuration.