----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49192/#review139576 -----------------------------------------------------------
Hi Szabi, I like you solution (both of that you directly close the connection after the job is finished with the metadata collection [not having this being in a hanging open stage until the end of the whole MR job, and the fact you're passing a dedicated connection to the record reader [not the "cached" one]). However would you please cover you're implementation with unit tests? I think something like: Passing a mock connection instance and verify it's closed. Verify if the record reader closes the passed connection. Verify no other connections created (if it's possible). Any further use cases you'd like to cover. Thanks Attila - Attila Szabo On June 24, 2016, 11:46 a.m., Szabolcs Vasas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49192/ > ----------------------------------------------------------- > > (Updated June 24, 2016, 11:46 a.m.) > > > Review request for Sqoop. > > > Bugs: SQOOP-2971 > https://issues.apache.org/jira/browse/SQOOP-2971 > > > Repository: sqoop-trunk > > > Description > ------- > > Connections are now closed properly in OraOopDataDrivenDBInputFormat class. > > > Diffs > ----- > > src/java/org/apache/sqoop/manager/oracle/OraOopDataDrivenDBInputFormat.java > 13f05d5 > src/java/org/apache/sqoop/mapreduce/db/DBInputFormat.java 3a8e5d0 > > Diff: https://reviews.apache.org/r/49192/diff/ > > > Testing > ------- > > We have started an import job on a cluster with a patched Sqoop version and > we have verified that 1 map task now uses only 1 Oracle connection. > > > Thanks, > > Szabolcs Vasas > >
