Thanks Chris and Sai. I was hoping to use the standard jetty configuration (noting another thread on these forums indicating that it is the default and supported container). but will migrate to tomcat of needed. Has anyone found a workaround that works with the standard container?
We are sending updates of around 1000 records at a time, about 500k for the whole json document. Sent from my iPhone > On Oct 25, 2013, at 6:01 AM, Sai Gadde <gadde....@gmail.com> wrote: > > We were trying to migrate to 4.5 from 4.0 and faced similar issue as well. > I saw the ticket raised by Chris and tried setting formdataUploadLimitInKB > to a higher value and which did not resolve this issue. > > We use Solr 4.0.0 currently and no additional container settings are > required. But it is very strange since when I tested with a single instance > there was no problem at all. How come it is so difficult for two Solr > instances to communicate with each other! I except Solr cloud setup should > be independent of container configuration. > > Anyway thanks Chris for the info we will try these tomcat settings and see > if this issue goes away. > > >> On Fri, Oct 25, 2013 at 4:35 PM, Chris Geeringh <geeri...@gmail.com> wrote: >> >> Hi Michael, >> >> I opened that ticket, and it looks like there is indeed a buffer or limit I >> was exceeding. As per the ticket I guess the stream is cut off at that >> limit, and is then malformed. I am using Tomcat, and since increasing some >> limits on the connector, I haven't had any issues since. I'll close that >> ticket. >> >> <Connector port="8080" protocol="HTTP/1.1" >> connectionTimeout="60000" >> redirectPort="8443" maxPostSize="104857600" >> maxHttpHeaderSize="819200" maxThreads="10000"/> >> >> Hope that helps. >> >> Cheers, >> Chris >> >> >>> On 25 October 2013 03:48, Michael Tracey <mtra...@biblio.com> wrote: >>> >>> Hey Solr-users, >>> >>> I've got a single solr 4.5.1 node with 96GB ram, a 65GB index (105 >> million >>> records) and a lot of daily churn of newly indexed files (auto softcommit >>> and commits). I'm trying to bring another matching node into the mix, >> and >>> am getting these errors on the new node: >>> >>> org.apache.solr.common.SolrException; >>> org.apache.solr.common.SolrException: Illegal to have multiple roots >> (start >>> tag in epilog?). >>> >>> On the old server, still running, I'm getting: >>> >>> shard update error StdNode: http://server1:xxxx >> /solr/collection/:org.apache.solr.client.solrj.SolrServerException: >>> Server refused connection at: http://server2:xxxx/solr/collection >>> >>> the new core never actually comes online, stays in recovery mode. The >>> other two tiny cores (100,000+ records each and not updated frequently), >>> work just fine. >>> >>> is this SOLR-4327 bug? https://issues.apache.org/jira/browse/SOLR-5331 >>> And if so, how can I get the new node up and running so I can get back in >>> production with some redundancy and speed? >>> >>> I'm running an external zookeeper, and that is all running just fine. >>> Also internal Solrj/jetty with little to no modifications. >>> >>> Any ideas would be appreciated, thanks, >>> >>> M. >>
