[jira] [Assigned] (TRAFODION-2982) JNI HDFS interface should support varied sized large buffers for read/write

[Sandhya Sundaresan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandhya Sundaresan reassigned TRAFODION-2982:
-

Assignee: Selvaganesan Govindarajan

> JNI HDFS interface should support varied sized large buffers for read/write
> ---
>
> Key: TRAFODION-2982
> URL: https://issues.apache.org/jira/browse/TRAFODION-2982
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-exe
>Reporter: Sandhya Sundaresan
>Assignee: Selvaganesan Govindarajan
>Priority: Major
>
> The newly developed JNI API for reading/writing to hdfs could be used for LOB 
> read/write if it can support efficient reading/writing to HDFS.  The larger 
> the buffer sizes it can support, the fewer the number of chunks the caller 
> will need to read/write. This is related to the work done as part of Jira : 
> https://issues.apache.org/jira/browse/TRAFODION-2917



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TRAFODION-2982) JNI HDFS interface should support varied sized large buffers for read/write

[Sandhya Sundaresan (JIRA)]

Sandhya Sundaresan created TRAFODION-2982:
-

 Summary: JNI HDFS interface should support varied sized large 
buffers for read/write
 Key: TRAFODION-2982
 URL: https://issues.apache.org/jira/browse/TRAFODION-2982
 Project: Apache Trafodion
  Issue Type: Improvement
  Components: sql-exe
Reporter: Sandhya Sundaresan


