Discussion:
Possible to change default value for staleConnectionCheckEnabled?
Christopher Schultz
2017-07-11 19:54:59 UTC
Permalink
All,

I have a conflict between two products that must operate in the same JVM and same ClassLoader. One product was based upon http-client 4.3 and another based upon 4.5. Nearly everything works (thanks for the great backward compatibility, folks!) except that the product relying upon 4.3 semantics is expecting the default value for staleConnectionCheckEnabled to be "true" while it is "false" in the latest versions.

Unfortunately, patching the code of the "older" product is very ... challenging.

Is there a system property or anything like that I can use to change this default? Maybe a static setDefaultStateConnectionCheckEnabled(boolean) method? I realize that the whole staleConnectionCheckEnabled setting is deprecated, but having changed the default value for it is causing me some backward-compatibility headaches.

Thanks,
-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Gary Gregory
2017-07-11 22:43:46 UTC
Permalink
Hi Chris,

Have you tried
resetting org.apache.http.client.config.RequestConfig.DEFAULT?

Gary
Post by Christopher Schultz
All,
I have a conflict between two products that must operate in the same JVM
and same ClassLoader. One product was based upon http-client 4.3 and
another based upon 4.5. Nearly everything works (thanks for the great
backward compatibility, folks!) except that the product relying upon 4.3
semantics is expecting the default value for staleConnectionCheckEnabled to
be "true" while it is "false" in the latest versions.
Unfortunately, patching the code of the "older" product is very ... challenging.
Is there a system property or anything like that I can use to change this
default? Maybe a static setDefaultStateConnectionCheckEnabled(boolean)
method? I realize that the whole staleConnectionCheckEnabled setting is
deprecated, but having changed the default value for it is causing me some
backward-compatibility headaches.
Thanks,
-chris
---------------------------------------------------------------------
Christopher Schultz
2017-07-12 16:05:51 UTC
Permalink
Gary,

