hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Date Fri, 23 May 2014 12:38:49 GMT
>>>>>>
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.
<<<<<<

Your preferred option is fine with me, and would make things more backwards
compatible.  But I thought you wanted to get away from supported deprecated
code. ;-)

Karl


On Fri, May 23, 2014 at 8:25 AM, Oleg Kalnichevski <olegk@apache.org> wrote:

> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message