The newly developed JNI API for reading/writing to hdfs could be used for LOB 
read/write if it can support efficient reading/writing to HDFS.  The larger the 
buffer sizes it can support, the fewer the number of chunks the caller will 
need to read/write. This is related to the work done as part of Jira : 
https://issues.apache.org/jira/browse/TRAFODION-2917



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388986#comment-16388986
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172729543
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/master/DcsMaster.java ---
@@ -111,11 +104,59 @@ public DcsMaster(String[] args) {
 trafodionHome = System.getProperty(Constants.DCS_TRAFODION_HOME);
 jvmShutdownHook = new JVMShutdownHook();
 Runtime.getRuntime().addShutdownHook(jvmShutdownHook);
-thrd = new Thread(this);
-thrd.start();
+
+ExecutorService executorService = Executors.newFixedThreadPool(1);
+CompletionService completionService = new 
ExecutorCompletionService(executorService);
+
+while (true) {
+completionService.submit(this);
+Future f = null;
+try {
+f = completionService.take();
+if (f != null) {
+Integer status = f.get();
+if (status <= 0) {
+System.exit(status);
+} else {
+// 35000 * 15mins ~= 1 years
+RetryCounter retryCounter = 
RetryCounterFactory.create(35000, 15, TimeUnit.MINUTES);
+while (true) {
+try {
+ZkClient tmpZkc = new ZkClient();
+tmpZkc.connect();
+tmpZkc.close();
+tmpZkc = null;
+LOG.info("Connected to ZooKeeper 
successful, restart DCS Master.");
+// reset lock
+isLeader = new CountDownLatch(1);
+break;
--- End diff --

As we discussed, Zookeeper connection lost has been covered by session 
expired event, so this loop is useless.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388988#comment-16388988
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172735971
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/master/DcsMaster.java ---
@@ -262,12 +308,38 @@ public void run() {
 future.get();// block
 
 } catch (Exception e) {
-LOG.error(e);
-e.printStackTrace();
+LOG.error(e.getMessage(), e);
+try {
+FloatingIp floatingIp = FloatingIp.getInstance(this);
+floatingIp.unbindScript();
+} catch (Exception e1) {
+if (LOG.isErrorEnabled()) {
+LOG.error("Error creating class FloatingIp [" + 
e.getMessage() + "]", e1);
+}
+}
 if (pool != null)
 pool.shutdown();
-System.exit(0);
+if (ls != null) {
+ListenerWorker lw = ls.getWorker();
+if (lw != null) {
+lw.interrupt();
+LOG.info("Interrupt listenerWorker.");
+}
+ls.interrupt();
+LOG.info("Interrupt listenerService.");
+}
+if (infoServer != null) {
+try {
+infoServer.stop();
+LOG.info("Stop infoServer.");
+} catch (Exception e1) {
+LOG.error(e1.getMessage(), e1);
+}
+}
+return 1;
+
--- End diff --

Add try-catch for each progress.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388995#comment-16388995
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172737467
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/zookeeper/ZkClient.java ---
@@ -176,7 +208,19 @@ public ZooKeeper getZk() {
public void process(WatchedEvent event) {
if(event.getState() == Watcher.Event.KeeperState.SyncConnected) 
{
connectedSignal.countDown();
-   }
+   } else if (event.getState() == 
Watcher.Event.KeeperState.Expired) {
+LOG.info("session expired. now rebuilding");
+// session expired, may be never happending. but if it happen 
there
+// need to close old client and rebuild new client
+try {
+connect(true);
--- End diff --

In connect(...), I saw it was catch for zookeeper exception, how can get 
exception here?


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388994#comment-16388994
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172736627
  
--- Diff: 
dcs/src/main/java/org/trafodion/dcs/master/listener/ListenerWorker.java ---
@@ -93,6 +93,7 @@ public void run() {
 try {
 queue.wait();
 } catch (InterruptedException e) {
+return;
--- End diff --

Log message for what happened by debug level.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388990#comment-16388990
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172736542
  
--- Diff: 
dcs/src/main/java/org/trafodion/dcs/master/listener/ListenerService.java ---
@@ -263,14 +264,20 @@ else if ((key.interestOps() & SelectionKey.OP_WRITE) 
== SelectionKey.OP_WRITE) {
 }
 }
 }
+if (this.isInterrupted()) {
+throw new InterruptedException();
+}
 //gc();
 }
+} catch (InterruptedException e) {
 } catch (IOException e) {
 LOG.error(e);
 System.exit(1);
 } finally {
+LOG.info("close ServerSocketChannel...");
 if (server != null) {
 try {
+server.socket().close();
 server.close();
 } catch (IOException e) {
 e.printStackTrace();
--- End diff --

it's better to print the message into log file.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388999#comment-16388999
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172736968
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/zookeeper/ZkClient.java ---
@@ -151,8 +163,28 @@ public void connect() throws IOException, 
InterruptedException {
this.zk=null;
throw new IOException("Cannot connect to 
Zookeeper");
}
-   
-   LOG.debug("Zookeeper.State=" + this.zk.getState());
+
+// Solve the forcible reconnection
+// When zk reconn, the backup-master may take over the master,
+// so current master should restart, and queues in 
/dcs/master/leader
+if (LOG.isDebugEnabled()) {
+LOG.debug("force = [" + force + "]. checkPath = [" + 
checkPath + "]");
+}
+if (force && checkPath != null) {
+try {
+Stat stat = zk.exists(checkPath, false);
+if (LOG.isDebugEnabled()) {
+LOG.debug("stat = [" + stat + "].");
+}
+if (stat == null) {
+// this means master has change.
+setSessionRecoverSuccessful(false);
+}
+} catch (KeeperException e) {
+e.printStackTrace();
--- End diff --

Log messages in file.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388998#comment-16388998
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172736451
  
--- Diff: 
dcs/src/main/java/org/trafodion/dcs/master/listener/ListenerService.java ---
@@ -263,14 +264,20 @@ else if ((key.interestOps() & SelectionKey.OP_WRITE) 
== SelectionKey.OP_WRITE) {
 }
 }
 }
+if (this.isInterrupted()) {
+throw new InterruptedException();
+}
 //gc();
 }
+} catch (InterruptedException e) {
 } catch (IOException e) {
 LOG.error(e);
--- End diff --

it's better to use 2 parameters API for LOG.error


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388989#comment-16388989
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172733924
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/master/DcsMaster.java ---
@@ -129,19 +170,19 @@ public void run() {
 instance = "1";
 } catch (NullPointerException e) {
 LOG.error("No args found: ", e);
-System.exit(1);
+return -1;
 } catch (ParseException e) {
 LOG.error("Could not parse: ", e);
-System.exit(1);
+return -1;
 }
 
 try {
 zkc = new ZkClient();
 zkc.connect();
 LOG.info("Connected to ZooKeeper");
 } catch (Exception e) {
-LOG.error(e);
-System.exit(1);
+LOG.error(e.getMessage(), e);
+return 1;
--- End diff --

Close zk connection while any connection exception happens. it's better to 
use specific Exception for zookeeper.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388991#comment-16388991
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172737025
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/zookeeper/ZkClient.java ---
@@ -176,7 +208,19 @@ public ZooKeeper getZk() {
public void process(WatchedEvent event) {
if(event.getState() == Watcher.Event.KeeperState.SyncConnected) 
{
connectedSignal.countDown();
-   }
+   } else if (event.getState() == 
Watcher.Event.KeeperState.Expired) {
+LOG.info("session expired. now rebuilding");
+// session expired, may be never happending. but if it happen 
there
+// need to close old client and rebuild new client
+try {
+connect(true);
+} catch (IOException e) {
+setSessionRecoverSuccessful(false);
+LOG.error("session expired and throw IOException while do 
reconnect: " + e.getMessage());
--- End diff --

Use 2 params API for log. If it doesn't matter for whatever the message is, 
it should be LOG.warn.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388993#comment-16388993
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172736344
  
--- Diff: 
dcs/src/main/java/org/trafodion/dcs/master/listener/ListenerService.java ---
@@ -263,14 +264,20 @@ else if ((key.interestOps() & SelectionKey.OP_WRITE) 
== SelectionKey.OP_WRITE) {
 }
 }
 }
+if (this.isInterrupted()) {
+throw new InterruptedException();
--- End diff --

Add some specific message for this exception.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388987#comment-16388987
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172734228
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/master/DcsMaster.java ---
@@ -203,8 +244,8 @@ public void run() {
 } catch (KeeperException.NodeExistsException e) {
 // do nothing...some other server has created znodes
--- End diff --

it should be better to add warning for this exception that we could what 
happened. Any events happened should be reflected in log files.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388992#comment-16388992
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172736094
  
--- Diff: dcs/src/main/java/org/trafodion/dcs/master/FloatingIp.java ---
@@ -61,6 +61,43 @@ public boolean isEnabled() {
 return isEnabled;
 }
 
+public synchronized int unbindScript() throws Exception {
+if (isEnabled)
+LOG.info("Floating IP is enabled");
+else {
+LOG.info("Floating IP is disabled");
+return 0;
+}
+
+ScriptContext scriptContext = new ScriptContext();
+scriptContext.setScriptName(Constants.SYS_SHELL_SCRIPT_NAME);
+scriptContext.setStripStdOut(false);
+scriptContext.setStripStdErr(false);
+
+String command = 
master.getConfiguration().get(Constants.DCS_MASTER_FLOATING_IP_COMMAND_UNBIND,
+Constants.DEFAULT_DCS_MASTER_FLOATING_IP_COMMAND_UNBIND);
+
+scriptContext.setCommand(command);
+LOG.info("Unbind Floating IP [" + scriptContext.getCommand() + 
"]");
+ScriptManager.getInstance().runScript(scriptContext);// Blocking 
call
+
+StringBuilder sb = new StringBuilder();
+sb.append("exit code [" + scriptContext.getExitCode() + "]");
+if (!scriptContext.getStdOut().toString().isEmpty())
+sb.append(", stdout [" + scriptContext.getStdOut().toString() 
+ "]");
+if (!scriptContext.getStdErr().toString().isEmpty())
+sb.append(", stderr [" + scriptContext.getStdErr().toString() 
+ "]");
+if (LOG.isErrorEnabled())
+LOG.info(sb.toString());
+
+if (scriptContext.getExitCode() == 0)
+LOG.info("Unbind Floating IP successful");
+else
+LOG.error("Unbind Floating IP failed");
--- End diff --

It's better to print exit code.


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (TRAFODION-2701) [ODBC]The maxlength for LargeInt was fixed to 8

[Jian Jin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jian Jin reassigned TRAFODION-2701:
---

Assignee: Weiqing Xu

> [ODBC]The maxlength for LargeInt was fixed to 8
> ---
>
> Key: TRAFODION-2701
> URL: https://issues.apache.org/jira/browse/TRAFODION-2701
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: client-odbc-linux, client-odbc-windows
>Affects Versions: 2.2.0, 2.3
> Environment: CentOS6.7 Windows
>Reporter: haolin.song
>Assignee: Weiqing Xu
>Priority: Major
> Fix For: 2.2.0, 2.3
>
>
> [ODBC]The maxlength for LargeInt was fixed to 8
> SQLBindParameter
> SQLGetData



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2981) mxosrvr crashes during explain using EXPLAIN_QID

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388845#comment-16388845
 ] 

ASF GitHub Bot commented on TRAFODION-2981:
---

GitHub user mashengchen opened a pull request:

https://github.com/apache/trafodion/pull/1464

TRAFODION-2981 mxosrvr crashes during explain using EXPLAIN_QID

SELECT * FROM TABLE(explain(null, 
'EXPLAIN_QID=MXID11070192123841538945334162206U308T150010100_923_SQL_CUR_2'));
this is related to TRAFODION-1755


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mashengchen/trafodion TRAFODION-2981

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafodion/pull/1464.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1464


commit 6b8fc454df57076d54c3e566eec8bcd3ea806a6d
Author: aven 
Date:   2018-03-06T09:59:04Z

TRAFODION-2981 mxosrvr crashes during explain using EXPLAIN_QID




> mxosrvr crashes during explain using EXPLAIN_QID
> 
>
> Key: TRAFODION-2981
> URL: https://issues.apache.org/jira/browse/TRAFODION-2981
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
>
> When the following sequence of commands are executed via trafci, the mxosrvr 
> abends and we do not get the explain output.
> SELECT * FROM TABLE(explain(null, 
> 'EXPLAIN_QID=MXID11070192123841538945334162206U308T150010100_923_SQL_CUR_2'));
>  
> this issue is related to TRAFODION-1755



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-2884) Trafodion Foundation Scalability Enhancements

[Gonzalo E Correa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gonzalo E Correa updated TRAFODION-2884:

Attachment: TRAFODION-2884-Scalable_Name_Space-DesignNotes-review.v1.0.pdf
TRAFODION-2884-Scalable_Name_Space-DesignNotes.v1.0.pdf

> Trafodion Foundation Scalability Enhancements
> -
>
> Key: TRAFODION-2884
> URL: https://issues.apache.org/jira/browse/TRAFODION-2884
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: dtm, foundation, installer
>Affects Versions: 2.3
>Reporter: Gonzalo E Correa
>Assignee: Gonzalo E Correa
>Priority: Major
> Fix For: 2.3
>
> Attachments: 
> TRAFODION-2884-Scalable_Name_Space-Architecure-review.v2.2.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v1.0.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v1.1.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v2.0.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v2.1.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v2.2.pdf, 
> TRAFODION-2884-Scalable_Name_Space-DesignNotes-review.v1.0.pdf, 
> TRAFODION-2884-Scalable_Name_Space-DesignNotes.v0.1.pdf, 
> TRAFODION-2884-Scalable_Name_Space-DesignNotes.v1.0.pdf
>
>
> Architectural changes are needed in the Trafodion Foundation components to 
> effectively scale above 256 servers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-2884) Trafodion Foundation Scalability Enhancements

[Gonzalo E Correa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gonzalo E Correa updated TRAFODION-2884:

Attachment: TRAFODION-2884-Scalable_Name_Space-Architecure-review.v2.2.pdf
TRAFODION-2884-Scalable_Name_Space-Architecure.v2.2.pdf

> Trafodion Foundation Scalability Enhancements
> -
>
> Key: TRAFODION-2884
> URL: https://issues.apache.org/jira/browse/TRAFODION-2884
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: dtm, foundation, installer
>Affects Versions: 2.3
>Reporter: Gonzalo E Correa
>Assignee: Gonzalo E Correa
>Priority: Major
> Fix For: 2.3
>
> Attachments: 
> TRAFODION-2884-Scalable_Name_Space-Architecure-review.v2.2.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v1.0.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v1.1.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v2.0.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v2.1.pdf, 
> TRAFODION-2884-Scalable_Name_Space-Architecure.v2.2.pdf, 
> TRAFODION-2884-Scalable_Name_Space-DesignNotes-review.v1.0.pdf, 
> TRAFODION-2884-Scalable_Name_Space-DesignNotes.v0.1.pdf, 
> TRAFODION-2884-Scalable_Name_Space-DesignNotes.v1.0.pdf
>
>
> Architectural changes are needed in the Trafodion Foundation components to 
> effectively scale above 256 servers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-245) LP Bug: 1315527 - JDBC T2 : Batch execute with prepared insert stmt containing multiple rows fails

[Sandhya Sundaresan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388683#comment-16388683
 ] 

Sandhya Sundaresan commented on TRAFODION-245:
--

Batch Updates and inserts are working fine now on Trafodion though T4/T2 . We 
have daily regression tests that tests this feature. Closing this as "No fix".

> LP Bug: 1315527 - JDBC T2 : Batch execute with prepared insert stmt 
> containing multiple rows fails
> --
>
> Key: TRAFODION-245
> URL: https://issues.apache.org/jira/browse/TRAFODION-245
> Project: Apache Trafodion
>  Issue Type: Wish
>  Components: client-jdbc-t4
>Reporter: Aruna Sadashiva
>Assignee: Sandhya Sundaresan
>Priority: Minor
>
> With JDBC T2/T4 driver executeBatch of prepared insert with multiple rows 
> fails with the exception below. Same test works on SQ.
> sql : insert into " + IN1 + " values(?,?,?,?),(?,?,?,?),(?,?,?,?)";
> Batch10 : ERROR: Exception in insert batch mode.
> java.sql.BatchUpdateException: The message id: batch_command_failed
> at 
> org.trafodion.jdbc.t4.TrafT4PreparedStatement.executeBatch(TrafT4PreparedStatement.java:307)
> at TestBatch.JDBCBatch10(TestBatch.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:128)
> at org.junit.runner.JUnitCore.runClasses(JUnitCore.java:73)
> at TestRunner.main(TestRunner.java:8)
> The message id: batch_command_failed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TRAFODION-179) LP Bug: 1274962 - EXECUTE.BATCH update creates core-file

[Sandhya Sundaresan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandhya Sundaresan resolved TRAFODION-179.
--
Resolution: Cannot Reproduce

> LP Bug: 1274962 - EXECUTE.BATCH update creates core-file
> 
>
> Key: TRAFODION-179
> URL: https://issues.apache.org/jira/browse/TRAFODION-179
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Guy Groulx
>Assignee: Sandhya Sundaresan
>Priority: Critical
>
> Using atomics suite.
> Test 10 is an update test using JDBC batch feature.
> Test 12 is a delete test using JDBC batch feature.
> Test is configured to batch 500 rows and then does execute batch.   See code 
> for update.  Similar code for delete.
> /*Prepare the insert statement.   */
> String sqlStmtCmd = "UPDATE " + dbTableName + " SET COL1=?, COL2=? WHERE 
> CNT = ?";
> try {
>   sqlStmt = dbConnection.prepareStatement(sqlStmtCmd);
> } catch (SQLException e) {
>   log_error("Exception in update_with_rowsets\n");
>   return(e.getErrorCode());
> }
> ...
> for (i = 0; i < (int)numbtmf; i++) {   <== numbtmf is a passed parameter, 
> set to 500 in my tests.
>   try {
> sqlStmt.setLong(1, up_col1);
> sqlStmt.setLong(2, up_col2);
> sqlStmt.setLong(3, hv_cnt);
> sqlStmt.addBatch();
> hv_cnt++;
> if (hv_cnt >= hv_cnt2) hv_cnt = hv_cnt1; /*  Need to restart. */
>   } catch (SQLException e) {
> log_error("Exception in update_with_rowsets\n");
> SQLException nextException;
> nextException = e;
> retcode = e.getErrorCode();
> do {
>   log_error(nextException.getMessage() + " State: " + 
> nextException.getSQLState() + "\n");
> } while ((nextException = nextException.getNextException()) != null);
>   }
> }
> beginTXN();
> try {
>   resultCountL = sqlStmt.executeBatch();<== This is where is hangs 
> for a very long time.
>   rowCnt+=resultCountL.length;
>   if (resultCountL.length != numbtmf) {
> log_error("Error UPDATING!! resultCount: " + resultCountL.length + 
> "\n");
> retcode = 1;
>   } else {
> for (i = 0; i < resultCountL.length; i++) {
>   if ((resultCountL[i] != 1) && (resultCountL[i] != 
> Statement.SUCCESS_NO_INFO)) {
> log_error("Error UPDATING!! resultCount: " + resultCountL[i] + 
> "\n");
> retcode = resultCountL[i];
> break;
>   }
> }
>   }
>   sqlStmt.clearBatch();
> } catch (SQLException e) {
>   log_error("Exception in update_with_rowsets\n");
>   SQLException nextException;
>   nextException = e;
>   retcode = e.getErrorCode();
>   do {
> log_error(nextException.getMessage() + " State: " + 
> nextException.getSQLState() + "\n");
>   } while ((nextException = nextException.getNextException()) != null);
> }
> commitTXN();
> return retcode;
> Eventually, get: 
> Exception in update_with_rowsets
> Exception in update_with_rowsets
> Batch Update Failed, See next exception for details State: HY000
> Batch Update Failed, See next exception for details State: HY000
> *** ERROR[8448] Unable to access Hbase interface. Call to 
> ExpHbaseInterface::insertRows returned error HBASE_ACCESS_ERROR(-705). Cause: 
> org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after 
> attempts=10, exceptions:
> Fri Jan 31 14:38:42 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:43 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:44 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:45 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:47 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:49 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:53 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:57 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:39:05 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 

[jira] [Commented] (TRAFODION-179) LP Bug: 1274962 - EXECUTE.BATCH update creates core-file

[Sandhya Sundaresan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388672#comment-16388672
 ] 

Sandhya Sundaresan commented on TRAFODION-179:
--

JDBC regression tests which test batch udate and batch insert don't show this 
as an issue anymore . Several fixes have gone in. So resolving this as "Fixed". 

> LP Bug: 1274962 - EXECUTE.BATCH update creates core-file
> 
>
> Key: TRAFODION-179
> URL: https://issues.apache.org/jira/browse/TRAFODION-179
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Guy Groulx
>Assignee: Sandhya Sundaresan
>Priority: Critical
>
> Using atomics suite.
> Test 10 is an update test using JDBC batch feature.
> Test 12 is a delete test using JDBC batch feature.
> Test is configured to batch 500 rows and then does execute batch.   See code 
> for update.  Similar code for delete.
> /*Prepare the insert statement.   */
> String sqlStmtCmd = "UPDATE " + dbTableName + " SET COL1=?, COL2=? WHERE 
> CNT = ?";
> try {
>   sqlStmt = dbConnection.prepareStatement(sqlStmtCmd);
> } catch (SQLException e) {
>   log_error("Exception in update_with_rowsets\n");
>   return(e.getErrorCode());
> }
> ...
> for (i = 0; i < (int)numbtmf; i++) {   <== numbtmf is a passed parameter, 
> set to 500 in my tests.
>   try {
> sqlStmt.setLong(1, up_col1);
> sqlStmt.setLong(2, up_col2);
> sqlStmt.setLong(3, hv_cnt);
> sqlStmt.addBatch();
> hv_cnt++;
> if (hv_cnt >= hv_cnt2) hv_cnt = hv_cnt1; /*  Need to restart. */
>   } catch (SQLException e) {
> log_error("Exception in update_with_rowsets\n");
> SQLException nextException;
> nextException = e;
> retcode = e.getErrorCode();
> do {
>   log_error(nextException.getMessage() + " State: " + 
> nextException.getSQLState() + "\n");
> } while ((nextException = nextException.getNextException()) != null);
>   }
> }
> beginTXN();
> try {
>   resultCountL = sqlStmt.executeBatch();<== This is where is hangs 
> for a very long time.
>   rowCnt+=resultCountL.length;
>   if (resultCountL.length != numbtmf) {
> log_error("Error UPDATING!! resultCount: " + resultCountL.length + 
> "\n");
> retcode = 1;
>   } else {
> for (i = 0; i < resultCountL.length; i++) {
>   if ((resultCountL[i] != 1) && (resultCountL[i] != 
> Statement.SUCCESS_NO_INFO)) {
> log_error("Error UPDATING!! resultCount: " + resultCountL[i] + 
> "\n");
> retcode = resultCountL[i];
> break;
>   }
> }
>   }
>   sqlStmt.clearBatch();
> } catch (SQLException e) {
>   log_error("Exception in update_with_rowsets\n");
>   SQLException nextException;
>   nextException = e;
>   retcode = e.getErrorCode();
>   do {
> log_error(nextException.getMessage() + " State: " + 
> nextException.getSQLState() + "\n");
>   } while ((nextException = nextException.getNextException()) != null);
> }
> commitTXN();
> return retcode;
> Eventually, get: 
> Exception in update_with_rowsets
> Exception in update_with_rowsets
> Batch Update Failed, See next exception for details State: HY000
> Batch Update Failed, See next exception for details State: HY000
> *** ERROR[8448] Unable to access Hbase interface. Call to 
> ExpHbaseInterface::insertRows returned error HBASE_ACCESS_ERROR(-705). Cause: 
> org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after 
> attempts=10, exceptions:
> Fri Jan 31 14:38:42 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:43 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:44 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:45 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:47 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:49 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:53 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:57 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> 

[jira] [Commented] (TRAFODION-909) LP Bug: 1412641 - log4cpp -- Node number in master*.log is always 0

[Sandhya Sundaresan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388666#comment-16388666
 ] 

Sandhya Sundaresan commented on TRAFODION-909:
--

The issue still exists but is a more minor issue now. The Node Number is now 
actually reported as a CPU number which is reported correctly. As  fix we can 
remove CPU number and report it as the Node Number so it is consistent with the 
other logging components. 

 

This is from monitor log

2018-03-06 05:03:16,195, INFO, MON, *Node Number: 2*,, PIN: 11987 , Process 
Name: $MONITOR,,, TID: 16075, Message ID: 101011300, [CCluster::NodeTmReady], 
Node activated! pnid=2, name=(devcdh-3.novalocal)

 

This is from sql log

2018-03-06 05:04:41,216, INFO, SQL.EXE, *Node Number: 0, CPU: 2*, PIN: 20751, 
Process Name: $Z020GXW,,, An executor process is launched.

> LP Bug: 1412641 - log4cpp -- Node number in master*.log is always 0
> ---
>
> Key: TRAFODION-909
> URL: https://issues.apache.org/jira/browse/TRAFODION-909
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Gao, Rui-Xian
>Assignee: Sandhya Sundaresan
>Priority: Major
>
> Node number in master*.log is always 0, tm.log has correct number.
> SQL>select [first 5] * from udf(event_log_reader('f')) where 
> log_file_name='master_exec_0_7476.log';
> LOG_TS SEVERITY   COMPONENTNODE_NUMBER 
> CPU PIN PROCESS_NAME SQL_CODEQUERY_ID 
>   
>   MESSAGE 
>  
> LOG_FILE_NODE LOG_FILE_NAME   
>  
> LOG_FILE_LINE PARSE_STATUS
> -- --  --- 
> --- ---  --- 
> 
>  
> 
>  - 
> 
>  - 
> 2015-01-19 04:29:53.454000 INFO   SQL.ESP0
>2   24361 $Z020JW1NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  1
> 2015-01-19 04:29:53.462000 INFO   SQL.ESP0
>2   24360 $Z020JW0NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  2
> 2015-01-19 04:29:53.452000 INFO   SQL.ESP0
>5   31881 $Z050R0WNULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  1
> 2015-01-19 04:35:23.101000 INFO   SQL.ESP0
>51892 $Z0501J2NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  2
> 2015-01-19 04:29:53.454000 INFO   SQL.ESP   

[jira] [Commented] (TRAFODION-1099) LP Bug: 1437384 - sqenvcom.sh. Our CLASSPATH is too big.

[Sandhya Sundaresan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388651#comment-16388651
 ] 

Sandhya Sundaresan commented on TRAFODION-1099:
---

There have been no issues with the Trafodion classpath being too big on any 
installations. So this isn't a critical issue anymore. No need to change to 
using wildcards which won't work correctly anyway. So resolving this as "no 
fix".

> LP Bug: 1437384 - sqenvcom.sh.Our CLASSPATH is too big.
> ---
>
> Key: TRAFODION-1099
> URL: https://issues.apache.org/jira/browse/TRAFODION-1099
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Reporter: Guy Groulx
>Assignee: Sandhya Sundaresan
>Priority: Major
>
> sqenvcom.sh sets up CLASSPATH for trafodion.
> With HDP2.2, this CLASSPATH is huge.   On one of our system, echo $CLASSPATH 
> | wc -l return > 13000 bytes.
> I believe java/Linux truncates these variables when it's too big.
> Since going to HDP 2.2, we've been hit with "class not found" error 
> eventhough the jar is in CLASSPATH.
> http://stackoverflow.com/questions/1237093/using-wildcard-for-classpath 
> explains that we can use wildcards in CLASSPATH to reduce it.
> Rules:
> Use * and not *.jar.Java assumes that * in classpath are for *.jar
> When using export CLASSPATHuse quotes so that * is not expanded.   EG:
> export CLASSPATH=”/usr/hdp/current/hadoop-client/lib/*:${CLASSPATH}”
> We need to modify our sqenvcom.sh to use wildcards instead of putting 
> individual jar.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TRAFODION-1099) LP Bug: 1437384 - sqenvcom.sh. Our CLASSPATH is too big.

[Sandhya Sundaresan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandhya Sundaresan resolved TRAFODION-1099.
---
Resolution: Won't Fix

> LP Bug: 1437384 - sqenvcom.sh.Our CLASSPATH is too big.
> ---
>
> Key: TRAFODION-1099
> URL: https://issues.apache.org/jira/browse/TRAFODION-1099
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Reporter: Guy Groulx
>Assignee: Sandhya Sundaresan
>Priority: Major
>
> sqenvcom.sh sets up CLASSPATH for trafodion.
> With HDP2.2, this CLASSPATH is huge.   On one of our system, echo $CLASSPATH 
> | wc -l return > 13000 bytes.
> I believe java/Linux truncates these variables when it's too big.
> Since going to HDP 2.2, we've been hit with "class not found" error 
> eventhough the jar is in CLASSPATH.
> http://stackoverflow.com/questions/1237093/using-wildcard-for-classpath 
> explains that we can use wildcards in CLASSPATH to reduce it.
> Rules:
> Use * and not *.jar.Java assumes that * in classpath are for *.jar
> When using export CLASSPATHuse quotes so that * is not expanded.   EG:
> export CLASSPATH=”/usr/hdp/current/hadoop-client/lib/*:${CLASSPATH}”
> We need to modify our sqenvcom.sh to use wildcards instead of putting 
> individual jar.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (TRAFODION-1151) LP Bug: 1442483 - SQL queries hang when Region Server goes down

[Sandhya Sundaresan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandhya Sundaresan resolved TRAFODION-1151.
---
   Resolution: Fixed
Fix Version/s: 2.2.0

> LP Bug: 1442483 - SQL queries hang when Region Server goes down
> ---
>
> Key: TRAFODION-1151
> URL: https://issues.apache.org/jira/browse/TRAFODION-1151
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Sandhya Sundaresan
>Assignee: Sandhya Sundaresan
>Priority: Major
> Fix For: 2.2.0
>
>
> When the RS goes down - for example killed by zookeeper due to out of memory 
> conditions, the SQL query that was executing hangs and doesn't timeout for 
> atleast an hour . 
> But subsequent SQL queries immediately detect that RS is down and retirn an 
> Hbase -705 error. 
> The timeout values in JNI calls need to be investigated to see why the hang 
> happens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-1151) LP Bug: 1442483 - SQL queries hang when Region Server goes down

[Sandhya Sundaresan (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388647#comment-16388647
 ] 

Sandhya Sundaresan commented on TRAFODION-1151:
---

This issue has been addressed by several JIRAs that improve exception handling. 
Now the issue of hangs no longer exists. It's been fixed in Trafodion 2.2. by 
these JIRAs :

https://issues.apache.org/jira/browse/TRAFODION-1988

https://issues.apache.org/jira/browse/TRAFODION-2231

https://issues.apache.org/jira/browse/TRAFODION-2414

https://issues.apache.org/jira/browse/TRAFODION-2148

> LP Bug: 1442483 - SQL queries hang when Region Server goes down
> ---
>
> Key: TRAFODION-1151
> URL: https://issues.apache.org/jira/browse/TRAFODION-1151
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Sandhya Sundaresan
>Assignee: Sandhya Sundaresan
>Priority: Major
>
> When the RS goes down - for example killed by zookeeper due to out of memory 
> conditions, the SQL query that was executing hangs and doesn't timeout for 
> atleast an hour . 
> But subsequent SQL queries immediately detect that RS is down and retirn an 
> Hbase -705 error. 
> The timeout values in JNI calls need to be investigated to see why the hang 
> happens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2974) Some predefined UDFs should be regular UDFs so we can revoke rights

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388504#comment-16388504
 ] 

ASF GitHub Bot commented on TRAFODION-2974:
---

Github user asfgit closed the pull request at:

https://github.com/apache/trafodion/pull/1463


> Some predefined UDFs should be regular UDFs so we can revoke rights
> ---
>
> Key: TRAFODION-2974
> URL: https://issues.apache.org/jira/browse/TRAFODION-2974
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmu
>Affects Versions: 2.2.0
>Reporter: Hans Zeller
>Assignee: Hans Zeller
>Priority: Major
> Fix For: 2.3
>
>
> Roberta pointed out that we have two predefined UDFs, EVENT_LOG_READER and 
> JDBC, where the system administrator should have the ability to control who 
> can execute these functions.
> To do this, these two UDFs cannot be "predefined" UDFs anymore, since those 
> don't have the metadata that's required for doing grant and revoke.
> Roberta also pointed out that the JDBC UDF should refuse to connect to the T2 
> driver, for security reasons.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2974) Some predefined UDFs should be regular UDFs so we can revoke rights

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16388407#comment-16388407
 ] 

ASF GitHub Bot commented on TRAFODION-2974:
---

GitHub user zellerh opened a pull request:

https://github.com/apache/trafodion/pull/1463

[TRAFODION-2974] Update expected files

New privileges granted to public and a new library caused two privs1 tests 
and one udr test to fail.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zellerh/trafodion bug/R23a

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafodion/pull/1463.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1463


commit d505aee7a0939fc0f50454fdd2491b0a6cc5e84a
Author: Hans Zeller 
Date:   2018-03-06T19:32:03Z

[TRAFODION-2974] Update expected files

New privileges granted to public caused several tests to fail.




> Some predefined UDFs should be regular UDFs so we can revoke rights
> ---
>
> Key: TRAFODION-2974
> URL: https://issues.apache.org/jira/browse/TRAFODION-2974
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmu
>Affects Versions: 2.2.0
>Reporter: Hans Zeller
>Assignee: Hans Zeller
>Priority: Major
> Fix For: 2.3
>
>
> Roberta pointed out that we have two predefined UDFs, EVENT_LOG_READER and 
> JDBC, where the system administrator should have the ability to control who 
> can execute these functions.
> To do this, these two UDFs cannot be "predefined" UDFs anymore, since those 
> don't have the metadata that's required for doing grant and revoke.
> Roberta also pointed out that the JDBC UDF should refuse to connect to the T2 
> driver, for security reasons.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (TRAFODION-2980) Add build-in function instr as Oracle

[Anoop Sharma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anoop Sharma reassigned TRAFODION-2980:
---

Assignee: Anoop Sharma

> Add build-in function instr as Oracle
> -
>
> Key: TRAFODION-2980
> URL: https://issues.apache.org/jira/browse/TRAFODION-2980
> Project: Apache Trafodion
>  Issue Type: New Feature
>  Components: sql-general
>Reporter: Yuan Liu
>Assignee: Anoop Sharma
>Priority: Major
>
> Add an build-in function as Oracle instr.
>  
> For example,
> select instr('helloworld',',',2,2) from dual; --return 4
> select instr('helloworld', 'l', 4, 2) from dual; – return 9



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1422) Delete column can be dramatically improved (ALTER statement)

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1422:
--
Fix Version/s: (was: 2.2.0)

> Delete column can be dramatically improved (ALTER statement)
> 
>
> Key: TRAFODION-1422
> URL: https://issues.apache.org/jira/browse/TRAFODION-1422
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-general
>Reporter: Eric Owhadi
>Assignee: Eric Owhadi
>Priority: Minor
>  Labels: performance
>
> The current code path for delete column has not been optimized and can be 
> greatly improved. See comments bellow for many ways to implement optimization.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-605) LP Bug: 1366227 - core file from shell during shutdown

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-605:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1366227 - core file from shell during shutdown
> --
>
> Key: TRAFODION-605
> URL: https://issues.apache.org/jira/browse/TRAFODION-605
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: foundation
>Reporter: Christopher Sheedy
>Assignee: Atanu Mishra
>Priority: Minor
>
> Change 332 had a failure in core-regress-seabase-cdh4.4 when doing shutdown. 
> http://logs.trafodion.org/32/332/2/check/core-regress-seabase-cdh4.4/6a54826/console.html
>  has:
> Shutting down (normal) the SQ environment!
> Fri Sep 5 18:52:26 UTC 2014
> Processing cluster.conf on local host slave01
> [$Z000BBN] Shell/shell Version 1.0.1 Release 0.8.4 (Build release 
> [0.8.3rc1-203-ga165839master_Bld177], date 20140905_175103)
> ps
> [$Z000BBN] %ps
> [$Z000BBN] NID,PID(os)  PRI TYPE STATES  NAMEPARENT  PROGRAM
> [$Z000BBN]  ---  --- --- --- 
> ---
> [$Z000BBN] 000,00031016 000 WDG  ES--A-- $WDT000 NONEsqwatchdog
> [$Z000BBN] 000,00031017 000 PSD  ES--A-- $PSD000 NONEpstartd
> [$Z000BBN] 000,00031061 001 DTM  ES--A-- $TM0NONEtm
> [$Z000BBN] 000,00013883 001 GEN  ES--A-- $Z000BBNNONEshell
> [$Z000BBN] 001,00031018 000 PSD  ES--A-- $PSD001 NONEpstartd
> [$Z000BBN] 001,00031015 000 WDG  ES--A-- $WDT001 NONEsqwatchdog
> [$Z000BBN] 001,00031139 001 DTM  ES--A-- $TM1NONEtm
> shutdown
> [$Z000BBN] %shutdown
> /home/jenkins/workspace/core-regress-seabase-cdh4.4/trafodion/core/sqf/sql/scripts/sqshell:
>  line 7: 13883 Aborted (core dumped) shell $1 $2 $3 $4 $5 $6 
> $7 $8 $9
> Issued a 'shutdown normal' request
> Shutdown in progress
> # of SQ processes: 0
> SQ Shutdown (normal) from 
> /home/jenkins/workspace/core-regress-seabase-cdh4.4/trafodion/core/sql/regress
>  Successful
> Fri Sep 5 18:52:34 UTC 2014
> + ret=0
> + [[ 0 == 124 ]]
> + echo 'Return code 0'
> Return code 0
> + sudo /usr/local/bin/hbase-sudo.sh stop
> Stopping hbase-master
> Stopping HBase master daemon (hbase-master):[  OK  ]
> stopping master.
> Return code 0
> + echo 'Return code 0'
> Return code 0
> + cd ../../sqf/rundir
> + set +x
> = seabase
> 09/05/14 18:21:07 (RELEASE build)
> 09/05/14 18:23:51  TEST010### PASS ###
> 09/05/14 18:25:38  TEST011### PASS ###
> 09/05/14 18:27:46  TEST012### PASS ###
> 09/05/14 18:29:36  TEST013### PASS ###
> 09/05/14 18:29:50  TEST014### PASS ###
> 09/05/14 18:32:05  TEST016### PASS ###
> 09/05/14 18:32:35  TEST018### PASS ###
> 09/05/14 18:50:28  TEST020### PASS ###
> 09/05/14 18:50:44  TEST022### PASS ###
> 09/05/14 18:52:26  TEST024### PASS ###
> 09/05/14 18:21:07 - 18:52:26  (RELEASE build)
> WARNING: Core files found in 
> /home/jenkins/workspace/core-regress-seabase-cdh4.4/trafodion/core :
> -rw---. 1 jenkins jenkins 44552192 Sep  5 18:52 
> sql/regress/core.slave01.13883.shell
> 
> Total Passed:   10
> Total Failures: 0
> Failure : Found 1 core files
> Build step 'Execute shell' marked build as failure
> The core file's back trace is:
> -bash-4.1$ core_bt -d sql/regress
> core file  : -rw---. 1 jenkins jenkins 44552192 Sep  5 18:52 
> sql/regress/core.slave01.13883.shell
> gdb command: gdb shell sql/regress/core.slave01.13883.shell --batch -n -x 
> /tmp/tmp.xEFWF2xufh 2>&1
> Missing separate debuginfo for
> Try: yum --disablerepo='*' --enablerepo='*-debug*' install 
> /usr/lib/debug/.build-id/1e/0a7d58f454926e2afb4797865d85801ed65ece
> [New Thread 13884]
> [New Thread 13883]
> [Thread debugging using libthread_db enabled]
> Core was generated by `shell -a'.
> Program terminated with signal 6, Aborted.
> #0  0x0030ada32635 in raise () from /lib64/libc.so.6
> #0  0x0030ada32635 in raise () from /lib64/libc.so.6
> #1  0x0030ada33e15 in abort () from /lib64/libc.so.6
> #2  0x00411982 in LIOTM_assert_fun (pp_exp=0x4d4f40 "0", 
> pp_file=0x4d175e "clio.cxx", pv_line=1022, pp_fun=0x4d2d60 "int 
> Local_IO_To_Monitor::process_notice(message_def*)") at clio.cxx:99
> #3  0x00413b26 in Local_IO_To_Monitor::process_notice (this=0x7c6e80, 
> pp_msg=) at clio.cxx:1022
> #4  0x00413e03 in Local_IO_To_Monitor::get_io (this=0x7c6e80, 
> pv_sig=, pp_siginfo=) at 
> clio.cxx:637
> #5  0x00414075 in local_monitor_reader (pp_arg=0x7916) at clio.cxx:154
> #6  0x0030ae2079d1 in start_thread () from /lib64/libpthread.so.0
> #7  0x0030adae886d in clone () from /lib64/libc.so.6



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1175) LP Bug: 1444228 - Trafodion should record the FQDN as client_name in Repository tables

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1175:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1444228 - Trafodion should record the FQDN as client_name in 
> Repository tables
> --
>
> Key: TRAFODION-1175
> URL: https://issues.apache.org/jira/browse/TRAFODION-1175
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: client-odbc-linux, connectivity-general
>Reporter: Chengxin Cai
>Assignee: Gao Jie
>Priority: Major
>
> select distinct application_name, rtrim(client_name) from 
> "_REPOS_".METRIC_QUERY_AGGR_TABLE;
> APPLICATION_NAME  
>   (EXPR)
> --  
> 
> /usr/bin/python sq1176
> TrafCI
> sq1176.houston.hp.com
> --- 2 row(s) selected.
> Actually, sq1176 and sq1176.houston.hp.com are the same client, but they show 
> different result when using odbc or jdbc client.
> They should always be the FQDN whatever the client is.
> And the same problem in METRIC_QUERY_TABLE and METRIC_SESSION_TABLE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1194) LP Bug: 1446917 - T2 tests don't include parallel plans

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1194:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1446917 - T2 tests don't include  parallel plans
> 
>
> Key: TRAFODION-1194
> URL: https://issues.apache.org/jira/browse/TRAFODION-1194
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-general
>Reporter: Sandhya Sundaresan
>Assignee: Anuradha Hegde
>Priority: Major
>
> The T2 test suite  should include proper coverage of parallel plans involving 
> ESPs. 
> This is needed to ensure IPC mechanism does not regress with any of the 
> current changes underway. 
> This coverage is especially important wr.t  the new work being done for 
> multi-threaded DCS server. 
> Atleast one test with ESPs should be made a Gating test as well in Jenkins.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1220) LP Bug: 1450515 - Compilation time for NOT IN predicate *much* longer than for IN predicate

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1220:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1450515 - Compilation time for NOT IN predicate *much* longer than 
> for IN predicate
> ---
>
> Key: TRAFODION-1220
> URL: https://issues.apache.org/jira/browse/TRAFODION-1220
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Apache Trafodion
>Assignee: Qifan Chen
>Priority: Major
>
> If you have a simple SELECT query with an IN predicate with a list of say 930 
> items in the list, the query will compile (on one of the sqws*** machines) in 
> approximately 13.5 seconds.   If you change the 'IN' to 'NOT IN', the 
> compilation time goes to over 50 seconds.
>  Furthermore, once the changes get made to allow IN lists and NOT IN lists 
> that are say 3000 items long, if you then try the same SELECT query  with a 
> IN list of 3000 items (unique items), the compilation time is about 18-20 
> seconds.  However, if you then change the query to specify NOT IN, the 
> compilation time goes to 15-20 *minutes*. NOTE: Currently, IN lists are 
> limited to about 2230 unique items and NOT IN lists are limited to about 930 
> unique items (beyond those lengths you get stack overflow.)   Once a fix to 
> LP 1323826 gets checked into the source base, you should be able to have IN 
> lists or NOT IN lists with as many as 3000 unique items.
> Example SELECT query (with 930 unique items) that exhibits this behavior is 
> as follows:
> --create table mytable97 (partnum decimal(4,0), partname char(18));
> prepare s1 from select * from mytable97 where partname in (
>   'A10','B10','C10','D10','E10','F10','G10','H10','I10','J10'
>  ,'K10','L10','M10','N10','O10','P10','Q10','R10','S10','T10'
>  ,'AA10','AB10','AC10','AD10','AE10','AF10','AG10','AH10','AI10','AJ10'
>  ,'BA10','BB10','BC10','BD10','BE10','BF10','BG10','BH10','BI10','BJ10'
>  ,'CA10','CB10','CC10','CD10','CE10','CF10','CG10','CH10','CI10','CJ10'
>  ,'DA10','DB10','DC10','DD10','DE10','DF10','DG10','DH10','DI10','DJ10'
>  ,'EA10','EB10','EC10','ED10','EE10','EF10','EG10','EH10','EI10','EJ10'
>  ,'FA10','FB10','FC10','FD10','FE10','FF10','FG10','FH10','FI10','FJ10'
>  ,'GA10','GB10','GC10','GD10','GE10','GF10','GG10','GH10','GI10','GJ10'
>  ,'HA10','HB10','HC10','HD10','HE10','HF10','HG10','HH10','HI10','HJ10'
>  ,'A11','B11','C11','D11','E11','F11','G11','H11','I11','J11'
>  ,'K11','L11','M11','N11','O11','P11','Q11','R11','S11','T11'
>  ,'AA11','AB11','AC11','AD11','AE11','AF11','AG11','AH11','AI11','AJ11'
>  ,'BA11','BB11','BC11','BD11','BE11','BF11','BG11','BH11','BI11','BJ11'
>  ,'CA11','CB11','CC11','CD11','CE11','CF11','CG11','CH11','CI11','CJ11'
>  ,'DA11','DB11','DC11','DD11','DE11','DF11','DG11','DH11','DI11','DJ11'
>  ,'EA11','EB11','EC11','ED11','EE11','EF11','EG11','EH11','EI11','EJ11'
>  ,'FA11','FB11','FC11','FD11','FE11','FF11','FG11','FH11','FI11','FJ11'
>  ,'GA11','GB11','GC11','GD11','GE11','GF11','GG11','GH11','GI11','GJ11'
>  ,'HA11','HB11','HC11','HD11','HE11','HF11','HG11','HH11','HI11','HJ11'
>  ,'A12','B12','C12','D12','E12','F12','G12','H12','I12','J12'
>  ,'K12','L12','M12','N12','O12','P12','Q12','R12','S12','T12'
>  ,'AA12','AB12','AC12','AD12','AE12','AF12','AG12','AH12','AI12','AJ12'
>  ,'BA12','BB12','BC12','BD12','BE12','BF12','BG12','BH12','BI12','BJ12'
>  ,'CA12','CB12','CC12','CD12','CE12','CF12','CG12','CH12','CI12','CJ12'
>  ,'DA12','DB12','DC12','DD12','DE12','DF12','DG12','DH12','DI12','DJ12'
>  ,'EA12','EB12','EC12','ED12','EE12','EF12','EG12','EH12','EI12','EJ12'
>  ,'FA12','FB12','FC12','FD12','FE12','FF12','FG12','FH12','FI12','FJ12'
>  ,'GA12','GB12','GC12','GD12','GE12','GF12','GG12','GH12','GI12','GJ12'
>  ,'HA12','HB12','HC12','HD12','HE12','HF12','HG12','HH12','HI12','HJ12'
>  ,'A13','B13','C13','D13','E13','F13','G13','H13','I13','J13'
>  ,'K13','L13','M13','N13','O13','P13','Q13','R13','S13','T13'
>  ,'AA13','AB13','AC13','AD13','AE13','AF13','AG13','AH13','AI13','AJ13'
>  ,'BA13','BB13','BC13','BD13','BE13','BF13','BG13','BH13','BI13','BJ13'
>  ,'CA13','CB13','CC13','CD13','CE13','CF13','CG13','CH13','CI13','CJ13'
>  ,'DA13','DB13','DC13','DD13','DE13','DF13','DG13','DH13','DI13','DJ13'
>  ,'EA13','EB13','EC13','ED13','EE13','EF13','EG13','EH13','EI13','EJ13'
>  ,'FA13','FB13','FC13','FD13','FE13','FF13','FG13','FH13','FI13','FJ13'
>  ,'GA13','GB13','GC13','GD13','GE13','GF13','GG13','GH13','GI13','GJ13'
>  ,'HA13','HB13','HC13','HD13','HE13','HF13','HG13','HH13','HI13','HJ13'
>  ,'A14','B14','C14','D14','E14','F14','G14','H14','I14','J14'
>  ,'K14','L14','M14','N14','O14','P14','Q14','R14','S14','T14'
>  

[jira] [Updated] (TRAFODION-464) LP Bug: 1344129 - add support enabling/disabling contraints

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-464:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1344129 - add support  enabling/disabling contraints
> 
>
> Key: TRAFODION-464
> URL: https://issues.apache.org/jira/browse/TRAFODION-464
> Project: Apache Trafodion
>  Issue Type: Wish
>  Components: sql-cmu
>Reporter: Apache Trafodion
>Assignee: Anoop Sharma
>Priority: Minor
>
> Currently Trafodion does not support enabling and disable constraints
> we may need to add support for:
> - disabling one constraint
> -disabling all constraints
> -enabling one constraint and applying the constraint also as part of enabling 
> it
> -enabling all constraints and applying them  also as part of enabling them



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1037) LP Bug: 1428857 - CMP: create index stmt sometimes generates core

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1037:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1428857 - CMP: create index stmt sometimes generates core
> -
>
> Key: TRAFODION-1037
> URL: https://issues.apache.org/jira/browse/TRAFODION-1037
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Ravisha Neelakanthappa
>Assignee: Qifan Chen
>Priority: Major
>
> Trying create an index from sqlci session sometimes results in core though 
> the index gets created. To reproduce this problem try creating as many 
> indices as possible from same sqlci session.
> nravishag4t2966$ sqlci
> Trafodion Conversational Interface 1.1.0
> (c) Copyright 2014 Hewlett-Packard Development Company, LP.
> >>set schema trafodion.orderentry;
> --- SQL operation complete.
> >>CREATE INDEX CUSTOMER_DID ON CUSTOMER
>  (
> C_D_ID ASC
>   )
> ;+>+>+>+>+>
> --- SQL operation complete.
> >>CREATE INDEX CUSTOMER_ID ON CUSTOMER
>  (
> C_ID ASC
>   )
> ;+>+>+>+>+>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x75c78058, pid=8025, tid=140737178194496
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 
> 1.7.0_67-b01)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # C  [libustat.so+0x102058]  NormValue::copy(NormValue const&)+0x10
> #
> nravishag4t2966$ ls
> core.g4t2966.houston.hp.com.8025.tdm_arkcmp
> The core file indicates, arkcmp crashes in 
> nravishag4t2966$ mygdb tdm_arkcmp core.g4t2966.houston.hp.com.8025.tdm_arkcmp
> Core was generated by `tdm_arkcmp SQMON1.1 0 0 008025 $Z0006JA 
> 16.235.163.24:33326 4 0'.
> Program terminated with signal 6, Aborted.
> #0  0x003980a328a5 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x003980a328a5 in raise () from /lib64/libc.so.6
> #1  0x003980a3400d in abort () from /lib64/libc.so.6
> #2  0x70d78a55 in os::abort(bool) ()
>from /opt/home/tools/jdk1.7.0_67/jre/lib/amd64/server/libjvm.so
> #3  0x70ef8f87 in VMError::report_and_die() ()
>from /opt/home/tools/jdk1.7.0_67/jre/lib/amd64/server/libjvm.so
> #4  0x70d7d96f in JVM_handle_linux_signal ()
>from /opt/home/tools/jdk1.7.0_67/jre/lib/amd64/server/libjvm.so
> #5  
> #6  0x75c78058 in NormValue::copy (this=0x7fffdbbb61a0, other=...)
> at ../optimizer/EncodedValue.h:70
> #7  0x75c780b7 in NormValue::operator= (this=0x7fffdbbb61a0, 
> other=...)
> at ../optimizer/EncodedValue.h:87
> #8  0x75c7857e in EncodedValue::operator= (this=0x7fffdbbb6190)
> at ../optimizer/EncodedValue.h:154
> #9  0x74b47bf9 in NACollection::copy 
> (this=0x7fffdbbafab8,
> other=...) at ../common/Collections.cpp:61
> #10 0x74b46c56 in NAList::operator= 
> (this=0x7fffdbbafab8,
> other=...) at ../common/Collections.cpp:808
> #11 0x74b4685f in MCboundaryValueList::operator= (this=0x7fffdbbafab8)
> at ../optimizer/Stats.h:453
> #12 0x74b1c3fe in HistInt::copy (this=0x7fffdbbafa80, other=...)
> at ../optimizer/Stats.cpp:112
> #13 0x75c7848f in HistInt::operator= (this=0x7fffdbbafa80, other=...)
> at ../optimizer/Stats.h:587
> #14 0x746d62bd in NACollection::copy (this=0x7fffdbb906a8, 
> other=...)
> at ../common/Collections.cpp:61
> #15 0x746cf77d in NACollection::NACollection 
> (this=0x7fffdbb906a8,
> #16 0x746ca547 in NAList::NAList (this=0x7fffdbb906a8, 
> other=...,
> heap=0x7fffdca27eb8) at ../common/Collections.h:1968
> #17 0x746c7854 in Histogram::Histogram (this=0x7fffdbb906a8, hist=...,
> h=0x7fffdca27eb8) at ../optimizer/Stats.h:695
> #18 0x74b2801d in ColStats::getHistogramToModify (this=0x7fffdbb8a3e0)
> at ../optimizer/Stats.cpp:3443
> #19 0x748bf07b in NATable::getStatistics (this=0x7fffdb981ba0)
> at ../optimizer/NATable.cpp:6163
> #20 0x74b6da18 in TableDesc::getTableColStats (this=0x7fffdb98a478)
> at ../optimizer/TableDesc.cpp:382
> #21 0x77ac8e2a in TableDesc::tableColStats (this=0x7fffdb98a478)
> at ../optimizer/TableDesc.h:130
> #22 0x749a1afa in Scan::synthLogProp (this=0x7fffdca3b168,
> normWAPtr=0x7fff54e0) at ../optimizer/OptLogRelExpr.cpp:5062
> #23 0x7498f8b9 in RelExpr::synthLogProp (this=0x7fffdca2f680,
> normWAPtr=0x7fff54e0) at ../optimizer/OptLogRelExpr.cpp:619
> #24 0x749a355b in GenericUpdate::synthLogProp (this=0x7fffdca2f680,
> normWAPtr=0x7fff54e0) at ../optimizer/OptLogRelExpr.cpp:5448
> #25 0x7498f8b9 in 

[jira] [Updated] (TRAFODION-1098) LP Bug: 1437314 - NULL value for severity and cpu in some monitor log files

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1098:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1437314 - NULL value for severity and cpu in some monitor log files
> ---
>
> Key: TRAFODION-1098
> URL: https://issues.apache.org/jira/browse/TRAFODION-1098
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: foundation
>Reporter: Gao, Rui-Xian
>Assignee: Atanu Mishra
>Priority: Major
>
> severity, component, node_number and cpu is null in some monitor log files, 
> and also got some  '2181' for severity and component.
> System info – centos-mapr1.hpl.hp.com (port num: 37800)
> results --
> 1.   CPU is NULL in some monitor logs.
> SQL>select [first 6] * from udf(event_log_reader('f')) where cpu is NULL;
> LOG_TS SEVERITY   COMPONENTNODE_NUMBER 
> CPU PIN PROCESS_NAME SQL_CODEQUERY_ID 
>   
>   MESSAGE 
>  
> LOG_FILE_NODE LOG_FILE_NAME   
>  
> LOG_FILE_LINE PARSE_STATUS
> -- --  --- 
> --- ---  --- 
> 
>  
> 
>  - 
> 
>  - 
> 2015-03-24 17:36:00.606000 INFO   MON3
> NULL5775 $MONITORNULL NULL
>   
>TID: 5775, Message ID: 101020103, [CMonitor::main], 
> monitor Version 1.0.1 Release 1.1.0 (Build release [1.0.0-237-gf89a122_Bld9], 
> branch f89a122-master, date 20150324_083001), Started! CommType: Sockets  
>2 mon.20150324.17.35.59.centos-mapr3.5775.log  
> 1
> 2015-03-24 17:36:00.607000 INFO   MON3
> NULL5775 $MONITORNULL NULL
>   
>TID: 5775, Message ID: 101010401, [CCluster::CCluster] 
> Validation of node down is enabled
> 2 mon.20150324.17.35.59.centos-mapr3.5775.log 
>  2
> 2015-03-24 17:36:40.004000 NULL   NULLNULL
> NULLNULL NULLNULL NULL
>   
>:24095(0x7f9cc387fac0):ZOO_INFO@log_env@723: Client 
> environment:os.name=Linux 
>0 mon.20150324.17.35.59.centos-mapr5.23499.log 
> 8 
> E
> 2015-03-24 17:36:40.004000 NULL   NULLNULL
> NULLNULL NULLNULL NULL
>   
>:24095(0x7f9cc387fac0):ZOO_INFO@log_env@724: Client 
> environment:os.arch=2.6.32-358.23.2.el6.x86_64
>0 mon.20150324.17.35.59.centos-mapr5.23499.log 
> 9 
> E
> 2015-03-24 17:36:40.004000 NULL   NULLNULL
> NULLNULL NULLNULL NULL
>   
>:24095(0x7f9cc387fac0):ZOO_INFO@log_env@725: Client 
> environment:os.version=#1 SMP Wed Oct 16 18:37:12 UTC 2013
>0 mon.20150324.17.35.59.centos-mapr5.23499.log  

[jira] [Updated] (TRAFODION-986) LP Bug: 1419906 - pthread_mutex calls do not always check return code

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-986:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1419906 - pthread_mutex calls do not always check return code
> -
>
> Key: TRAFODION-986
> URL: https://issues.apache.org/jira/browse/TRAFODION-986
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: foundation
>Reporter: dave george
>Assignee: Prashanth Vasudev
>Priority: Major
>
> In quite a few places, the code shows:
>   pthread_mutex_lock() or pthread_mutex_unlock()
> The return code from these calls should be checked.
> A more generic summary would be something like:
> return codes from functions that return error codes should be checked.
> It may be possible to use coverity or other such tool in trying to automate 
> the more general issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1099) LP Bug: 1437384 - sqenvcom.sh. Our CLASSPATH is too big.

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1099:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1437384 - sqenvcom.sh.Our CLASSPATH is too big.
> ---
>
> Key: TRAFODION-1099
> URL: https://issues.apache.org/jira/browse/TRAFODION-1099
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Reporter: Guy Groulx
>Assignee: Sandhya Sundaresan
>Priority: Major
>
> sqenvcom.sh sets up CLASSPATH for trafodion.
> With HDP2.2, this CLASSPATH is huge.   On one of our system, echo $CLASSPATH 
> | wc -l return > 13000 bytes.
> I believe java/Linux truncates these variables when it's too big.
> Since going to HDP 2.2, we've been hit with "class not found" error 
> eventhough the jar is in CLASSPATH.
> http://stackoverflow.com/questions/1237093/using-wildcard-for-classpath 
> explains that we can use wildcards in CLASSPATH to reduce it.
> Rules:
> Use * and not *.jar.Java assumes that * in classpath are for *.jar
> When using export CLASSPATHuse quotes so that * is not expanded.   EG:
> export CLASSPATH=”/usr/hdp/current/hadoop-client/lib/*:${CLASSPATH}”
> We need to modify our sqenvcom.sh to use wildcards instead of putting 
> individual jar.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-909) LP Bug: 1412641 - log4cpp -- Node number in master*.log is always 0

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-909:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1412641 - log4cpp -- Node number in master*.log is always 0
> ---
>
> Key: TRAFODION-909
> URL: https://issues.apache.org/jira/browse/TRAFODION-909
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Gao, Rui-Xian
>Assignee: Sandhya Sundaresan
>Priority: Major
>
> Node number in master*.log is always 0, tm.log has correct number.
> SQL>select [first 5] * from udf(event_log_reader('f')) where 
> log_file_name='master_exec_0_7476.log';
> LOG_TS SEVERITY   COMPONENTNODE_NUMBER 
> CPU PIN PROCESS_NAME SQL_CODEQUERY_ID 
>   
>   MESSAGE 
>  
> LOG_FILE_NODE LOG_FILE_NAME   
>  
> LOG_FILE_LINE PARSE_STATUS
> -- --  --- 
> --- ---  --- 
> 
>  
> 
>  - 
> 
>  - 
> 2015-01-19 04:29:53.454000 INFO   SQL.ESP0
>2   24361 $Z020JW1NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  1
> 2015-01-19 04:29:53.462000 INFO   SQL.ESP0
>2   24360 $Z020JW0NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  2
> 2015-01-19 04:29:53.452000 INFO   SQL.ESP0
>5   31881 $Z050R0WNULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  1
> 2015-01-19 04:35:23.101000 INFO   SQL.ESP0
>51892 $Z0501J2NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  2
> 2015-01-19 04:29:53.454000 INFO   SQL.ESP0
>2   24361 $Z020JW1NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_0_7476.log  
>  1
> --- 5 row(s) selected.
> SQL>select [first 5] * from udf(event_log_reader('f')) where log_file_name 
> like 'tm%';
> LOG_TS SEVERITY   COMPONENT   

[jira] [Updated] (TRAFODION-912) LP Bug: 1412806 - log4cpp : incorrect timestamp in logs for SQL info

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-912:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1412806 - log4cpp : incorrect timestamp in logs for SQL info
> 
>
> Key: TRAFODION-912
> URL: https://issues.apache.org/jira/browse/TRAFODION-912
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Gao, Rui-Xian
>Assignee: Sandhya Sundaresan
>Priority: Major
>
> There are messages which have LOG_TS later than current timestamp logged into 
> the log file.
> current time is '2015-01-20 05:43:05', but there are messges have '2015-01-20 
> 13:16:16' in the log, only for SQL INFO.
> [trafodion@centos-mapr1 logs]$ date
> Tue Jan 20 05:43:05 PST 2015
> SQL>select * from udf(event_log_reader('f')) where log_ts > 
> timestamp'2015-01-20 06:00:00.00' order by 1;
> LOG_TS SEVERITY   COMPONENTNODE_NUMBER 
> CPU PIN PROCESS_NAME SQL_CODEQUERY_ID 
>   
>   MESSAGE 
>  
> LOG_FILE_NODE LOG_FILE_NAME   
>  
> LOG_FILE_LINE PARSE_STATUS
> -- --  --- 
> --- ---  --- 
> 
>  
> 
>  - 
> 
>  - 
> 2015-01-20 06:57:16.974000 INFO   SQL.ESP0
>5   26257 $Z050LF7NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_1_3719.log  
>  1
> 2015-01-20 06:57:16.974000 INFO   SQL.ESP0
>5   26257 $Z050LF7NULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_1_3719.log  
>  1
> 2015-01-20 06:57:17.011000 INFO   SQL.ESP0
>31982 $Z0301LMNULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_1_3719.log  
>  1
> 2015-01-20 06:57:17.011000 INFO   SQL.ESP0
>31982 $Z0301LMNULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_1_3719.log  
>  1
> 2015-01-20 06:57:17.011000 INFO   SQL.ESP0
>31982 $Z0301LMNULL NULL
>   
>An ESP process is launched.
>   
> 0 master_exec_1_3719.log  
> 

[jira] [Updated] (TRAFODION-785) LP Bug: 1395201 - MSG in sqenvcom.sh about Hadoop not find causing sftp to not work.

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-785:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1395201 - MSG in sqenvcom.sh about Hadoop not find causing sftp to 
> not work.
> 
>
> Key: TRAFODION-785
> URL: https://issues.apache.org/jira/browse/TRAFODION-785
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: foundation
>Reporter: Guy Groulx
>Assignee: Atanu Mishra
>Priority: Major
>
> A check is now in sqenvcom.sh which verified if hadoop is available on the 
> node.   If it is not, it displays a message "ERROR: Did not find supported 
> Hadoop distribution".
> Since sqenvcom.sh is used via .bashrc, ie on every ssh, it causes issues.
> eg:   You can not connect sftp to a system where this msg is displayed as 
> sftp does not recognize the message being returned.
> I understand that trafodion software will probably be installed mostly on 
> nodes where hadoop is installed, but in cases where it does not, we should 
> not be affected ssh or sftp ability to connect successfully.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-952) LP Bug: 1415156 - DELETE concurrent with index creation causes corruption

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-952:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1415156 - DELETE concurrent with index creation causes corruption
> -
>
> Key: TRAFODION-952
> URL: https://issues.apache.org/jira/browse/TRAFODION-952
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Apache Trafodion
>Assignee: Prashanth Vasudev
>Priority: Major
>
> If queries delete rows from a table during CREATE INDEX there is a risk that 
> the index will have more rows than the base table. See the example sqlci 
> session quoted below. Note that the delete happens in the background with no 
> output shown. The test script is attached.
> >>
> >>obey index_corrupter_traf(cr_table);
> >>create table t113b  (uniq int not null,
> +>   c100k int,   c10K int ,   c1K   int,   c100  int,   
> +>   c10   int,   c1int,   primary key (uniq)  );
> --- SQL operation complete.
> >>
> >>prepare s1 from upsert using load into t113b select
> +>0 + (10 * x10) + (1 * x1) + (1000 * x1000) + 
> +>  (100 * x100) + (10 * x10) +( 1 * x1),
> +>0 + (1 * x1) + (1000 * x1000) + (100 * x100) + 
> +>  (10 * x10) +( 1 * x1),
> +>0 + (1000 * x1000) + (100 * x100) + (10 * x10) + (1 * x1),
> +>0 + (100 * x100) + (10 * x10) + (1 * x1),
> +>0 + (10 * x10) + (1 * x1),
> +>0 + (1 * x1),
> +>0
> +>from (values(0)) t
> +>transpose 0,1,2,3,4,5,6,7,8,9 as x10
> +>transpose 0,1,2,3,4,5,6,7,8,9 as x1
> +>transpose 0,1,2,3,4,5,6,7,8,9 as x1000
> +>transpose 0,1,2,3,4,5,6,7,8,9 as x100
> +>transpose 0,1,2,3,4,5,6,7,8,9 as x10
> +>transpose 0,1,2,3,4,5,6,7,8,9 as x1;
> --- SQL command prepared.
> >>
> >>explain options 'f' s1;
> LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD
>          -
> 9.10   root  1.00E+007
> 789tuple_flow1.00E+007
> ..8trafodion_load  T113B 1.00E+000
> 6.7transpose 1.00E+006
> 5.6transpose 1.00E+005
> 4.5transpose 1.00E+004
> 3.4transpose 1.00E+003
> 2.3transpose 1.00E+002
> 1.2transpose 1.00E+001
> ..1values1.00E+000
> --- SQL operation complete.
> >>
> >>display qid for s1;
> QID is MXID11151972122891392598747010206U300_478_S1
> QID details: 
> 
>   Segment Num:  0
>   Segment Name: 
>   Cpu:  0
>   Pin:  15197
>   ExeStartTime: 212289139259874701= 2015/01/27 17:20:59.874701 LCT
>   SessionNum:   2
>   UserName: U3
>   SessionName:  NULL
>   QueryNum: 478
>   StmtName: S1
>   SessionId:MXID11151972122891392598747010206U300
> >>
> >>execute s1;
> --- 100 row(s) inserted.
> >>
> >>get statistics for qid current;
> Qid  
> MXID11151972122891392598747010206U300_478_S1
> Compile Start Time   2015/01/27 17:21:18.824433
> Compile End Time 2015/01/27 17:21:20.080504
> Compile Elapsed Time 0:00:01.256071
> Execute Start Time   2015/01/27 17:21:20.124949
> Execute End Time 2015/01/27 17:22:24.244243
> Execute Elapsed Time 0:01:04.119294
> StateCLOSE
> Rows Affected1,000,000
> SQL Error Code   0
> Stats Error Code 0
> Query Type   SQL_INSERT_NON_UNIQUE
> Sub Query Type   SQL_STMT_NA
> Estimated Accessed Rows  0
> Estimated Used Rows  0
> Parent Qid   NONE
> Parent Query System  NONE
> Child QidNONE
> Number of SQL Processes  1
> Number of Cpus   1
> Transaction Id   -1
> Source Stringupsert using load into t113b select 0 + (10 * 
> x10) + (1 * x1) + (1000 * x1000) +(100 * x100) + (10 * x10) 
> +( 1 * x1), 0 + (1 * x1) + (1000 * x1000) + (100 * x100) +(10 * 
> x10) +( 1 * x1), 0 + (1000 * x1000) + (100 * x100) +
> SQL Source Length613
> Rows Returned0
> First Row Returned Time  -1
> Last Error before AQR0
> Number of AQR retries0
> Delay before AQR 0
> No. of times reclaimed   0
> Cancel Time  -1
> Last Suspend Time-1
> Stats 

[jira] [Updated] (TRAFODION-880) LP Bug: 1409928 - Number of transactions being recovered is always 0

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-880:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1409928 - Number of transactions being recovered is always 0
> 
>
> Key: TRAFODION-880
> URL: https://issues.apache.org/jira/browse/TRAFODION-880
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: dtm
>Reporter: Marvin Anderson
>Assignee: Atanu Mishra
>Priority: Major
>
> During sqstart a message displays the number of transactions being recovered. 
>  It is always zero even when transactions are being recovered.  It should 
> reflect a non-zero count.  Whether that is actual transactions or regions or 
> TMs recovering doesn't matter but it should display some values.
> Assigned to LaunchPad User Adriana Fuentes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1278) LP Bug: 1465899 - Create table LIKE hive table fails silently

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1278:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1465899 - Create table LIKE hive table fails silently
> -
>
> Key: TRAFODION-1278
> URL: https://issues.apache.org/jira/browse/TRAFODION-1278
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Reporter: Barry Fritchman
>Assignee: Qifan Chen
>Priority: Critical
>
> When using the CREATE TABLE  LIKE  syntax with a hive table as 
> , the statement appears to execute successfully, but the table is in 
> fact not created:
> >>create table traf_orders like hive.hive.orders;
> --- SQL operation complete.
> >>invoke traf_orders;
> *** ERROR[4082] Object TRAFODION.SEABASE.TRAF_ORDERS does not exist or is 
> inaccessible.
> --- SQL operation failed with errors.
> >>
> The problem seems to occur only when a Hive table is the source.  This 
> problem causes an error when attempting to update statistics for a hive table 
> using sampling, because the sample table is not created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-444) LP Bug: 1342180 - Memory leak in cmp context heap when cli context is deallocated

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-444:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1342180 - Memory leak in cmp context heap when cli context is 
> deallocated
> -
>
> Key: TRAFODION-444
> URL: https://issues.apache.org/jira/browse/TRAFODION-444
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Pavani Puppala
>Assignee: Qifan Chen
>Priority: Major
>
> When SQL_EXEC_DeleteContext is called the second cmp context used for 
> reentrant compiler for metadata queries is not being deallocated.  This 
> causes memory leak where the cmp context heap allocated for the metadata cmp 
> context is not deleted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-608) LP Bug: 1367413 - metadata VERSIONS table need to be updated with current version

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-608:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1367413 - metadata VERSIONS table need to be updated with current 
> version
> -
>
> Key: TRAFODION-608
> URL: https://issues.apache.org/jira/browse/TRAFODION-608
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Anoop Sharma
>Assignee: Anoop Sharma
>Priority: Major
>
> Metadata contains VERSIONS table which contains the released software version.
> This table can be accessed by users through SQL interface.
> This should  be updated with latest software version values whenever software 
> is installed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-284) LP Bug: 1321058 - TRAFDSN should be eliminated, Trafodion ODBC linux driver should use the standard config files, odbc.ini and odbcinst.ini

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-284:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1321058 - TRAFDSN should be eliminated, Trafodion ODBC linux driver 
> should use the standard config files, odbc.ini and odbcinst.ini
> ---
>
> Key: TRAFODION-284
> URL: https://issues.apache.org/jira/browse/TRAFODION-284
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: client-odbc-linux
>Reporter: Aruna Sadashiva
>Assignee: Anuradha Hegde
>Priority: Major
>
> Traf ODBC driver should use the standard odbc ini files for configuration, 
> instead of custom config file TRAFDSN. If we don't install to default 
> location, user has to have TRAFDSN in application dir, there is no way to 
> specify TRAFDSN location to driver.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1242) LP Bug: 1457207 - Create table and constraint using the same name returns error 1043

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1242:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1457207 - Create table and constraint using the same name returns 
> error 1043
> 
>
> Key: TRAFODION-1242
> URL: https://issues.apache.org/jira/browse/TRAFODION-1242
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Weishiun Tsai
>Assignee: Anoop Sharma
>Priority: Critical
>
> Create a table with a constraint that has the same name as the table itself 
> now returns a perplexing 1043 error complaining that the constraint already 
> exists.  This is a regression introduced sometime between the v0513 build and 
> the v0519 build.  It had been working fine until the v0513 build where SQL 
> tests were last run.
> This is seen on the v0513 build.
> --
> Here is the entire script to reproduce it:
> create schema mytest;
> set schema mytest;
> create table t1 (c1 int , c2 int constraint t1 check (c2 > 10));
> drop schema mytest cascade;
> --
> Here is the execution output:
> >>create schema mytest;
> --- SQL operation complete.
> >>set schema mytest;
> --- SQL operation complete.
> >>create table t1 (c1 int , c2 int constraint t1 check (c2 > 10));
> *** ERROR[1043] Constraint TRAFODION.MYTEST.T1 already exists.
> *** ERROR[1029] Object TRAFODION.MYTEST.T1 could not be created.
> --- SQL operation failed with errors.
> >>drop schema mytest cascade;
> --- SQL operation complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1241) LP Bug: 1456304 - mtserver - spjs with resultsets failing - no results returned

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1241:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1456304 - mtserver - spjs with resultsets failing - no results 
> returned
> ---
>
> Key: TRAFODION-1241
> URL: https://issues.apache.org/jira/browse/TRAFODION-1241
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: client-jdbc-t2
>Reporter: Aruna Sadashiva
>Assignee: Anuradha Hegde
>Priority: Critical
>
> SPJ tests with result sets failed because there are no result sets returned 
> from the procedure.  the same SPJ works from sqlci, but fails from trafci. 
> Steps:
> -
> SQL>create table t1 (a int not null primary key, b varchar(20));
> SQL>insert into t1 values(111, 'a');
> SQL>insert into t1 values(222, 'b');
> SQL>create library testrs file '/opt/home/trafodion/SPJ/testrs.jar';
> SQL>create procedure RS200()
>language java
>parameter style java
>external name 'Testrs.RS200'
>dynamic result sets 1
>library testrs;
> SQL>call rs200();
> --- SQL operation complete.
> -
> The expected result is:
> SQL >call rs200();
> AB
> ---  
> 111  a
> 222  b
> --- 2 row(s) selected.
> --- SQL operation complete.
> The jar file, testrs.jar, is on amber7 under /opt/home/trafodion/SPJ.  It has 
> the SPJ procedure:
>public static void RS200(ResultSet[] paramArrayOfResultSet)
>throws Exception
>{
>  String str1 = "jdbc:default:connection";
>  
>  String str2 = "select * from t1";
>  Connection localConnection = DriverManager.getConnection(str1);
>  Statement localStatement = localConnection.createStatement();
>  paramArrayOfResultSet[0] = localStatement.executeQuery(str2);
>}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1251) LP Bug: 1459804 - mtserver - ODBC catalog apis fail with comm link failure

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1251:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1459804 - mtserver - ODBC catalog apis fail with comm link failure
> --
>
> Key: TRAFODION-1251
> URL: https://issues.apache.org/jira/browse/TRAFODION-1251
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-dcs
>Reporter: Aruna Sadashiva
>Assignee: Rao Kakarlamudi
>Priority: Critical
>
> With mtserver config odbc catalog apis are failing with communication link 
> failure. 
> SQLColumns:
>   In: StatementHandle 
> = 0x005ECF00, 
>   
> CatalogName = "TRAFODION", NameLength1 = 9, SchemaName = "T4QA", NameLength2 
> = 4, 
>   
> TableName = "TABALL", NameLength3 = 6, ColumnName = "%", NameLength4 = 1
>   Return: SQL_ERROR=-1
>   stmt:   szSqlState = "08S01", 
> *pfNativeError = 98, *pcbErrorMsg = 255, *ColumnNumber = -1, *RowNumber = -2
>   
> MessageText = "[TRAF][Trafodion ODBC Driver] Communication link failure. The 
> server timed out or disappeared Platform: PC, Transport: TCPIP, Api: 
> GETCATALOGS, Error type: DRIVER, Process: 
> TCP:g4q0014.houston.hp.com/37806:ODBC, Operation: DO_WRITE_READ, function: 
> RECV_GE"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1250) LP Bug: 1459763 - mtserver - explain plan fails with 'provided input stmt does not exist', works from sqlci

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1250:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1459763 - mtserver - explain plan fails with 'provided input stmt 
> does not exist', works from sqlci
> ---
>
> Key: TRAFODION-1250
> URL: https://issues.apache.org/jira/browse/TRAFODION-1250
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-dcs
>Reporter: Aruna Sadashiva
>Assignee: Rao Kakarlamudi
>Priority: Critical
>
> Explain is not working with mtserver thru jdbc. It works ok from sqlci.
> SQL>explain options 'f' select * from t4qa.taball;
>  
> LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD   
>          -
>  
> 1.2root  1.00E+004
> ..1trafodion_scan  TABALL1.00E+004
> --- SQL operation complete.
> SQL>prepare s02 from select * from t4qa.taball;
> --- SQL command prepared.
> SQL>explain s02;
> *** ERROR[8804] The provided input statement does not exist in the current 
> context.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1235) LP Bug: 1453969 - User CQDs should not affect internal query compilation and execution

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1235:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1453969 - User CQDs should not affect internal query compilation and 
> execution
> --
>
> Key: TRAFODION-1235
> URL: https://issues.apache.org/jira/browse/TRAFODION-1235
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Weishiun Tsai
>Assignee: Sandhya Sundaresan
>Priority: Critical
>
> Currently, user CQD settings would impact internal query compilation and 
> execution.  This is causing strange errors in unexpected places.  The 
> following scenario is one of such examples.  Setting the CQD 
> UPDATE_CLUSTERING_OR_UNIQUE_INDEX_KEY ‘OFF’ caused the next alter rename 
> statement to fail with a perplexing 4033 error.  The statement worked fine 
> after the CQD was reset.
> This case is filed not only about this particular CQD.  In general, we need 
> to avoid sending user CQDs to internal query compilation and execution.  
> Trafodion has hundreds of CQDs.  Some of them may be recommended to customers 
> in the future to improve performance or to work around certain problems.  If 
> we don’t stop sending CQDs to internal query compilation, this problem is 
> bound to show up again and again in the future.
> This problem can be seen on the v0505 build.
> ---
> Here is the entire script to reproduce it:
> create schema testsch;
> set schema testsch;
> create table t1 (a int);
> control query default UPDATE_CLUSTERING_OR_UNIQUE_INDEX_KEY 'OFF';
> alter table t1 rename to t2;
> control query default UPDATE_CLUSTERING_OR_UNIQUE_INDEX_KEY reset;
> alter table t1 rename to t2;
> drop schema testsch cascade;
> ---
> Here is the execution output:
> >>create schema testsch;
> --- SQL operation complete.
> >>set schema testsch;
> --- SQL operation complete.
> >>create table t1 (a int);
> --- SQL operation complete.
> >>control query default UPDATE_CLUSTERING_OR_UNIQUE_INDEX_KEY 'OFF';
> --- SQL operation complete.
> >>alter table t1 rename to t2;
> *** ERROR[4033] Column CATALOG_NAME is a primary or clustering key column and 
> cannot be updated.
> *** ERROR[8822] The statement was not prepared.
> --- SQL operation failed with errors.
> >>control query default UPDATE_CLUSTERING_OR_UNIQUE_INDEX_KEY reset;
> --- SQL operation complete.
> >>alter table t1 rename to t2;
> --- SQL operation complete.
> >>drop schema testsch cascade;
> --- SQL operation complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1127) LP Bug: 1439541 - mxosrvr core when zookeeper connection gets dropped due to timeout

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1127:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1439541 - mxosrvr core when zookeeper connection gets dropped due to 
> timeout
> 
>
> Key: TRAFODION-1127
> URL: https://issues.apache.org/jira/browse/TRAFODION-1127
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-mxosrvr
>Reporter: Aruna Sadashiva
>Assignee: Rao Kakarlamudi
>Priority: Critical
>
> Mxosrvr cores were seen on Zircon during perf tests. the connection to 
> zookeeper is getting dropped (zh=0x0) – maybe because of timeout or other 
> errors.
> #0  0x74a318a5 in raise () from /lib64/libc.so.6
> #1  0x74a3300d in abort () from /lib64/libc.so.6
> #2  0x75d50a55 in os::abort(bool) ()
>from /usr/java/jdk1.7.0_67/jre/lib/amd64/server/libjvm.so
> #3  0x75ed0f87 in VMError::report_and_die() ()
>from /usr/java/jdk1.7.0_67/jre/lib/amd64/server/libjvm.so
> #4  0x75d5596f in JVM_handle_linux_signal ()
>from /usr/java/jdk1.7.0_67/jre/lib/amd64/server/libjvm.so
> #5  
> #6  0x765bcce9 in zoo_exists (zh=0x0, 
> path=0xeb2598 
> "/squser4/dcs/servers/registered/zircon-n018.usa.hp.com:8:88", watch=0, 
> stat=0x7fffe61bf080) at src/zookeeper.c:3503
> #7  0x004c59f5 in updateZKState (currState=CONNECTED, 
> newState=AVAILABLE) at SrvrConnect.cpp:9057
> #8  0x004ca966 in odbc_SQLSvc_TerminateDialogue_ame_ (
> objtag_=0xedb8b0, call_id_=0xedb908, dialogueId=313965727)
> at SrvrConnect.cpp:3885
> #9  0x00493dce in DISPATCH_TCPIPRequest (objtag_=0xedb8b0, 
> call_id_=0xedb908, operation_id=)
> at Interface/odbcs_srvr.cpp:1772
> #10 0x00433882 in BUILD_TCPIP_REQUEST (pnode=0xedb8b0)
> at ../Common/TCPIPSystemSrvr.cpp:603
> #11 0x0043421d in PROCESS_TCPIP_REQUEST (pnode=0xedb8b0)
> ---Type  to continue, or q  to quit---
> at ../Common/TCPIPSystemSrvr.cpp:581
> #12 0x00462406 in CNSKListenerSrvr::tcpip_listener (arg=0xda5510)
> at Interface/linux/Listener_srvr_ps.cpp:400
> #13 0x747e52e0 in sb_thread_sthr_disp (pp_arg=0xeb4c70)
> at threadl.cpp:253
> #14 0x745b1851 in start_thread () from /lib64/libpthread.so.0
> #15 0x74ae790d in clone () from /lib64/libc.so.6



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1162) LP Bug: 1443246 - WRONG QUERY_STATUS/QUERY_SUB_STATUS for canceled queries in METRIC_QUERY_TABLE

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1162:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1443246 - WRONG QUERY_STATUS/QUERY_SUB_STATUS for canceled queries in 
> METRIC_QUERY_TABLE
> 
>
> Key: TRAFODION-1162
> URL: https://issues.apache.org/jira/browse/TRAFODION-1162
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-mxosrvr
>Reporter: FengQiang
>Assignee: Gao Jie
>Priority: Critical
>
> Two scenarios for this issue
> 1. Cancel a running query with sql command control query cancel qid 
> "MXID11136022122946686468383500906U300_32053_XX".
> In "_REPOS_".METRIC_QUERY_TABLE, it has value for EXEC_END_UTC_TS. But 
> QUERY_STATUS is COMPLETED and no value for QUERY_SUB_STATUS. Should either of 
> the status tells that the query was canceled?
> 2. Kill the trafci client while a select query is still running.
> In "_REPOS_".METRIC_QUERY_TABLE, it has value for EXEC_END_UTC_TS. But 
> QUERY_STATUS remains 'EXECUTING' and no value for QUERY_SUB_STATUS. Should 
> either of the status tells that the query was canceled?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1208) LP Bug: 1449195 - mxosrvr failing to write to repos session and aggr metric table when we test connection from odbc administrator, errors in master log

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1208:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1449195 - mxosrvr failing to write to repos session and aggr metric 
> table when we test connection from odbc administrator,  errors in master log
> 
>
> Key: TRAFODION-1208
> URL: https://issues.apache.org/jira/browse/TRAFODION-1208
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-mxosrvr
>Reporter: Aruna Sadashiva
>Assignee: Anuradha Hegde
>Priority: Critical
>
> After trying etst connection from odbc administrator on Windows, the 
> following errors are logged in the master log file and there are no rows 
> inserted into the metric session and aggr tables. The test connection 
> succeeds. 
> 2015-04-27 17:54:28,169, ERROR, SQL, Node Number: 0, CPU: 3, PIN: 20885, 
> Process Name: $Z030H1Q, SQLCODE: 15001, QID: 
> MXID110030208852122969171678495210306U300_483_STMT_PUBLICATION, 
> *** ERROR[15001] A syntax error occurred at or before: 
> insert into Trafodion."_REPOS_".metric_query_aggr_table 
> values(0,0,0,20885,2088
> 5,3,0,0,'16.235.158.28',0,'$Z030H1Q','MXID11003020885212296917167849521
> 0406U300',CONVERTTIMESTAMP(212296917268168600),CONVERTTIMESTAMP(21229691726
> 8168603),6,3,'DB__ROOT','NONE','SARUNA2','saruna','Trafodion ODBC 
> Data 
> Source 'amethyst' 
> Configuration',0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>^ (332 characters from start of SQL statement)
> 2015-04-27 17:54:28,169, ERROR, MXOSRVR, Node Number: 3, CPU: 3, PIN:20885, 
> Process Name:$Z030H1Q , , ,A NonStop Process Service error Failed to write 
> statistics: insert into Trafodion."_REPOS_".metric_query_aggr_table 
> values(0,0,0,20885,20885,3,0,0,'16.235.158.28',0,'$Z030H1Q','MXID110030208852122969171678495210406U300',CONVERTTIMESTAMP(212296917268168600),CONVERTTIMESTAMP(212296917268168603),6,3,'DB__ROOT','NONE','SARUNA2','saruna','Trafodion
>  ODBC Data Source 'amethyst' 
> Configuration',0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)Error
>  detail - *** ERROR[15001] A syntax error occurred at or before: 
> insert into Trafodion."_REPOS_".metric_query_aggr_table 
> values(0,0,0,20885,2088
> 5,3,0,0,'16.235.158.28',0,'$Z030H1Q','MXID11003020885212296917167849521
> 0406U300',CONVERTTIMESTAMP(212296917268168600),CONVERTTIMESTAMP(21229691726
> 8168603),6,3,'DB__ROOT','NONE','SARUNA2','saruna','Trafodion ODBC 
> Data 
> Source 'amethyst' 
> Configuration',0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>^ (332 characters from start of SQL statement) [2015-04-27 
> 17:54:28] has occurred. 
> 2015-04-27 17:54:33,241, ERROR, SQL, Node Number: 0, CPU: 3, PIN: 20885, 
> Process Name: $Z030H1Q, SQLCODE: 15001, QID: 
> MXID110030208852122969171678495210306U300_487_STMT_PUBLICATION, 
> *** ERROR[15001] A syntax error occurred at or before: 
> insert into Trafodion."_REPOS_".metric_session_table 
> values(0,0,0,20885,20885,3
> ,0,0,'16.235.158.28',0,'$Z030H1Q','MXID11003020885212296917167849521040
> 6U300','END',CONVERTTIMESTAMP(212296917268168600),CONVERTTIMESTAMP(21229691
> 7273198784),3,'DB__ROOT','NONE','SARUNA2','saruna','Trafodion ODBC Data 
> Sou
> rce 'amethyst' Configuration',0,0,0,0,0,0,0,0,0,0,0,0,0,0,5827,29,0,0,0,0,0);
> ^ (329 characters from start of SQL statement)
> 2015-04-27 17:54:33,241, ERROR, MXOSRVR, Node Number: 3, CPU: 3, PIN:20885, 
> Process Name:$Z030H1Q , , ,A NonStop Process Service error Failed to write 
> statistics: insert into Trafodion."_REPOS_".metric_session_table 
> values(0,0,0,20885,20885,3,0,0,'16.235.158.28',0,'$Z030H1Q','MXID110030208852122969171678495210406U300','END',CONVERTTIMESTAMP(212296917268168600),CONVERTTIMESTAMP(212296917273198784),3,'DB__ROOT','NONE','SARUNA2','saruna','Trafodion
>  ODBC Data Source 'amethyst' 
> Configuration',0,0,0,0,0,0,0,0,0,0,0,0,0,0,5827,29,0,0,0,0,0)Error detail 
> - *** ERROR[15001] A syntax error occurred at or before: 
> insert into Trafodion."_REPOS_".metric_session_table 
> values(0,0,0,20885,20885,3
> ,0,0,'16.235.158.28',0,'$Z030H1Q','MXID11003020885212296917167849521040
> 6U300','END',CONVERTTIMESTAMP(212296917268168600),CONVERTTIMESTAMP(21229691
> 7273198784),3,'DB__ROOT','NONE','SARUNA2','saruna','Trafodion ODBC Data 
> Sou
> rce 'amethyst' Configuration',0,0,0,0,0,0,0,0,0,0,0,0,0,0,5827,29,0,0,0,0,0);
> ^ (329 characters from start of SQL statement) [2015-04-27 
> 17:54:33] has occurred.



--
This 

[jira] [Updated] (TRAFODION-1240) LP Bug: 1455679 - mtserver - spjs with output params fail with error 29019

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1240:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1455679 - mtserver - spjs with output params fail with error 29019
> --
>
> Key: TRAFODION-1240
> URL: https://issues.apache.org/jira/browse/TRAFODION-1240
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-dcs
>Reporter: Aruna Sadashiva
>Assignee: Anuradha Hegde
>Priority: Critical
>
> With multithreaded dcs, SPJs with output params are failing.
> SQL>create library spjcall file '/opt/home/trafodion/SPJ/call.jar';
> SQL>Create procedure N0210 (in in1 int, out out1 int)
> external name 'Procs.N0210'
> library spjcall
> language java
> parameter style java;
> SQL>Call N0210(64548478,?);
> *** ERROR[29019] Parameter 1 for 1 set of parameters is not set
> The SPJ jar file, call.jar, can be found on amber7 under 
> /opt/home/trafodion/SPJ. It has a very simple SPJ procedure:
>   public static void N0210(int paramInt, int[] paramArrayOfInt)
>   {
> paramArrayOfInt[0] = paramInt;
>   }



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-1107) LP Bug: 1438466 - Multiple tdm_arkcmp child processes started after receipt of HBase error

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1107:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1438466 - Multiple tdm_arkcmp child processes started after receipt 
> of HBase error
> --
>
> Key: TRAFODION-1107
> URL: https://issues.apache.org/jira/browse/TRAFODION-1107
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Joanie Cooper
>Assignee: Qifan Chen
>Priority: Critical
>
> During a fresh test of running the compGeneral regression suite
> while artificially interjecting an error return from the TrxRegionEndpoint
> coprocessor, numerous tdm_arkcmp child processes were started.
> Before the error hit, we seemed to have a normal number of compilers
> [$Z0005MG] 000,3170 001 GEN  ES--A-- $Z0002KK$Z0002IVtdm_arkcmp   
>   
> [$Z0005MG] 000,3292 001 GEN  ES--A-- $Z0002P2$Z0002KKtdm_arkcmp   
>   
> [$Z0005MG] 000,3816 001 GEN  ES--A-- $Z000341$Z0002P2tdm_arkcmp   
>   
> [$Z0005MG] 000,3886 001 GEN  ES--A-- $Z000361$Z000341tdm_arkcmp
> After forcing the error, it looks like we have new compilers being generated,
> all ultimately part of the original tdm_arkcmp parent off of the sqlci 
> session.
> This is a result of a drop statement.  From the sqlci window, the
> statement appears hung, as it never returns.  But, it appears the
> compilers keep generating new children and the query ultimately never returns.
> When I killed the query, it had 174 compilers running.
> I tried a pstack for one of the compilers, I’ve attached it below.
> g4t3037{joaniec}3: sqps
> Processing cluster.conf on local host g4t3037.houston.hp.com
> [$Z000AF9] Shell/shell Version 1.0.1 Release 1.1.0 (Build release [joaniec], 
> date 26Mar15)
> [$Z000AF9] %ps  
> [$Z000AF9] NID,PID(os)  PRI TYPE STATES  NAMEPARENT  PROGRAM
> [$Z000AF9]  ---  --- --- --- 
> ---
> [$Z000AF9] 000,00018562 000 WDG  ES--A-- $WDG000 NONEsqwatchdog   
>   
> [$Z000AF9] 000,00018563 000 PSD  ES--A-- $PSD000 NONEpstartd  
>   
> [$Z000AF9] 000,00018592 001 DTM  ES--A-- $TM0NONEtm   
>   
> [$Z000AF9] 000,00019243 001 GEN  ES--A-- $ZSC000 NONEmxsscp   
>   
> [$Z000AF9] 000,00019274 001 SSMP ES--A-- $ZSM000 NONEmxssmp   
>   
> [$Z000AF9] 000,00020982 001 GEN  ES--A-- $ZLOBSRV0   NONEmxlobsrvr
>   
> [$Z000AF9] 000,7356 001 GEN  ES--A-- $Z000606NONEsqlci
>   
> [$Z000AF9] 000,7416 001 GEN  ES--A-- $Z00061W$Z000606tdm_arkcmp   
>   
> [$Z000AF9] 000,7960 001 GEN  ES--A-- $Z0006HF$Z00061Wtdm_arkcmp   
>   
> [$Z000AF9] 000,8021 001 GEN  ES--A-- $Z0006J6$Z0006HFtdm_arkcmp   
>   
> [$Z000AF9] 000,8079 001 GEN  ES--A-- $Z0006KU$Z0006J6tdm_arkcmp   
>   
> [$Z000AF9] 000,8137 001 GEN  ES--A-- $Z0006MH$Z0006KUtdm_arkcmp   
>   
> [$Z000AF9] 000,8194 001 GEN  ES--A-- $Z0006P4$Z0006MHtdm_arkcmp   
>   
> [$Z000AF9] 000,8252 001 GEN  ES--A-- $Z0006QS$Z0006P4tdm_arkcmp   
>   
> [$Z000AF9] 000,8312 001 GEN  ES--A-- $Z0006SH$Z0006QStdm_arkcmp   
>   
> [$Z000AF9] 000,8369 001 GEN  ES--A-- $Z0006U4$Z0006SHtdm_arkcmp   
>   
> [$Z000AF9] 000,8427 001 GEN  ES--A-- $Z0006VS$Z0006U4tdm_arkcmp   
>   
> [$Z000AF9] 000,8491 001 GEN  ES--A-- $Z0006XL$Z0006VStdm_arkcmp   
>   
> [$Z000AF9] 000,9023 001 GEN  ES--A-- $Z0007CT$Z0006XLtdm_arkcmp   
>   
> [$Z000AF9] 000,9081 001 GEN  ES--A-- $Z0007EG$Z0007CTtdm_arkcmp   
>   
> [$Z000AF9] 000,9141 001 GEN  ES--A-- $Z0007G6$Z0007EGtdm_arkcmp   
>   
> [$Z000AF9] 000,9202 001 GEN  ES--A-- $Z0007HX$Z0007G6tdm_arkcmp   
>   
> [$Z000AF9] 000,9262 001 GEN  ES--A-- $Z0007JM$Z0007HXtdm_arkcmp   
>   
> [$Z000AF9] 000,9320 001 GEN  ES--A-- $Z0007LA$Z0007JMtdm_arkcmp   
>   
> [$Z000AF9] 000,9489 001 GEN  ES--A-- $Z0007R4$Z0007LAtdm_arkcmp   
>   
> [$Z000AF9] 000,9547 001 GEN  ES--A-- $Z0007SS$Z0007R4tdm_arkcmp   
>   
> [$Z000AF9] 000,9604 001 GEN  ES--A-- $Z0007UE$Z0007SStdm_arkcmp   
>   
> [$Z000AF9] 000,9661 001 GEN  ES--A-- $Z0007W1$Z0007UEtdm_arkcmp   
>   
> [$Z000AF9] 000,9728 001 GEN  ES--A-- $Z0007XY$Z0007W1tdm_arkcmp   
>   
> [$Z000AF9] 000,00010268 001 GEN  ES--A-- $Z0008DD$Z0007XYtdm_arkcmp   
>   
> [$Z000AF9] 000,00010364 001 GEN  ES--A-- $Z0008G4$Z0008DDtdm_arkcmp   
>   
> [$Z000AF9] 000,00010421 001 GEN  ES--A-- $Z0008HR$Z0008G4tdm_arkcmp   
>   
> 

[jira] [Updated] (TRAFODION-1062) LP Bug: 1432950 - When stats type is set to Query, every query should be logged in the metric query table

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1062:
--
Fix Version/s: (was: 2.2.0)

> LP Bug: 1432950 - When stats type is set to Query, every query should be 
> logged in the metric query table
> -
>
> Key: TRAFODION-1062
> URL: https://issues.apache.org/jira/browse/TRAFODION-1062
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-general
>Reporter: Aruna Sadashiva
>Assignee: Anuradha Hegde
>Priority: Critical
>  Labels: repos
>
> When stats type is set to "query", all queries should be found in 
> _REPOS_.METRIC_QUERY_TABLE. Currently only long running queries, that run 
> longer than interval time get logged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-924) LP Bug: 1413241 - ENDTRANSACTION hang, transaction state FORGETTING

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-924:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1413241 - ENDTRANSACTION hang, transaction state FORGETTING
> ---
>
> Key: TRAFODION-924
> URL: https://issues.apache.org/jira/browse/TRAFODION-924
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: dtm
>Reporter: Apache Trafodion
>Assignee: Atanu Mishra
>Priority: Critical
>
> A loop to reexecute the seabase developer regression suite hung on the 14th 
> iteration in TEST016. The sqlci console looked like this:
> >>-- char type
> >>create table mcStatPart1
> +>(a int not null not droppable,
> +>b char(10) not null not droppable,
> +>f int, txt char(100),
> +>primary key (a,b))
> +>salt using 8 partitions ;
> --- SQL operation complete.
> >>
> >>insert into mcStatPart1 values 
> >>(1,'123',1,'xyz'),(1,'133',1,'xyz'),(1,'423',1,'xyz'),(2,'111',1,'xyz'),(2,'223',1,'xyz'),(2,'323',1,'xyz'),(2,'423',1,'xyz'),
> +>   
> (3,'123',1,'xyz'),(3,'133',1,'xyz'),(3,'423',1,'xyz'),(4,'111',1,'xyz'),(4,'223',1,'xyz'),(4,'323',1,'xyz'),(4,'423',1,'xyz');
> A pstack of the sqlci (0,13231) showed it blocking in a call to 
> ENDTRANSACTION.   And dtmci showed this for the transaction:
> DTMCI > list
> Transid Owner eventQ  pending Joiners TSEsState
> (0,13742)   0,13231   0   0   0   0   FORGETTING
> Here's a copy of Sean's analysis:
> From: Broeder, Sean 
> Sent: Wednesday, January 21, 2015 8:43 AM
> To: Hanlon, Mike; Cooper, Joanie
> Cc: DeRoo, John
> Subject: RE: ENDTRANSACTION hang, transaction state FORGETTING
> Hi Mike,
> It looks like we have a zookeeper problem right at the time of the commit.  A 
> table is offline:
> 2015-01-21 11:13:45,529 WARN zookeeper.ZKUtil: 
> hconnection-0x1646b7c-0x14aefd0ac4a5e18, quorum=localhost:47570, 
> baseZNode=/hbase Unable to get data of znode 
> /hbase/table/TRAFODION.HBASE.MCSTATPART1
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
> = ConnectionLoss for /hbase/table/TRAFODION.HBASE.MCSTATPART1
> Then we fail after 3 retries of sending the commit request
> 2015-01-21 11:14:04,405 ERROR transactional.TransactionManager: doCommitX, 
> result size: 0
> 2015-01-21 11:14:04,405 ERROR transactional.TransactionManager: doCommitX, 
> result size: 0
> Normally we would create a recovery entry for this transaction to redrive 
> commit, but it appears we are unable to do that due to the zookeeper errors 
> 2015-01-21 11:14:04,408 DEBUG 
> client.HConnectionManager$HConnectionImplementation: Removed all cached 
> region locations that map to g4t3005.houston.hp.com,4   2243,1421362639257
> 471340 2015-01-21 11:14:05,255 WARN zookeeper.RecoverableZooKeeper: Possibly 
> transient ZooKeeper, quorum=localhost:47570, 
> exception=org.apache.zookeeper.KeeperExc   
> eption$ConnectionLossException: KeeperErrorCode = ConnectionLoss for 
> /hbase/table/TRAFODION.HBASE.MCSTATPART1
> 471341 2015-01-21 11:14:05,256 WARN zookeeper.RecoverableZooKeeper: Possibly 
> transient ZooKeeper, quorum=localhost:47570, 
> exception=org.apache.zookeeper.KeeperExc   
> eption$ConnectionLossException: KeeperErrorCode = ConnectionLoss for 
> /hbase/table/TRAFODION.HBASE.MCSTATPART1
> 471342 2015-01-21 11:14:05,256 INFO util.RetryCounter: Sleeping 1000ms before 
> retry #0...
> 471343 2015-01-21 11:14:05,256 INFO util.RetryCounter: Sleeping 1000ms before 
> retry #0...
> Hbase looks like it’s having troubles as I can’t even do a list operation 
> from the hbase shell
> 2015-01-21 14:40:28,816 ERROR [main] 
> client.HConnectionManager$HConnectionImplementation: Can't get connection to 
> ZooKeeper: KeeperErrorCode = ConnectionLoss for /hbase
> We need to think of how better to handle this in the TransactionManager, but 
> in reality I’m not sure what we can do if Zookeeper fails.  You can open an 
> LP bug so we have record of it and can discuss what to do.
> Thanks,
> Sean
> _
> From: Hanlon, Mike 
> Sent: Wednesday, January 21, 2015 6:17 AM
> To: Cooper, Joanie
> Cc: Broeder, Sean; DeRoo, John
> Subject: ENDTRANSACTION hang, transaction state FORGETTING
> Hi Joanie,
> Have we seen this before? A SQL regression test (in this case 
> seabase/TEST016) hangs in a call to ENDTRANSACTION. The transaction state is 
> shown in dtmci to be FORGETTING.  It probably is not easy to reproduce, since 
> the problem occurred on the 14th iteration of a loop to re-execute the 
> seabase suite. 
> There are a lot of messages in 
> /opt/home/mhanlon/trafodion/core/sqf/logs/trafodion.dtm.log on my 
> workstation, sqws112. The transid in question is 13742. Would somebody like 

[jira] [Updated] (TRAFODION-939) LP Bug: 1413831 - Phoenix tests run into several error 8810 when other tests are run in parallel with it

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-939:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1413831 - Phoenix tests run into several error 8810 when other tests 
> are run in parallel with it
> 
>
> Key: TRAFODION-939
> URL: https://issues.apache.org/jira/browse/TRAFODION-939
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Aruna Sadashiva
>Assignee: Prashanth Vasudev
>Priority: Critical
>
> Running phoenix and jdbc catalog api tests at the same time resulted in 16 
> failures in phoenix with error 8810, during ddl operations as shown below. 
> All the jdbc catalog api tests passed. 
> Phoenix runs fine when no other tests are running on the system. 
> test.java.com.hp.phoenix.end2end.ToNumberFunctionTest
> *** ERROR[8810] Executor ran into an internal failure and returned an 
> error without populating the diagnostics area. This error is being injected 
> to indicate that. [2015-01-22 08:32:31]
> E.E.
> Time: 701.811
> There were 2 failures:
> 1) 
> testKeyProjectionWithIntegerValue(test.java.com.hp.phoenix.end2end.ToNumberFunctionTest)
> java.lang.AssertionError: Failed to drop object: table TO_NUMBER_TABLE
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> test.java.com.hp.phoenix.end2end.BaseTest.dropTestObjects(BaseTest.java:180)
>   at 
> test.java.com.hp.phoenix.end2end.BaseTest.doBaseTestCleanup(BaseTest.java:112)
> On Justin's sugegstion, added ABORT_ON_ERROR for 8810 and the core has this 
> stack:
> #0  0x74a458a5 in raise () from /lib64/libc.so.6
> #1  0x74a4700d in abort () from /lib64/libc.so.6
> #2  0x71248114 in ComCondition::setSQLCODE (
> this=, newSQLCODE=-8810)
> at ../export/ComDiags.cpp:1425
> #3  0x73f66e36 in operator<< (d=..., dgObj=...)
> at ../common/DgBaseType.cpp:138
> #4  0x7437e4e3 in CliStatement::fetch (this=, 
> cliGlobals=0xeeade0, output_desc=, diagsArea=..., 
> newOperation=1) at ../cli/Statement.cpp:5310
> #5  0x74324e0f in SQLCLI_PerformTasks(CliGlobals *, ULng32, 
> SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag 
> __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) 
> (cliGlobals=0xeeade0, tasks=8063, 
> statement_id=0x1fbea88, input_descriptor=0x1fbeab8, 
> output_descriptor=0x0, 
> num_input_ptr_pairs=0, num_output_ptr_pairs=0, ap=0x7fffe41ef030, 
> input_ptr_pairs=0x0, output_ptr_pairs=0x0) at ../cli/Cli.cpp:3382
> #6  0x7438a40b in SQL_EXEC_ClearExecFetchClose (
> statement_id=0x1fbea88, input_descriptor=0x1fbeab8, 
> output_descriptor=0x0, 
> num_input_ptr_pairs=0, num_output_ptr_pairs=0, num_total_ptr_pairs=0)
> at ../cli/CliExtern.cpp:2627
> #7  0x768703bf in SRVR::WSQL_EXEC_ClearExecFetchClose (
> statement_id=0x1fbea88, input_descriptor=, 
> output_descriptor=, 
> num_input_ptr_pairs=, 
> num_output_ptr_pairs=, 
> num_total_ptr_pairs=) at SQLWrapper.cpp:459
> #8  0x76866cff in SRVR::EXECUTE2 (pSrvrStmt=0x1fbe470)
> at sqlinterface.cpp:5520
> #9  0x7689733e in odbc_SQLSvc_Execute2_sme_ (
> objtag_=, call_id_=, 
> dialogueId=, sqlAsyncEnable=, 
> ---Type  to continue, or q  to quit---
> queryTimeout=, inputRowCnt=, 
> sqlStmtType=128, stmtHandle=33285232, cursorLength=0, cursorName=0x0, 
> cursorCharset=1, holdableCursor=0, inValuesLength=0, inValues=0x0, 
> returnCode=0x7fffe41ef928, sqlWarningOrErrorLength=0x7fffe41ef924, 
> sqlWarningOrError=@0x7fffe41ef900, rowsAffected=0x7fffe41ef920, 
> outValuesLength=0x7fffe41ef914, outValues=@0x7fffe41ef8f8)
> at srvrothers.cpp:1517
> #10 0x004cbc42 in odbc_SQLSrvr_ExecDirect_ame_ (objtag_=0x24a84d0, 
> call_id_=0x24a8528, dialogueId=1492150530, 
> stmtLabel=, cursorName=0x0, 
> stmtExplainLabel=, stmtType=0, sqlStmtType=128, 
> sqlString=0x2d43ea4 "drop table PRODUCT_METRICS cascade", 
> sqlAsyncEnable=0, queryTimeout=0, inputRowCnt=0, txnID=0, 
> holdableCursor=0)
> at SrvrConnect.cpp:7636
> #11 0x00494086 in SQLEXECUTE_IOMessage (objtag_=0x24a84d0, 
> call_id_=0x24a8528, operation_id=3012) at Interface/odbcs_srvr.cpp:1734
> #12 0x00494134 in DISPATCH_TCPIPRequest (objtag_=0x24a84d0, 
> call_id_=0x24a8528, operation_id=)
> at Interface/odbcs_srvr.cpp:1799
> #13 0x00433822 in BUILD_TCPIP_REQUEST (pnode=0x24a84d0)
> at ../Common/TCPIPSystemSrvr.cpp:603
> #14 0x004341bd in PROCESS_TCPIP_REQUEST (pnode=0x24a84d0)
> at ../Common/TCPIPSystemSrvr.cpp:581
> #15 0x00462396 in 

[jira] [Updated] (TRAFODION-979) LP Bug: 1418142 - Parallel DDL operations sees error 8810

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-979:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1418142 - Parallel DDL operations sees error 8810
> -
>
> Key: TRAFODION-979
> URL: https://issues.apache.org/jira/browse/TRAFODION-979
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Weishiun Tsai
>Assignee: Prashanth Vasudev
>Priority: Critical
>
> To be able to run SQL regression tests in parallel on the same instance is 
> one of the goals that we would like to see happen for the post-1.0 release.  
> In order to do this, Trafodion needs to be able to handle parallel execution 
> with a workload that has a mixture of DDLs and DMLs together.  Right now, 
> Trafodion is not very robust when it comes to handling concurrent DDL 
> executions. (or a DDL execution with another DML execution.  It’s hard to 
> tell if it has to be 2 DDLs to cause all the problems that we seeing.) 
> There are several problems in this area.  The first noticeable one is this 
> particular 8810 error.   QA did an experiment last night by splitting the 
> regression test suites into 2 parts and ran them together on a 4-node 
> cluster.   After both completed, we saw a total of 50 occurrences of this 
> 8810 error:
> -bash-4.1$ grep 8810 */*.log | grep ERROR | wc -l
> 33
> -bash-4.1$ grep 8810 */*.log | grep ERROR | wc -l
> 17
> A typical error looks like this:
> SQL>drop table t10a104;
> *** ERROR[8810] Executor ran into an internal failure and returned an error 
> without populating the diagnostics area. This error is being injected to 
> indicate that. [2015-02-04 07:12:04]
> There is a bug report https://bugs.launchpad.net/trafodion/+bug/1413831 
> ‘Phoenix tests run into several error 8810 when other tests are run in 
> parallel with it´ that describes a similar problem.  But that one has a 
> narrower scope focusing only on phoenix tests and the severity of the bug 
> report is only High.  This one is intended to cover a broader issue of 
> running parallel DDL operations in general.  We will mark it as Critical as 
> we need to remove this obstacle first to see what other problems may lie 
> beneath for executing DDLs in parallel.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-900) LP Bug: 1411541 - [DCS] query with long query text is missing from METRIC_QUERY_TABLE

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-900:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1411541 - [DCS] query with long query text is missing from 
> METRIC_QUERY_TABLE
> -
>
> Key: TRAFODION-900
> URL: https://issues.apache.org/jira/browse/TRAFODION-900
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-general
>Reporter: FengQiang
>Assignee: Rao Kakarlamudi
>Priority: Critical
>
> QUERY_TEXT  is VARCHAR(5 CHARS)  in METRIC_QUERY_TABLE.
> Set dcs.server.user.program.statistics.type to 'query' to publish every query.
> When running a query with query text longer than 5, it did not published 
> to METRIC_QUERY_TABLE.
> Should the query text be trimed to fit the datatype and got published?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-911) LP Bug: 1412652 - _REPOS_.METRIC_QUERY_TABLE has rows with QUERY_ID and sometimes empty QUERY_TEXT

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-911:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1412652 - _REPOS_.METRIC_QUERY_TABLE has rows with  QUERY_ID 
> and sometimes empty QUERY_TEXT
> -
>
> Key: TRAFODION-911
> URL: https://issues.apache.org/jira/browse/TRAFODION-911
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: connectivity-mxosrvr
>Reporter: Aruna Sadashiva
>Assignee: Anuradha Hegde
>Priority: Critical
>
> Don't know how to recreate this yet, but _REPOS_.METRIC_QUERY_TABLE has 
> several rows with QUERY_ID set to . The session id looks ok. QUERY_TEXT 
> is sometimes empty. 
> Arvind found 2 places in code where query id is explicitly set to , but 
> not sure how it gets there.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-138) LP Bug: 1246183 - volatile table is not dropped after hpdci session ends

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-138:
-
Fix Version/s: (was: 2.2.0)
   2.3

> LP Bug: 1246183 - volatile table is not dropped after hpdci session ends
> 
>
> Key: TRAFODION-138
> URL: https://issues.apache.org/jira/browse/TRAFODION-138
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Weishiun Tsai
>Assignee: Sandhya Sundaresan
>Priority: Critical
> Fix For: 2.3
>
>
> A volatile table is not dropped after the hpdci session has ended.  In the 
> following example, the volatile table persists after several hpdci 
> disconnects and reconnects.  This problem is not seen from sqlci, so I am 
> assuming that the problem is in how mxosvr handles volatile tables.
> -bash-4.1$ hpdci.seascape2-sqtopl7.sh
> Welcome to HP Database Command Interface 3.0
> (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP.
> Connected to Data Source: TDM_Default_DataSource
> SQL>set schema seabase.mytest;
> --- SQL operation complete.
> SQL>create volatile table abc (a int not null not droppable primary key);
> --- SQL operation complete.
> SQL>showddl abc;
> CREATE VOLATILE TABLE ABC
>   (
> AINT NO DEFAULT NOT NULL NOT DROPPABLE
>   , PRIMARY KEY (A ASC)
>   )
> ;
> --- SQL operation complete.
> SQL>exit;
> -bash-4.1$ hpdci.seascape2-sqtopl7.sh
> Welcome to HP Database Command Interface 3.0
> (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP.
> Connected to Data Source: TDM_Default_DataSource
> SQL>set schema seabase.mytest;
> --- SQL operation complete.
> SQL>showddl abc;
> CREATE VOLATILE TABLE ABC
>   (
> AINT NO DEFAULT NOT NULL NOT DROPPABLE
>   , PRIMARY KEY (A ASC)
>   )
> ;
> --- SQL operation complete.
> SQL>exit;
> -bash-4.1$ hpdci.seascape2-sqtopl7.sh
> Welcome to HP Database Command Interface 3.0
> (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP.
> Connected to Data Source: TDM_Default_DataSource
> SQL>set schema seabase.mytest;
> --- SQL operation complete.
> SQL>showddl abc;
> CREATE VOLATILE TABLE ABC
>   (
> AINT NO DEFAULT NOT NULL NOT DROPPABLE
>   , PRIMARY KEY (A ASC)
>   )
> ;
> --- SQL operation complete.
> SQL>exit;
> -bash-4.1$ hpdci.seascape2-sqtopl7.sh
> Welcome to HP Database Command Interface 3.0
> (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP.
> Connected to Data Source: TDM_Default_DataSource
> SQL>set schema seabase.mytest;
> --- SQL operation complete.
> SQL>showddl abc;
> CREATE VOLATILE TABLE ABC
>   (
> AINT NO DEFAULT NOT NULL NOT DROPPABLE
>   , PRIMARY KEY (A ASC)
>   )
> ;
> --- SQL operation complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-533) LP Bug: 1355042 - SPJ w result set failed with ERROR[11220], SQLCODE of -29261, SQLSTATE of HY000

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-533:
-
Fix Version/s: (was: 2.2.0)
   2.3

> LP Bug: 1355042 - SPJ w result set failed with ERROR[11220], SQLCODE of 
> -29261, SQLSTATE of HY000
> -
>
> Key: TRAFODION-533
> URL: https://issues.apache.org/jira/browse/TRAFODION-533
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-exe
>Reporter: Chong Hsu
>Assignee: Kevin Xu
>Priority: Critical
> Fix For: 2.3
>
>
> Tested with Trafodion build, 20140801-0830.
> Calling a SPJ that calls another SPJ with result set:
>public static void RS363()
>  throws Exception
>{
>  String str = "jdbc:default:connection";
>  
>  Connection localConnection = DriverManager.getConnection(str);
>  Statement localStatement = localConnection.createStatement();
>  
>  CallableStatement localCallableStatement = 
> localConnection.prepareCall("{call RS200()}");
>  localCallableStatement.execute();
>}
>public static void RS200(ResultSet[] paramArrayOfResultSet)
>throws Exception
>{
>  String str1 = "jdbc:default:connection";
>  
>  String str2 = "select * from t1";
>  Connection localConnection = DriverManager.getConnection(str1);
>  Statement localStatement = localConnection.createStatement();
>  paramArrayOfResultSet[0] = localStatement.executeQuery(str2);
>}
> it failed with ERROR:
> *** ERROR[11220] A Java method completed with an uncaught 
> java.sql.SQLException with invalid SQLSTATE. The uncaught exception had a 
> SQLCODE of -29261 and SQLSTATE of HY000. Details: java.sql.SQLException: No 
> error message in SQL/MX diagnostics area, but sqlcode is non-zero [2014-08-04 
> 22:57:28]
> The SPJ Jar file is attached. Here are the steps to produce the error:
>   
> set schema testspj;
> create library spjrs file '//Testrs.jar';
> create procedure RS363()
>language java 
>parameter style java  
>external name 'Testrs.RS363'
>dynamic result sets 0
>library spjrs;
> --- SQL operation complete.
> create procedure RS200()
>language java 
>parameter style java  
>external name 'Testrs.RS200' 
>dynamic result sets 1
>library spjrs;
> create table  T1
>   (
> AINT DEFAULT NULL
>   , BINT DEFAULT NULL
>   ) no partitions; 
> Call RS363();
> *** ERROR[11220] A Java method completed with an uncaught 
> java.sql.SQLException with invalid SQLSTATE. The uncaught exception had a 
> SQLCODE of -29261 and SQLSTATE of HY000. Details: java.sql.SQLException: No 
> error message in SQL/MX diagnostics area, but sqlcode is non-zero [2014-08-04 
> 22:57:28]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (TRAFODION-179) LP Bug: 1274962 - EXECUTE.BATCH update creates core-file

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-179:
-
Fix Version/s: (was: 2.2.0)

> LP Bug: 1274962 - EXECUTE.BATCH update creates core-file
> 
>
> Key: TRAFODION-179
> URL: https://issues.apache.org/jira/browse/TRAFODION-179
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Guy Groulx
>Assignee: Sandhya Sundaresan
>Priority: Critical
>
> Using atomics suite.
> Test 10 is an update test using JDBC batch feature.
> Test 12 is a delete test using JDBC batch feature.
> Test is configured to batch 500 rows and then does execute batch.   See code 
> for update.  Similar code for delete.
> /*Prepare the insert statement.   */
> String sqlStmtCmd = "UPDATE " + dbTableName + " SET COL1=?, COL2=? WHERE 
> CNT = ?";
> try {
>   sqlStmt = dbConnection.prepareStatement(sqlStmtCmd);
> } catch (SQLException e) {
>   log_error("Exception in update_with_rowsets\n");
>   return(e.getErrorCode());
> }
> ...
> for (i = 0; i < (int)numbtmf; i++) {   <== numbtmf is a passed parameter, 
> set to 500 in my tests.
>   try {
> sqlStmt.setLong(1, up_col1);
> sqlStmt.setLong(2, up_col2);
> sqlStmt.setLong(3, hv_cnt);
> sqlStmt.addBatch();
> hv_cnt++;
> if (hv_cnt >= hv_cnt2) hv_cnt = hv_cnt1; /*  Need to restart. */
>   } catch (SQLException e) {
> log_error("Exception in update_with_rowsets\n");
> SQLException nextException;
> nextException = e;
> retcode = e.getErrorCode();
> do {
>   log_error(nextException.getMessage() + " State: " + 
> nextException.getSQLState() + "\n");
> } while ((nextException = nextException.getNextException()) != null);
>   }
> }
> beginTXN();
> try {
>   resultCountL = sqlStmt.executeBatch();<== This is where is hangs 
> for a very long time.
>   rowCnt+=resultCountL.length;
>   if (resultCountL.length != numbtmf) {
> log_error("Error UPDATING!! resultCount: " + resultCountL.length + 
> "\n");
> retcode = 1;
>   } else {
> for (i = 0; i < resultCountL.length; i++) {
>   if ((resultCountL[i] != 1) && (resultCountL[i] != 
> Statement.SUCCESS_NO_INFO)) {
> log_error("Error UPDATING!! resultCount: " + resultCountL[i] + 
> "\n");
> retcode = resultCountL[i];
> break;
>   }
> }
>   }
>   sqlStmt.clearBatch();
> } catch (SQLException e) {
>   log_error("Exception in update_with_rowsets\n");
>   SQLException nextException;
>   nextException = e;
>   retcode = e.getErrorCode();
>   do {
> log_error(nextException.getMessage() + " State: " + 
> nextException.getSQLState() + "\n");
>   } while ((nextException = nextException.getNextException()) != null);
> }
> commitTXN();
> return retcode;
> Eventually, get: 
> Exception in update_with_rowsets
> Exception in update_with_rowsets
> Batch Update Failed, See next exception for details State: HY000
> Batch Update Failed, See next exception for details State: HY000
> *** ERROR[8448] Unable to access Hbase interface. Call to 
> ExpHbaseInterface::insertRows returned error HBASE_ACCESS_ERROR(-705). Cause: 
> org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after 
> attempts=10, exceptions:
> Fri Jan 31 14:38:42 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:43 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:44 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:45 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:47 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:49 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:53 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:38:57 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:39:05 UTC 2014, 
> org.apache.hadoop.hbase.client.transactional.TransactionalTable$7@1c36686e, 
> java.lang.NullPointerException
> Fri Jan 31 14:39:21 

[jira] [Updated] (TRAFODION-1575) Self-referencing update updates the column to a wrong value

[Suresh Subbiah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Subbiah updated TRAFODION-1575:
--
Fix Version/s: (was: 2.2.0)
   2.3

> Self-referencing update updates the column to a wrong value
> ---
>
> Key: TRAFODION-1575
> URL: https://issues.apache.org/jira/browse/TRAFODION-1575
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Affects Versions: 1.3-incubating
> Environment: Can be reproduced on a workstation
>Reporter: David Wayne Birdsall
>Assignee: Selvaganesan Govindarajan
>Priority: Major
> Fix For: 2.3
>
>
> As shown in the following execution output, the update statement tries to 
> update c2 with count(distinct c2) from the same table. While the subquery 
> ‘select c from (select count(distinct c2) from mytable) dt(c)’ returns the 
> correct result 3 when it is run by itself, the update statement using the 
> same subquery updated the column c2 to 2, instead of 3. The updated value 
> always seems to be 1 less in this case.
> Here is the execution output:
> >>create schema mytest;
> --- SQL operation complete.
> >>
> >>create table mytable (c1 char(1), c2 integer);
> --- SQL operation complete.
> >>
> >>insert into mytable values ('A', 100), ('B', 200), ('C', 300);
> --- 3 row(s) inserted.
> >>select * from mytable order by 1;
> C1 C2
> -- ---
> A 100
> B 200
> C 300
> --- 3 row(s) selected.
> >>select c from (select count(distinct c2) from mytable) dt(c);
> C
> 
>3
> --- 1 row(s) selected.
> >>
> >>prepare xx from update mytable set c2 =
> +>(select c from (select count(distinct c2) from mytable) dt(c))
> +>where c2 = 100;
> --- SQL command prepared.
> >>explain options 'f' xx;
> LC RC OP OPERATOR OPT DESCRIPTION CARD
>       -
> 12 . 13 root x 1.00E+001
> 10 11 12 tuple_flow 1.00E+001
> . . 11 trafodion_insert MYTABLE 1.00E+000
> 9 . 10 sort 1.00E+001
> 8 4 9 hybrid_hash_join 1.00E+001
> 6 7 8 nested_join 1.00E+001
> . . 7 trafodion_delete MYTABLE 1.00E+000
> 5 . 6 sort 1.00E+001
> . . 5 trafodion_scan MYTABLE 1.00E+001
> 3 . 4 sort_scalar_aggr 1.00E+000
> 2 . 3 sort_scalar_aggr 1.00E+000
> 1 . 2 hash_groupby 2.00E+000
> . . 1 trafodion_scan MYTABLE 1.00E+002
> --- SQL operation complete.
> >>execute xx;
> --- 1 row(s) updated.
> >>
> >>select * from mytable order by 1;
> C1 C2
> -- ---
> A 2
> B 200
> C 300
> --- 3 row(s) selected.
> >>
> >>drop schema mytest cascade;
> --- SQL operation complete.
> >>
> The value of C2 in row A above should have been updated to 3.
> This problem was found by Wei-Shiun Tsai.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387540#comment-16387540
 ] 

ASF GitHub Bot commented on TRAFODION-2940:
---

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

https://github.com/apache/trafodion/pull/1427#discussion_r172462100
  
--- Diff: dcs/bin/scripts/dcsunbind.sh ---
@@ -51,6 +51,31 @@ function check_node {
 done
 }
 
+function check_self_node {
+for myinterface in `/sbin/ip link show|cut -d: -f1- | cut -c1- | awk 
-F': ' '/^[0-9]+:.*/ {print $2;}'`; do
+ip_output=$(/sbin/ip addr show $myinterface | cut -d: -f1- | cut 
-c1-)
+
+myifport=`echo "$ip_output" | grep -w $gv_float_external_ip`
+status=$?
+if [ $status -eq 0 ]; then
+tempinterface=`echo $gv_float_interface:$gv_port`
+# check if another interface is bound to this virtual ip 
address
+echo "$myifport" | grep "$tempinterface"  > /dev/null
+if [ $? -eq 0 ]; then
+unbindip=`echo "$myifport" | awk '{print $2}'`
+unbindlb=`echo "$myifport"|awk '{print $NF}'`
+echo "Virtual ip $gv_float_external_ip is in use on node 
$HOSTNAME bound to interface $myinterface($unbindlb) - unbinding..."
+sudo /sbin/ip addr del $unbindip dev $myinterface
+status=$?
--- End diff --

this function is a little different from the one using PDSH,  the ouput of 
`$SQ_PDSH $MY_NODES /sbin/ip addr show` is different from `/sbin/ip link show` 
, so the cut step after the " | " (pipe) is different. 


> In HA env, one node lose network, when recover, trafci can't use
> 
>
> Key: TRAFODION-2940
> URL: https://issues.apache.org/jira/browse/TRAFODION-2940
> Project: Apache Trafodion
>  Issue Type: Bug
>Affects Versions: any
>Reporter: mashengchen
>Assignee: mashengchen
>Priority: Major
> Fix For: 2.3
>
>
> In HA env, if one node lose network for a long time , once network recover, 
> there will have two floating ip, two working dcs master, and trafci can't be 
> use.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TRAFODION-2981) mxosrvr crashes during explain using EXPLAIN_QID

[mashengchen (JIRA)]

mashengchen created TRAFODION-2981:
--

 Summary: mxosrvr crashes during explain using EXPLAIN_QID
 Key: TRAFODION-2981
 URL: https://issues.apache.org/jira/browse/TRAFODION-2981
 Project: Apache Trafodion
  Issue Type: Bug
Reporter: mashengchen
Assignee: mashengchen


When the following sequence of commands are executed via trafci, the mxosrvr 
abends and we do not get the explain output.

SELECT * FROM TABLE(explain(null, 
'EXPLAIN_QID=MXID11070192123841538945334162206U308T150010100_923_SQL_CUR_2'));

 

this issue is related to TRAFODION-1755



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)