[JBoss JIRA] (TEIID-2502) org.teiid.net.socket.SingleInstanceCommunicationException
by luca gioppo (JIRA)
[ https://issues.jboss.org/browse/TEIID-2502?page=com.atlassian.jira.plugin... ]
luca gioppo commented on TEIID-2502:
------------------------------------
The query is a select so it seems that the getObject method does not work as expected (why it issues a writeObject??).
The actual value of the geometry column is a SDO_POINT_TYPE (I believe the DB is not under my complete control :-) I'm the virtualizator guy that has to do the magic on a black box :( ) it should be a struct.
--- from Oracle site ---
oracle.spatial.geometry.JGeometry
All Implemented Interfaces:
java.io.Serializable, java.lang.Cloneable
public class JGeometry
extends java.lang.Object
implements java.lang.Cloneable, java.io.Serializable
A Java class that maps Oracle Spatial's SQL type MDSYS.SDO_GEOMETRY. Supports only Oracle JDBC Driver version 8.1.7 or higher. Provides basic access functions to the geomeries stroed in Oracle Spatial database.
Note that this class is not synchornized, meaning if one thread is reading this geometry and another is modifying it (such as changing its ordinates array), there may be in-consistencies.
The main methods for reading/writing db geometries are: load(STRUCT) and store(). Here is a simple example showing how to use these two methods:
/// reading a geometry from database
ResultSet rs = statement.executeQuery("SELECT geometry FROM states where name='Florida'");
STRUCT st = (oracle.sql.STRUCT) rs.getObject(1);
//convert STRUCT into geometry
JGeometry j_geom = JGeometry.load(st);
// ... manipulate the geometry or create a new JGeometry ...
/// writing a geometry back to database
PreparedStatement ps = connection.prepareStatement("UPDATE states set geometry=? where name='Florida'");
//convert JGeometry instance to DB STRUCT
STRUCT obj = JGeometry.store(j_geom, connection);
ps.setObject(1, obj);
ps.execute();
--- end ---
So maybe a struct could be better than object? Is something that can be tried on my part or a patch yuo need to address?
I believe that using JTS could help (to get an open source licenced lib), but have not other hints.
There is a bug on the hibernatespatial http://www.hibernatespatial.org/jira/browse/HIBSPA-21, but do not know if can be of any help.
> org.teiid.net.socket.SingleInstanceCommunicationException
> ---------------------------------------------------------
>
> Key: TEIID-2502
> URL: https://issues.jboss.org/browse/TEIID-2502
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Environment: centos 6.3
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Priority: Critical
>
> I'm issuing a query (a simple select * from table) on a VDB's table that contains a geometric column from oracle spatial.
> I'm getting the following error in SquirrelSQL
> Error: org.teiid.net.socket.SingleInstanceCommunicationException
> SQLState: 08S01
> ErrorCode: 0
> Afterwards the connection is broken and I cannot access any other table and have to reconnect since I get:
> Error: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Socket closed
> SQLState: TEIID20013
> ErrorCode: 0
> I'm trying to access a SDO table and a geometry type column, but hoped that TEIID could read it as a BLOB without caring about the real type.
> Probably it doesn't like it too much.
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2502) org.teiid.net.socket.SingleInstanceCommunicationException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2502?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-2502 at 5/16/13 10:34 AM:
-----------------------------------------------------------------
A non-serializable value in persisted results (whether the final socket result or intermediate results) is something that is difficult for us to handle. When it or any error occurs at the transport layer we just assume that the connection is in an invalid state and terminate (which could be improved upon somewhat - with TEIID-2505 at least the error will be logged at an error level).
Some things that could be done:
1. In general we can use memory tracking, similar to our approach to attached lob values, which would allow non-serializable types to work for everything but socket results.
2. Introduce built-in or custom handling for the offending value types.
was (Author: shawkins):
A non-serializable value in persisted results (whether the final socket result or intermediate results) is something that is difficult for us to handle. When it or any error occurs at the transport layer we just assume that the connection is in an invalid state and terminate (which could be improved upon somewhat - with TEIID-2504 at least the error will be logged at an error level).
Some things that could be done:
1. In general we can use memory tracking, similar to our approach to attached lob values, which would allow non-serializable types to work for everything but socket results.
2. Introduce built-in or custom handling for the offending value types.
> org.teiid.net.socket.SingleInstanceCommunicationException
> ---------------------------------------------------------
>
> Key: TEIID-2502
> URL: https://issues.jboss.org/browse/TEIID-2502
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Environment: centos 6.3
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Priority: Critical
>
> I'm issuing a query (a simple select * from table) on a VDB's table that contains a geometric column from oracle spatial.
> I'm getting the following error in SquirrelSQL
> Error: org.teiid.net.socket.SingleInstanceCommunicationException
> SQLState: 08S01
> ErrorCode: 0
> Afterwards the connection is broken and I cannot access any other table and have to reconnect since I get:
> Error: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Socket closed
> SQLState: TEIID20013
> ErrorCode: 0
> I'm trying to access a SDO table and a geometry type column, but hoped that TEIID could read it as a BLOB without caring about the real type.
> Probably it doesn't like it too much.
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2502) org.teiid.net.socket.SingleInstanceCommunicationException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2502?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2502:
---------------------------------------
There is currently no special handling for oracle spatial type values. Assuming that you have the column typed as object, we're just using the getObject method on the result set to get the value. If there is a better representation, then a different getter or post retrieval operation can be performed (for example if there a standard type representation that is acceptable).
Otherwise the translator or the batch serialization logic needs to do more to handle these values. Do you know what the java class representation is?
> org.teiid.net.socket.SingleInstanceCommunicationException
> ---------------------------------------------------------
>
> Key: TEIID-2502
> URL: https://issues.jboss.org/browse/TEIID-2502
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Environment: centos 6.3
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Priority: Critical
>
> I'm issuing a query (a simple select * from table) on a VDB's table that contains a geometric column from oracle spatial.
> I'm getting the following error in SquirrelSQL
> Error: org.teiid.net.socket.SingleInstanceCommunicationException
> SQLState: 08S01
> ErrorCode: 0
> Afterwards the connection is broken and I cannot access any other table and have to reconnect since I get:
> Error: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Socket closed
> SQLState: TEIID20013
> ErrorCode: 0
> I'm trying to access a SDO table and a geometry type column, but hoped that TEIID could read it as a BLOB without caring about the real type.
> Probably it doesn't like it too much.
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2502) org.teiid.net.socket.SingleInstanceCommunicationException
by luca gioppo (JIRA)
[ https://issues.jboss.org/browse/TEIID-2502?page=com.atlassian.jira.plugin... ]
luca gioppo commented on TEIID-2502:
------------------------------------
I believe that the offending type is the geometry column type, but I assumed that the oracle spatial types were merged into the single Oracle connector.
Do this means that is not possible to get the value out even in raw format?
> org.teiid.net.socket.SingleInstanceCommunicationException
> ---------------------------------------------------------
>
> Key: TEIID-2502
> URL: https://issues.jboss.org/browse/TEIID-2502
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Environment: centos 6.3
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Priority: Critical
>
> I'm issuing a query (a simple select * from table) on a VDB's table that contains a geometric column from oracle spatial.
> I'm getting the following error in SquirrelSQL
> Error: org.teiid.net.socket.SingleInstanceCommunicationException
> SQLState: 08S01
> ErrorCode: 0
> Afterwards the connection is broken and I cannot access any other table and have to reconnect since I get:
> Error: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Socket closed
> SQLState: TEIID20013
> ErrorCode: 0
> I'm trying to access a SDO table and a geometry type column, but hoped that TEIID could read it as a BLOB without caring about the real type.
> Probably it doesn't like it too much.
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2503) XML Recursive and Nested Doc queries are producing "TEIID30328 Unable to evaluate "INPUT".nextKey: No value was available error"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2503?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2503:
----------------------------------
Fix Version/s: 8.4.1
> XML Recursive and Nested Doc queries are producing "TEIID30328 Unable to evaluate "INPUT".nextKey: No value was available error"
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2503
> URL: https://issues.jboss.org/browse/TEIID-2503
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Environment: EAP6.1Alpha and Teiid8.4Alpha
> Reporter: Warren Gibson
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.4.1
>
> Attachments: QT_PostgreSQL91_Push.vdb, SERVER.log
>
>
> The following queries are producing TEIID30328 Unable to evaluate "INPUT".nextKey: No value was available error.
> The queries were returning expected query results in SOA-P5.3.1 release. However, when testing them with EAP 6.1Alpha and
> Teiid 8.4Alpha they are returning the "Unable to evaluate "INPUT".nextKey" message. This is occuring on Postgres91, Oracle10,11,11RAC, Mysql55, Teradata, and Greenplum data sources.
> I isolated "SELECT * FROM XQTNestedDoc.testSimpleNested ORDER BY recursiveroot.key" and ran a test to produce a log entry which
> is attached. If you need other testing artifacts such as VDB please let me know.
> SELECT * FROM XQTNestedDoc.testBoundTempTable
> SELECT * FROM XQTNestedDoc.testExcludeFromDoc ORDER BY recursiveroot.key
> SELECT * FROM XQTNestedDoc.testOptimizableTempTable ORDER BY recursiveroot.key
> SELECT * FROM XQTNestedDoc.testRootTempTable ORDER BY recursiveroot.key
> SELECT * FROM XQTNestedDoc.testSimpleNested ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testNested2Document ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testNestedDocument ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testSimpleDocument ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testSimpleTempTable ORDER BY recursiveroot.key
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2502) org.teiid.net.socket.SingleInstanceCommunicationException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2502?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2502:
---------------------------------------
A non-serializable value in persisted results (whether the final socket result or intermediate results) is something that is difficult for us to handle. When it or any error occurs at the transport layer we just assume that the connection is in an invalid state and terminate (which could be improved upon somewhat - with TEIID-2504 at least the error will be logged at an error level).
Some things that could be done:
1. In general we can use memory tracking, similar to our approach to attached lob values, which would allow non-serializable types to work for everything but socket results.
2. Introduce built-in or custom handling for the offending value types.
> org.teiid.net.socket.SingleInstanceCommunicationException
> ---------------------------------------------------------
>
> Key: TEIID-2502
> URL: https://issues.jboss.org/browse/TEIID-2502
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Environment: centos 6.3
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Priority: Critical
>
> I'm issuing a query (a simple select * from table) on a VDB's table that contains a geometric column from oracle spatial.
> I'm getting the following error in SquirrelSQL
> Error: org.teiid.net.socket.SingleInstanceCommunicationException
> SQLState: 08S01
> ErrorCode: 0
> Afterwards the connection is broken and I cannot access any other table and have to reconnect since I get:
> Error: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Socket closed
> SQLState: TEIID20013
> ErrorCode: 0
> I'm trying to access a SDO table and a geometry type column, but hoped that TEIID could read it as a BLOB without caring about the real type.
> Probably it doesn't like it too much.
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2502) org.teiid.net.socket.SingleInstanceCommunicationException
by luca gioppo (JIRA)
[ https://issues.jboss.org/browse/TEIID-2502?page=com.atlassian.jira.plugin... ]
luca gioppo commented on TEIID-2502:
------------------------------------
Here is the trace
10:31:24,820 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue30) START DATA SRC COMMAND: startTime=2013-05-16 10:31:24.82 requestID=vtrcecGayv27.12 sourceCommandID=0 txID=null modelName=twistDB translatorName=oracle sessionID=vtrcecGayv27 principal=user@teiid-security sql=SELECT g_0.ID_PT_LOCINC AS c_0, g_0.FK_INCIDENTE AS c_1, g_0.GEOMETRIA AS c_2 FROM twistDB.SISS_SDO_PT_LOCINC AS g_0 LIMIT 100
10:31:24,823 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue30) Source-specific command: SELECT c_0, c_1, c_2 FROM (SELECT g_0.ID_PT_LOCINC AS c_0, g_0.FK_INCIDENTE AS c_1, g_0.GEOMETRIA AS c_2 FROM "SISS"."SISS_SDO_PT_LOCINC" g_0) WHERE ROWNUM <= 100
10:31:24,825 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue29) Request Thread
10:31:25,289 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue30) vtrcecGayv27.12.0.1
10:31:25,290 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue30) vtrcecGayv27.12.0.1
10:31:25,290 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue30) vtrcecGayv27.12.0.1
10:31:25,297 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue30) vtrcecGayv27.12.0.1
10:31:25,298 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue31) Request Thread
10:31:25,300 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue31) QueryProcessor: closing processor
10:31:25,300 DEBUG [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue32) Running task for parent thread
10:31:25,301 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue31) [RequestWorkItem.sendResultsIfNeeded] requestID:
10:31:25,303 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue32) vtrcecGayv27.12.0.1
10:31:25,304 DEBUG [org.teiid.TRANSPORT] (Worker0_QueryProcessorQueue31) send message: MessageHolder: key=40 contents=ResultsMessage rowCount=100 finalRow=100
10:31:25,306 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue32) vtrcecGayv27.12.0.1
10:31:25,310 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue32) END SRC COMMAND: endTime=2013-05-16 10:31:25.309 requestID=vtrcecGayv27.12 sourceCommandID=0 txID=null modelName=twistDB translatorName=oracle sessionID=vtrcecGayv27 principal=user@teiid-security finalRowCount=100
10:31:25,316 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue32) vtrcecGayv27.12.0.1
10:31:25,321 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue32) vtrcecGayv27.12.0.1
10:31:25,327 DEBUG [org.teiid.TRANSPORT] (Worker0_QueryProcessorQueue31) Unhandled exception, closing client instance: java.io.NotSerializableException: oracle.jdbc.driver.T4CConnection
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) [rt.jar:1.6.0_25]
at org.teiid.client.BatchSerializer$ColumnSerializer.writeObject(BatchSerializer.java:439) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.BatchSerializer$ObjectColumnSerializer.writeObject(BatchSerializer.java:245) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.BatchSerializer$ObjectColumnSerializer.writeObject(BatchSerializer.java:230) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.BatchSerializer$ColumnSerializer.writeColumn(BatchSerializer.java:424) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.BatchSerializer$ObjectColumnSerializer.writeColumn(BatchSerializer.java:215) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.BatchSerializer.writeBatch(BatchSerializer.java:721) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.ResultsMessage.writeExternal(ResultsMessage.java:277) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) [rt.jar:1.6.0_25]
at org.teiid.net.socket.Message.writeExternal(Message.java:56) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) [rt.jar:1.6.0_25]
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) [rt.jar:1.6.0_25]
at org.teiid.transport.ObjectEncoder.handleDownstream(ObjectEncoder.java:115) [teiid-runtime-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.netty.channel.Channels.write(Channels.java:611) [netty-3.2.6.Final.jar:]
at org.jboss.netty.channel.Channels.write(Channels.java:578) [netty-3.2.6.Final.jar:]
at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:251) [netty-3.2.6.Final.jar:]
at org.teiid.transport.SSLAwareChannelHandler$ObjectChannelImpl.write(SSLAwareChannelHandler.java:94) [teiid-runtime-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.transport.SocketClientInstance.send(SocketClientInstance.java:82) [teiid-runtime-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.transport.ServerWorkItem.sendResult(ServerWorkItem.java:137) [teiid-runtime-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.transport.ServerWorkItem$1.onCompletion(ServerWorkItem.java:107) [teiid-runtime-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:130) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:37) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:75) [teiid-client-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.RequestWorkItem.sendResultsIfNeeded(RequestWorkItem.java:748) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:567) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:191) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:166) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:384) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:288) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:216) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:250) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:123) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:298) [teiid-engine-8.2.0.Final.jar:8.2.0.Final]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25]
10:31:25,428 DEBUG [org.teiid.TRANSPORT] (Worker0_QueryProcessorQueue31) Channel closed
10:31:25,430 DEBUG [org.teiid.SECURITY] (Worker0_QueryProcessorQueue31) closeSession
10:31:25,432 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue31) cancelQuery for requestID=vtrcecGayv27.12
10:31:25,435 DEBUG [org.teiid.TXN_LOG] (Worker0_QueryProcessorQueue31) before cancelTransactions:org.teiid.dqp.internal.process.TransactionServerImpl@f2882ad(vtrcecGayv27,true)
10:31:25,439 DEBUG [org.teiid.TXN_LOG] (Worker0_QueryProcessorQueue31) after cancelTransactions : null
10:31:25,442 DEBUG [org.teiid.TXN_LOG] (Worker0_QueryProcessorQueue31) before cancelTransactions:org.teiid.dqp.internal.process.TransactionServerImpl@f2882ad(vtrcecGayv27,false)
10:31:25,446 DEBUG [org.teiid.TXN_LOG] (Worker0_QueryProcessorQueue31) after cancelTransactions : null
10:31:25,448 DEBUG [org.teiid.PROCESSOR] (Worker1_QueryProcessorQueue33) Request Thread
> org.teiid.net.socket.SingleInstanceCommunicationException
> ---------------------------------------------------------
>
> Key: TEIID-2502
> URL: https://issues.jboss.org/browse/TEIID-2502
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Environment: centos 6.3
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Priority: Critical
>
> I'm issuing a query (a simple select * from table) on a VDB's table that contains a geometric column from oracle spatial.
> I'm getting the following error in SquirrelSQL
> Error: org.teiid.net.socket.SingleInstanceCommunicationException
> SQLState: 08S01
> ErrorCode: 0
> Afterwards the connection is broken and I cannot access any other table and have to reconnect since I get:
> Error: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Socket closed
> SQLState: TEIID20013
> ErrorCode: 0
> I'm trying to access a SDO table and a geometry type column, but hoped that TEIID could read it as a BLOB without caring about the real type.
> Probably it doesn't like it too much.
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2503) XML Recursive and Nested Doc queries are producing "TEIID30328 Unable to evaluate "INPUT".nextKey: No value was available error"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2503?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2503:
----------------------------------
Attachment: QT_PostgreSQL91_Push.vdb
> XML Recursive and Nested Doc queries are producing "TEIID30328 Unable to evaluate "INPUT".nextKey: No value was available error"
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2503
> URL: https://issues.jboss.org/browse/TEIID-2503
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Environment: EAP6.1Alpha and Teiid8.4Alpha
> Reporter: Warren Gibson
> Assignee: Steven Hawkins
> Priority: Minor
> Attachments: QT_PostgreSQL91_Push.vdb, SERVER.log
>
>
> The following queries are producing TEIID30328 Unable to evaluate "INPUT".nextKey: No value was available error.
> The queries were returning expected query results in SOA-P5.3.1 release. However, when testing them with EAP 6.1Alpha and
> Teiid 8.4Alpha they are returning the "Unable to evaluate "INPUT".nextKey" message. This is occuring on Postgres91, Oracle10,11,11RAC, Mysql55, Teradata, and Greenplum data sources.
> I isolated "SELECT * FROM XQTNestedDoc.testSimpleNested ORDER BY recursiveroot.key" and ran a test to produce a log entry which
> is attached. If you need other testing artifacts such as VDB please let me know.
> SELECT * FROM XQTNestedDoc.testBoundTempTable
> SELECT * FROM XQTNestedDoc.testExcludeFromDoc ORDER BY recursiveroot.key
> SELECT * FROM XQTNestedDoc.testOptimizableTempTable ORDER BY recursiveroot.key
> SELECT * FROM XQTNestedDoc.testRootTempTable ORDER BY recursiveroot.key
> SELECT * FROM XQTNestedDoc.testSimpleNested ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testNested2Document ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testNestedDocument ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testSimpleDocument ORDER BY recursiveroot.key
> SELECT * FROM XQTRecursiveDoc.testSimpleTempTable ORDER BY recursiveroot.key
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2504) Improve socket results processing
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2504?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2504.
-----------------------------------
Resolution: Done
Most of the apparent performance gains stems from the prefetch, which needed changes to the way results are written/read - so that full result deserialization can be performed after the prefetch result is sent (a more simplistic approach, such was employed with MMX still would still largely put the deserialization cost in the request/response critical path).
The changes also allow for a limited multi-batch fetch. Due to the abstractions surround our socket usage it is not easy to have the server reserve/unreserve memory with the asynch nature of the server to client writes. So a compromise is to allow approximately 3 (more if the actual memory footprint of the batches is smaller than the estimate) batches to be fetched together. This memory usage is essentially unaccounted for, so extreme amounts of concurrent response processing may require rethinking this approach - the most simplistic being to change the notion of the default fetch size, which is currently still 2048.
> Improve socket results processing
> ---------------------------------
>
> Key: TEIID-2504
> URL: https://issues.jboss.org/browse/TEIID-2504
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Driver, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> To increase large result transfer performance we can:
> 1. use a prefetch (which ideally will be performed before full deserialization)
> 2. allow for the client to fetch multiple server batches (although this has quite a few implementation considerations
--
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
12 years, 10 months
[JBoss JIRA] (TEIID-2505) MultiArrayOutputStream computes count incorrectly
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2505?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2505.
-----------------------------------
Resolution: Done
Corrected the count computation and added widen error logging from uncaught server side socket exceptions to be include all non-socket ioexceptions.
> MultiArrayOutputStream computes count incorrectly
> -------------------------------------------------
>
> Key: TEIID-2505
> URL: https://issues.jboss.org/browse/TEIID-2505
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Driver
> Affects Versions: 8.3
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 8.4
>
>
> The count computed may not be correct when the bytes written exceeds the primary array size. This impacts teiid in client to server messaging when the client message exceeds 1 < 15 bytes - which is uncommon, but can happen with extremely large sql, large directly bound (not stream) values, etc.
> The exception produced will be shown as "Connection reset". The server will log the exception as an EOFException - but at a detail level since we assume that IOExceptions can be logged at a lower level.
--
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
12 years, 10 months