[
https://issues.jboss.org/browse/TEIID-2617?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-2617:
---------------------------------------
I guess "isValid()" is OK but then can't tell the
difference between missing data source and Validation errors.
Perhaps part of the confusion is the terminology around isValid and getValidityErrors is
weak and was not similarly cleaned up like status was. To us the internal form a validity
error is just a message of some severity (could be a warning, error, etc.). Any design
time validation "error" means that the VDB will end up as FAILED. Runtime
errors are attached dynamically based upon metadata load (which we've added a simple
flag form) / source missing. These are typically not severe errors as the load process
can recover/resume for example when a source becomes available.
So as for telling the difference between the errors, that's not really an issue for a
non-failed vdb - as any error has some relevance to the runtime validity. You can of
course examine the getValidationErrors if you want to know what they are for.
Your above description for active/invalid: "in theory not a
possible state as invalid should have set to inactive" gets to the heart of why I
logged this JIRA. Seems that if data source is removed, then the VDB should maybe be
"Inactive"
Seems like I haven't explained myself well enough then. I'm say that prior to
status change to {loading, active, failed, removed} there was effectively little
difference between the notion of "valid" and "active". They were
highly correlated and also the negatives invalid/inactive did not individually convey
anything meaningful about what was wrong with the vdb.
It seems like you are getting tripped up on not using the inactive term anymore. In the
olden days we controlled "datasources" as well, so some of this complexity
didn't exist. However in the AS world inactive was never a good description of the
pre/post load vdb status since a source could go missing at any time, not just prior to
deployment. You for example want to recover from the "inactive" state if a
datasource becomes available and you are attempting to do a metadata load. Also for
example consider user1 connects to an active/valid vdb successfully and a source goes
missing. With the old logic the vdb is now "inactive" and user2 can't make
a connection. However user1 was not booted and may issue some failing queries until the
source is available. What's the point of denying user2 a connection then? In both of
these cases the term "inactive" is not accurate.
So is this a bug then?
As written no. There is still nothing tangible here that needs addressed based upon your
comments. If you can drill in a little more on what you may need - without just looking
for the old inactive status - then there may be something we can do.
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