> On Jan. 21, 2014, 2:40 p.m., Eric Newton wrote:
> > src/server/src/main/java/org/apache/accumulo/server/trace/TraceServer.java, 
> > line 209
> > <https://reviews.apache.org/r/17129/diff/1/?file=432898#file432898line209>
> >
> >     Why duplicate the same code for two different exception types?
> >
> 
> Sean Busbey wrote:
>     I wanted to make sure we scope our catching minimally to just handle MRE 
> and Runtime, so that should the methods in the try{} later add additional 
> checked exceptions the compiler will let us know that this spot needs to be 
> examined.
>     
>     Once we can use Java 7 features this duplication can go away.

bump. Eric, does that seem reasonable or would you prefer I refactor to avoid 
duplication?


- Sean


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17129/#review32360
-----------------------------------------------------------


On Jan. 22, 2014, 8:17 p.m., Sean Busbey wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17129/
> -----------------------------------------------------------
> 
> (Updated Jan. 22, 2014, 8:17 p.m.)
> 
> 
> Review request for accumulo and Eric Newton.
> 
> 
> Bugs: ACCUMULO-2213
>     https://issues.apache.org/jira/browse/ACCUMULO-2213
> 
> 
> Repository: accumulo
> 
> 
> Description
> -------
> 
> ACCUMULO-2213 Make writer recovery in the Tracer more robust.
>     
>     * Cleans up writer reseting in the TraceServer, avoids overly broad 
> catching.
>     * tones down log levels in TraceServer to WARN because trace information 
> is transient and we retry everything.
> 
> 
> Diffs
> -----
> 
>   src/server/src/main/java/org/apache/accumulo/server/trace/TraceServer.java 
> 4d89e9c13f89e71e674875db32cf267e045d6131 
> 
> Diff: https://reviews.apache.org/r/17129/diff/
> 
> 
> Testing
> -------
> 
> running on cluster with injected failures now
> 
> 
> Thanks,
> 
> Sean Busbey
> 
>

Reply via email to