: DirectXmlRequest is part of the SolrJ library, so I guess that means it
: is not commonly used. My use case is that I'm applying an XSLT to the
: raw XML on the client side, instead of leaving that up to the Solr
: master (although even if I applied the XSLT on the Solr server, I'd
I think Otis's point was that most people don't have Solr XML files lying
arround that they send to Solr, nor do they build up XML strings in Java
in the Solr input format (with XSLT or otherwise) ... most people using
SolrJ build up SolrInputDocument objects and pass those to their
SolrServer instance.
: I've done some research and I'm fairly confident that apache
: commons-fileupload library is responsible for the temp files. There's
I believe you are correct ... searching for "solr fileupload temp files"
lead me to this issue which seems to have fallen by the way side...
https://issues.apache.org/jira/browse/SOLR-1953
...if you could try that patch outand/or post your comments it would be
helpful.
Something that seems really odd to me however is how/why your basic
updates are even causing multipart/file-upload functionality to be used
... a quick skim of the client code suggests that that should only happen
if your try to send multiple ContentStreams in a single request: I can
understand why that wouldn't typically happen for most users building up
multiple SolrInputDocuments (they would get added to a single stream); and
i can understand why that would typically happen for users sending
multiple binary files to something like ExtractingRequestHandler -- but if
you are using DirectXmlRequest in the way you described each xml file
should be sent as a single stream in a single request and the XML should
be sent in the raw POST body -- the commons-fileupload code shouldn't even
come into play. (either that, or i'm missing something, or you're using
an older version of solr that used fileupload even if there was only a
single content stream)
-Hoss
