Version 2



    Currently when a data source is created / removed using the CLI the "reload-status" is set to "requires reload", based how the resource is expected to be managed in WF.


    In Teiid, it is common practice to add/remove data sources dynamically and restarting server will affect performance and usability severely:

    • Because delete/re-add is in Teiid's workflow to manage a data sources and when the server restarts TEIID loose the whole state of the virtual database. That means TEIID need re-establish runtime status. For example, all the existing sessions will be killed.
    • Runtime environments are often shared, that could kill other users' tasks in flight leaving them hanging with errors.
    • Every time data source starts TEIID fetch metadata from the source, this is very expensive operation.


    Issue Metadata


    EAP Issue:

    WF Issue: [WFLY-6773] Provide ability to start/stop Data Source creation without restart of server - JBoss Issue Tracker

    Possibly related/impacted issue:

    Dev Contact: Stefano Maestri

    QE Contact:

    AFFECTED PROJECTS OR COMPONENTS: connector subsystem



    We need to provide a remove operation for datasources supporting "resource-service" paradigm. From official WF10 documentation:

    • resource-services – The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.)



    We are not supporting any graceful remove of datasources. Removing datasource providing "allow-resource-service-restart" will stop immediately datasource's related services eventually killing open connections. It's also up to the client ensure the operation will not break any dependent deployments. In case of not removed dependencies, the operation could fail.