WORK IN PROGRESS
Some of the well known quirks for the Sqoop2 integration test suite is documented here so that developers can be aware of what to expect when running
mvn clean integration-test
How does the integration test suite work?
// todo : Jarcec
What DB does integration tests use today for storing the Sqoop entities ?
By default it is embedded Derby
public class DerbyProvider extends DatabaseProvider { @Override public void start() { // Start embedded server try { port = NetworkUtils.findAvailablePort(); LOG.info("Will bind to port " + port); server = new NetworkServerControl(InetAddress.getByName("localhost"), port); server.start(new LoggerWriter(LOG, Level.INFO)); // Start won't thrown an exception in case that it fails to start, one // have to explicitly call ping() in order to verify if the server is // up. Check DERBY-1465 for more details. server.ping(); } catch (Exception e) { LOG.error("Can't start Derby network server", e); throw new RuntimeException("Can't derby server", e); } super.start(); }
NOTE: Even though there are other providers such as MySQLProvider and PostgreSQLProvider, they are not used in any of the tests.
What are the datasets we use in some of the integration tests ?
Anything that extends the following base class
public abstract class DataSet { ..}
Where to look for MR Job related logs in the integration tests?
Look under /test/target
under your source folder. Inside each of the MiniMRCluster_XXXX folders there will sub folders and logs.
/path/to/sqoop2/test/target/MiniMRCluster_96106422 MiniMRCluster_96106422-localDir-nm-0_0 MiniMRCluster_96106422-localDir-nm-0_2 MiniMRCluster_96106422-logDir-nm-0_0 MiniMRCluster_96106422-logDir-nm-0_2 MiniMRCluster_96106422-localDir-nm-0_1 MiniMRCluster_96106422-localDir-nm-0_3 MiniMRCluster_96106422-logDir-nm-0_1 MiniMRCluster_96106422-logDir-nm-0_3
What happens when integration tests are abruptly terminated due to CTRL + C or failures?
Please look for zombie java processes and kill them all before running the integration tests. Currently the cluster does not cleanly shutdown.
If zombie java exists, please kill them before starting integration tests next time, because these zombie java processes will hold the ports (such as 12000, 8080, 1527) and the following integration test could not obtain these ports. Then the following integration test will stuck.
ps -ef | grep java killall -9 java or more advanced.... for p in `ps aux | grep java | grep YarnChild| sed -re "s/<username> ([0-9]+) ./\1/"`; do echo $p; kill -9 $p; done
Some related tickets that is in place to fix some of these quirks
- SQOOP-1840 - DerbyProvider quirks,
- SQOOP-1844 -
- SQOOP-1832
- SQOOP-1831 - MR file names now logged