[teiid-issues] [JBoss JIRA] (TEIID-2617) Deleting a Data Source for a Deployed/Active VDB in Teiid Designer via Servers view does not set VDB inactive

Wed Aug 7 16:14:26 EDT 2013

    [ https://issues.jboss.org/browse/TEIID-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795671#comment-12795671 ] 

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