[
https://issues.apache.org/jira/browse/SOLR-14768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Doupnik updated SOLR-14768:
-------------------------------
Attachment: Solr v8.6.x fails with multipart MIME in commands.eml
Ishan and Markus,
Patches. Alas, given the large untamed dense tropical jungle of
Solr/Lucene's Java material that task is more than I can undertake
myself. That isn't to say I have not explored and tried, but the details
are far too diffuse and many to decode matters. As I write this I have
yet another test build in the making, this with the problem file of
SolrRequestParsers.java, section cleanupMultipartFiles(), replaced by a
simple return in an attempt to avoid the not-found effect. This build
will take quite a while to finish, assuming I gave the correct sequence
of ant commands, and then test. Even with that the problem is not
solved, just its use location has been verified.
The Jetty material on the web, for example, discusses abandoning
MultiParts in v9 to use a new, presumably faster, rendition in v10. What
is apparent is presently there is a missing Java file, or equivalently a
needed reference to it, to compose a working Solr. Finding such missing
references is for those who are deeply immersed in those details.
For easy reference I have attached the email version of my original
report, which has details and screen captures.
A suggestion. It is all very nice to have nearly a thousand minor
Java "test" utilities, but the facilities end results must be tested for
correct operation, and it is apparent that such overall testing is
lacking presently. To help with that part my suggestion is get my
crawler program (which exhibits the problem encountered by Markus and
myself), strip it down to just basic core operations (create, delete,
add a few files to) to obtain experimental results which are just the
kind used in the field. Snippets of the PHP code are in my attached
message, and the full material is available from https://netlab1.net, go
to section "Presentations of long term utility", thence to "Solr/Lucene
Search Service." Grab the offered SearchService2.1.tar.gz file which has
PHP code and documentation, and put the crawler to work as a test tool.
Shrinking down the crawler to just needed test essentials is easy,
valuable and free, and can be part of the pre-release test and
validation process.
A second free suggestion is offer folks the _complete_ source tar
ball, not just parts which go out on the web to fetch lots of other
source files. Pretend the Internet does not exist. Those "other files"
keep changing and hence are not thoroughly tested within the full Solr
unit. We need the complete set which has been both tested and proven
successful, not mixing the latest bits off someone's machine. Within
reason, if not proven correct then not shipped.
A last freebee. I see some individual in the project wants to
abandon Tika and friends and instead just play with Lucene. That is an
unacceptably narrow and regressive approach to the material, and it
strongly works directly against users of Solr in the field. The entire
package is what we need, not end users be players assembling and
shuffling Java parts about willy nilly. Markus has commented on the
large number of users of his Drupal interface material for Solr.
The build process seems as if more hours need elapse to finish the
"test" building component, so I will stop here. Oh dear, "ant package"
failed, saying file lucene/common-build.xml, line 2331 failed (that line
wants $(git.exe) for gosh sakes). I am building on SUSE Leap 15.2 Linux,
not Windows.
I appreciate that we are dealing with a complicated assemblage of
material with constantly changing responsible people, and with limits on
project resources. Thus both Markus and myself are willing to assist as
we can, but we cannot be expected to become deeply immersed in this
dense material. That chore for those responsible people. Thus can we
escalate matters to those folks and see if we can rectify the problem.
Thanks,
Joe D.
> Error 500 on PDF extraction: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/server/MultiParts
> ------------------------------------------------------------------------------------------------
>
> Key: SOLR-14768
> URL: https://issues.apache.org/jira/browse/SOLR-14768
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
> Affects Versions: 8.6, 8.6.1
> Reporter: Markus Kalkbrenner
> Priority: Major
> Attachments: Solr v8.6.x fails with multipart MIME in commands.eml,
> Solr v8.6.x fails with multipart MIME in commands.eml
>
>
> See [https://www.mail-archive.com/[email protected]/msg152182.html]
> The integration tests of the solarium PHP library and the integration tests
> of the Search API Solr Drupal module both fail on PDF extraction if executed
> on Solr 8.6.
> They still work on Solr 8.5.1 an earlier versions.
> {quote}2020-08-20 12:30:35.279 INFO (qtp855700733-19) [ x:5f3e6ce2810ef]
> o.a.s.u.p.LogUpdateProcessorFactory [5f3e6ce2810ef] webapp=/solr
> path=/update/extract
> params=\{json.nl=flat&commitWithin=0&omitHeader=false&resource.name=testpdf.pdf&literal.id=extract-test&commit=true&extractOnly=false&uprefix=attr_&wt=json}{add=[extract-test
> (1675547519474466816)],commit=} 0 957
> solr8_1 | 2020-08-20 12:30:35.280 WARN (qtp855700733-19) [ ]
> o.e.j.s.HttpChannel /solr/5f3e6ce2810ef/update/extract =>
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
> solr8_1 | java.lang.NoClassDefFoundError: org/eclipse/jetty/server/MultiParts
> solr8_1 | at
> org.apache.solr.servlet.SolrRequestParsers.cleanupMultipartFiles(SolrRequestParsers.java:624)
> ~[?:?]
> solr8_1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:443)
> ~[?:?]
> solr8_1 | at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> ~[?:?]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> ~[jetty-security-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> ~[jetty-servlet-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> ~[jetty-rewrite-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at org.eclipse.jetty.server.Server.handle(Server.java:500)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> ~[jetty-server-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> ~[jetty-io-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> ~[jetty-io-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> ~[jetty-io-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
> ~[jetty-util-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
> ~[jetty-util-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
> ~[jetty-util-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
> ~[jetty-util-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
> ~[jetty-util-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> ~[jetty-util-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> ~[jetty-util-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at java.lang.Thread.run(Unknown Source) [?:?]
> solr8_1 | Caused by: java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.MultiParts
> solr8_1 | at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:565)
> ~[jetty-webapp-9.4.27.v20200227.jar:9.4.27.v20200227]
> solr8_1 | at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:?]
> solr8_1 | ... 40 more
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
