[JBoss JIRA] (TEIID-4097) No active transaction found while executing long running update statement
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4097?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4097.
-----------------------------------
Resolution: Won't Fix
Marking as resolved for now.
> No active transaction found while executing long running update statement
> -------------------------------------------------------------------------
>
> Key: TEIID-4097
> URL: https://issues.jboss.org/browse/TEIID-4097
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.11.3
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
>
> When executing the following statement an exception "java.sql.SQLException: javax.resource.ResourceException: IJ000460: Error checking for a transaction" occurs
> update MVGobs set SequenceName = (select Naam from #seqUniek where ordernumber = MVGobs.OrderNumber and patientID = MVGobs.patientid) where patientid <= 60222
> The MVGObs table is a foreign temporary table on a MySQL 5.6 server. It has almost 1 million rows.
> #seqUniek is an in memory temporary table. It has a primary key defined on the combination of ordernumber and patientid. It has almost 12000 rows.
> This is the complete stack trace:
> 10:44:12,929 WARN [org.teiid.CONNECTOR] (Worker36735_QueryProcessorQueue1249945) E6abWUweBXyr Connector worker process failed for atomic-request=E6abWUweBXyr.41.2.311518: org.teiid.translator.TranslatorException: TEIID11009 java.sql.SQLException: javax.resource.ResourceException: IJ000460: Error checking for a transaction
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getConnection(JDBCExecutionFactory.java:270) [translator-jdbc-8.11.3.jar:8.11.3]
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getConnection(JDBCExecutionFactory.java:68) [translator-jdbc-8.11.3.jar:8.11.3]
> at org.teiid.translator.ExecutionFactory.getConnection(ExecutionFactory.java:194) [teiid-api-8.11.3.jar:8.11.3]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:305)
> at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source) [:1.8.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy47.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:298)
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:135)
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:369)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:69)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:70)
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:84)
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:92)
> at org.teiid.query.processor.proc.ProcedurePlan.executePlan(ProcedurePlan.java:603)
> at org.teiid.query.processor.proc.CreateCursorResultSetInstruction.process(CreateCursorResultSetInstruction.java:69)
> at org.teiid.query.processor.proc.ProcedurePlan.processProcedure(ProcedurePlan.java:384)
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatchDirect(ProcedurePlan.java:293)
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatch(ProcedurePlan.java:267)
> at org.teiid.query.processor.relational.PlanExecutionNode.nextBatchDirect(PlanExecutionNode.java:118)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000460: Error checking for a transaction
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getConnection(JDBCExecutionFactory.java:266) [translator-jdbc-8.11.3.jar:8.11.3]
> ... 41 more
> Caused by: javax.resource.ResourceException: IJ000460: Error checking for a transaction
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:362)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:510)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:143)
> ... 42 more
> Caused by: javax.resource.ResourceException: IJ000459: Transaction is not active: tx=TransactionImple < ac, BasicAction: 0:ffff7f000101:3ecd82e1:56b9cee9:3599e status: ActionStatus.ABORTED >
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:352)
> ... 44 more
> This is the execution plan:
> PlanExecutionNode
> Relational Node ID=4,
> Output Columns=Count (integer),
> Cost Estimates=Estimated Node Cardinality: -1.0,
> Program
> ASSIGNMENT
> Variable=VARIABLES.ROWS_UPDATED,
> Expression=0,
> LOOP
> Result Set=X,
> ProjectNode
> Relational Node ID=0,
> Output Columns=s_0 (string),s_1 (integer),s_2 (integer),
> Cost Estimates=Estimated Node Cardinality: -1.0,
> Select Columns=(SELECT #seqUniek.Naam FROM #seqUniek WHERE (#seqUniek.Ordernumber = MVGObs.Ordernumber) AND (#seqUniek.Patientid = MVGObs.Patientid) LIMIT 2) AS s_0,MVGObs.Patientid AS s_1,MVGObs.Ordernumber AS s_2,
> AccessNode
> Relational Node ID=1,
> Output Columns=Patientid (integer),Ordernumber (integer),
> Cost Estimates=Estimated Node Cardinality: -1.0,
> Query=SELECT g_0.Patientid, g_0.Ordernumber FROM MVGObs AS g_0 WHERE g_0.Patientid <= 60222,
> Model Name=tmptables,
> LimitNode
> Relational Node ID=0,
> Output Columns=Naam (string),
> Cost Estimates=Estimated Node Cardinality: 1.0,
> Row Offset=null,
> Row Limit=2,
> AccessNode
> Relational Node ID=1,
> Output Columns=Naam (string),
> Cost Estimates=Estimated Node Cardinality: 1.0,
> Query=SELECT #seqUniek.Naam FROM #seqUniek WHERE (#seqUniek.Ordernumber = MVGObs.Ordernumber) AND (#seqUniek.Patientid = MVGObs.Patientid),
> Model Name=__TEMP__,
> Program
> CREATE CURSOR
> AccessNode
> Relational Node ID=2,
> Output Columns=Count (integer),
> Cost Estimates=Estimated Node Cardinality: -1.0,
> Query=UPDATE MVGObs SET SequenceName = X.s_0 WHERE (MVGObs.Patientid = X.s_1) AND (MVGObs.Ordernumber = X.s_2),
> Model Name=tmptables,
> ASSIGNMENT
> Variable=VARIABLES.ROWS_UPDATED,
> Expression=(VARIABLES.ROWS_UPDATED + 1),
> CREATE CURSOR
> ProjectNode
> Relational Node ID=3,
> Output Columns=ROWS_UPDATED (integer),
> Cost Estimates=Estimated Node Cardinality: 1.0,
> Select Columns=VARIABLES.ROWS_UPDATED,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (TEIID-4018) Class loading issue using ProtoSchemaBuilder to register annotated pojo
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4018?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4018.
-----------------------------------
Fix Version/s: 9.0
8.12.5
(was: 9.x)
(was: 8.12.x)
Assignee: Van Halbert (was: Steven Hawkins)
Resolution: Done
Merged the pull request.
> Class loading issue using ProtoSchemaBuilder to register annotated pojo
> -----------------------------------------------------------------------
>
> Key: TEIID-4018
> URL: https://issues.jboss.org/browse/TEIID-4018
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Blocker
> Fix For: 9.0, 8.12.5
>
>
> Logic was changed in the infinispan dsl translator to use the ProtoSchemaBuilder to register the protobuf annotated pojo so that the marshaller(s) and protobuf definition files are not needed. However, there's an infinispan class loading issue that requires the upgrading to the protostream-3.0.5 version.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (TEIID-3480) External Materialization status
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3480?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3480 at 3/24/16 10:28 AM:
--------------------------------------------------------------
What's the difference caused by different position of status table:
* Internal Materialization use system table SYSADMIN.MatViews as system table
* External Materialization use a external table passed via "teiid_rel:MATVIEW_STATUS_TABLE" parameter point to a external data store server
But both CLI/web-console get data via "select * from SYSADMIN.MatViews", so in External the return is raw data(the updated data saved in external server)
Now if close/remove difference, keep Internal and External consistent, there are lots of logic related, the logic related with mat including: MaterializationManager, metadata loading, query logic, so far, I have concern is why we need create a status table in External? this not only increase the complexity, but also caused the inconsistent, if keep external use SYSADMIN.MatViews as status table, it will be easy to solve this issue, any ideas for this?
was (Author: kylin):
What's the difference caused by different status table:
* Internal Materialization use system table SYSADMIN.MatViews as system table
* External Materialization use a external table passed via "teiid_rel:MATVIEW_STATUS_TABLE" parameter point to a external data store server
But both CLI/web-console get data via "select * from SYSADMIN.MatViews", so in External the return is raw data(the updated data saved in external server)
Now if close/remove difference, keep Internal and External consistent, there are lots of logic related, the logic related with mat including: MaterializationManager, metadata loading, query logic, so far, I have concern is why we need create a status table in External? this not only increase the complexity, but also caused the inconsistent, if keep external use SYSADMIN.MatViews as status table, it will be easy to solve this issue, any ideas for this?
> External Materialization status
> -------------------------------
>
> Key: TEIID-3480
> URL: https://issues.jboss.org/browse/TEIID-3480
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> When external materialization is configured with "STATUS" table, then Teiid should expose those stats over CLI and in the web-console. Currently the internal materialization does show status, need to expand to the external matviews.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (TEIID-3480) External Materialization status
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3480?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3480 at 3/24/16 10:28 AM:
--------------------------------------------------------------
What's the difference caused by different position of status table:
* Internal Materialization use system table SYSADMIN.MatViews as system table
* External Materialization use a external table passed via "teiid_rel:MATVIEW_STATUS_TABLE" parameter point to a external data store server
But both CLI/web-console get data via "select * from SYSADMIN.MatViews", so in External the return is raw data(the updated data saved in external server)
Now if close/remove difference, keep Internal and External consistent, there are lots of logic related, the logic related with mat including: MaterializationManager, metadata loading, query logic, so far, I have concern is why we need create a status table in External? this not only increase the complexity, but also caused the inconsistent, if keep external use SYSADMIN.MatViews as status table, it will be easy to solve this issue, any ideas for this?
was (Author: kylin):
What's the difference caused by different position of status table:
* Internal Materialization use system table SYSADMIN.MatViews as system table
* External Materialization use a external table passed via "teiid_rel:MATVIEW_STATUS_TABLE" parameter point to a external data store server
But both CLI/web-console get data via "select * from SYSADMIN.MatViews", so in External the return is raw data(the updated data saved in external server)
Now if close/remove difference, keep Internal and External consistent, there are lots of logic related, the logic related with mat including: MaterializationManager, metadata loading, query logic, so far, I have concern is why we need create a status table in External? this not only increase the complexity, but also caused the inconsistent, if keep external use SYSADMIN.MatViews as status table, it will be easy to solve this issue, any ideas for this?
> External Materialization status
> -------------------------------
>
> Key: TEIID-3480
> URL: https://issues.jboss.org/browse/TEIID-3480
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> When external materialization is configured with "STATUS" table, then Teiid should expose those stats over CLI and in the web-console. Currently the internal materialization does show status, need to expand to the external matviews.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (TEIID-3480) External Materialization status
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3480?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3480:
------------------------------------
What's the difference caused by different status table:
* Internal Materialization use system table SYSADMIN.MatViews as system table
* External Materialization use a external table passed via "teiid_rel:MATVIEW_STATUS_TABLE" parameter point to a external data store server
But both CLI/web-console get data via "select * from SYSADMIN.MatViews", so in External the return is raw data(the updated data saved in external server)
Now if close/remove difference, keep Internal and External consistent, there are lots of logic related, the logic related with mat including: MaterializationManager, metadata loading, query logic, so far, I have concern is why we need create a status table in External? this not only increase the complexity, but also caused the inconsistent, if keep external use SYSADMIN.MatViews as status table, it will be easy to solve this issue, any ideas for this?
> External Materialization status
> -------------------------------
>
> Key: TEIID-3480
> URL: https://issues.jboss.org/browse/TEIID-3480
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 8.4
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.0
>
>
> When external materialization is configured with "STATUS" table, then Teiid should expose those stats over CLI and in the web-console. Currently the internal materialization does show status, need to expand to the external matviews.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (TEIID-4102) Infinispan 6 resource-adapter has not valid module.xml
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4102?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4102.
-----------------------------------
Fix Version/s: 8.12.5
Resolution: Done
Merged the pull request
> Infinispan 6 resource-adapter has not valid module.xml
> ------------------------------------------------------
>
> Key: TEIID-4102
> URL: https://issues.jboss.org/browse/TEIID-4102
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x
> Reporter: Jan Stastny
> Assignee: Van Halbert
> Fix For: 8.12.5
>
>
> There is problem with invalid module.xml file in infinispan 6 resource-adapter.
> In its dependencies there is:
> {code:xml}
> <module name="org.jboss.teiid.translator.infinispan.cache" export=true/>
> {code}
> There should be
> {code:xml}
> <module name="org.jboss.teiid.translator.infinispan.cache" export="true"/>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months