Nope. That field is 100% undocumented (https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/config/RequestConfig.html#DEFAULT) so messing-around with it seems like a bad idea.

What do you suggest, specifically? It's a static final field, but I don't believe we are running under a SecurityManager, so I could probably use reflection to blast-away the value with one of my choosing.

I haven't looked at the code... is the DEFAULT object cloned (at least semantically) whenever a new RequestConfig object is built to act as the default values for everything?

Thanks,
-chris
Post by Gary Gregory
Hi Chris,
Have you tried
resetting org.apache.http.client.config.RequestConfig.DEFAULT?
Gary
Post by Christopher Schultz
All,
I have a conflict between two products that must operate in the same JVM
and same ClassLoader. One product was based upon http-client 4.3 and
another based upon 4.5. Nearly everything works (thanks for the great
backward compatibility, folks!) except that the product relying upon 4.3
semantics is expecting the default value for staleConnectionCheckEnabled to
be "true" while it is "false" in the latest versions.
Unfortunately, patching the code of the "older" product is very ... challenging.
Is there a system property or anything like that I can use to change this
default? Maybe a static setDefaultStateConnectionCheckEnabled(boolean)
method? I realize that the whole staleConnectionCheckEnabled setting is
deprecated, but having changed the default value for it is causing me some
backward-compatibility headaches.
Thanks,
-chris
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Christopher Schultz
2017-07-12 16:17:05 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Gary,
Post by Christopher Schultz
Gary,
Nope. That field is 100% undocumented
(https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org
/apache/http/client/config/RequestConfig.html#DEFAULT)
Post by Christopher Schultz
so messing-around with it seems like a bad idea.
What do you suggest, specifically? It's a static final field, but I
don't believe we are running under a SecurityManager, so I could
probably use reflection to blast-away the value with one of my
choosing.
I haven't looked at the code... is the DEFAULT object cloned (at
least semantically) whenever a new RequestConfig object is built to
act as the default values for everything?
Looks like not. I don't see that RequestConfig.DEFAULT is useful in
any way, unless client code decides to use it for some reason.

- -chris
Post by Christopher Schultz
Post by Gary Gregory
Hi Chris,
Have you tried resetting
org.apache.http.client.config.RequestConfig.DEFAULT?
Gary
On Tue, Jul 11, 2017 at 12:54 PM, Christopher Schultz
Post by Christopher Schultz
All,
I have a conflict between two products that must operate in the
same JVM and same ClassLoader. One product was based upon
http-client 4.3 and another based upon 4.5. Nearly everything
works (thanks for the great backward compatibility, folks!)
except that the product relying upon 4.3 semantics is expecting
the default value for staleConnectionCheckEnabled to be "true"
while it is "false" in the latest versions.
Unfortunately, patching the code of the "older" product is very ... challenging.
Is there a system property or anything like that I can use to
change this default? Maybe a static
setDefaultStateConnectionCheckEnabled(boolean) method? I
realize that the whole staleConnectionCheckEnabled setting is
deprecated, but having changed the default value for it is
causing me some backward-compatibility headaches.
Thanks, -chris
--------------------------------------------------------------------
- -
Post by Christopher Schultz
---------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZZkuBAAoJEBzwKT+lPKRY0kYP/1KbhqPL4yIDXOw0foMU/4sW
ExOWv1hpNPnxfren7Q8e9omgrXs8t0cF0TZpPyYdpgGFQy9tskjd0fdF+60sVLW1
jyEUDm5dXYnt1riYYgLqL1p//gx8IEw6EBDpB06hrom8KDJ3S4MwTYuIqUAJym34
va07thcF881KiyIkamghhaaFQms02lMpjeZD+/4RbFM3tArAQpJ2jClxh0j0YSqr
BwXJbQT67WCAZcaFLaykzwdFax83D3BDZ2RqGKiN/W9JuKoMJ1CWsXI62QKc4Rsn
TEUL0Pq9hZ7IUgTqyxJlxB3/2F/kI2YQ9SGT1M+/p79bXbXj28q43Dp3s1AIWxpJ
kqPlYT0+jI21csvGdybGedIX5bIDwwwbFLFeeC0TbAWc19eP0ZhqonXQ3e41xlo7
9vn7j6Rm9C46YRq1pMp8GyQ0hjRMXGMxvkcUOc1qK1hWQUF6T7ZYBH7DxJf3a3BU
Ce6QvSzxn9TR7k9k3ssrftqaSs6TKq45Tjiwcy6WNkL5hyw4hsqJPVHiLIHbFyb+
u4+LriKKTBJfsC1PSJgW4KsBX1jr8vUaqh3yIdcgiJ17ap+xC5vghQtHLf1RsRp1
3nDqoADYGUZcaH9aw0WKGhkEfGud4XcgCvtj8BhVMVt08/6E3zXetZqarfpsTjyx
BG2b1p82K3AVXEF1iPex
=6R3m
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Christopher Schultz
2017-07-12 16:57:27 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Gary,
Post by Christopher Schultz
Gary,
Post by Christopher Schultz
Gary,
Nope. That field is 100% undocumented
(https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/or
g
/apache/http/client/config/RequestConfig.html#DEFAULT)
Post by Christopher Schultz
Post by Christopher Schultz
so messing-around with it seems like a bad idea.
What do you suggest, specifically? It's a static final field, but
I don't believe we are running under a SecurityManager, so I
could probably use reflection to blast-away the value with one of
my choosing.
I haven't looked at the code... is the DEFAULT object cloned (at
least semantically) whenever a new RequestConfig object is built
to act as the default values for everything?
Looks like not. I don't see that RequestConfig.DEFAULT is useful
in any way, unless client code decides to use it for some reason.
The client code in question looks like this:

===
PoolingHttpClientConnectionManager httpClientConnectionManager
= new PoolingHttpClientConnectionManager(socketFactoryRegistry);

httpClientConnectionManager.setDefaultMaxPerRoute(5);


httpClientConnectionManager.setDefaultSocketConfig(SocketConfig.custom()
.setSoTimeout(timeout).build());



client =
HttpClients.custom().setConnectionManager(httpClientConnectionManager).b
uild();

requestConfig =
RequestConfig.custom().setConnectTimeout(CONNECT_TIMEOUT).setConnectionR
equestTimeout(CONNECT_TIMEOUT).setSocketTimeout(timeout).build();
===

I'm not sure there is a way to do this other than with some really
ugly reflection from outside code.

Any suggestions?

Thanks,
- -chris
Post by Christopher Schultz
Post by Christopher Schultz
On 2017-07-11 18:43 (-0400), Gary Gregory
Post by Gary Gregory
Hi Chris,
Have you tried resetting
org.apache.http.client.config.RequestConfig.DEFAULT?
Gary
On Tue, Jul 11, 2017 at 12:54 PM, Christopher Schultz
Post by Christopher Schultz
All,
I have a conflict between two products that must operate in
the same JVM and same ClassLoader. One product was based
upon http-client 4.3 and another based upon 4.5. Nearly
everything works (thanks for the great backward
compatibility, folks!) except that the product relying upon
4.3 semantics is expecting the default value for
staleConnectionCheckEnabled to be "true" while it is "false"
in the latest versions.
Unfortunately, patching the code of the "older" product is
very ... challenging.
Is there a system property or anything like that I can use
to change this default? Maybe a static
setDefaultStateConnectionCheckEnabled(boolean) method? I
realize that the whole staleConnectionCheckEnabled setting is
deprecated, but having changed the default value for it is
causing me some backward-compatibility headaches.
Thanks, -chris
-------------------------------------------------------------------
- -
- -
Post by Christopher Schultz
Post by Christopher Schultz
---------------------------------------------------------------------
---------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZZlT3AAoJEBzwKT+lPKRYehMP+gPqxIMnSrTEMTYg99Dk2yb6
myRvi97sW6648hlzRgRO7VvIHKGoK4ggPn3TRcwCuczyS3Ik/FMXmoGhdYgutnIT
41krI3zE2ZTTp+N4IMgQW6c5MHkALXw91Dd95cSAHAJEEsISSSNwSkhmylgtc4SI
ITRW8wAmqXRMUT+OZ28WIEzRsgnRcFhfnbSPAsQGbYaxJKk2ZWNenoNHCLJbtq47
JOzOJs4RsuZHk7n0CbOo5D3lUbo+FywYIvQRUD9zSN1k+Kjw4pyzodTjFoMDuIrI
I3U4VwF+jYFonua/Wh+GBaXWewVV1aBXoXSGmZJdlaXqwGwx6R0h5/b6Y/hGg+To
ahtMMcg2c+1A1S3+lZnrNVcbEGC2L6Izfnz2UBVQrG5tYUDT7nMwfIZnjNi2WPtA
pmKST+owTeI0ETwLGLV8h6TFcAz8F40H5TmV+7nlbRGT8TkwVNzTWXy0yQnYB+Ey
qkNIsjWA2OMiZv7eIr/5JN61c4RNqbDx9Br2oLZPrx4zLHLNiIxFCDi8M7Ba9gwB
NMHz1c0SSx+5PIouWnDuEsTMJ4aAHOyKJku9LKUrQgD6IG2lT5YiMt7wQLVCF0/c
kkLpMKGevrndym/RlcfzuR5uMlj8I7dxmiRmQOWV22oQLASOc4WtKZzb90pu6rtb
gE/0ir+y89BoI10ZG1oc
=/Ygm
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Gary Gregory
2017-07-13 02:33:27 UTC
Permalink
Post by Christopher Schultz
Gary,
Nope. That field is 100% undocumented (https://hc.apache.org/
httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/config/
RequestConfig.html#DEFAULT) so messing-around with it seems like a bad
idea.
What do you suggest, specifically? It's a static final field, but I don't
believe we are running under a SecurityManager, so I could probably use
reflection to blast-away the value with one of my choosing.\
Ah, crud, I thought the field was mutable. Let's do a What-if: What if that
field was mutable (and documented), would that solve your problem? You
could try... ;-)

Gary
Post by Christopher Schultz
I haven't looked at the code... is the DEFAULT object cloned (at least
semantically) whenever a new RequestConfig object is built to act as the
default values for everything?
Thanks,
-chris
Post by Gary Gregory
Hi Chris,
Have you tried
resetting org.apache.http.client.config.RequestConfig.DEFAULT?
Gary
On Tue, Jul 11, 2017 at 12:54 PM, Christopher Schultz <
Post by Christopher Schultz
All,
I have a conflict between two products that must operate in the same
JVM
Post by Gary Gregory
Post by Christopher Schultz
and same ClassLoader. One product was based upon http-client 4.3 and
another based upon 4.5. Nearly everything works (thanks for the great
backward compatibility, folks!) except that the product relying upon
4.3
Post by Gary Gregory
Post by Christopher Schultz
semantics is expecting the default value for
staleConnectionCheckEnabled to
Post by Gary Gregory
Post by Christopher Schultz
be "true" while it is "false" in the latest versions.
Unfortunately, patching the code of the "older" product is very ... challenging.
Is there a system property or anything like that I can use to change
this
Post by Gary Gregory
Post by Christopher Schultz
default? Maybe a static setDefaultStateConnectionCheckEnabled(boolean)
method? I realize that the whole staleConnectionCheckEnabled setting is
deprecated, but having changed the default value for it is causing me
some
Post by Gary Gregory
Post by Christopher Schultz
backward-compatibility headaches.
Thanks,
-chris
---------------------------------------------------------------------
---------------------------------------------------------------------
Christopher Schultz
2017-07-13 15:52:19 UTC
Permalink
Gary,
Post by Gary Gregory
Post by Christopher Schultz
Gary,
Nope. That field is 100% undocumented (https://hc.apache.org/
httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/config/
RequestConfig.html#DEFAULT) so messing-around with it seems like a bad
idea.
What do you suggest, specifically? It's a static final field, but I don't
believe we are running under a SecurityManager, so I could probably use
reflection to blast-away the value with one of my choosing.\
Ah, crud, I thought the field was mutable. Let's do a What-if: What if that
field was mutable (and documented), would that solve your problem? You
could try... ;-)
I can definitely try. I don't actually mind using reflection to bash my
way in, either (this is a fairly desperate situation for me), but
changing the field still looks like it's not going to have any effect...
unless I'm reading the code incorrectly, the DEFAULT member is
completely ignored by the rest of the code in the class.

