> On May 10, 2015, 10:42 p.m., Jacques Nadeau wrote: > > As I mentioned on JIRA, we should be ensuring that we consume all messages > > from the socket. Why would we need to disable throttling?
(See JIRA for additional explanation:) It's stopping thottling (resuming unlimited sending, not entirely disabling the feature of throttling) and that is specifically to make sure the client consumes all the messages. - Daniel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34026/#review83193 ----------------------------------------------------------- On May 10, 2015, 10:29 p.m., Daniel Barclay wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34026/ > ----------------------------------------------------------- > > (Updated May 10, 2015, 10:29 p.m.) > > > Review request for drill, Mehant Baid and Parth Chandra. > > > Bugs: DRILL-2993 > https://issues.apache.org/jira/browse/DRILL-2993 > > > Repository: drill-git > > > Description > ------- > > Added unthrottling in close(). > Cleaned up throttling logic code: > - Applied AtomicBoolean to eliminate race conditions. > - Extracted methods for starting/stopping throttling. > > Made small edits to some message: > - Fixed missed, inconsistent ResultsListener log messages. > - Clarified exception message. > > > Diffs > ----- > > exec/jdbc/src/main/java/org/apache/drill/jdbc/impl/DrillResultSetImpl.java > 8ef2af3 > > Diff: https://reviews.apache.org/r/34026/diff/ > > > Testing > ------- > > Manually confirmed unthrottling upon cancelation and delivery of messages > (via log message) and confirmed lack of previous hanging behavior on > subsequence queries. > > Ran regular tests; no new errors. > > > Thanks, > > Daniel Barclay > >
