[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:all-tabpanel ]

Steven Hawkins closed TEIID-4920.
---------------------------------


> [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.5.0#75005)