This patch is failing when i try to index large documents of size
>20MB(mainly excel and pdf)
Can anyone help?
Regards,
Pavan
On Wed, Mar 12, 2008 at 2:04 PM, pavan kumar donepudi <
[EMAIL PROTECTED]> wrote:
> I got the following error when try to launch solr in tomcat after applying
> patch
init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
compile-common:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/common
[javac] Compiling 31 source files to /tmp/apache-solr-nightly/build/common
[javac] Note: Some input files use unchecked or unsafe o
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/386/changes
: Log:
: Incorporate the prefixPath, if configured, on the forwards
this doesn't really seem like the correct usage of prefixPath .. it's
suppose to be set to whatever the SolrDispatchFIlter is configured to
intercept, not a generic webapp name ... with this change, won't
SolrDispatchFilter co
On Mar 24, 2008, at 4:54 PM, Chris Hostetter wrote:
: Log:
: Incorporate the prefixPath, if configured, on the forwards
this doesn't really seem like the correct usage of prefixPath .. it's
suppose to be set to whatever the SolrDispatchFIlter is configured to
intercept, not a generic webapp nam
Further on this via the servlet-spec RequestDispatcher#forward
may or may not re-run the filter chain, depending on web.xml
configuration. FORWARD on the filter-
mapping is required which I don't have configured. Iff that were the
case, then yeah I guess it could be recursive, huh? So
: Going to /solr/admin/stats.jsp, it was intercepting and forwarding to
: /admin/stats.jsp which is a 404. _info.jsp can leverage a default core in a
: multicore configuration and let the old (non-core prefixed) paths work fine,
: but the forwarding wasn't taking into account /solr being mapped v
: not re-run the filter chain, depending on web.xml configuration.
: FORWARD on the filter-mapping is required which I
: don't have configured. Iff that were the case, then yeah I guess it could be
: recursive, huh? So perhaps we put a note by the filter-mapping in our web.xml
: that says "don't
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581747#action_12581747
]
Stu Hood commented on SOLR-303:
---
Because the subqueries to Solr shards use GET requests (via So
On Mar 24, 2008, at 6:23 PM, Chris Hostetter wrote:
: Going to /solr/admin/stats.jsp, it was intercepting and
forwarding to
: /admin/stats.jsp which is a 404. _info.jsp can leverage a
default core in a
: multicore configuration and let the old (non-core prefixed) paths
work fine,
: but t
On Mar 24, 2008, at 8:50 PM, Erik Hatcher wrote:
On Mar 24, 2008, at 6:23 PM, Chris Hostetter wrote:
: Going to /solr/admin/stats.jsp, it was intercepting and
forwarding to
: /admin/stats.jsp which is a 404. _info.jsp can leverage a
default core in a
: multicore configuration and let the
client source needs to be included in releases
--
Key: SOLR-510
URL: https://issues.apache.org/jira/browse/SOLR-510
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Fix For
: I've updated the docs. I'm not quite sure what the setter and getter of
: pathPrefix are good for though, as the setting comes from the init-param, and
: that setter is never called. Seems like we could remove the setter/getter
: altogether, unless someone has a case where the Filter would be
13 matches
Mail list logo
