On 9/4/2015 12:36 PM, Oleg Kalnichevski wrote:
> There is nothing wrong with your code. Feel free to run it outside
> Solr without any extra dependencies to make sure it works as intended.
> I _strongly_ suspect there is an older version of HttpClient /
> HttpCore on your classpath.
I'm willing to believe almost anything the evidence supports at this
point, but I haven't seen anything to support that theory.
I will try to come up with a test program using HttpClient only that
calls one of our optimize URLs to see whether I get the same timeout.
If it works as expected, I will take this problem to the Solr list.
The classpath calculation is simple. Here's the "env.sh" that my start
script sources to set the classpath:
root@bigindy5:/opt/sparkbuild# cat env.sh
#!/bin/sh
for i in \
-Xms4M \
-Xmx1024M \
-XX:+UseG1GC \
-XX:+ParallelRefProcEnabled \
-XX:G1HeapRegionSize=8m \
-XX:MaxGCPauseMillis=200 \
-XX:+UseLargePages \
-XX:+AggressiveOpts \
# -Dcom.sun.management.jmxremote \
# -Dcom.sun.management.jmxremote.port=3001 \
# -Dcom.sun.management.jmxremote.ssl=false \
# -Dcom.sun.management.jmxremote.authenticate=false \
do
OPTS="${OPTS} $i"
done
export OPTS
CLASSPATH="bin:resources"
for i in lib/*.jar
do
CLASSPATH=${CLASSPATH}:${i}
done
export CLASSPATH
At the following URL is the entire "lsof" output for the running copy of
my program. I only see one location for the HC jars. They do show up
twice, but it's the same location each time. The only change I made in
this output was to redact our domain name from the TCP entries. Solr is
listening on 8982, which explains the connections to that port in
CLOSE_WAIT.
http://apaste.info/38Z
Separate from my apparent inability to get a socket timeout set, but
possibly related, I'm somewhat mystified by the fact that I get a socket
timeout exception after 30 seconds when typical Java and Linux defaults
are no socket timeout and the DEBUG entries from httpclient are saying
that the connection can be kept alive indefinitely. I haven't changed
any timeout settings in the Ubuntu OS, so unless Ubuntu sets a default
socket timeout, I don't know where this is coming from. The same thing
happens on the production servers running CentOS 6, and I have not set
any OS-level timeouts there either.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
