[teiid-issues] [JBoss JIRA] (TEIID-4920) [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished

[Steven Hawkins (JIRA)]

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

Steven Hawkins commented on TEIID-4920:
---------------------------------------

Yes, there is no way without a code change to reverse the startup order.  This also mimics the behavior of Teiid running in a container as the vdb deployments are happening simultaneously with starting the transports.  There is also a wait_for_load parameter that may attempt a connection before the vdb is deployed/available that can mitigate seeing the intermediate exceptions when connecting.

> [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: TEIID-4920
>                 URL: https://issues.jboss.org/browse/TEIID-4920
>             Project: Teiid
>          Issue Type: Bug
>          Components: Embedded, JDBC Connector, VDB
>    Affects Versions: 8.10
>            Reporter: Krum Bakalsky
>            Assignee: Steven Hawkins
>            Priority: Minor
>
> Our application uses Embedded Teiid server, and upon starting up it first creates and starts the Teiid server, and then performs a VDB deployment on top of it:
> {code}
> void startApplication() {
>     createEmbeddedServer(); // 1
>     deployVDB();            // 2
> }
> createEmbeddedServer() method does the following:
> {
>   EmbeddedConfiguration ec = createEmbeddedConfiguration();
>   EmbeddedServer teiidServer = createEmbeddedTeiidServer();
>   teiidServer.start(ec);
> }
> {code}
> Step 2 - deployVDB() method - takes a while to complete, at minimum around 6-8 seconds. However, executing step 1 (creating and starting the embedded server) already creates its worker thread pool (the DQP pool), that is ready to serve incoming JDBC calls.
> One of the reasons why we chose to perform these steps in that very order, is because of the [deployVDB|http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.teiid/teiid-runtime/8.10.0.Final/org/teiid/runtime/EmbeddedServer.java#684] method: it first checks if the server is started and fails if that is not the case. So the order is somehow implied by the way Teiid deployment works.
> This particular way of using Teiid is vulnerable to the following race condition: if client JDBC calls start coming while step 2 is not yet completed (VDB deployment is still in progress), then they will fail since the VDB metadata will be null:
> {code}
> 2017-02-14 11:18:12,250 ERROR org.teiid.PROCESSOR: TEIID30019 Unexpected exception for request <request_id>
> org.teiid.core.TeiidComponentException: TEIID30489 Unable to load metadata for VDB <vdb_name>.
> at org.teiid.dqp.internal.process.Request.initMetadata(Request.java:191)
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:436)
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:627)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:326)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:265)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Please advise of what is the safest way to achieve VDB deployment + server start, and in what order.
> *Note*: Please note that this is probably not best categorized as a bug, but rather some glitch in the behavior of Embedded Teiid, or maybe even some misunderstanding about how deployment should be done w.r.t starting the embedded server.
> I am assigning a minor priority since the impact of this problem is relatively small and limited - clients will be affected until VDB deployment is in progress.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)