[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584103#comment-14584103
]
Hrishikesh Gadre commented on SOLR-7344:
----------------------------------------
I am running into a problem while writing a Solr specific policy using the
above mentioned framework. I am trying to use the request parameters for
identifying request types e.g.
- presence of update.distrib parameter identifies internal_indexing request
- presence of isShard parameter identifies internal_querying request
- Absence of both these parameter identifies external request
It looks like for POST requests, these parameters are passed via the request
body. The HttpServletRequest implementation reads the InputStream when we
invoke method to retrieve these parameters. But the side effect of this
invocation is that this information is not available to downstream filter chain
(SolrDispatchFilter in our case) and it breaks the Solr functionality. Here is
a relevant discussion thread on the internet,
http://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once
Is there any other reliable way to identify the request types (e.g. by
interpreting the URL path)? The workaround suggested for this requires copying
the InputStream into a byte array (in memory). I don't quite know if this is a
good idea for Solr.
Any suggestions/comments are welcome!
> Use two thread pools, one for internal requests and one for external, to
> avoid distributed deadlock and decrease the number of threads that need to be
> created.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Mark Miller
> Attachments: SOLR-7344.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
