[jira] [Commented] (TRAFODION-2704) JDBC regression test failed by too many statement on the same session
[ https://issues.apache.org/jira/browse/TRAFODION-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162506#comment-16162506 ] ASF GitHub Bot commented on TRAFODION-2704: --- Github user sandhyasun commented on a diff in the pull request: https://github.com/apache/incubator-trafodion/pull/1225#discussion_r138252548 --- Diff: core/conn/odbc/src/odbc/nsksrvrcore/srvrothers.cpp --- @@ -6489,6 +6506,31 @@ odbc_SQLSrvr_ExtractLob_sme_( exception_->u.SQLError.errorList._buffer = QryLobExtractSrvrStmt->sqlError.errorList._buffer; exception_->u.ParamError.ParamDesc = SQLSVC_EXCEPTION_EXECUTE_FAILED; } + +IDL_long_long zeroValue = 0; +snprintf(LobExtractQuery, sizeof(LobExtractQuery), "EXTRACT LOBTOBUFFER(LOB'%s', LOCATION %Ld, SIZE %Ld)", lobHandle, (Int64)lobDataValue, ); + +retcode = QryLobExtractSrvrStmt->ExecDirect(NULL, LobExtractQuery, EXTERNAL_STMT, TYPE_CALL, SQL_ASYNC_ENABLE_OFF, 0); + --- End diff -- This seems like a big restriction since we will allow a max of 512 MB only. This means the user cannot even havea picture file of 1 G or 2 G in this release ? How about for update lob ? Will the caller be able to use "update lob append " several times to append data to a single lob ? > JDBC regression test failed by too many statement on the same session > - > > Key: TRAFODION-2704 > URL: https://issues.apache.org/jira/browse/TRAFODION-2704 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Weiqing Xu >Assignee: Weiqing Xu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2704) JDBC regression test failed by too many statement on the same session
[ https://issues.apache.org/jira/browse/TRAFODION-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162498#comment-16162498 ] ASF GitHub Bot commented on TRAFODION-2704: --- Github user xwq commented on a diff in the pull request: https://github.com/apache/incubator-trafodion/pull/1225#discussion_r138251712 --- Diff: core/conn/odbc/src/odbc/nsksrvrcore/srvrothers.cpp --- @@ -6489,6 +6506,31 @@ odbc_SQLSrvr_ExtractLob_sme_( exception_->u.SQLError.errorList._buffer = QryLobExtractSrvrStmt->sqlError.errorList._buffer; exception_->u.ParamError.ParamDesc = SQLSVC_EXCEPTION_EXECUTE_FAILED; } + +IDL_long_long zeroValue = 0; +snprintf(LobExtractQuery, sizeof(LobExtractQuery), "EXTRACT LOBTOBUFFER(LOB'%s', LOCATION %Ld, SIZE %Ld)", lobHandle, (Int64)lobDataValue, ); + +retcode = QryLobExtractSrvrStmt->ExecDirect(NULL, LobExtractQuery, EXTERNAL_STMT, TYPE_CALL, SQL_ASYNC_ENABLE_OFF, 0); + --- End diff -- I will documented it. For the large data, they are some logic in JDBC need to be designed, I will add the code when I have the solution. > JDBC regression test failed by too many statement on the same session > - > > Key: TRAFODION-2704 > URL: https://issues.apache.org/jira/browse/TRAFODION-2704 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Weiqing Xu >Assignee: Weiqing Xu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2704) JDBC regression test failed by too many statement on the same session
[ https://issues.apache.org/jira/browse/TRAFODION-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162489#comment-16162489 ] ASF GitHub Bot commented on TRAFODION-2704: --- Github user sandhyasun commented on a diff in the pull request: https://github.com/apache/incubator-trafodion/pull/1225#discussion_r138250912 --- Diff: core/conn/odbc/src/odbc/nsksrvrcore/srvrothers.cpp --- @@ -6489,6 +6506,31 @@ odbc_SQLSrvr_ExtractLob_sme_( exception_->u.SQLError.errorList._buffer = QryLobExtractSrvrStmt->sqlError.errorList._buffer; exception_->u.ParamError.ParamDesc = SQLSVC_EXCEPTION_EXECUTE_FAILED; } + +IDL_long_long zeroValue = 0; +snprintf(LobExtractQuery, sizeof(LobExtractQuery), "EXTRACT LOBTOBUFFER(LOB'%s', LOCATION %Ld, SIZE %Ld)", lobHandle, (Int64)lobDataValue, ); + +retcode = QryLobExtractSrvrStmt->ExecDirect(NULL, LobExtractQuery, EXTERNAL_STMT, TYPE_CALL, SQL_ASYNC_ENABLE_OFF, 0); + --- End diff -- Ok this will not work for a large stream of data though. We cannot allocate that much in memory. Are all these limitations being documented in a JIRA ? > JDBC regression test failed by too many statement on the same session > - > > Key: TRAFODION-2704 > URL: https://issues.apache.org/jira/browse/TRAFODION-2704 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Weiqing Xu >Assignee: Weiqing Xu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2704) JDBC regression test failed by too many statement on the same session
[ https://issues.apache.org/jira/browse/TRAFODION-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162395#comment-16162395 ] ASF GitHub Bot commented on TRAFODION-2704: --- Github user xwq commented on a diff in the pull request: https://github.com/apache/incubator-trafodion/pull/1225#discussion_r138239370 --- Diff: core/conn/odbc/src/odbc/nsksrvrcore/srvrothers.cpp --- @@ -6489,6 +6506,31 @@ odbc_SQLSrvr_ExtractLob_sme_( exception_->u.SQLError.errorList._buffer = QryLobExtractSrvrStmt->sqlError.errorList._buffer; exception_->u.ParamError.ParamDesc = SQLSVC_EXCEPTION_EXECUTE_FAILED; } + +IDL_long_long zeroValue = 0; +snprintf(LobExtractQuery, sizeof(LobExtractQuery), "EXTRACT LOBTOBUFFER(LOB'%s', LOCATION %Ld, SIZE %Ld)", lobHandle, (Int64)lobDataValue, ); + +retcode = QryLobExtractSrvrStmt->ExecDirect(NULL, LobExtractQuery, EXTERNAL_STMT, TYPE_CALL, SQL_ASYNC_ENABLE_OFF, 0); + --- End diff -- For now, the lob extract all data in one query, so after this query, we can call the "zeroLength' query directly. In the further, I will support the extract the data in multiple times for large data, and then, we need JDBC change. > JDBC regression test failed by too many statement on the same session > - > > Key: TRAFODION-2704 > URL: https://issues.apache.org/jira/browse/TRAFODION-2704 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Weiqing Xu >Assignee: Weiqing Xu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2717) DCSMaster can't solve error data send from odbc and hang
[
https://issues.apache.org/jira/browse/TRAFODION-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162334#comment-16162334
]
ASF GitHub Bot commented on TRAFODION-2717:
---
Github user kevinxu021 commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/1209#discussion_r138233541
--- Diff:
dcs/src/main/java/org/trafodion/dcs/master/listener/ListenerWorker.java ---
@@ -86,39 +86,43 @@ public void run() {
DataEvent dataEvent;
while(true) {
-// Wait for data to become available
-synchronized(queue) {
-while(queue.isEmpty()) {
-try {
-queue.wait();
-} catch (InterruptedException e) {
+try {
+// Wait for data to become available
+synchronized(queue) {
+while(queue.isEmpty()) {
+try {
+queue.wait();
+} catch (InterruptedException e) {
+}
}
+dataEvent = queue.remove(0);
}
-dataEvent = queue.remove(0);
-}
-SelectionKey key = dataEvent.key;
-SocketChannel client = (SocketChannel) key.channel();
-Socket s = client.socket();
-ClientData clientData = (ClientData) key.attachment();
-ListenerService server = dataEvent.server;
-dataEvent.key = null;
-dataEvent.server = null;
-
-switch (clientData.hdr.getOperationId()){
-case ListenerConstants.DCS_MASTER_GETSRVRAVAILABLE:
-clientData =
requestGetObjectRef.processRequest(clientData, s);
-break;
-case ListenerConstants.DCS_MASTER_CANCELQUERY:
-clientData =
requestCancelQuery.processRequest(clientData, s);
-break;
-default:
-clientData = requestUnknown.processRequest(clientData,
s);
-break;
+SelectionKey key = dataEvent.key;
+SocketChannel client = (SocketChannel) key.channel();
+Socket s = client.socket();
+ClientData clientData = (ClientData) key.attachment();
+ListenerService server = dataEvent.server;
+dataEvent.key = null;
+dataEvent.server = null;
+
+switch (clientData.hdr.getOperationId()){
+case ListenerConstants.DCS_MASTER_GETSRVRAVAILABLE:
+clientData =
requestGetObjectRef.processRequest(clientData, s);
+break;
+case ListenerConstants.DCS_MASTER_CANCELQUERY:
+clientData =
requestCancelQuery.processRequest(clientData, s);
+break;
+default:
+clientData =
requestUnknown.processRequest(clientData, s);
+break;
+}
+// Return to sender
+int requestReply = clientData.requestReply;
+key.attach(clientData);
+server.send(new PendingRequest(key, requestReply));
+} catch (Exception e){
+LOG.error("Unexpected Exception", e);
--- End diff --
This is an issue for memory allocation failed, it doesn't mean the memory
has been ran out. I dont think it is reasonable to exit the process instead of
returning back the issue to the client. By the way, even we have socket
timeout, the real issue will be hidden. whatever the issue is on server-side,
you will always get socket timeout for every client request. Can customer
really accept the behavior? Again, the outside CATCH is to avoid process
exiting because of a very particular bad request. If it is a real OUT OF
MEMORY， i mean run out the memory, absolutely the process will be exiting.
More, OutOfMemoryError is an ERROR which not belongs to exception and will not
be covered by EXCEPTION block. In another word, the process will exit.
> DCSMaster can't solve error data send from odbc and hang
>
>
> Key: TRAFODION-2717
> URL: https://issues.apache.org/jira/browse/TRAFODION-2717
> Project: Apache Trafodion
> Issue Type: Bug
>Reporter: mashengchen
>Assignee: mashengchen
>
> odbc give a wrong length for dcsmaster when do new
[jira] [Commented] (TRAFODION-2735) LOB: Drop table/schema returns 8616 error but the drop statement can't be retried
[
https://issues.apache.org/jira/browse/TRAFODION-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161693#comment-16161693
]
Sandhya Sundaresan commented on TRAFODION-2735:
---
This problem can probably be reproduced by giving another stream of DDL running
in the background.
(1) sqlci -i mytest2.sql
(2) Wait until ‘create table mytable’ finish
(3) Use another terminal and run sqlci -i mytest1.sql to start another stream
of ddl operations.
(4) If mytest2.sql sees 8616 error at drop table, kill the sqlci of mytest1.sql
(5) Start another sqlci
Issue ‘drop table mytable cascade’ again.
$ cat mytest1.sql
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
create table t (c1 int, c2 int, c3 int, c4 int, c5 int, c6 int, c7 int, c8 int);
drop table t;
$ cat mytest2.sql
cqd TRAF_BLOB_AS_VARCHAR 'OFF';
cqd TRAF_CLOB_AS_VARCHAR 'OFF';
drop table if exists mytable cascade;
create table mytable (row_id int, c1 blob, c2 clob, c3 blob, c4 clob, c5 blob,
c6 clob);
insert into table mytable values (1, stringtolob('column 1'),
stringtolob('column 2'), stringtolob('column 1'), stringtolob('column 2'),
stringtolob('column 1'), stringtolob('column 2'));
insert into table mytable values (2, stringtolob('column 1'),
stringtolob('column 2'), stringtolob('column 1'), stringtolob('column 2'),
stringtolob('column 1'), stringtolob('column 2'));
insert into table mytable values (3, stringtolob('column 1'),
stringtolob('column 2'), stringtolob('column 1'), stringtolob('column 2'),
stringtolob('column 1'), stringtolob('column 2'));
drop table mytable cascade;
$ sqlci -i mytest2.sql
>>cqd TRAF_BLOB_AS_VARCHAR 'OFF';
--- SQL
[jira] [Created] (TRAFODION-2735) LOB: Drop table/schema returns 8616 error but the drop statement can't be retried
Sandhya Sundaresan created TRAFODION-2735: - Summary: LOB: Drop table/schema returns 8616 error but the drop statement can't be retried Key: TRAFODION-2735 URL: https://issues.apache.org/jira/browse/TRAFODION-2735 Project: Apache Trafodion Issue Type: Bug Components: dtm, sql-exe Affects Versions: 2.2-incubating Environment: May need to run 2 streams to see the effect of this. But see how we handle the 8616 error with LOB objects may be a good place to start. Reporter: Sandhya Sundaresan With the DDL in TRX feature when a DDL returns the 8616 error, the statement is generally rolled back and it can be retried until it succeeds. This, however, is not the case for a table/schema with LOB columns. Drop a table or schema with internal LOB tables would often returns the 8616 error, and on the next retry, returns the 1031 or 1073 error with no further explanation. This is likely caused by the 8616 error not handling the internal LOB tables correctly. At that moment, using cleanup to clean up the tables and the schema becomes the only option. This is often seen when SQL regression is run with multiple streams. It is causing a huge problem for running LOB tests since once a table/schema is not dropped cleanly, all tests afterwards get messed up. Here are some of such failures seen on the AdvEnt2.2 1010 build: SQL>drop table mytable cascade; *** ERROR[8616] A conflict was detected during commit processing. Transaction has been aborted. [2016-10-12 12:53:54] SQL>drop table mytable cascade; *** ERROR[1031] Object TRAFODION.FEATURES_LOB.MYTABLE could not be dropped. [2016-10-12 12:54:01] SQL>drop table mytable1 cascade; *** ERROR[8616] A conflict was detected during commit processing. Transaction has been aborted. [2016-10-12 13:20:20] SQL>drop table mytable1 cascade; *** ERROR[1031] Object TRAFODION.FEATURES_LOB.MYTABLE1 could not be dropped. [2016-10-12 13:20:37] *** MISMATCH *** expecting: '--- SQL operation complete.' SQL>drop schema trafodion.features_lob_TEST007 cascade; *** ERROR[8616] A conflict was detected during commit processing. Transaction has been aborted. [2016-10-12 12:59:48] SQL>drop schema trafodion.features_lob_TEST007 cascade; *** ERROR[1031] Object TRAFODION.FEATURES_LOB_TEST007.MYTABLE could not be dropped. [2016-10-12 13:00:01] *** ERROR[1073] Schema TRAFODION.FEATURES_LOB_TEST007 was partially dropped, call CLEANUP SCHEMA to remove remaining entries. [2016-10-12 13:00:01] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2704) JDBC regression test failed by too many statement on the same session
[ https://issues.apache.org/jira/browse/TRAFODION-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161591#comment-16161591 ] ASF GitHub Bot commented on TRAFODION-2704: --- Github user sandhyasun commented on a diff in the pull request: https://github.com/apache/incubator-trafodion/pull/1225#discussion_r138132569 --- Diff: core/conn/odbc/src/odbc/nsksrvrcore/srvrothers.cpp --- @@ -6489,6 +6506,31 @@ odbc_SQLSrvr_ExtractLob_sme_( exception_->u.SQLError.errorList._buffer = QryLobExtractSrvrStmt->sqlError.errorList._buffer; exception_->u.ParamError.ParamDesc = SQLSVC_EXCEPTION_EXECUTE_FAILED; } + +IDL_long_long zeroValue = 0; +snprintf(LobExtractQuery, sizeof(LobExtractQuery), "EXTRACT LOBTOBUFFER(LOB'%s', LOCATION %Ld, SIZE %Ld)", lobHandle, (Int64)lobDataValue, ); + +retcode = QryLobExtractSrvrStmt->ExecDirect(NULL, LobExtractQuery, EXTERNAL_STMT, TYPE_CALL, SQL_ASYNC_ENABLE_OFF, 0); + --- End diff -- So who is the caller of this with 'zero' value. It needs to be triggered by the JDBC driver. But I am not seeing any changes in the driver ? The 'zeroLength' can be passed in only when the application decides to close the resultset or the connection. It cannot be called soon after the extract statement is executed. Can you clarify ? > JDBC regression test failed by too many statement on the same session > - > > Key: TRAFODION-2704 > URL: https://issues.apache.org/jira/browse/TRAFODION-2704 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Weiqing Xu >Assignee: Weiqing Xu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TRAFODION-2734) Create *Trafodion LOB Guide*
[ https://issues.apache.org/jira/browse/TRAFODION-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liu Yu updated TRAFODION-2734: -- Summary: Create *Trafodion LOB Guide* (was: Create *Trafodion LOB Guide* and Add 1st Chapter *Introduction*) > Create *Trafodion LOB Guide* > - > > Key: TRAFODION-2734 > URL: https://issues.apache.org/jira/browse/TRAFODION-2734 > Project: Apache Trafodion > Issue Type: Documentation >Reporter: Liu Yu >Assignee: Liu Yu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
