[JBoss JIRA] (TEIID-2349) Cannot execute Two-Phase Commit using Multi-Source Model Dynamic VDB
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-2349?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-2349:
------------------------------------------------
Julian Coleman <jcoleman(a)redhat.com> changed the Status of [bug 895304|https://bugzilla.redhat.com/show_bug.cgi?id=895304] from MODIFIED to ON_QA
> Cannot execute Two-Phase Commit using Multi-Source Model Dynamic VDB
> --------------------------------------------------------------------
>
> Key: TEIID-2349
> URL: https://issues.jboss.org/browse/TEIID-2349
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 8.1, 7.7.4
>
>
> Description of problem:
> 2nd connection to Multi-Source Model Dynamic VDB is not Two-Phase Commit.
> How reproducible:
> Always
> Steps to Reproduce:
> Execute a update query via Multi-Source Model Dynamic VDB.
> ex)
> vdb - maseter-vdb.xml
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="MASTER-VDB" version="1">
> <description>A Dynamic VDB</description>
> <property name="UseConnectorMetadata" value="true" />
> <model visible="true" type="PHYSICAL" name="VDB1">
> <property name="supports-multi-source-bindings" value="true" />
> <source name="db02" translator-name="postgresql" connection-jndi-name="java:/PostgresXADS02" />
> <source name="db01" translator-name="postgresql" connection-jndi-name="java:/PostgresXADS01" />
> </model>
> </vdb>
>
> Additional info:
> Set the multisourceUpdate flag as first query plan creating.
> org.teiid.dqp.internal.process.multisource.MultiSourcePlanToProcessConverter.java
> 90: @Override
> 91: public synchronized RelationalPlan convert(PlanNode planNode)
> 92: throws QueryPlannerException, TeiidComponentException {
> 93: RelationalPlan result = null;
> 94: try {
> 95: result = super.convert(planNode);
> 96: return result;
> 97: } finally {
> 98: if (result != null && update && multiSource) {
> -> 99: result.setMultisourceUpdate(true);
> 100: }
> 101: update = false;
> 102: multiSource = false;
> 103: }
> 104: }
> If multisourceUpdate is true, transactionService is started by teiid engine. But, second connects does not set the multisourceUpdate flag. Therefore, teiid engine does not start transactionService.
> org.teiid.dqp.internal.process.Request.java
> 338: private void createProcessor() throws TeiidComponentException {
> --- snip ---
> 349: if(RequestMessage.TXN_WRAP_ON.equals(requestMsg.getTxnAutoWrapMode())){
> 350: startAutoWrapTxn = true;
> 351: } else if (RequestMessage.TXN_WRAP_DETECT.equals(requestMsg.getTxnAutoWrapMode())){
> 352: boolean transactionalRead = requestMsg.getTransactionIsolation() == Connection.TRANSACTION_REPEATABLE_READ
> 353: || requestMsg.getTransactionIsolation() == Connection.TRANSACTION_SERIALIZABLE;
> -> 354: startAutoWrapTxn = processPlan.requiresTransaction(transactionalRead);
> 355: }
> 356:
> 357: if (startAutoWrapTxn) {
> 358: try {
> -> 359: transactionService.begin(tc);
> 360: } catch (XATransactionException err) {
> 361: throw new TeiidComponentException(err);
> 362: }
> 363: }
> 364: }
> org.teiid.query.processor.relational.RelationalPlan.java
> 254: @Override
> 255: public boolean requiresTransaction(boolean transactionalReads) {
> 256: if (multisourceUpdate) {
> -> 257: return true;
> 258: }
> 259: if (this.with != null) {
> 260: if (transactionalReads) {
> 261: return true;
> 262: }
> 263: for (WithQueryCommand withCommand : this.with) {
> 264: if (withCommand.getCommand().getProcessorPlan().requiresTransaction(transactionalReads)) {
> 265: return true;
> 266: }
> 267: }
> 268: }
> 279: return requiresTransaction(transactionalReads, root);
> 270: }
--
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
11 years, 11 months
[JBoss JIRA] (TEIID-2366) If where clause contains both equal and greater then conditions then query may return no results
by Paul Lysak (JIRA)
Paul Lysak created TEIID-2366:
---------------------------------
Summary: If where clause contains both equal and greater then conditions then query may return no results
Key: TEIID-2366
URL: https://issues.jboss.org/browse/TEIID-2366
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.2
Reporter: Paul Lysak
Assignee: Steven Hawkins
If WHERE clause contains '>' and '=' conditions for the same field then query may produce no result - depending on conditions order.
The problem seems to be in org.teiid.query.rewriter.QueryRewriter class, method rewriteAndConjunct(). Pay attention to following piece of code:
... if (cc1.getOperator() == CompareCriteria.EQ) {
if (!Evaluator.compare(cc1, ((Constant)cc1.getRightExpression()).getValue(), ((Constant)cc.getRightExpression()).getValue())) {
return FALSE_CRITERIA;
}
Note that cc1 (which is guaranteed to have EQ criterion) is passed to Evaluator.compare. Thus right expressions of cc and cc1 are required to be equal. But if we have one contition EQ and another GT then it should instead check if right side of EQ is bigger then right side of GT.
--
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
11 years, 11 months
[JBoss JIRA] (TEIID-2363) proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2363?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2363:
---------------------------------------
I need to refine my earlier comments on this. The situation that should be automatically handled is a non-dependent MERGE JOIN (SORT/SORT) - since both sides will require buffering and may proceed independently. In this case, with the inner side being ALREADY_SORTED - the logic regardless will prefer to stream those values in rather than buffering them (which is the caveat I'm mentioning above). The approach there may be to do proactive fetching/buffering proportional to the amount of times the left side is blocking, but then process the buffer down while performing the join.
> proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
> -----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2363
> URL: https://issues.jboss.org/browse/TEIID-2363
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 7.7.2
> Reporter: Johnathon Lee
> Assignee: Steven Hawkins
>
> The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side
> For inner joins there is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven for non-dependent non-outer joins.
--
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
11 years, 11 months
[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 resolved TEIID-2362.
-----------------------------------
Resolution: Done
Updated the index logic to allow for virtual procedures to also represent functions.
We're expecting the additional relational extension metadata java-class and java-method. The pushdown attribute will be determined automatically - if the function has a java method or is virtual it will be marked as "CAN_PUSHDOWN" else if it is physical and does not have a java method it will be marked as "PUSHDOWN_REQUIRED".
We'll also now allow for physical procedures that represent functions to also specify a java method/class (before we assumed pushdown required).
> 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
11 years, 11 months
[JBoss JIRA] (TEIID-2365) Reduce the usage of output names on the server side
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2365:
-------------------------------------
Summary: Reduce the usage of output names on the server side
Key: TEIID-2365
URL: https://issues.jboss.org/browse/TEIID-2365
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Minor
Parsed objects retain much of the original parse string, which is generally unnecessary on the server side. The use of output names should reduced to unnecessary memory consumption.
--
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
11 years, 11 months
[JBoss JIRA] (TEIID-2364) Binding host interface with 0.0.0.0 fails to start JBOSS AS 7.1.1 successfully with Teiid 8.2 in domain mode
by Jose Chavez (JIRA)
Jose Chavez created TEIID-2364:
----------------------------------
Summary: Binding host interface with 0.0.0.0 fails to start JBOSS AS 7.1.1 successfully with Teiid 8.2 in domain mode
Key: TEIID-2364
URL: https://issues.jboss.org/browse/TEIID-2364
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 8.2
Environment: Ubuntu 10.04 Linux running on a VirtualCenter VM
Reporter: Jose Chavez
Assignee: Steven Hawkins
After installing/extracting JBOSS AS 7.1.1 and overlaying Teiid 8.2 final on top, fix a couple of issues in the JBOSS_HOME/bin/scripts/teiid-domain-mode-install.cli, it looks like Teiid 8.3 Beta 1 has fixed these syntax issues. Anyway, once Teiid is down, start JBOSS AS using domain.sh -b=0.0.0.0 -bmanagement=0.0.0.0, this will start JBOSS like a champ, no problems. Now run the teiid-domain-mode-install.cli file, "./jboss-cli.sh --file=scripts/teiid-domain-mode-install.cli" from the JBOSS_HOME/bin directory, if there are no errors with the cli file you will see all the changes succeed, but if you scroll up you will see stack traces indicating "address already in use". You can stop JBOSS and then restart again binding to 0.0.0.0 to get a better view of all the errors as well. Based on my testing and analysis of ports I think the issue is with:
tcp 0 0 hostname:54200 *:* LISTEN 14115/java
It looks like when JBOSS start successfully by binding to an external address I see these two ports are opened:
tcp 0 0 hostname:54201 *:* LISTEN 14115/java
tcp 0 0 hostname:54202 *:*
but when binding to 0.0.0.0 those do not get opened so my hunch is that the problem lies somewhere in this area. Also JDBC and ODBC teiid ports do not get opened in this case where as they do when binding to an external ip.
--
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
11 years, 11 months
[JBoss JIRA] (TEIID-2363) proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2363?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2363:
----------------------------------
Description:
The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side
For inner joins there is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven for non-dependent non-outer joins.
was:
The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side
There is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven.
> proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
> -----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2363
> URL: https://issues.jboss.org/browse/TEIID-2363
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 7.7.2
> Reporter: Johnathon Lee
> Assignee: Steven Hawkins
>
> The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side
> For inner joins there is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven for non-dependent non-outer joins.
--
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
11 years, 11 months
[JBoss JIRA] (TEIID-2363) proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
by Johnathon Lee (JIRA)
Johnathon Lee created TEIID-2363:
------------------------------------
Summary: proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
Key: TEIID-2363
URL: https://issues.jboss.org/browse/TEIID-2363
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 7.7.2
Reporter: Johnathon Lee
Assignee: Steven Hawkins
The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side
There is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven.
--
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
11 years, 11 months
[JBoss JIRA] (TEIID-2359) BufferManager reserved thread local can keep buffermanager references alive
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2359?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2359.
-----------------------------------
Fix Version/s: 8.3
Resolution: Done
Switched the reserved by thread to a static class to remove the erroneous reference to a buffermanager instance. Also changed the threadlocal pattern for buffer usage to just duplicating at the level of the InodeBlockManager. This will have a higher gc overhead, but it removes the need for using a theadlocal - which would also require a reference queue to actually clean up the references (although I suspect that would still be less overhead as the queue will typically be empty and thus low cost to check).
> BufferManager reserved thread local can keep buffermanager references alive
> ---------------------------------------------------------------------------
>
> Key: TEIID-2359
> URL: https://issues.jboss.org/browse/TEIID-2359
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.3
>
>
> The most common implementation of ThreadLocal holds does not garbarge collect ThreadLocal values when the ThreadLocal goes out of scope - only when the Thread stops. Thus the BufferManager reserved threadlocal being a non-static inner class is inadvertently keeping a reference alive.
> Marked as starting with Teiid 8.0 as selective Teiid restarts (which is how multiple instances are introduced) are not performed in the 7.x series.
--
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
11 years, 11 months