[JBoss JIRA] (TEIID-3612) NPE in connectorworkitem after close
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3612?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3612.
---------------------------------
> NPE in connectorworkitem after close
> ------------------------------------
>
> Key: TEIID-3612
> URL: https://issues.jboss.org/browse/TEIID-3612
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> An NPE can occur if the connectorworkitem has pending asynch more work that is cancelled, but still runs. Then the logic to call close (which is added as a completion listener and effectively executed immediately as the work will report isDone=true) can occur before the pending call to next.
> We should have an explicit check in more to prevent seeing the exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3533) Infinispan-dsl-cache translator: can't insert value into BYTE and BIGINTEGER columns
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3533?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3533.
---------------------------------
> Infinispan-dsl-cache translator: can't insert value into BYTE and BIGINTEGER columns
> ------------------------------------------------------------------------------------
>
> Key: TEIID-3533
> URL: https://issues.jboss.org/browse/TEIID-3533
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Filip Elias
> Assignee: Van Halbert
> Fix For: 8.7.1.6_2, 8.12
>
> Attachments: server.log, testVDB.vdb
>
>
> Sample query:
> {code}
> insert into smalla(intKey, byteNum) values(100,100);
> insert into smalla(intKey, BIGINTEGERVALUE) values(100,100);
> {code}
> Exception:
> {code}
> [org.teiid.CONNECTOR] (Worker9_QueryProcessorQueue59) Connector worker process failed for atomic-request=NuZ8Nt3h1bKx.20.0.13: java.lang.IllegalArgumentException: Conversion from String to java.math.BigDecimal is not supported
> at org.teiid.core.util.StringUtil.valueOf(StringUtil.java:797) [teiid-common-core-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> at org.teiid.core.util.PropertiesUtils.setProperty(PropertiesUtils.java:792) [teiid-common-core-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> at org.teiid.core.util.PropertiesUtils.setBeanProperty(PropertiesUtils.java:782) [teiid-common-core-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> at org.teiid.translator.infinispan.dsl.InfinispanUpdateExecution.handleInsert(InfinispanUpdateExecution.java:204)
> {code}
> The VDB and the server log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3557) Can't reload VDB in domain mode
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3557?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3557.
---------------------------------
> Can't reload VDB in domain mode
> -------------------------------
>
> Key: TEIID-3557
> URL: https://issues.jboss.org/browse/TEIID-3557
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Priority: Critical
> Fix For: 8.7.1.6_2, 8.12, 8.11.1
>
>
> Can't reload VDB in domain mode, get the following error:
> Server throws the following exception:
> [Server:server-one] 12:26:45,678 ERROR [org.teiid.RUNTIME] (teiid-async-threads - 1) TEIID40088 Could not replicate object org.teiid.query.tempdata.GlobalTableStoreImpl@4e6c9a30: java.lang.IllegalStateException: cluster 'ModeShape.1' is already connected to singleton transport: [dummy-1435055090515, loopback.1, ModeShape.1, loopback-dynamic.1, $TEIID_BM$, dummy-1435055090188, dummy-1435055205654, $TEIID_ED$, teiid-cache, ddl2-vdb.1]
> [Server:server-one] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:919) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.startStack(JChannel.java:827) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel._preConnect(JChannel.java:525) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.jgroups.JChannel.connect(JChannel.java:268) [jgroups-3.2.13.Final-redhat-1.jar:3.2.13.Final-redhat-1]
> [Server:server-one] at org.teiid.replication.jgroups.JGroupsObjectReplicator.replicate(JGroupsObjectReplicator.java:563) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.CompositeGlobalTableStore.createInstance(CompositeGlobalTableStore.java:57) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$1.finishedDeployment(VDBService.java:156) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.notifyFinished(VDBRepository.java:352) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.deployers.VDBRepository.finishDeployment(VDBRepository.java:308) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.runtime.AbstractVDBDeployer.metadataLoaded(AbstractVDBDeployer.java:202) [teiid-runtime-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService.access$1100(VDBService.java:85) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$6.run(VDBService.java:411) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-2.jar:8.7.1.6_2-redhat-2]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:server-one] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> VDB reload works fine in standalone mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3525) dependent join handling of multi-way joins
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3525?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3525.
---------------------------------
> dependent join handling of multi-way joins
> ------------------------------------------
>
> Key: TEIID-3525
> URL: https://issues.jboss.org/browse/TEIID-3525
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> In scenarios where the same column is used multiple times in a multi-way dependent join, it's affect may be duplicated in source predicates.
> For example:
> select pm1.g1.e1, pm1.g1.e2, pm2.g1.e2 FROM pm1.g2, pm1.g1, /*+ makedep */ pm2.g1 where pm1.g1.e1 = pm2.g1.e1 and pm1.g2.e1 = pm2.g1.e1
> Should have a source query of the form:
> SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm2.g1 AS g_0 WHERE g_0.e1 IN (<dependent values>) ORDER BY c_0
> Rather than having multiple dependent values predicates.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months
[JBoss JIRA] (TEIID-3492) Provide a mechanism for users to modify the salesforce api version
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3492?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3492.
---------------------------------
> Provide a mechanism for users to modify the salesforce api version
> ------------------------------------------------------------------
>
> Key: TEIID-3492
> URL: https://issues.jboss.org/browse/TEIID-3492
> Project: Teiid
> Issue Type: Feature Request
> Components: Salesforce Connector
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Fix For: 8.12
>
>
> We should provide a mechanism to easily target a different salesforce api version. We are currently defaulting to v22, which is quite old. The version change must be controlled as the metadata and the sf jars can be incompatible - if you for example build a model from v22, then you must stay on v22, and then recreate the model once you want to move to a later version.
> Currently the update procedure would be to copy/modify the salesforce translator module and have it point to newer wsc and partner api jars (which are java api compatible from what I have seen) and then change the any salesforce resource adapters to use the new api url.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 6 months