tephra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TEPHRA-240) TransactionConflictException should contain the conflicting key and client id
Date Tue, 12 Sep 2017 23:15:00 GMT

    [ https://issues.apache.org/jira/browse/TEPHRA-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16163826#comment-16163826

ASF GitHub Bot commented on TEPHRA-240:

Github user anew commented on a diff in the pull request:

    --- Diff: tephra-core/src/main/java/org/apache/tephra/TransactionManager.java ---
    @@ -206,12 +210,19 @@ public TransactionManager(Configuration conf, @Nonnull TransactionStateStorage
         // TODO: REMOVE WITH txnBackwardsCompatCheck()
         longTimeoutTolerance = conf.getLong("data.tx.long.timeout.tolerance", 10000);
    -    //
    +    ClientIdRetention retention = ClientIdRetention.valueOf(
    --- End diff --
    Hmmm. We don't do that for the other configurations... if any of the numeric properties
cannot be parsed as a number, it also fails. I think it is a good idea to fail on invalid
configuration, because if there is a configuration that is present, then that is most likely
with the intention to change the default. If there is a typo or some other error, and we only
log a warning, that warning is likely to go unnoticed and the system will behave in a way
that was intended, and that will go undetected until it causes failures. 

> TransactionConflictException should contain the conflicting key and client id
> -----------------------------------------------------------------------------
>                 Key: TEPHRA-240
>                 URL: https://issues.apache.org/jira/browse/TEPHRA-240
>             Project: Tephra
>          Issue Type: Bug
>            Reporter: Andreas Neumann
>            Assignee: Andreas Neumann
>             Fix For: 0.13.0-incubating
> Often transaction conflicts are hard to explain. Having the conflicting key, or even
the name of the client that performed the concurrent update would greatly help debug.

This message was sent by Atlassian JIRA

View raw message