October 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-2690: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016243, https://bugzilla.redhat.com/show_bug.cgi?id=1016272 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1016243) > Tuples lost in a with clause item. > ---------------------------------- > > Key: TEIID-2690 > URL: https://issues.jboss.org/browse/TEIID-2690 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.1, 7.7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.6 > > > Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. > On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2689) support for pg regproc cast

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2689?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2689. ----------------------------------- Resolution: Done Increased pg compatibility with support for regproc casts. > support for pg regproc cast > --------------------------- > > Key: TEIID-2689 > URL: https://issues.jboss.org/browse/TEIID-2689 > Project: Teiid > Issue Type: Quality Risk > Components: Server > Affects Versions: 8.5 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Minor > Fix For: 8.6 > > > Attempting to use the PG 8.3 JDBC driver against an 8.6/master instance, a query against pg_proc (select * from pg_proc) failed due to how the older driver was looking up additional metadata with our enhanced support for array types - this does not occur in a 7.7 Teiid. > The offending query will complete as expected with support for the ::regproc cast. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2690. ----------------------------------- Fix Version/s: 8.6 Resolution: Done As I recall this change was intended as part of TEIID-2442, but was not included probably due to the lack of a reproducing unit test. The correction is to simply reuse the BatchIterator instance (just as is done with all other code paths that use BatchIterators). > Tuples lost in a with clause item. > ---------------------------------- > > Key: TEIID-2690 > URL: https://issues.jboss.org/browse/TEIID-2690 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.6 > > > Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. > On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2690: ---------------------------------- Affects Version/s: 7.7.7 8.1 Component/s: Query Engine > Tuples lost in a with clause item. > ---------------------------------- > > Key: TEIID-2690 > URL: https://issues.jboss.org/browse/TEIID-2690 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.1, 7.7.7 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 8.6 > > > Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. > On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2690: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1016243|https://bugzilla.redhat.com/show_bug.cgi?id=1016243] from NEW to ASSIGNED > Tuples lost in a with clause item. > ---------------------------------- > > Key: TEIID-2690 > URL: https://issues.jboss.org/browse/TEIID-2690 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > > Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. > On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-2690: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016243 > Tuples lost in a with clause item. > ---------------------------------- > > Key: TEIID-2690 > URL: https://issues.jboss.org/browse/TEIID-2690 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > > Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. > On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2690: ---------------------------------- > Tuples lost in a with clause item. > ---------------------------------- > > Key: TEIID-2690 > URL: https://issues.jboss.org/browse/TEIID-2690 > Project: Teiid > Issue Type: Bug > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > > Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. > On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2690: ------------------------------------- Summary: Tuples lost in a with clause item. Key: TEIID-2690 URL: https://issues.jboss.org/browse/TEIID-2690 Project: Teiid Issue Type: Bug Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Blocker Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples. On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2673) CNF exception when getting data through infinispan-cache translator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2673?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2673: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1011502|https://bugzilla.redhat.com/show_bug.cgi?id=1011502] from ASSIGNED to MODIFIED > CNF exception when getting data through infinispan-cache translator > ------------------------------------------------------------------- > > Key: TEIID-2673 > URL: https://issues.jboss.org/browse/TEIID-2673 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.4.1 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 8.4.1, 8.6 > > > When getting data through infinispan-cache translator using remote hot rod access, DV will throw "...ClassNotFoundException: org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory". > Workaround: > Add "<module name="org.infinispan.client.hotrod"/>" as a dependency into module "org.jboss.teiid". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2668) Teiid procedure input parameter has limit for bulk data

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2668?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2668: --------------------------------------- With a 8.4 client you'll need to examine the server log for an indication as to why the connection was terminated. If nothing shows up initially, retest with trace logging. > Teiid procedure input parameter has limit for bulk data > ------------------------------------------------------- > > Key: TEIID-2668 > URL: https://issues.jboss.org/browse/TEIID-2668 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.3 > Environment: Teiid 8.3. > Reporter: Jing Li > Assignee: Steven Hawkins > > We wrote a Teiid procedure, one of the input parameters is List<List<Double>>. We found if we give too many data in there, e.g. 200x375, Teiid will throw out exception before go to my translator: > org.teiid.jdbc.TeiidSQLException: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Connection reset by peer: socket write error > at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:113) > at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:70) > at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:631) > at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:559) > at org.teiid.jdbc.PreparedStatementImpl.execute(PreparedStatementImpl.java:201) > at MyTest.testHorizon3DWrite(MyTest.java:102) > at MyTest.main(MyTest.java:27) > Caused by: [TeiidComponentException] TEIID20013: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Connection reset by peer: socket write error > 1 [SingleInstanceCommunicationException] TEIID20013: Error Code:TEIID20013 Message:java.net.SocketException: Connection reset by peer: socket write error > 2 [ExecutionException]java.net.SocketException: Connection reset by peer: socket write error > 3 [SocketException]Connection reset by peer: socket write error > at org.teiid.client.util.ExceptionUtil.convertException(ExceptionUtil.java:61) > at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler.invoke(SocketServerInstanceImpl.java:374) > at org.teiid.net.socket.SocketServerConnection$1.invoke(SocketServerConnection.java:243) > at $Proxy7.executeRequest(Unknown Source) > at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:629) > ... 4 more > Caused by: [SingleInstanceCommunicationException] TEIID20013: Error Code:TEIID20013 Message:java.net.SocketException: Connection reset by peer: socket write error > 1 [ExecutionException]java.net.SocketException: Connection reset by peer: socket write error > 2 [SocketException]Connection reset by peer: socket write error > at org.teiid.net.socket.SocketServerInstanceImpl.send(SocketServerInstanceImpl.java:177) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:102) > at $Proxy1.send(Unknown Source) > at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler.invoke(SocketServerInstanceImpl.java:362) > ... 7 more > Caused by: java.util.concurrent.ExecutionException: java.net.SocketException: Connection reset by peer: socket write error > at org.teiid.client.util.ResultsFuture.convertResult(ResultsFuture.java:100) > at org.teiid.client.util.ResultsFuture.get(ResultsFuture.java:95) > at org.teiid.net.socket.SocketServerInstanceImpl.send(SocketServerInstanceImpl.java:174) > ... 14 more > Caused by: java.net.SocketException: Connection reset by peer: socket write error > at java.net.SocketOutputStream.socketWrite0(Native Method) > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) > at java.net.SocketOutputStream.write(SocketOutputStream.java:136) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) > at java.io.DataOutputStream.write(DataOutputStream.java:90) > at org.teiid.netty.handler.codec.serialization.ObjectEncoderOutputStream.writeObjectOverride(ObjectEncoderOutputStream.java:65) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) > at org.teiid.net.socket.OioOjbectChannelFactory$OioObjectChannel.write(OioOjbectChannelFactory.java:130) > at org.teiid.net.socket.SocketServerInstanceImpl.send(SocketServerInstanceImpl.java:173) > ... 14 more > But if we give less number of data in that param, e.g. 100x375, it works fine. > Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues October 2013