[
https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627010#comment-16627010
]
Karl Wright commented on SOLR-12798:
------------------------------------
I'm looking for workarounds -- initially, at least.
What I've tried is adding the following code in the POST/PUT section of the
HttpSolrClient code:
{code}
// UpdateRequest uses PUT now, and ContentStreamUpdateHandler uses POST.
// We must override PUT with POST if multipart is on.
// If useMultipart is on, we fall back to getting streams directly from
the request.
final boolean mustUseMultipart;
final SolrRequest.METHOD methodToUse;
if (this.useMultiPartPost) {
final Collection<ContentStream> requestStreams =
request.getContentStreams();
mustUseMultipart = requestStreams != null && requestStreams.size() > 0;
if (mustUseMultipart) {
System.out.println("Overriding with multipart post");
streams = requestStreams;
methodToUse = SolrRequest.METHOD.POST;
} else {
methodToUse = request.getMethod();
}
} else {
mustUseMultipart = false;
methodToUse = request.getMethod();
}
//System.out.println("Post or put");
String url = basePath + path;
/*
boolean hasNullStreamName = false;
if (streams != null) {
for (ContentStream cs : streams) {
if (cs.getName() == null) {
hasNullStreamName = true;
break;
}
}
}
*/
/*
final boolean isMultipart = ((this.useMultiPartPost &&
SolrRequest.METHOD.POST == methodToUse)
|| (streams != null && streams.size() > 1)) && !hasNullStreamName;
*/
final boolean isMultipart = this.useMultiPartPost &&
SolrRequest.METHOD.POST == methodToUse &&
(streams != null && streams.size() >= 1);
System.out.println("isMultipart = "+isMultipart);
{code}
The problem is that when multipart post is used for document delete requests,
they fail because the stream is empty. And the code above doesn't distinguish
between UpdateRequests that include real documents and UpdateRequests that are
delete requests. Any ideas?
> Structural changes in SolrJ since version 7.0.0 have effectively disabled
> multipart post
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-12798
> URL: https://issues.apache.org/jira/browse/SOLR-12798
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Affects Versions: 7.4
> Reporter: Karl Wright
> Priority: Major
>
> Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from
> SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to
> SolrJ's HttpSolrClient class that seemingly disable any use of multipart
> post. This is critical because ManifoldCF's documents often contain metadata
> in excess of 4K that therefore cannot be stuffed into a URL.
> The changes in question seem to have been performed by Paul Noble on
> 10/31/2017, with the introduction of the RequestWriter mechanism. Basically,
> if a request has a RequestWriter, it is used exclusively to write the
> request, and that overrides the stream mechanism completely. I haven't
> chased it back to a specific ticket.
> ManifoldCF's usage of SolrJ involves the creation of
> ContentStreamUpdateRequests for all posts meant for Solr Cell, and the
> creation of UpdateRequests for posts not meant for Solr Cell (as well as for
> delete and commit requests). For our release cycle that is taking place
> right now, we're shipping a modified version of HttpSolrClient that ignores
> the RequestWriter when dealing with ContentStreamUpdateRequests. We
> apparently cannot use multipart for all requests because on the Solr side we
> get "pfountz Should not get here!" errors on the Solr side when we do, which
> generate HTTP error code 500 responses. That should not happen either, in my
> opinion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
