[JBoss JIRA] (TEIID-3141) Bad result of query with GROUB BY clause (underlying sybase15 datasource)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3141?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3141:
---------------------------------------
> Only rows with IntNum=1 and IntNum=-1 are correct. Same result for IntKey column.
Actually for the types involved, what sybase/Teiid is returning is the correct answer. You are performing integer division which results in most values being acos(0).
> I have tried oracle12 (VDB and original) and result has been OK
More than likely the source is performing decimal division. That is the intnum type is likely not a true integral type.
> Result is for every value in the table 1.5708 (same for ShortValue). In this case original sybase returns correct result.
Same as above. It matters what the source type is. From the Teiid perspective with the query as written you are performing integer division and thus getting acos(0).
An issue I do see is that if you issue 1.0/int Teiid should not evaluate using integer division, and should produce the wider decimal result.
> Bad result of query with GROUB BY clause (underlying sybase15 datasource)
> -------------------------------------------------------------------------
>
> Key: TEIID-3141
> URL: https://issues.jboss.org/browse/TEIID-3141
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1
> Environment: OS: fedora20
> arch: x86_64
> java: sun 1.7
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> Description:
> There is sybase15 database with table named SmallA and table named SmallA in VDB which is mapped to sybase table (see tables definition below).
> I am trying to run query against VDB:
> SELECT
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> FROM
> BQT1.SMALLA
> GROUP BY
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> Result is table which misses some values (the other values are OK):
> FloatNum: always 0
> ByteNum: always 0
> DateValue: always 1900-01-01
> TimeValue: always 00:00:00
> BooleanValue: always 'false'
> CharValue: always empty character
> ShortValue: always 0
> BigIntegerValue: always 0
> BigDecimalValue: always 0
> After removing 'INTKEY' and 'STRINGKEY' from the query is result OK (sybase15 has indices only for these two columns).
> ///////////////////
> Table definition
> ///////////////////
> SmallA (sybase) has these columns (name:type):
> IntKey:int -> PRIMARY KEY, HAS INDEX
> StringKey:varchar -> HAS INDEX
> IntNum:int
> StringNum:varchar
> FloatNum:float
> LongNum:numeric
> DoubleNum:float
> ByteNum:real
> DateValue:datetime
> TimeValue:datetime
> TimestampValue:datetime
> BooleanValue:tinyint
> CharValue:char
> ShortValue:numeric
> BigIntegerValue:numeric
> BigDecimalValue:numeric
> ObjectValue:text
> SmallA (VDB) has these columns (name:type):
> IntKey:integer
> StringKey:string
> IntNum:integer
> StringNum:string
> FloatNum:float
> LongNum:long
> DoubleNum:double
> ByteNum:byte
> DateValue:date
> TimeValue:time
> TimestampValue:timestamp
> BooleanValue:boolean
> CharValue:char
> ShortValue:short
> BigIntegerValue:biginteger
> BigDecimalValue:bigdecimal
> ObjectValue:object
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (TEIID-3158) VDB versioning does not work
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3158?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3158.
-----------------------------------
Resolution: Duplicate Issue
Duplicate of TEIID-2964
> VDB versioning does not work
> ----------------------------
>
> Key: TEIID-3158
> URL: https://issues.jboss.org/browse/TEIID-3158
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4.1
> Environment: - JDV 6.0.0
> Reporter: Hisanobu Okuda
> Assignee: Steven Hawkins
>
> The vdb "test.1.vdb" should be deployed as the vdb "test" of the version "1" as described in [1]. But, it is deployed as the vdb "test.1" in fact as following:-
> {code}
> 20:48:20,210 INFO [org.jboss.as.repository] (management-handler-thread - 6) JBAS014900: Content added at location /opt/dv600/jboss-eap-6.1/standalone/data/content/b8/a0bf2213af6edc2817c63f149f760d1d796cda/content
> 20:48:20,212 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "test.1.vdb" (runtime-name: "test.1.vdb")
> 20:48:20,270 INFO [org.teiid.RUNTIME] (MSC service thread 1-6) TEIID50029 VDB test.1 model "SourceModel" metadata is currently being loaded. Start Time: 10/2/14 8:48 PM
> 20:48:20,273 INFO [org.teiid.RUNTIME] (MSC service thread 1-6) TEIID50029 VDB test.1 model "ViewModel" metadata is currently being loaded. Start Time: 10/2/14 8:48 PM
> 20:48:20,296 INFO [org.teiid.RUNTIME] (teiid-async-threads - 4) TEIID50030 VDB test.1 model "ViewModel" metadata loaded. End Time: 10/2/14 8:48 PM
> 20:48:20,296 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50030 VDB test.1 model "SourceModel" metadata loaded. End Time: 10/2/14 8:48 PM
> 20:48:20,300 INFO [org.jboss.as.server] (management-handler-thread - 6) JBAS018559: Deployed "test.1.vdb" (runtime-name : "test.1.vdb")
> 20:48:20,334 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) Data Source SourceModel not accessible.
> 20:48:20,334 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID40003 VDB test.1 is set to ACTIVE
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (TEIID-3141) Bad result of query with GROUB BY clause (underlying sybase15 datasource)
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3141?page=com.atlassian.jira.plugin... ]
Juraj Duráni commented on TEIID-3141:
-------------------------------------
I have found these:
SELECT intnum, ACOS(1 / intnum) FROM BQT1.SmallA WHERE intnum <> 0 ORDER BY intnum
OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
AccessNode(0) output=[Source.SmallA.IntNum, ACOS(convert((1 / Source.SmallA.IntNum), double))] SELECT g_0.IntNum AS c_0, ACOS(convert((1 / g_0.IntNum), double)) AS c_1 FROM Source.SmallA AS g_0 WHERE g_0.IntNum <> 0 ORDER BY c_0 LIMIT 100
*Return for almost every value 1.5708* (=ACOS(0)). Only rows with IntNum=1 and IntNum=-1 are correct. Same result for IntKey column.
*But same result returns original sybaseDB* (maybe bug in sybase jdbc). I have tried oracle12 (VDB and original) and result has been OK.
----------------------------------------------------------------------------------------------------
SELECT longnum, ACOS(1 / longnum) FROM BQT1.SmallA WHERE longnum <> 0 ORDER BY longnum
OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
AccessNode(0) output=[Source.SmallA.LongNum, ACOS(convert((1 / Source.SmallA.LongNum), bigdecimal))] SELECT g_0.LongNum AS c_0, ACOS(convert((1 / g_0.LongNum), bigdecimal)) AS c_1 FROM Source.SmallA AS g_0 WHERE g_0.LongNum <> 0 ORDER BY c_0 LIMIT 100
*Result is correct* (same for FloatNum, DoubleNum, BigIntegerValue, BigDecimalValue). IntNum and LongNum columns have same values so results should be same.
-------------------------------------------------------------------------------------------------------
SELECT bytenum, ACOS(1 / bytenum) FROM BQT1.SmallA WHERE bytenum <> 0 ORDER BY bytenum
*Result is for every value in the table 1.5708* (same for ShortValue). In this case *original sybase returns correct result*.
-------------------------------------------------------------------------------------------------------
SELECT AVG(shortvalue) FROM BQT1.SmallA
SELECT AVG(bytenum) FROM BQT1.SmallA
*AVG returns integer* (-103/ByteNum, -32,743/ShortValue) but *should be real* (-103.2766/ByteNum, -32,743.65957/ShortValue).
*Original sybase DB returns correct result* in this case.
AVG with DoubleNum, LongNum, BigIntegerNum, BigDecimalNum, IntKey, IntNum, FloatNum returns correct result.
------------------------------------------------------------------------------------------------------
> Bad result of query with GROUB BY clause (underlying sybase15 datasource)
> -------------------------------------------------------------------------
>
> Key: TEIID-3141
> URL: https://issues.jboss.org/browse/TEIID-3141
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1
> Environment: OS: fedora20
> arch: x86_64
> java: sun 1.7
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> Description:
> There is sybase15 database with table named SmallA and table named SmallA in VDB which is mapped to sybase table (see tables definition below).
> I am trying to run query against VDB:
> SELECT
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> FROM
> BQT1.SMALLA
> GROUP BY
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> Result is table which misses some values (the other values are OK):
> FloatNum: always 0
> ByteNum: always 0
> DateValue: always 1900-01-01
> TimeValue: always 00:00:00
> BooleanValue: always 'false'
> CharValue: always empty character
> ShortValue: always 0
> BigIntegerValue: always 0
> BigDecimalValue: always 0
> After removing 'INTKEY' and 'STRINGKEY' from the query is result OK (sybase15 has indices only for these two columns).
> ///////////////////
> Table definition
> ///////////////////
> SmallA (sybase) has these columns (name:type):
> IntKey:int -> PRIMARY KEY, HAS INDEX
> StringKey:varchar -> HAS INDEX
> IntNum:int
> StringNum:varchar
> FloatNum:float
> LongNum:numeric
> DoubleNum:float
> ByteNum:real
> DateValue:datetime
> TimeValue:datetime
> TimestampValue:datetime
> BooleanValue:tinyint
> CharValue:char
> ShortValue:numeric
> BigIntegerValue:numeric
> BigDecimalValue:numeric
> ObjectValue:text
> SmallA (VDB) has these columns (name:type):
> IntKey:integer
> StringKey:string
> IntNum:integer
> StringNum:string
> FloatNum:float
> LongNum:long
> DoubleNum:double
> ByteNum:byte
> DateValue:date
> TimeValue:time
> TimestampValue:timestamp
> BooleanValue:boolean
> CharValue:char
> ShortValue:short
> BigIntegerValue:biginteger
> BigDecimalValue:bigdecimal
> ObjectValue:object
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (TEIID-3158) VDB versioning does not work
by Hisanobu Okuda (JIRA)
Hisanobu Okuda created TEIID-3158:
-------------------------------------
Summary: VDB versioning does not work
Key: TEIID-3158
URL: https://issues.jboss.org/browse/TEIID-3158
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 8.4.1
Environment: - JDV 6.0.0
Reporter: Hisanobu Okuda
Assignee: Steven Hawkins
The vdb "test.1.vdb" should be deployed as the vdb "test" of the version "1" as described in [1]. But, it is deployed as the vdb "test.1" in fact as following:-
{code}
20:48:20,210 INFO [org.jboss.as.repository] (management-handler-thread - 6) JBAS014900: Content added at location /opt/dv600/jboss-eap-6.1/standalone/data/content/b8/a0bf2213af6edc2817c63f149f760d1d796cda/content
20:48:20,212 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "test.1.vdb" (runtime-name: "test.1.vdb")
20:48:20,270 INFO [org.teiid.RUNTIME] (MSC service thread 1-6) TEIID50029 VDB test.1 model "SourceModel" metadata is currently being loaded. Start Time: 10/2/14 8:48 PM
20:48:20,273 INFO [org.teiid.RUNTIME] (MSC service thread 1-6) TEIID50029 VDB test.1 model "ViewModel" metadata is currently being loaded. Start Time: 10/2/14 8:48 PM
20:48:20,296 INFO [org.teiid.RUNTIME] (teiid-async-threads - 4) TEIID50030 VDB test.1 model "ViewModel" metadata loaded. End Time: 10/2/14 8:48 PM
20:48:20,296 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50030 VDB test.1 model "SourceModel" metadata loaded. End Time: 10/2/14 8:48 PM
20:48:20,300 INFO [org.jboss.as.server] (management-handler-thread - 6) JBAS018559: Deployed "test.1.vdb" (runtime-name : "test.1.vdb")
20:48:20,334 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) Data Source SourceModel not accessible.
20:48:20,334 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID40003 VDB test.1 is set to ACTIVE
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (TEIID-3158) VDB versioning does not work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3158?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3158:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1098413
> VDB versioning does not work
> ----------------------------
>
> Key: TEIID-3158
> URL: https://issues.jboss.org/browse/TEIID-3158
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4.1
> Environment: - JDV 6.0.0
> Reporter: Hisanobu Okuda
> Assignee: Steven Hawkins
>
> The vdb "test.1.vdb" should be deployed as the vdb "test" of the version "1" as described in [1]. But, it is deployed as the vdb "test.1" in fact as following:-
> {code}
> 20:48:20,210 INFO [org.jboss.as.repository] (management-handler-thread - 6) JBAS014900: Content added at location /opt/dv600/jboss-eap-6.1/standalone/data/content/b8/a0bf2213af6edc2817c63f149f760d1d796cda/content
> 20:48:20,212 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "test.1.vdb" (runtime-name: "test.1.vdb")
> 20:48:20,270 INFO [org.teiid.RUNTIME] (MSC service thread 1-6) TEIID50029 VDB test.1 model "SourceModel" metadata is currently being loaded. Start Time: 10/2/14 8:48 PM
> 20:48:20,273 INFO [org.teiid.RUNTIME] (MSC service thread 1-6) TEIID50029 VDB test.1 model "ViewModel" metadata is currently being loaded. Start Time: 10/2/14 8:48 PM
> 20:48:20,296 INFO [org.teiid.RUNTIME] (teiid-async-threads - 4) TEIID50030 VDB test.1 model "ViewModel" metadata loaded. End Time: 10/2/14 8:48 PM
> 20:48:20,296 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50030 VDB test.1 model "SourceModel" metadata loaded. End Time: 10/2/14 8:48 PM
> 20:48:20,300 INFO [org.jboss.as.server] (management-handler-thread - 6) JBAS018559: Deployed "test.1.vdb" (runtime-name : "test.1.vdb")
> 20:48:20,334 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) Data Source SourceModel not accessible.
> 20:48:20,334 INFO [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID40003 VDB test.1 is set to ACTIVE
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (TEIID-3153) Allow to write stream data with large size (>10G)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3153?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3153.
-----------------------------------
Resolution: Done
Made the max lob size configurable via a system property and updated the admin reference https://docs.jboss.org/author/display/TEIID/System+Properties
Will prioritize TEIID-3157 when intermediate copies become a storage or performance issue.
> Allow to write stream data with large size (>10G)
> -------------------------------------------------
>
> Key: TEIID-3153
> URL: https://issues.jboss.org/browse/TEIID-3153
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Haifen Bi
> Assignee: Steven Hawkins
> Fix For: 8.9
>
>
> We have quite large size of data file (>10G) that needs to be sent back to server from client. Following is JDBC client code:
> void writeData(int id) {
> String sql = "UPDATE DataSet set data = ? WHERE id = ?";
> try {
> InputStream is = new FileInputStream("c:\\temp\\data");
> this.ps = connection.prepareStatement(sql);
> this.ps.setBlob(1, is);
> this.ps.setInt(2, id);
> ps.executeUpdate();
> } catch (Exception e) {
> ..
> }
> }
> Teiid throws "lob too big" error when executing above code:
> 10:01:18,801 WARN [org.teiid.TRANSPORT] (New I/O worker #1) TEIID40113 Unhandled exception, aborting operation: java.io.StreamCorruptedException: lob too big:
> 429496456065534 (max: 4294967296)
> at org.teiid.transport.ObjectDecoder.decode(ObjectDecoder.java:142) [teiid-runtime-8.7.0.Final.jar:8.7.0.Final]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.2.Final.jar:]
>
> It seemed teiid has stream data size limit (4G?). With this limitation, it is not possible to send more than 4G of stream data in Teiid.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (TEIID-3153) Allow to write stream data with large size (>10G)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3153?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3153:
----------------------------------
Component/s: Server
(was: JDBC Driver)
> Allow to write stream data with large size (>10G)
> -------------------------------------------------
>
> Key: TEIID-3153
> URL: https://issues.jboss.org/browse/TEIID-3153
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Haifen Bi
> Assignee: Steven Hawkins
> Fix For: 8.9
>
>
> We have quite large size of data file (>10G) that needs to be sent back to server from client. Following is JDBC client code:
> void writeData(int id) {
> String sql = "UPDATE DataSet set data = ? WHERE id = ?";
> try {
> InputStream is = new FileInputStream("c:\\temp\\data");
> this.ps = connection.prepareStatement(sql);
> this.ps.setBlob(1, is);
> this.ps.setInt(2, id);
> ps.executeUpdate();
> } catch (Exception e) {
> ..
> }
> }
> Teiid throws "lob too big" error when executing above code:
> 10:01:18,801 WARN [org.teiid.TRANSPORT] (New I/O worker #1) TEIID40113 Unhandled exception, aborting operation: java.io.StreamCorruptedException: lob too big:
> 429496456065534 (max: 4294967296)
> at org.teiid.transport.ObjectDecoder.decode(ObjectDecoder.java:142) [teiid-runtime-8.7.0.Final.jar:8.7.0.Final]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.2.Final.jar:]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.2.Final.jar:]
>
> It seemed teiid has stream data size limit (4G?). With this limitation, it is not possible to send more than 4G of stream data in Teiid.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months
[JBoss JIRA] (TEIID-3157) Allow streaming without an intermediate copy
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3157?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3157:
----------------------------------
Issue Type: Feature Request (was: Enhancement)
Fix Version/s: (was: 8.9)
Description: With TEIID-3153 there are scenarios that require streaming larger than 4 gigs of data. We should also provide a mechanism for on demand streaming from the client to accommodate even larger streaming scenarios to eliminate the need for an intermediate copy. (was: We have quite large size of data file (>10G) that needs to be sent back to server from client. Following is JDBC client code:
void writeData(int id) {
String sql = "UPDATE DataSet set data = ? WHERE id = ?";
try {
InputStream is = new FileInputStream("c:\\temp\\data");
this.ps = connection.prepareStatement(sql);
this.ps.setBlob(1, is);
this.ps.setInt(2, id);
ps.executeUpdate();
} catch (Exception e) {
..
}
}
Teiid throws "lob too big" error when executing above code:
10:01:18,801 WARN [org.teiid.TRANSPORT] (New I/O worker #1) TEIID40113 Unhandled exception, aborting operation: java.io.StreamCorruptedException: lob too big:
429496456065534 (max: 4294967296)
at org.teiid.transport.ObjectDecoder.decode(ObjectDecoder.java:142) [teiid-runtime-8.7.0.Final.jar:8.7.0.Final]
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425) [netty-3.6.2.Final.jar:]
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.2.Final.jar:]
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.2.Final.jar:]
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.2.Final.jar:]
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.2.Final.jar:]
It seemed teiid has stream data size limit (4G?). With this limitation, it is not possible to send more than 4G of stream data in Teiid. )
> Allow streaming without an intermediate copy
> --------------------------------------------
>
> Key: TEIID-3157
> URL: https://issues.jboss.org/browse/TEIID-3157
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Driver, Server
> Reporter: Haifen Bi
> Assignee: Steven Hawkins
>
> With TEIID-3153 there are scenarios that require streaming larger than 4 gigs of data. We should also provide a mechanism for on demand streaming from the client to accommodate even larger streaming scenarios to eliminate the need for an intermediate copy.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 3 months