[
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:
https://github.com/apache/incubator-tephra/pull/47#discussion_r138490048
--- Diff:
tephra-core/src/main/java/org/apache/tephra/TransactionManager.java ---
@@ -206,12 +210,19 @@ public TransactionManager(Configuration conf,
@Nonnull TransactionStateStorage p
// 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
(v6.4.14#64029)
