#24290: Configure timeout for metrics-lib client, e.g., those using DescriptorIndexCollector ---------------------+------------------------------ Reporter: karsten | Owner: iwakeh Type: defect | Status: needs_review Priority: High | Milestone: Component: Metrics | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: ---------------------+------------------------------ Changes (by iwakeh):
* status: accepted => needs_review * component: Metrics/Library => Metrics Comment: Moving this to component Metrics because all metrics-lib clients are concerned. I could reproduce the exact thread stack trace above. The waiting there would indeed be stopped using a read timeout. Apparently, there is some connect timeout in place already (probably in the socket implementation) as can be viewed in CollecTor2's logs: {{{ WARN o.t.d.i.DescriptorIndexCollector:77 Cannot fetch index file https://collector.torproject.org/index/index.json and hence cannot determine which remote files to fetch. Aborting descriptor collection. java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:673) at sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:173) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:463) ... sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263) at java.net.URL.openStream(URL.java:1045) at org.torproject.descriptor.index.IndexNode.fetchIndex(IndexNode.java:101) at org.torproject.descriptor.index.DescriptorIndexCollector.collectDescriptors(DescriptorIndexCollector.java:74) at org.torproject.collector.sync.SyncManager.collectFromOtherInstances(SyncManager.java:59) at org.torproject.collector.sync.SyncManager.merge(SyncManager.java:43) at org.torproject.collector.cron.CollecTorMain.run(CollecTorMain.java:76) ... at java.lang.Thread.run(Thread.java:748) }}} Today I've noticed similar traces in the Onionoo logs. So in general, this is a java configuration not an implementation issue. The timeouts should not be hard-coded as the need for shorter or longer settings depends on the environment. As remedy two jvm properties need to be set {{{ -Dsun.net.client.defaultConnectTimeout=5000 -Dsun.net.client.defaultReadTimeout=5000 }}} The read timeout fixes the problem reported in the description. Setting the connect timeout, too, in order to be consistent. Five seconds should be ok? (Slightly related: For the ftp implementation the timeout got changed from infinite to five minutes in [http://www.oracle.com/technetwork/java/javase/8u151-relnotes-3850493.html JDK 8u151].) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24290#comment:5> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs