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

Re: [tor-bugs] #14071 [metrics-lib]: BlockingIteratorImpl.hasNext waits forever

#14071: BlockingIteratorImpl.hasNext waits forever
-----------------------------+----------------------
     Reporter:  iwakeh       |      Owner:  karsten
         Type:  defect       |     Status:  accepted
     Priority:  blocker      |  Milestone:
    Component:  metrics-lib  |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------

Comment (by iwakeh):

 **Analysis**

 From reading the source I concluded that the above situation is going to
 happen
 when the thread running 'DescriptorReaderRunnable' (in
 DescriptorReaderImpl.java)
 is terminated before [https://gitweb.torproject.org/metrics-
 lib.git/tree/src/org/torproject/descriptor/impl/DescriptorReaderImpl.java#n157
 this.descriptorQueue.setOutOfDescriptors();]
 inside the [https://gitweb.torproject.org/metrics-
 lib.git/tree/src/org/torproject/descriptor/impl/DescriptorReaderImpl.java#n152
 run method].

 The methods called from run() contain unhandled exceptions and any other
 odd RuntimeException
 could just terminate this thread prematurely.
 If this happens before the call to 'setOutOfDescriptors()' the while-loop
 in BlockingIteratorIml.hasNext() won't ever exit.

 **Possible remedies**

 Maybe, surround the contents of [https://gitweb.torproject.org/metrics-
 lib.git/tree/src/org/torproject/descriptor/impl/DescriptorReaderImpl.java#n152
 run method] with try-catch for all throwables or have a catch-clause for
 each line in run() in order to handle errors differently?
 What do you think? Should the application exit? Or only
 'this.descriptorQueue.setOutOfDescriptors()' be called?
 Logging would be very important too, but metrics-lib does not use slf4j
 yet and its introduction would take a while, afaik?



 In the long run an event mechanism and using java.concurrent might be a
 good replacement.
 With the customizable factory classes (I think this was #12868) it would
 be easy to have two versions of metrics-lib available.
 So, a new approach would not be risky for the other projects depending on
 metrics-lib.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14071#comment:4>
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