On Thu, 2014-05-22 at 18:16 -0400, Karl Wright wrote: > The resolution to this problem was simple -- after I audited both > HttpClient and SolrJ code. > > (0) Expect/continue handling, in the POST-case I was looking at, was in > fact *off*. It was disguised by the fact that the thread ID differed and I > did not note that in the log when I looked at it. > (1) In InternalHttpClient, if *any* configuration parameters are set, then > configuration parameters are used, and the RequestConfig is *thrown away*. > (2) In HttpSolrServer, randomly, it sets *one* configuration parameter, > namely one turning on redirection handling. This was actually in the code > I included in the ticket, and it was sufficient to completely throw away my > builder-created configuration. > (3) The solution was to create a modified version of HttpSolrServer and fix > the code so that it didn't do that. > > Any of the following would have been very helpful: > > (a) At least, output a log message when both parameters AND Config object > were present. > (b) Documentation (javadoc) making the implemented behavior clear. > (c) Ideally, if you set a parameter and you've already got a Config object, > an IllegalStateException should be thrown. > > This would have likely made it much quicker to diagnose than repeated > debugging sessions, via patched diagnostic jars, with clients half a world > away. Better to fail immediately than give the impression that things were > okay when they were not. Thoughts? >
HttpParams interface and related classes are deprecated, aren't they? I personally would not be in favor of throwing an IllegalStateException in case of conflicting configurations for the compatibility sake. My preference would be either to log a big, scary warning or investing some time into making HttpClientParamConfig capable merging old style and new style configurations, the latter being the preferred option. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
