[
https://issues.apache.org/jira/browse/TRAFODION-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355633#comment-15355633
]
ASF GitHub Bot commented on TRAFODION-1988:
-------------------------------------------
Github user trinakrug commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/559#discussion_r69006058
--- Diff:
core/sqf/src/seatrans/tm/hbasetmlib2/src/main/java/org/trafodion/dtm/HBaseTxClient.java
---
@@ -1033,17 +961,16 @@ public void run() {
Map<String, byte[]> regions = null;
Map<Long, TransactionState> transactionStates =
new HashMap<Long, TransactionState>();
- try {
- regions = zookeeper.checkForRecovery();
- } catch (Exception e) {
- if (regions != null) { // ignore no object
returned by zookeeper.checkForRecovery
- LOG.error("An ERROR occurred while checking
for regions to recover. " + "TM: " + tmID);
- StringWriter sw = new StringWriter();
- PrintWriter pw = new PrintWriter(sw);
- e.printStackTrace(pw);
- LOG.error(sw.toString());
- }
- }
+ boolean loopBack = false;
+ do {
+ try {
+ regions = zookeeper.checkForRecovery();
--- End diff --
Should there be a loopBack = false after checkForRecovery in the case where
an exception occurred but then the operation succeeded?
> Better java exception handling in the java layer of Trafodion
> -------------------------------------------------------------
>
> Key: TRAFODION-1988
> URL: https://issues.apache.org/jira/browse/TRAFODION-1988
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: dtm, sql-exe
> Affects Versions: 2.1-incubating
> Reporter: Selvaganesan Govindarajan
> Assignee: Selvaganesan Govindarajan
>
> Java exceptions are not handled in consistent manner in Trafodion. The SQL
> interface layer in Trafodion is capable of displaying the entire java stack
> trace to the client application when an exception is raised in java portion
> of the Trafodion/Hbase/Hdfs stack. However, there are portions of the code in
> Trafodion where the exceptions are not handled in a consistent manner. This
> JIRA attempts to fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
