[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #24290 [Metrics]: Configure timeout for metrics-lib client, e.g., those using DescriptorIndexCollector (was: Use timeout for fetching remote index.json in DescriptorIndexCollector)

#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs