[JBoss JIRA] (TEIID-586) Like pushdown handling
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-586?page=com.atlassian.jira.plugin.... ]
Steven Hawkins updated TEIID-586:
---------------------------------
Fix Version/s: 8.6
(was: 9.0)
> Like pushdown handling
> ----------------------
>
> Key: TEIID-586
> URL: https://issues.jboss.org/browse/TEIID-586
> Project: Teiid
> Issue Type: Bug
> Components: LDAP Connector, Query Engine, Salesforce Connector
> Affects Versions: 6.0.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.6
>
>
> Both salesforce and ldap like semantics are not the same as SQL. We could capture this with more capabilities supportsLikeCaseSensitive and supportsLikeWildcardSingleCharacter repectively, or another approach would be to allow the connector to generically indicate partial support and have the query engine both push down the conjunct and leave a copy to be applied after the query. With either explicit supports or generic partial support it would only applicable to top level where clause conjuncts.
--
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, 5 months
[JBoss JIRA] (TEIID-2593) often report: the trustAnchors parameter must be non-empty
by ying ma (JIRA)
[ https://issues.jboss.org/browse/TEIID-2593?page=com.atlassian.jira.plugin... ]
ying ma commented on TEIID-2593:
--------------------------------
Hi，Ramesh, thanks a lot for your comment, sorry for verify so late, the link you attach is useful, acturally it's caused by the wrong config of 'javax.net.ssl.trustStore', we put the new one to server, and it turns to noraml again, thanks a lot.
> often report: the trustAnchors parameter must be non-empty
> ----------------------------------------------------------
>
> Key: TEIID-2593
> URL: https://issues.jboss.org/browse/TEIID-2593
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector, JDBC Driver
> Affects Versions: 7.7
> Environment: Operating System: RHEL6
> JBoss: 6.1
> JDK: java-1.7.0-openjdk-1.7.0.0.x86_64
> Teiid: 7.7.0.Final
> Connecting to teiid via JDBC, the EngVDBF Database
> Reporter: ying ma
> Assignee: Steven Hawkins
> Priority: Critical
> Labels: eap6, jboss, sync
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> This ques appear when we upgrade JBoss from 6.0 to 6.1, the teiid always could not create connection, as below:
> 23:49:41,639 SEVERE [org.teiid.jdbc] (Timer-2) Could not create connection: org.teiid.jdbc.TeiidSQLException: Error establishing socket to host and port: vdb.engineering.redhat.com:31000. Reason: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:113) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:70) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.jdbc.SocketProfile.connect(SocketProfile.java:56) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.jdbc.TeiidDriver.connect(TeiidDriver.java:107) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at java.sql.DriverManager.getConnection(DriverManager.java:571) [rt.jar:1.7.0_25]
> at java.sql.DriverManager.getConnection(DriverManager.java:215) [rt.jar:1.7.0_25]
> at com.rehat.tools.vault.service.impl.BugzillaProductUpdate.productVersionUpdateTask(BugzillaProductUpdate.java:42) [vault-service-1.1.1.jar:]
> at com.redhat.tools.vault.listener.UpdateTimer.run(UpdateTimer.java:31) [classes:]
> at java.util.TimerThread.mainLoop(Timer.java:555) [rt.jar:1.7.0_25]
> at java.util.TimerThread.run(Timer.java:505) [rt.jar:1.7.0_25]
> Caused by: [SingleInstanceCommunicationException]Error establishing socket to host and port: vdb.engineering.redhat.com:31000. Reason: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> 1 [SSLException]java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> 2 [RuntimeException]Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> 3 [InvalidAlgorithmParameterException]the trustAnchors parameter must be non-empty
> at org.teiid.net.socket.SocketServerConnection.selectServerInstance(SocketServerConnection.java:161) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.net.socket.SocketServerConnection.<init>(SocketServerConnection.java:95) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.net.socket.SocketServerConnectionFactory.getConnection(SocketServerConnectionFactory.java:320) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.jdbc.SocketProfile.connect(SocketProfile.java:54) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> ... 7 more
> Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) [jsse.jar:1.7.0_25]
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1886) [jsse.jar:1.7.0_25]
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1844) [jsse.jar:1.7.0_25]
> at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1827) [jsse.jar:1.7.0_25]
> at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1753) [jsse.jar:1.7.0_25]
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:113) [jsse.jar:1.7.0_25]
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) [rt.jar:1.7.0_25]
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) [rt.jar:1.7.0_25]
> at java.io.BufferedInputStream.read(BufferedInputStream.java:334) [rt.jar:1.7.0_25]
> at java.io.DataInputStream.read(DataInputStream.java:149) [rt.jar:1.7.0_25]
> at org.teiid.netty.handler.codec.serialization.ObjectDecoderInputStream.fillBuffer(ObjectDecoderInputStream.java:164) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.netty.handler.codec.serialization.ObjectDecoderInputStream.findLength(ObjectDecoderInputStream.java:147) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.netty.handler.codec.serialization.ObjectDecoderInputStream.readObjectOverride(ObjectDecoderInputStream.java:81) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:364) [rt.jar:1.7.0_25]
> at org.teiid.net.socket.OioOjbectChannelFactory$OioObjectChannel.read(OioOjbectChannelFactory.java:114) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.net.socket.SocketServerInstanceImpl.doHandshake(SocketServerInstanceImpl.java:113) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.net.socket.SocketServerInstanceImpl.connect(SocketServerInstanceImpl.java:94) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.net.socket.SocketServerConnectionFactory.getServerInstance(SocketServerConnectionFactory.java:279) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.net.socket.SocketServerConnection.connect(SocketServerConnection.java:199) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> at org.teiid.net.socket.SocketServerConnection.selectServerInstance(SocketServerConnection.java:125) [teiid-client-7.7.0.Final.jar:7.7.0.Final]
> ... 10 more
> Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:90) [rt.jar:1.7.0_25]
> at sun.security.validator.Validator.getInstance(Validator.java:179) [rt.jar:1.7.0_25]
> at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:314) [jsse.jar:1.7.0_25]
> at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:173) [jsse.jar:1.7.0_25]
> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:186) [jsse.jar:1.7.0_25]
> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126) [jsse.jar:1.7.0_25]
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1323) [jsse.jar:1.7.0_25]
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153) [jsse.jar:1.7.0_25]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868) [jsse.jar:1.7.0_25]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:804) [jsse.jar:1.7.0_25]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016) [jsse.jar:1.7.0_25]
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_25]
> at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:882) [jsse.jar:1.7.0_25]
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:102) [jsse.jar:1.7.0_25]
> ... 24 more
> Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200) [rt.jar:1.7.0_25]
> at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120) [rt.jar:1.7.0_25]
> at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104) [rt.jar:1.7.0_25]
> at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:88) [rt.jar:1.7.0_25]
> ... 37 more
> According to the log, it may be caused by the cacerts in jre/lib/security is NULL, however, we've create the symlink to ../../../../../../../etc/pki/java/cacerts.
> I'm so confused about it, before jboss upgrade, the teiid is normal. So could you follow the issue? have any reason will cause the error?
--
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, 5 months
[JBoss JIRA] (TEIID-2575) Hive's Binary Type Handling by Teiid
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2575?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2575.
-----------------------------------
Fix Version/s: 8.4.1
8.5
Resolution: Done
Updated the type handling for hive.
> Hive's Binary Type Handling by Teiid
> ------------------------------------
>
> Key: TEIID-2575
> URL: https://issues.jboss.org/browse/TEIID-2575
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.4.1
> Reporter: Filip Nguyen
> Assignee: Ramesh Reddy
> Fix For: 8.4.1, 8.5
>
>
> I have simple Hive table (column definition: "OBJECTVALUE BINARY" see [1]). When running a simple query "statement.executeQuery("select OBJECTVALUE from smalla;");" I am getting [2]. When I run it simply from Hive console it works ok.
> [1]
> https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types
> [2]
> {noformat}
> org.teiid.jdbc.TeiidSQLException: TEIID10076 Invalid conversion from type class org.teiid.core.types.BinaryType with value 'EFBFBDEFBFBDEFBFBD' to type class java.lang.String
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
> at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:667)
> at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:63)
> at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:516)
> at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:130)
> at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:37)
> at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:75)
> at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:235)
> at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:271)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:102)
> at $Proxy6.read(Unknown Source)
> at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:370)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:525)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:393)
> at org.teiid.jdbc.StatementImpl.executeQuery(StatementImpl.java:327)
> at org.jboss.qe.HiveTranslatorTest.simpleQueryTest(HiveTranslatorTest.java:58)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:46)
> at org.testng.internal.InvokeMethodRunnable.run(InvokeMethodRunnable.java:37)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: org.teiid.core.types.TransformationException: TEIID10076 Invalid conversion from type class org.teiid.core.types.BinaryType with value 'EFBFBDEFBFBDEFBFBD' to type class java.lang.String
> at org.teiid.core.types.DataTypeManager.transformValue(DataTypeManager.java:891)
> at org.teiid.dqp.internal.process.DataTierTupleSource.correctTypes(DataTierTupleSource.java:186)
> at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:326)
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:306)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:149)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:149)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:112)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:153)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214)
> {noformat}
--
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, 5 months
[JBoss JIRA] (TEIID-2577) Translator API to provide session backed connection
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2577?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2577:
---------------------------------------
Under our normal procedure scoping rules when you create a temporary table in a block it is scoped to that block. Logically a source procedure is executing in it's own block and thus it's somewhat inconsistent to allow temporary tables created by a source procedure to create/reference session scoped table.
> Translator API to provide session backed connection
> ---------------------------------------------------
>
> Key: TEIID-2577
> URL: https://issues.jboss.org/browse/TEIID-2577
> Project: Teiid
> Issue Type: Feature Request
> Components: Connector API
> Reporter: Mark Addleman
> Assignee: Steven Hawkins
> Fix For: 8.6
>
>
> Provide an API (probably from an ExecutionContext) to obtain a JDBC connection to the same Teiid instance under the client's session.
--
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, 5 months
[JBoss JIRA] (TEIID-2309) Add support for "conformed" tables in Teiid
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2309?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2309:
----------------------------------
Fix Version/s: 8.6
Provisionally putting into 8.6. The optimizer logic is fairly straight-forward - however there is no clarity on how table conformity will be specified by the user.
Possiblities include:
- An extension property on the canonical table indicating the other source names in which it exists
This can be done at design, altered deploys (mixing in ddl alter option statements in the vdb.xml to set the metadata) or runtime (through property updates which would require a custom metadata repository)
A downside is that no metadata will exist in the Teiid system for the table on the other source. A variation would be akin to setting the materialization target such that a fully qualified list of existing conforming targets could be specified.
Another downside is that you have to be consistent in choosing the canonical table at design time otherwise the confirmed extension property would have to exist on all of the conformed tables or we would have to internally set that.
- A more general design time concept of a conformed table/model (although I'm not entierly sure what that would look like)
- A more general runtime approach based upon the temp table integration (but creating actual tables) to create copies of the reference data on the fly.
> Add support for "conformed" tables in Teiid
> -------------------------------------------
>
> Key: TEIID-2309
> URL: https://issues.jboss.org/browse/TEIID-2309
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Debbie Steigner
> Fix For: 8.6
>
>
> Teiid would support tables from different data sources being marked as "conformed", meaning they are the same (or perhaps a different name). When optimising a query, it would take the conformity into account and choose the appropriate copy of the table (presumably one in the same database as other tables in the query, if available). I would not regard it as a problem if Teiid *required* the dimensions to be strictly the same as opposed to permitting subsets, though as with so many areas, it would be up to the user to ensure this was really true: I would not expect the engine to do anything to verify that the tables really were conformed.
> Usecase:
> In Data Warehousing, it is relatively common to have multiple copies of the same dimensions spread over multiple Data Warehouses or Marts, or in the same Data Warehouse when associated with different Fact Tables. If these copies are either identical or strict subsets of an idealised dimension (and, by extension, share *exactly* the same naming and structure), then they may be said to be "conformed". It is expected that the dimension includes at least the values required to support the facts in the database in which it occurs or the Fact Table to which it is paired.
> Example:
>
> Source S1:
>
> BIGBIGBIG (millions of rows)
> bigkey
> ccy
> other_stuff
>
> CURRENCY (100s of rows) let's call it S1_CCY if we need to distinguish
> ccy
> ccy_name
>
>
> Source S2:
>
> BIGGER (millions of rows)
> biggerkey
> bigkey
> ccy
> more_stuff
>
> CURRENCY (100s of rows) similarly, S2_CCY
> ccy
> ccy_name
>
>
> When executing:
>
> SELECT B.*
> FROM BIGBIGBIG B,
> CURRENCY CCY
> WHERE B.ccy = CCY.ccy
> AND CCY.ccy_name LIKE "%DOLLAR%"
>
> Then it is clearly advantageous to use the copy of CURRENCY in S1 and re-write the query using S1_CCY. In this situation, federation is eliminated completely.
>
--
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, 5 months
[JBoss JIRA] (TEIID-2617) Deleting a Data Source for a Deployed/Active VDB in Teiid Designer via Servers view does not set VDB inactive
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2617?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2617.
-----------------------------------
Resolution: Rejected
TEIIDDES-1822 should address this on the designer side.
> Deleting a Data Source for a Deployed/Active VDB in Teiid Designer via Servers view does not set VDB inactive
> -------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2617
> URL: https://issues.jboss.org/browse/TEIID-2617
> Project: Teiid
> Issue Type: Bug
> Reporter: Barry LaFond
> Assignee: Steven Hawkins
>
> 1) Created simple Parts model and deployed it in a PartsVDB and tested.
> 2) Selected and removed/deleted the Parts Data Source in the Servers view
> 3) Console logged the following:
> {code}
> 10:59:22,711 INFO [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue11) zBnnx+1aVUjv OracleExecutionFactory Commit=true;DatabaseProductName=Oracle;DatabaseProductVersion=Oracle Database 11g Release 11.1.0.0.0 - Production;DriverMajorVersion=10;DriverMajorVersion=2;DriverName=Oracle JDBC driver;DriverVersion=10.2.0.4.0;IsolationLevel=2
> 10:59:40,554 INFO [org.teiid.RUNTIME] (MSC service thread 1-8) TEIID40012 For PartsVDB.1 VDB, Data Source "PartsOracle11" not found.
> 10:59:40,554 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) JBAS010409: Unbound data source [java:/PartsOracle11]
> {code}
> 4) VDB was not set to inactive and I was still able to connect to it in Data Tools explorer and try to "Sample Contents", or basically preview it.
> {code}
> 10:59:40,902 ERROR [org.jboss.remoting.remote.connection] (Remoting "blafond-thinkpad-t520:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Connection reset by peer
> 11:02:59,017 WARN [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue22) +l1hF0r0+BN4 Connector worker process failed for atomic-request=+l1hF0r0+BN4.3.0.3: org.teiid.translator.TranslatorException: TEIID30481 Failed to find the Connection Factory with JNDI name PartsOracle11. Please check the name or deploy the Connection Factory with specified name.
> at org.teiid.dqp.internal.datamgr.ConnectorManager.getConnectionFactory(ConnectorManager.java:251) [teiid-engine-8.4.1.jar:8.4.1]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:211) [teiid-engine-8.4.1.jar:8.4.1]
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:446) [teiid-engine-8.4.1.jar:8.4.1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:159) [teiid-engine-8.4.1.jar:8.4.1]
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:156) [teiid-engine-8.4.1.jar:8.4.1]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.6.0_27]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.6.0_27]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58) [teiid-engine-8.4.1.jar:8.4.1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.4.1.jar:8.4.1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.4.1.jar:8.4.1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.4.1.jar:8.4.1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_27]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_27]
> at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_27]
> Caused by: javax.naming.NameNotFoundException: PartsOracle11 -- service jboss.naming.context.java.PartsOracle11
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:103) [jboss-as-naming-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197) [jboss-as-naming-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:120) [jboss-as-naming-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183) [jboss-as-naming-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [jboss-as-naming-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at javax.naming.InitialContext.lookup(InitialContext.java:409) [rt.jar:1.6.0_27]
> at org.teiid.dqp.internal.datamgr.ConnectorManager.getConnectionFactory(ConnectorManager.java:247) [teiid-engine-8.4.1.jar:8.4.1]
> ... 13 more
> 11:02:59,024 WARN [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue23) +l1hF0r0+BN4 TEIID30020 Processing exception for request +l1hF0r0+BN4.3 'TEIID30504 PartsOracle11: TEIID30481 Failed to find the Connection Factory with JNDI name PartsOracle11. Please check the name or deploy the Connection Factory with specified name.'. Originally TeiidProcessingException 'PartsOracle11 -- service jboss.naming.context.java.PartsOracle11' ServiceBasedNamingStore.java:103. Enable more detailed logging to see the entire stacktrace.
> {code}
--
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, 5 months
[JBoss JIRA] (TEIID-2101) Statement.setMaxRows is not always used
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2101?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2101:
---------------------------------------
This also addressed a narrow issue - using the cache directive on a callable statement that returns parameters and has the max rows set will be cached as if it were the full result. Subsequent access of the cached results with a larger row limit will not see the missing rows.
> Statement.setMaxRows is not always used
> ---------------------------------------
>
> Key: TEIID-2101
> URL: https://issues.jboss.org/browse/TEIID-2101
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Driver, Query Engine
> Affects Versions: 7.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> The maxRows setting is not used when returning cached result sets or when getting a result set from a callablestatement procedure that returns parameters.
--
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, 5 months