[
https://issues.apache.org/jira/browse/SQOOP-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226743#comment-14226743
]
Sqoop QA bot commented on SQOOP-1816:
-------------------------------------
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12683898/SQOOP-1816.patch
against branch sqoop2.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} Clean was successful
{color:green}SUCCESS:{color} Patch applied correctly
{color:green}SUCCESS:{color} Patch add/modify test case
{color:green}SUCCESS:{color} Patch compiled
{color:green}SUCCESS:{color} All tests passed
Console output: https://builds.apache.org/job/PreCommit-SQOOP-Build/675/console
This message is automatically generated.
> Sqoop2: Add logging to the test DerbyProvider implementation
> ------------------------------------------------------------
>
> Key: SQOOP-1816
> URL: https://issues.apache.org/jira/browse/SQOOP-1816
> Project: Sqoop
> Issue Type: Bug
> Affects Versions: 1.99.4
> Reporter: Jarek Jarcec Cecho
> Assignee: Jarek Jarcec Cecho
> Fix For: 1.99.5
>
> Attachments: SQOOP-1816.patch
>
>
> I was recently investigating why integration tests are in infinite loop on my
> machine. I've seen only a lot of repeating messages from HDFS mini cluster
> talking about heartbeats and nothing else was happening. I originally though
> that something is going on in the Hadoop minicluster.
> Looking closer at {{jstack}} dump I've noticed that the main thread is stuck
> in
> {{[DriverManager.getConnection()|https://github.com/apache/sqoop/blob/sqoop2/common-test/src/main/java/org/apache/sqoop/common/test/db/DatabaseProvider.java#L131]}},
> waiting on opening connection to testing Derby database. The Derby should
> have been [already
> started|https://github.com/apache/sqoop/blob/sqoop2/common-test/src/main/java/org/apache/sqoop/common/test/db/DerbyProvider.java#L39]
> at that point in execution, so the wait shouldn't be there. Sadly there
> weren't any logs from Derby, so It was hard to figure out what is happening.
> I've eventually triaged the issue to port 1527 being sort of used and hence
> Derby wasn't able to start properly on that port. This seems as expected
> behavior that is covered by DERBY-1465 - unsuccessful Derby start won't
> thrown an exception as anticipated, one needs to explicitly call method
> {{ping()}} to verify that the server is indeed up and running.
> Triaging this issue would be much simpler if we would be logging Derby output
> as I would get the exception that derby server can't start in the logs. Hence
> I would like to suggest to add that. It would be also helpful to explicitly
> call the {{ping()}} method to die fast rather then end up in infinite loop.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
