[JBoss JIRA] Created: (TEIID-867) Possibly Teiid embedded clients (Designer) not pinging query engine, causing session timeouts
by Paul Nittel (JIRA)
Possibly Teiid embedded clients (Designer) not pinging query engine, causing session timeouts
---------------------------------------------------------------------------------------------
Key: TEIID-867
URL: https://jira.jboss.org/jira/browse/TEIID-867
Project: Teiid
Issue Type: Bug
Environment: fedora 10, Teiid Designer 6.2
Reporter: Paul Nittel
Assignee: Steven Hawkins
I started the Teiid 6.2 Designer, executed a VDB and ran a simple query. Then I waited about 35 minutes and finally clicked the Running Dude(tm) button. Instead of nicely arranged rows of data, I got:
Error 2009-09-30 14:41:48.107 Error processing query
com.metamatrix.jdbc.MMSQLException: Error trying to execute a statement select IntKey, StringKey, IntNum, StringNum, FloatNum, LongNum, DoubleNum, ByteNum, DateValue, TimeValue, TimestampValue, BooleanValue, CharValue, ShortValue, BigIntegerValue, BigDecimalValue, ObjectValue from "SP"."BQT2.SmallA"
.
at com.metamatrix.jdbc.MMSQLException.create(MMSQLException.java:116)
at com.metamatrix.jdbc.MMStatement.executeSql(MMStatement.java:414)
at com.metamatrix.jdbc.MMStatement.execute(MMStatement.java:318)
at net.sourceforge.sqlexplorer.sqlpanel.SqlExecProgress.processQuery(SqlExecProgress.java:192)
at net.sourceforge.sqlexplorer.sqlpanel.SqlExecProgress.run(SqlExecProgress.java:121)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: com.metamatrix.jdbc.MMSQLException: The specified session ID "2" is invalid. It cannot be found in the userbase.
at com.metamatrix.jdbc.MMSQLException.create(MMSQLException.java:123)
at com.metamatrix.jdbc.MMSQLException.create(MMSQLException.java:71)
at com.metamatrix.jdbc.MMStatement.sendRequestMessageAndWait(MMStatement.java:855)
at com.metamatrix.jdbc.MMStatement.executeSql(MMStatement.java:410)
... 4 more
Caused by: [MetaMatrixComponentException]The specified session ID "2" is invalid. It cannot be found in the userbase.
1 [InvalidSessionException]The specified session ID "2" is invalid. It cannot be found in the userbase.
at com.metamatrix.client.ExceptionUtil.convertException(ExceptionUtil.java:59)
at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:119)
at $Proxy24.executeRequest(Unknown Source)
at com.metamatrix.jdbc.MMStatement.sendRequestMessageAndWait(MMStatement.java:853)
... 5 more
Caused by: [InvalidSessionException]The specified session ID "2" is invalid. It cannot be found in the userbase.
at com.metamatrix.platform.security.session.service.SessionServiceImpl.getSessionInfo(SessionServiceImpl.java:295)
at com.metamatrix.platform.security.session.service.SessionServiceImpl.validateSession(SessionServiceImpl.java:287)
at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:109)
... 7 more
The session timeout property is commented out in the workspace.properties file.
Steve Hawkins opined the embedded clients ae not pinging the server.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (TEIID-913) Refine buffer management
by Steven Hawkins (JIRA)
Refine buffer management
------------------------
Key: TEIID-913
URL: https://jira.jboss.org/jira/browse/TEIID-913
Project: Teiid
Issue Type: Task
Components: Query Engine
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 7.0
The current buffermanagement scheme has several limitations that should be resolved:
1. We over use the buffermanager to create temporary results for sub-plans and sort operations where batch streaming would suffice.
2. The blockedonmemory exception is inefficient for resolving resource conflicts.
3. Most of the buffers in the plan (batches stored on nodes and intermeiated node results) are not accounted for in the active batches.
4. Outside of the initial sort phase of the multi-pass sort batch access is highly ephemeral and is inherently limited by the number of process worker threads.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (TEIID-911) Prepared Batch Update against a view table fails with "Unable to evaluate $param/pos0: No value was available"
by Larry O'Leary (JIRA)
Prepared Batch Update against a view table fails with "Unable to evaluate $param/pos0: No value was available"
--------------------------------------------------------------------------------------------------------------
Key: TEIID-911
URL: https://jira.jboss.org/jira/browse/TEIID-911
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.0
Environment: teiid-engine revision 1662
Reporter: Larry O'Leary
Assignee: Steven Hawkins
Attachments: JBEDSP-1133_Teiid-Rev-1662_UnitTests_200912211050.patch
Attempting to execute a prepared batch update against a view table results in the following stack trace:
[MetaMatrixComponentException] ERR.015.006.0033: Error Code:ERR.015.006.0033 Message:Unable to evaluate $param/pos0: No value was available
at com.metamatrix.query.sql.util.VariableContext.getGlobalValue(VariableContext.java:68)
at com.metamatrix.query.sql.util.VariableContext.getGlobalValue(VariableContext.java:64)
at com.metamatrix.query.eval.Evaluator.internalEvaluate(Evaluator.java:562)
at com.metamatrix.query.eval.Evaluator.evaluate(Evaluator.java:524)
at com.metamatrix.query.processor.proc.ProcedurePlan.evaluateExpression(ProcedurePlan.java:648)
at com.metamatrix.query.processor.proc.ProcedurePlan.open(ProcedurePlan.java:187)
at com.metamatrix.query.processor.relational.PlanExecutionNode.open(PlanExecutionNode.java:74)
at com.metamatrix.query.processor.relational.RelationalNode.open(RelationalNode.java:236)
at com.metamatrix.query.processor.relational.RelationalPlan.open(RelationalPlan.java:101)
at com.metamatrix.query.processor.batch.BatchedUpdatePlan.open(BatchedUpdatePlan.java:114)
at com.metamatrix.query.processor.QueryProcessor.initialize(QueryProcessor.java:112)
at com.metamatrix.query.processor.QueryProcessor.process(QueryProcessor.java:152)
at com.metamatrix.query.processor.QueryProcessor.process(QueryProcessor.java:127)
at com.metamatrix.query.processor.TestProcessor.doProcess(TestProcessor.java:234)
at org.teiid.dqp.internal.process.TestPreparedStatement.helpTestProcessing(TestPreparedStatement.java:121)
at org.teiid.dqp.internal.process.TestPreparedStatementBatchedUpdate.testUpdateSameNumCmds_Virtual(TestPreparedStatementBatchedUpdate.java:246)
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.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
This was produced using a UnitTest that simply creates a prepared statement similar to:
preparedSql = "UPDATE vm1.g1 SET vm1.g1.e2=? WHERE vm1.g1.e1=?"
values.add(new ArrayList<Object>(Arrays.asList(new Object[] { new Integer(0), "a" })));
values.add(new ArrayList<Object>(Arrays.asList(new Object[] { new Integer(1), "b" })));
Then execute the prepared statement.
Attached unit test patch includes the failing unit tests against a virtual and some refactoring of the existing unit test methods to handle some unit test framework changes from R050503.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (TEIID-902) Restructure planning
by Steven Hawkins (JIRA)
Restructure planning
--------------------
Key: TEIID-902
URL: https://jira.jboss.org/jira/browse/TEIID-902
Project: Teiid
Issue Type: Task
Components: Query Engine
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 7.0
All transformation queries should be cached - not just views.
All cached queries should already be validated - and not revalidated with every request.
Cached queries should be stored individually - not as full and separate trees as they are now, where the same view command exists can exist multiple times in cache.
The choice about whether to use a materialized view or not should also be moved to planning time - not a resolver activity.
We should remove the concept of non-embedded command from everything except planning logic. It's error-prone and confusing in a resolving/rewrite context.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years