Added the above mentioned metadata load states to Model.

The field will likely be called MetadataStatus. How about the values LOADING, LOADED, FAILED, RETRYING

So what do call this 4th state?

• METADATA_LOAD_FAILED
• DATA_SOURCE_ERROR
• ?

I'm saying that if VDB.getStatus == LOADING and Model.getMetadataStatus == FAILED that necessarily means that the error is recoverable. Only when the VDB status moves to FAILED does it mean that there is something truly wrong. But that must seem confusing so 4 model metadata states will work just fine.

I was thinking that FAILED == fix the issue, redeploy

Here we just have to fix the Data source issue, the process of deploy will pickup from the model where it has stopped. Would it work the same way, with single state?

> We need some quick way to represent a recoverable error, rather than user looking at model errors.

I know that is the goal, but I don't think you understood me. VDB loading and model metadata failed means it is a recoverable error. I'm just trying to keep the states to a minimum. There's no problem though with adding another state.

Yes, that last statement summarizes it - I think the states should indicate somehow if its recoverable. I understand the current mechanism now, but I think this could be a source of confusion for users in the future.

IMO, I do think we need two states, because from earlier discussions

He was not sure if the VDB was deployed first vs the data source deployed first. We did not wanted to create that dependency in deployment chain. Even if both configuration went at same time, or one after the other in right dependency timeline, since AS7 deployment process being asynchronous we could not depend on, when one is finished, so that other can start. Thus one of the reason we had the data source not availability as soft error. If we make that as hard error as single state "FAILED", then there may be some false deployment errors.

We need some quick way to represent a recoverable error, rather than user looking at model errors.

In the context of a metadata load WAITING is just a special case of FAILED, such that the overall deployment is still loading. However we can treat that as two states if a single seems too complicated.

So Mark how would a Model.getMetadataStatus where the Status could be one of (LOADING, LOADED, or FAILED) work?

I'm not sure the waiting status is needed for the entire vdb. It seems like you just need/want a clearer indication that a particular error message on a model means that the source is unavailable or otherwise erroring out. Perhaps that means loading statuses for each model to see which ones are waiting vs. those that are just taking a long time (due to a custom repository or large source crawl) vs. those that are already done.

I think LOADING implies that something is in process, but if a dataSource is unavailable that's not the case. So maybe add another state?
For example:
LOADING
WAITING
ACTIVE
FAILED
So if metadata is really loading, you are in the LOADING state. If one or more sources are unavailable (bad credentials or whatever) it goes to WAITING. If the source comes back online at some point, you'd potentially go to LOADING then ACTIVE.

Mark based upon these comments, what needs done to resolve this issue?

The datasource not availability ones, I do not think I see them on console.

Ramesh what do you mean? Exceptions from metadata loads are logged. Metadata validation errors are logged. VDBStatusChecker logs errors/warnings.

VDBRepository source validation is not logged, but only affects validity - as it is called after load.

The confusion sometimes is Teiid does not write any of these warnings or errors into log, so you would have to query the vdb before one can find out why a VDB is in LOADING state. Should we write these to a log perhaps?

Mutually exclusive states are

LOADING
ACTIVE
FAILED

Which can be queried through "vdb.getStatus", Now as Steve says, every one of these states can have Errors and/or Warnings, you ask "hasErrors" to check if there are any. If you find that there are then you can call "getValidityErrors" for list of them. You can only connect using JDBC when the VDB is ACTIVE.

Now depending upon the metadata load requirements (Dynamic vdb vs Designer VDB) a data source may be required at deployment time or not, based on that a VDB may be marked as ACTIVE or LOADING is the data source is not available. Which Steve is saying it is a recoverable error, than can be fixed by supplying the data source.

So, if your application after deployment, is saying vdb is LOADING, then keep looking for "getValidityErrors", if you find it fix them, if there are no validity errors and status LOADING wait for status to change or until your next poll.

reference https://issues.jboss.org/browse/TEIID-2105 and the release note text is "VDB.Status now has four states - LOADING, ACTIVE, FAILED, REMOVED. To check for validity use the isValid method, rather than checking for the VALID state. FAILED deployments will still be accessible via the admin getVDB methods."

removed should not be seen by the client, so that just leaves loading/active/failed. You start as loading. You transition to active after all metadata has been loaded. This means the vdb is complete and querable, but that you may get exceptions (isValid may be false since a source may be down/missing). You transition to failed if there is a non-recoverable exception during loading (typically a metadata validation issue).

Right, if you guys could explain what each of those mutually exclusive states means would help. Or a state diagram showing how we go between states. And examples of what types of warnings/errors might be applicable in each state.

There may be some confusion here as those booleans that you are listing are really a set of mutually exclusive states - VDB.getStatus(). You can be loading/active/failed/removed. You can have validity warnings/errors in any of those states. We may need to do some cleanup on the distinction between errors/warnings as an error does not always imply a failed deployment (such as a source requiring a datasource not having that datasource deployed).

I guess I'm confused by the different states and validity errors. Do you have a state diagram or a write up to further explain how the vdb progresses from one state to the next?

In this particular case,
isLoading = true
isActive = false
hasFailed = false

I then have to get the list of validity errors to figure out that the data source is not available.

Has the deployment truly failed or just not succeeded? isLoading can still be true with a missing datasource as that is considered a recoverable error and loading will resume once the datasource is available. On the other hand something like a metadata error should cause the deployment to fully fail.