db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5406) Intermittent failures in CompressTableTest and TruncateTableTest
Date Thu, 20 Oct 2011 15:11:10 GMT

     [ 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:,
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: d5406-1a-detect-invalidation-during-compilation.diff, d5406-1b.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


View raw message