[JBoss JIRA] (TEIID-3535) Infinispan-dsl-cache translator: NPE when inserting data if a table doesn't have primary key defined
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3535?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3535.
---------------------------------
> Infinispan-dsl-cache translator: NPE when inserting data if a table doesn't have primary key defined
> ----------------------------------------------------------------------------------------------------
>
> Key: TEIID-3535
> URL: https://issues.jboss.org/browse/TEIID-3535
> 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
>
>
> Exception:
> {code}
> ERROR [org.teiid.CONNECTOR] (Worker12_QueryProcessorQueue194) Connector worker process failed for atomic-request=ziNYENHc9zCz.0.0.33: java.lang.NullPointerException
> at org.teiid.translator.infinispan.dsl.InfinispanUpdateExecution.handleInsert(InfinispanUpdateExecution.java:149)
> at org.teiid.translator.infinispan.dsl.InfinispanUpdateExecution.execute(InfinispanUpdateExecution.java:107)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem$1.execute(ConnectorWorkItem.java:358) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:325) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:298) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.1.6_2-redhat-1.jar:8.7.1.6_2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3279) SOLR: Error when date, time or timestamp literal is in where clause
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3279?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3279.
---------------------------------
> SOLR: Error when date,time or timestamp literal is in where clause
> ------------------------------------------------------------------
>
> Key: TEIID-3279
> URL: https://issues.jboss.org/browse/TEIID-3279
> Project: Teiid
> Issue Type: Bug
> Components: Connector API
> Affects Versions: 8.7
> Reporter: Filip Elias
> Assignee: Ramesh Reddy
> Fix For: 8.7.1.6_2, 8.11
>
>
> Query fails when time,date or timestamp literal is used in where clause.
> Examples:
> Query:
> {code}select intkey from smalla where timevalue = '11:30:20'{code}
> Error:
> {code}
> '11:30:20'org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'11-30-20'
> at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491)
> {code}
> Query:
> {code}select intkey from smalla where datevalue = '2002-02-02'{code}
> Error:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'11-30-20'
> at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491)
> {code}
> Query:
> {code}select intkey from smalla where timestampvalue = '2000-01-01 00:00:04'{code}
> Error:
> {code} org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'2000-01-01T00-00-04'
> at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491)
> {code}
> SOLR supports only timestamps (YYYY-mm-ddThh:mm:ssZ) so date and time types should be converted into timestamp before a query is send to SOLR.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3748) Impala translator - SELECT and HAVING statements are translating differently for Case statements
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3748?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3748:
---------------------------------------
I am not able to reproduce this on 8.11/12. Would it be possible to provide some of a log that shows the user query and the source query / exception? Generally I don't see why you would have cast(null as string) as there's no need to introduce the string type.
> Impala translator - SELECT and HAVING statements are translating differently for Case statements
> ------------------------------------------------------------------------------------------------
>
> Key: TEIID-3748
> URL: https://issues.jboss.org/browse/TEIID-3748
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.11.4
> Environment: Ubuntu Trusty
> Reporter: Don Krapohl
> Assignee: Steven Hawkins
> Labels: Impala_Translator, Translators
>
> Error from Impala-
> all DISTINCT aggregate functions need to have the same set of parameters as count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE CAST(NULL AS STRING) END))
> deviating function: count(DISTINCT (CASE WHEN (secondcol >= 0) THEN 1 ELSE NULL END))
> Query:
> SELECT user_key, sum(firstcol),count(distinct case when secondcol >= 0 then 1 end)
> FROM sometable
> WHERE customer_key=6
> GROUP BY user_key
> HAVING sum(firstcol)>100
> AND count(distinct case when secondcol >= 0 then 1 end)=0
>
> Query explanation:
> For all users
> Add up values in the firstcol column (integer column)
> count distinct values in secondcol where secondcol value zero or more
> otherwise return null (output is string)
> Translated Teiid query:
> SELECT user_key, SUM(firstcol) as `EXPR_0`, COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE CAST(NULL AS STRING) END)) as `EXPR_1`
> FROM sometable
> WHERE customer_key` = 6
> HAVING (EXPR_0 > 100) AND (COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' ELSE NULL END)) = 0))
> Note the difference between the select and having for EXPR_1:
> Select - THEN '1' ELSE CAST(NULL AS STRING) END
> Having - THEN '1' ELSE NULL END
> Impala doesn't accept that these are the same aggregate function. Aliases aren't accepted in the HAVING.
> One further observation- if we swap the translation and write the statement in the select as
> COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE NULL END*))
> Teiid translates the SELECT to
> COUNT(DISTINCT (CASE WHEN (secondcol >= 0) THEN '1' *ELSE CAST(NULL AS STRING) END*))
> So it always makes these mismatched.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3747) Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3747?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3747:
-------------------------------------
JBoss CLI, or Admin Api does not generally allow you to just override the deployed artifact. You would need to force it, which works as removing and adding the new deployment. And this only applies when the deployment names match. Copying the updated file into "deployments" file is akin to this forced update.
>>The deleting before redeploying doesn't make sense. The deployment model has always been that a new vdb by the same name can be deployed.
If deleting does not make sense, that is one of the reasons, Teiid provides a VDB versioning along with different types of configuration options for "Connection Type" where user can move from one version to another. One could have updated the version, if you do not want to delete the previous one. As per the same named VDB can be re-deployed, see above again the difference between deployment names and VDB names. Both needs to match to "force" the redeployment.
>> This would be no different than a user who deploys using the admin-console.
sure, but there is no remedy for one choosing same VDB name using the two deployment names. This is no different from you deploying two different WAR files with "same" web context name. The context name is result of the deployment, so is the VDB name, which comes from the deployment of the artifact.
>>That wouldn't work, because there would be a gap in between when the VDB is actually accessible (between when its deleted and redeployed).
I sure do hope no enterprise does this in production/testing, if they do, shame on their process.
The only thing we can do in Teiid is check the current repository of deployed VDBs, then gracefully reject the deployment rather than the error you seen above.
> Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-3747
> URL: https://issues.jboss.org/browse/TEIID-3747
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> deployed a dynamic vdb using CLI: deploy teiidfiles/vdb/portfolio-vdb.xml
> then in Designer, tried to deploy the same named VDB, but as a .vdb and the deployment fails with errors indicating duplicate service:
> 11:26:31,301 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."Portfolio.vdb".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."Portfolio.vdb".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "Portfolio.vdb"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.teiid.ds-listener.Portfolio.1./accounts-ds is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3747) Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3747?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3747:
------------------------------------
The deleting before redeploying doesn't make sense. The deployment model has always been that a new vdb by the same name can be deployed. And if the current VDB is in use, existing logged in users will have to log out and log back in to use the new version. And I'm almost %100 certain designer doesn't do a check and remove a vdb prior to redeployment. This would be no different than a user who deploys using the admin-console. You're saying they would have to delete the prior VDB before redeploying a subsequent version of the same named VDB. That wouldn't work, because there would be a gap in between when the VDB is actually accessible (between when its deleted and redeployed).
> Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-3747
> URL: https://issues.jboss.org/browse/TEIID-3747
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> deployed a dynamic vdb using CLI: deploy teiidfiles/vdb/portfolio-vdb.xml
> then in Designer, tried to deploy the same named VDB, but as a .vdb and the deployment fails with errors indicating duplicate service:
> 11:26:31,301 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."Portfolio.vdb".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."Portfolio.vdb".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "Portfolio.vdb"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.teiid.ds-listener.Portfolio.1./accounts-ds is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (TEIID-3747) Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3747?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3747:
-------------------------------------
As I mentioned above there are two semantics to the VDB identification
- VDB Name ( Name you gave inside the vdb.xml)
- deployment name (name of the file, like foo.vdb or foo-vdb.xml)
When Designer only using .vdb, they have control over what is being deployed, they may be successfully able to delete the old one and redeploy new one. In this case Designer is not able to recognize there is an existing VDB, thus the issue.
When a VDB is deployed using "Admin.deploy" it takes a "deployed" name, same also with "Admin.undeploy". However, when you call "Admin.getVDBs()" this will return the VDB object that contains the name of the VDB, user can call VDB.getProperty("deployment-name") that can give the "deployed" name of the vdb (in this case portfolio-vdb.xml), which can used to undeploy. I am not sure how Designer is checking, thus the issue.
> Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates
> ---------------------------------------------------------------------------------------
>
> Key: TEIID-3747
> URL: https://issues.jboss.org/browse/TEIID-3747
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> deployed a dynamic vdb using CLI: deploy teiidfiles/vdb/portfolio-vdb.xml
> then in Designer, tried to deploy the same named VDB, but as a .vdb and the deployment fails with errors indicating duplicate service:
> 11:26:31,301 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."Portfolio.vdb".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."Portfolio.vdb".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "Portfolio.vdb"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.teiid.ds-listener.Portfolio.1./accounts-ds is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months