Thanks,
-chris
Post by Gary Gregory
Post by Christopher Schultz
I haven't looked at the code... is the DEFAULT object cloned (at least
semantically) whenever a new RequestConfig object is built to act as the
default values for everything?
Thanks,
-chris
Post by Gary Gregory
Hi Chris,
Have you tried
resetting org.apache.http.client.config.RequestConfig.DEFAULT?
Gary
On Tue, Jul 11, 2017 at 12:54 PM, Christopher Schultz <
Post by Christopher Schultz
All,
I have a conflict between two products that must operate in the same
JVM
Post by Gary Gregory
Post by Christopher Schultz
and same ClassLoader. One product was based upon http-client 4.3 and
another based upon 4.5. Nearly everything works (thanks for the great
backward compatibility, folks!) except that the product relying upon
4.3
Post by Gary Gregory
Post by Christopher Schultz
semantics is expecting the default value for
staleConnectionCheckEnabled to
Post by Gary Gregory
Post by Christopher Schultz
be "true" while it is "false" in the latest versions.
Unfortunately, patching the code of the "older" product is very ... challenging.
Is there a system property or anything like that I can use to change
this
Post by Gary Gregory
Post by Christopher Schultz
default? Maybe a static setDefaultStateConnectionCheckEnabled(boolean)
method? I realize that the whole staleConnectionCheckEnabled setting is
deprecated, but having changed the default value for it is causing me
some
Post by Gary Gregory
Post by Christopher Schultz
backward-compatibility headaches.
Thanks,
-chris
---------------------------------------------------------------------
---------------------------------------------------------------------
Loading...