[JBoss JIRA] (TEIID-2362) Add UDF support for procedure in view model with function=true
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2362?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2362.
---------------------------------
> Add UDF support for procedure in view model with function=true
> --------------------------------------------------------------
>
> Key: TEIID-2362
> URL: https://issues.jboss.org/browse/TEIID-2362
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Fix For: 8.3
>
>
> Request adding udf support for procedures in view models since Function Models will be deprecated. Per TEIIDDES-1556 discussion from 11 Jan, we will make the following changes in designer:
> For procedure in a ViewModel with FUNCTION=TRUE
> - relax validation so a transformation is not required
> - perform same parameter validation checks currently done with ScalarFunctions
> - add Java Class("java-class") and Java Method("java-method") extension properties same as ScalarFunction is handled currently
--
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-2459) WITH statement translated wrongly for Oracle 10
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2459?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2459.
---------------------------------
> WITH statement translated wrongly for Oracle 10
> ------------------------------------------------
>
> Key: TEIID-2459
> URL: https://issues.jboss.org/browse/TEIID-2459
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> I am using Oracle 10g [1] and I have set the Oracle version to 9.2 in a dynamic VDB [2].
> I am running simple WITH statement against Oracle: WITH x AS (select DATEVALUE from SMALLA) select DATEVALUE from x. Which throws [3]. Probably because Oracle 10 doesn't support column aliasing "WITH x (DATEVALUE)".
> [1] Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
> With the Partitioning, OLAP and Data Mining options
> [2] <property name="DatabaseVersion" value="9.2" />
> [3] Caused by: org.teiid.translator.TranslatorException: Error Code:32033 Message:Remote org.teiid.translator.jdbc.JDBCExecutionException: Error Code:32033 Message:'ORA-32033: unsupported column aliasing
> ' error executing statement(s): [Prepared Values: [] SQL: WITH x (DATEVALUE) AS (SELECT g_0."DATEVALUE" FROM "BQT2_RO"."SMALLA" g_0) SELECT g_0.DATEVALUE FROM x g_0]
--
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-2460) Weird behavior when Max buffer space restriction is hit
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2460:
---------------------------------------
> Did you mean to free up the disk space? Or is this just addressing clearing of the heap?
It allows for the heap to also be cleaned up related to that tuplebuffer. The only way to get the exception that you have attached is if the memory buffer/disk cleanup has happened.
> With current fixes in the backported 7.7.x I do not see such a behavior.
I do not agree, unless there was an issue with the backport. More that likely this is just the difference between 8.3+ behavior in which we create far fewer tuplebuffers for sorting thus cleanup takes effectively longer than just clearing a single tuplebuffer at the disk layer - the owning query must still be resumed and attempt to use the invalid tuplebuffer. You should be able to confirm that the fix works in 7.7 if the disk limit is not exceeded, the exception reporting is not excessive, if the affected queries are aborted, and the disk/memory space after the queries are terminated becomes available for use.
> It is true that the query now fails immediatelly with exception [1], but the disk space is still occupied (thus it is not possible to submit another query that needs buffer space). Is this the intended behavior?
Other space occupied by the owning query will remain occupied until the overall query fails (which for 7.7 may take some time). Also the root cleanup is asynch to begin with (there are three memory regions - heap, memory buffer, and disk - the last two are asynch to the first so any error that is happening at the disk layer is not synchronized to query processing), so it's highly likely likely that when hitting the out of disk condition that other queries will fail soon after under load.
Again, this is not intended to be a graceful handling of the situation, just a mechanism to prevent runaway disk consumption.
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Fix For: 8.4, 7.7.7
>
> Attachments: teiid-jboss-beans.xml
>
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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-2398) Web console in domain mode loose active servers and shows just inactive ones
by luca gioppo (JIRA)
[ https://issues.jboss.org/browse/TEIID-2398?page=com.atlassian.jira.plugin... ]
luca gioppo commented on TEIID-2398:
------------------------------------
It seems to work.
Tried with EAP 6.1 final and TEIID 8.4cr2.
> Web console in domain mode loose active servers and shows just inactive ones
> ----------------------------------------------------------------------------
>
> Key: TEIID-2398
> URL: https://issues.jboss.org/browse/TEIID-2398
> Project: Teiid
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 8.2
> Environment: Centos 6.3, JBoss 7.1.1 TEIID 8.2, Java 1.6
> Reporter: luca gioppo
> Assignee: Ramesh Reddy
> Labels: console, domain, web
> Fix For: 8.4
>
> Attachments: teiid-console-dist-1.1.0-SNAPSHOT-jboss-as7.zip, teiid.png, teiid2.png, teiid3.png, teiid4.png, teiid5.png
>
>
> I have a domain environment (for now just one host with both the domain controllere and tow servers instances) with two server groups and one servre in each group; it will be configured to be in HA.
> I added the web console to the installation (copyed the stuff in the folder and hope this was the correct way of doing)
> When I go to the runtime only the stopped server are present and canno select the running one.
> This makes the console un-usable since not choosing the server stop all other activity with errors.
--
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-2460) Weird behavior when Max buffer space restriction is hit
by Filip Nguyen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Filip Nguyen reopened TEIID-2460:
---------------------------------
see the last comment
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Fix For: 8.4, 7.7.7
>
> Attachments: teiid-jboss-beans.xml
>
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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-2460) Weird behavior when Max buffer space restriction is hit
by Filip Nguyen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2460?page=com.atlassian.jira.plugin... ]
Filip Nguyen commented on TEIID-2460:
-------------------------------------
What is meant by:
#2) added a callback into the buffer manager to clear out all memory related to the failing tuple batch and ensured if additional batches are added that the process will fail (not just if a batch is retrieved).
Did you mean to free up the disk space? Or is this just addressing clearing of the heap? With current fixes in the backported 7.7.x I do not see such a behavior. It is true that the query now fails immediatelly with exception [1], but the disk space is still occupied (thus it is not possible to submit another query that needs buffer space). Is this the intended behavior?
[1]
{code}
org.teiid.jdbc.TeiidSQLException: Cannot add batch to invalidated cache group "{1}". Check prior logs to see if there was an error persisting a batch.
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:113)
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:70)
at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:643)
at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:62)
at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:547)
at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:130)
at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:37)
at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:75)
at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:222)
at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:101)
at com.sun.proxy.$Proxy1.read(Unknown Source)
at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:356)
at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:556)
at org.teiid.jdbc.StatementImpl.executeQuery(StatementImpl.java:334)
at JDBCClient.execute(JDBCClient.java:77)
at JDBCClient.main(JDBCClient.java:45)
Caused by: org.teiid.core.TeiidComponentException: Cannot add batch to invalidated cache group "{1}". Check prior logs to see if there was an error persisting a batch.
at org.teiid.common.buffer.impl.BufferManagerImpl$BatchManagerImpl.createManagedBatch(BufferManagerImpl.java:211)
at org.teiid.common.buffer.TupleBuffer.saveBatch(TupleBuffer.java:254)
at org.teiid.common.buffer.TupleBuffer.addTuple(TupleBuffer.java:191)
at org.teiid.common.buffer.TupleBuffer.addTupleBatch(TupleBuffer.java:204)
at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:73)
at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69)
at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:85)
at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:91)
at org.teiid.query.processor.relational.NestedTableJoinStrategy.process(NestedTableJoinStrategy.java:120)
at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:210)
at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:155)
at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:70)
at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69)
at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:85)
at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48)
at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:248)
at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:185)
at org.teiid.query.processor.relational.SortNode.sortPhase(SortNode.java:99)
at org.teiid.query.processor.relational.SortNode.getFinalBuffer(SortNode.java:180)
at org.teiid.query.processor.relational.RelationalPlan.getFinalBuffer(RelationalPlan.java:280)
at org.teiid.query.processor.QueryProcessor.getFinalBuffer(QueryProcessor.java:239)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:137)
at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:377)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:290)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:218)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:244)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:122)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:292)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
> Weird behavior when Max buffer space restriction is hit
> --------------------------------------------------------
>
> Key: TEIID-2460
> URL: https://issues.jboss.org/browse/TEIID-2460
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.7.6
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
> Fix For: 8.4, 7.7.7
>
> Attachments: teiid-jboss-beans.xml
>
>
> I was trying to restrict the disk space used by buffer manager (see steps to reproduce for my methodology). When the disk limit is hit, it really tries to stop the query, but doesn't succeed immediately.
> There is a big amount of exceptions [1] for relatively long period of time (minutes for big files), until it fails eventually with [2]. The error [2] is also given back to the JDBC client.
> Problem is that after the query fails in this fashion, the whole buffer disk space is still occupied and any new query, that needs even small (acceptable) buffer disk space, fails.
> Only way that I have found to make the buffer space usable again is to restart the server.
> [1] Error transferring block to storage 149742
> java.io.IOException: Max buffer space of 31,457,280 bytes has been exceed. The current operation will be aborted.
> [2] org.teiid.jdbc.TeiidSQLException: Batch not found in storage 50937
--
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