-
Bug
-
Resolution: Obsolete
-
Minor
-
None
-
8.10
-
None
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:
void startApplication() {
createEmbeddedServer(); // 1
deployVDB(); // 2
}
createEmbeddedServer() method does the following:
{
EmbeddedConfiguration ec = createEmbeddedConfiguration();
EmbeddedServer teiidServer = createEmbeddedTeiidServer();
teiidServer.start(ec);
}
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 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:
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)
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.
