[teiid-issues] [JBoss JIRA] (TEIID-4920) [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished
Krum Bakalsky created TEIID-4920:
------------------------------------
Summary: [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: Barry LaFond
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}
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/rep...]
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)