[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
>My reading of the issue is that VDBs possible down to a user level need to choose the authentication scheme, rather than only have it configured at the transport level. So yes the deployer needs to know the authentication scheme, but to have VDB encapsulation I think that is somewhat required.
agree that the security-domain enforcement is at transport and VDB. But what I am saying is choice of user is not there, and choice of configuring both at same time is not there. Then user is forced to login to domain that is configured.
>Yes if we want special handling there, then we can add it. However I was unsure if we want to have a JAAS name mean that GSS will be used. For example will that property ever be used for other authentication types beyond GSS?
No, JAAS name is only used in GSS. This defines the JAAS domain name space in the GSS property file.
>Do you have any thoughts on the security domain handling in the JBossSessionService? Do we need to revert back to using a list on the transport, or do we need to be more flexible with how we look them up?
ah, I think this is where we not communicating correctly as to how the SPENGO security domain works. It has delegation model. Where you can define "GSS" and "PASSWORD" based domains on it, and based on how you invoke it it chooses the right one. Thus we do not need multiple of domains.
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Attachments: auth.patch
>
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Patrick Deenen edited comment on TEIID-2892 at 3/11/14 10:57 AM:
-----------------------------------------------------------------
No, I just use a simple HTTP connection with java.net.HttpURLConnection to execute the URL mentioned in the text above. Affter that I download the results from the first HTTP response, that's it.
was (Author: pdeenen):
No, I just use a simple HTTP connection with java.net.HttpURLConnection to execute the URL mentioned in the text above.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Patrick Deenen edited comment on TEIID-2892 at 3/11/14 10:57 AM:
-----------------------------------------------------------------
No, I just use a simple HTTP connection with java.net.HttpURLConnection to execute the URL mentioned in the text above. After that I download the results from the first HTTP response, that's it.
was (Author: pdeenen):
No, I just use a simple HTTP connection with java.net.HttpURLConnection to execute the URL mentioned in the text above. Affter that I download the results from the first HTTP response, that's it.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Patrick Deenen commented on TEIID-2892:
---------------------------------------
No, I just use a simple HTTP connection with java.net.HttpURLConnection to execute the URL mentioned in the text above.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2892:
---------------------------------------
Patrick are you requesting the row count?
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2863:
---------------------------------------
> I thought that was the intent of this issue.
My reading of the issue is that VDBs possible down to a user level need to choose the authentication scheme, rather than only have it configured at the transport level. So yes the deployer needs to know the authentication scheme, but to have VDB encapsulation I think that is somewhat required.
> "authType", negotiation with JDBC is good, but IMO that path is 100% guaranteed to end up with failure as no "jassName", so we might as fail to begin with.
Yes if we want special handling there, then we can add it. However I was unsure if we want to have a JAAS name mean that GSS will be used. For example will that property ever be used for other authentication types beyond GSS?
Do you have any thoughts on the security domain handling in the JBossSessionService? Do we need to revert back to using a list on the transport, or do we need to be more flexible with how we look them up?
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Attachments: auth.patch
>
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2892:
-------------------------------------
In OData protocol, you can request with offset in both directions, so I believe to support that Teiid used TYPE_SCROLL_INSENSITIVE cursor, so this will be keeping results in cache. Yes, as side effect it can also report correct row counts. However, I am not sure why it would not return first batch until all rows are read.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
* Instead of fixed patterns like "GSS", I see that you delegated them back to session service and user, which is fine.
* I see that user has to decide now during the deploy time what authentication they support. USERPASSWORD or GSS, my previous code was trying accommodate both at same time during connection. User has choice of logging into one or other. I thought that was the intent of this issue. With jdbc that still seems to be the case based on configured properties on client side, not with ODBC.
* "authType", negotiation with JDBC is good, but IMO that path is 100% guaranteed to end up with failure as no "jassName", so we might as fail to begin with.
Possible that I may be reading something wrong from what u intended.
> Allow both gssapi and username/password authentication on the same transport
> ----------------------------------------------------------------------------
>
> Key: TEIID-2863
> URL: https://issues.jboss.org/browse/TEIID-2863
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Attachments: auth.patch
>
>
> With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2892:
---------------------------------------
I think it has to do this for the caching related to paging and to determine the row count. Ramesh is that correct?
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
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
10 years, 3 months
[JBoss JIRA] (TEIID-2890) IndexOutOfBoundsException when using GROUP BY
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2890?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2890.
-----------------------------------
Resolution: Done
changed the logic to use the grouping expression position rather than just assume they are unique.
> IndexOutOfBoundsException when using GROUP BY
> ---------------------------------------------
>
> Key: TEIID-2890
> URL: https://issues.jboss.org/browse/TEIID-2890
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Tom Arnold
> Assignee: Steven Hawkins
> Labels: 8.7, grouping, translator
> Fix For: 8.7
>
>
> I have a translator that does not support aggregates or grouping. I am using a view to try to normalize data from several sources. I am duplicating some of the fields as an approximation. I have existing software that is querying with GROUP BY, and sometimes this happens.
> This query works fine in 8.6:
> {code:sql}
> select identifier
> from foo.items
> group by identifier, identifier;
> {code}
> In 8.7 this happens:
> {code}
> 10:15:24,280 ERROR [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue39) njknuxobPkVY TEIID30019 Unexpected exception for request njknuxobPkVY.3: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:604) [rt.jar:1.7.0_02]
> at java.util.ArrayList.get(ArrayList.java:382) [rt.jar:1.7.0_02]
> at org.teiid.query.processor.relational.MergeJoinStrategy.compareTuples(MergeJoinStrategy.java:313) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.GroupingNode.sameGroup(GroupingNode.java:488) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.GroupingNode.groupPhase(GroupingNode.java:414) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:336) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:146) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:159) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:141) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:273) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.7.0.Beta2-SNAPSHOT.jar:8.7.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_02]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_02]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_02]
> {code}
--
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
10 years, 3 months