You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (Updated) (JIRA)" <ji...@apache.org> on 2011/10/20 17:11:10 UTC
[jira] [Updated] (DERBY-5406) Intermittent failures in
CompressTableTest and TruncateTableTest
[ https://issues.apache.org/jira/browse/DERBY-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-5406:
--------------------------------------
Attachment: d5406-2a-invalidate-self.diff
Attaching patch 2a which makes FromBaseTable.bindNonVTITables() invalidate the statement itself when it discovers that the conglomerate has disappeared. That way, if the conglomerate was dropped between buildTableDescriptor() and createDependency() so that the original invalidation was lost, we'll still invalidate the statement and make GenericPreparedStatement.executeStmt() detect that a recompilation is needed.
I've run four parallel instances of the D4275 test case for 1.5 hours without seeing any instances of stack trace (2) mentioned in an earlier comment. That stack trace usually reproduces in 2 to 5 minutes on the same machine without the patch.
A very similar stack trace was seen three times in those 1.5 hours. That exception was thrown at the exact same place in FromBaseTable, but the re-compilation had been started at a lower level, from GenericActivationHolder, instead of directly from GenericPreparedStatement.executeStmt().
I think the reason why it still fails if the compilation was started at a lower level, is that the self-invalidation introduced by this patch is ignored because it happens while the statement is being compiled. This was the exact same problem as the one addressed by the 1b patch. However, the 1b patch only added logic to retry compilations started directly from GenericPreparedStatement.executeStmt(). So it looks like the retry logic from 1b must be enhanced to cover more cases.
But, in any case, I think the 2a patch is an improvement on its own. It makes the failures happen less frequently, and I haven't noticed any new failures because of it.
The full regression test suite is currently running. I plan to commit the patch if all the tests pass, and then I'll go on trying to fix the retry logic for the cases that are still missed out.
> Intermittent failures in CompressTableTest and TruncateTableTest
> ----------------------------------------------------------------
>
> Key: DERBY-5406
> URL: https://issues.apache.org/jira/browse/DERBY-5406
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.8.2.0, 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: d5406-1a-detect-invalidation-during-compilation.diff, d5406-1b.diff, d5406-2a-invalidate-self.diff
>
>
> The test cases CompressTableTest.testConcurrentInvalidation() and TruncateTableTest.testConcurrentInvalidation() fail intermittently with errors such as:
> ERROR XSAI2: The conglomerate (2,720) requested does not exist.
> The problem has been analyzed in the comments on DERBY-4275, and a patch attached to that issue (invalidation-during-compilation.diff) fixes the underlying race condition. However, that patch only works correctly together with the fix for DERBY-5161, which was backed out because it caused the regression DERBY-5280.
> We will therefore need to find a way to fix DERBY-5161 without reintroducing DERBY-5280 in order to resolve this issue.
--
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