[
https://issues.apache.org/jira/browse/CONNECTORS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258111#comment-13258111
]
Karl Wright commented on CONNECTORS-347:
----------------------------------------
I was able to catch it again and do a database postmortem. Here's how the
involved tables appear:
{code}
mysql> select dochash,docid from jobqueue;
+------------------------------------------+------------------------------------------------------------------------+
| dochash | docid
|
+------------------------------------------+------------------------------------------------------------------------+
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test1.txt |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\test2.txt |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
C:\wip\mcf\trunk\tests\filesystem\test-mysql-output\testdata\testdir |
+------------------------------------------+------------------------------------------------------------------------+
4 rows in set (0.00 sec)
mysql> select parentidhash,childidhash from intrinsiclink;
+------------------------------------------+------------------------------------------+
| parentidhash | childidhash |
+------------------------------------------+------------------------------------------+
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| 1D9DB3181447F82677FB9AB91C56F33B1A2C75B0 |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 | |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
| B622AAB99E7BFF749E2C93E01009C3E02F90693C |
1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 |
5432CFFCE5729BF1F3E695FFCF83B08E415694C6 |
+------------------------------------------+------------------------------------------+
6 rows in set (0.00 sec)
mysql> select parentidhash,distance from hopcount;
+------------------------------------------+----------+
| parentidhash | distance |
+------------------------------------------+----------+
| 5432CFFCE5729BF1F3E695FFCF83B08E415694C6 | 0 |
| 9F6F59234CC36DF341184FAEC934BEEE516E1E60 | 1 |
| CD31925B98C4B481F6523030A1C7C9D9DF0CC080 | 1 |
| 1B26DBA4653B26B3151433EBB4C1CDCB8358C1F2 | 1 |
+------------------------------------------+----------+
4 rows in set (0.00 sec)
{code}
While the jobqueue and hopcount tables are self-consistent, the intrinsiclink
table is pretty broken here. There are rows that should not even be there.
I'll need to compare against a run on postgresql to establish whether this is a
bug in the code we've just missed, or is particular to mysql somehow.
> MySQL HopCount test sometimes fails
> -----------------------------------
>
> Key: CONNECTORS-347
> URL: https://issues.apache.org/jira/browse/CONNECTORS-347
> Project: ManifoldCF
> Issue Type: Bug
> Components: Framework core
> Affects Versions: ManifoldCF 0.5, ManifoldCF 0.6
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 0.6
>
>
> The HopcountMySQLIT test sometimes fails complaining that it is expecting to
> see 6 documents but only sees 4.
> {code}
> [junit] org.apache.manifoldcf.core.interfaces.ManifoldCFException: Wrong
> number of documents processed - expected 6, saw 4
> [junit] at
> org.apache.manifoldcf.filesystem_tests.HopcountMySQLIT.hopcountCheck(HopcountMySQLIT.java:152)
> {code}
> This does not happen on every run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
