: 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