[JBoss JIRA] (TEIID-3036) Update CXF to current version (3.0.0)
by Gary Gregory (JIRA)
[ https://issues.jboss.org/browse/TEIID-3036?page=com.atlassian.jira.plugin... ]
Gary Gregory commented on TEIID-3036:
-------------------------------------
I'm not sure how Wildfly and JBoss EAP are related but I can see that JBoss EAP ships with CXF 2.7.11. Does that mean that Teiid 8.9 can or will pickup CXF 2.7.11?
> Update CXF to current version (3.0.0)
> -------------------------------------
>
> Key: TEIID-3036
> URL: https://issues.jboss.org/browse/TEIID-3036
> Project: Teiid
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Embedded
> Affects Versions: 8.8
> Reporter: Gary Gregory
> Assignee: Steven Hawkins
>
> In the same vein as TEIID-3030, we embed CXF and Teiid in our server. We use CXF 2.7.10 and are about to update to 3.0.0. At worse, we'll go to 2.7.11 as an interim step to 3.0.0.
> Teiid embedded delivers CXF 2.6.6 for web services support.
> It would be great if we could get Teiid to the latest and greatest from CXF so we can all live in the same space without being forced to deal with any incompatibilities or class loader hacks.
> Thank you,
> Gary
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3099) RejectedExecutionException for Teiid during high query load
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3099?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3099:
---------------------------------------
After looking at this again, it would be simpler to just set the actual pool max threads to a much higher number or unbounded, with the possibility of temporarily creating too many threads rather than getting the rejection.
> RejectedExecutionException for Teiid during high query load
> -----------------------------------------------------------
>
> Key: TEIID-3099
> URL: https://issues.jboss.org/browse/TEIID-3099
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine, Server
> Affects Versions: 8.7
> Environment: Windows (x64) and Mainframe z/OS (x64)
> Reporter: Mark Ackert
> Assignee: Steven Hawkins
> Labels: queryengine, rejectedexecutionexception, teiid-engine, threads
>
> Occasionally, when a standalone Teiid server is under high load from concurrent queries, a RejectedExecutionException is thrown. The relevant part of the stacktrace is below. I investigated the ThreadReuseExecutor source, and I believe the issue's cause is based around the sycnhronized(poolLock) code - see below the stack trace for info, and psuedo-code snippet with my analysis below the stacktrace.
> Caused by: java.util.concurrent.RejectedExecutionException: Task org.teiid.dqp.internal.process.ThreadReuseExecutor$3@c75a8114 rejected from org.teiid.dqp.internal.process.ThreadReuseExecutor$2@8b1166ec[Running, pool size = 128, active threads = 128, queued tasks = 0, completed tasks = 692637]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) [rt.jar:1.7.0]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor.executeDirect(ThreadReuseExecutor.java:200) [teiid-engine-8.7.0.FinalCAFix-SNAPSHOT.jar:8.7.0.FinalCAFix-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor.execute(ThreadReuseExecutor.java:177) [teiid-engine-8.7.0.FinalCAFix-SNAPSHOT.jar:8.7.0.FinalCAFix-SNAPSHOT]
> In the below executeDirect, the race condition that appears plausible to me is: given "activeCount" is at the thread pool size limit and a single thread is finishing execution...Let activeCount be reduced by one in the tpe.execute runnable's synchronized block. The synchronized block exits, and goes to the warnWait/logging code - at this point a thread context switch occurs, and a new PrioritizedRunnable (one which isn't waiting on the poolLock at the beginning of the executeDirect method) comes through executeDirect and proceeds forward because "poolLock" has been released, "activeCount" is now sizeLimit-1. The tpe tries to execute a new Runnable wrapping this PrioritizedRunnable, but the previous thread which hasn't completed it's logging code yet is still present in the the threadpool, and as such we get a RejectedExecutionException due to too many threads trying to be executed in a fixed size thread pool.
> private void executeDirect(final PrioritizedRunnable command) {
> boolean atMaxThreads = false;
> synchronized (poolLock) {
> .... if activeCount!=max_limit; activeCount++
> }
> .......
> tpe.execute(.....
> finally {
> synchronized (poolLock) {
> .......
> activeCont--;
> }
> if (success) {
> ......some log code
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3099) RejectedExecutionException for Teiid during high query load
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3099?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3099:
---------------------------------------
Yes, I agree that can occur. Even if we expand the scope of the poolLock there is still a potential for a timing issue. It seems best to not rely on a SynchronousQueue and instead use a LinkeBlockingQueue, but we'll also have to check that queue as part of the reuse logic as to keep scheduling more fair.
> RejectedExecutionException for Teiid during high query load
> -----------------------------------------------------------
>
> Key: TEIID-3099
> URL: https://issues.jboss.org/browse/TEIID-3099
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine, Server
> Affects Versions: 8.7
> Environment: Windows (x64) and Mainframe z/OS (x64)
> Reporter: Mark Ackert
> Assignee: Steven Hawkins
> Labels: queryengine, rejectedexecutionexception, teiid-engine, threads
>
> Occasionally, when a standalone Teiid server is under high load from concurrent queries, a RejectedExecutionException is thrown. The relevant part of the stacktrace is below. I investigated the ThreadReuseExecutor source, and I believe the issue's cause is based around the sycnhronized(poolLock) code - see below the stack trace for info, and psuedo-code snippet with my analysis below the stacktrace.
> Caused by: java.util.concurrent.RejectedExecutionException: Task org.teiid.dqp.internal.process.ThreadReuseExecutor$3@c75a8114 rejected from org.teiid.dqp.internal.process.ThreadReuseExecutor$2@8b1166ec[Running, pool size = 128, active threads = 128, queued tasks = 0, completed tasks = 692637]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) [rt.jar:1.7.0]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor.executeDirect(ThreadReuseExecutor.java:200) [teiid-engine-8.7.0.FinalCAFix-SNAPSHOT.jar:8.7.0.FinalCAFix-SNAPSHOT]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor.execute(ThreadReuseExecutor.java:177) [teiid-engine-8.7.0.FinalCAFix-SNAPSHOT.jar:8.7.0.FinalCAFix-SNAPSHOT]
> In the below executeDirect, the race condition that appears plausible to me is: given "activeCount" is at the thread pool size limit and a single thread is finishing execution...Let activeCount be reduced by one in the tpe.execute runnable's synchronized block. The synchronized block exits, and goes to the warnWait/logging code - at this point a thread context switch occurs, and a new PrioritizedRunnable (one which isn't waiting on the poolLock at the beginning of the executeDirect method) comes through executeDirect and proceeds forward because "poolLock" has been released, "activeCount" is now sizeLimit-1. The tpe tries to execute a new Runnable wrapping this PrioritizedRunnable, but the previous thread which hasn't completed it's logging code yet is still present in the the threadpool, and as such we get a RejectedExecutionException due to too many threads trying to be executed in a fixed size thread pool.
> private void executeDirect(final PrioritizedRunnable command) {
> boolean atMaxThreads = false;
> synchronized (poolLock) {
> .... if activeCount!=max_limit; activeCount++
> }
> .......
> tpe.execute(.....
> finally {
> synchronized (poolLock) {
> .......
> activeCont--;
> }
> if (success) {
> ......some log code
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3099) RejectedExecutionException for Teiid during high query load
by Mark Ackert (JIRA)
Mark Ackert created TEIID-3099:
----------------------------------
Summary: RejectedExecutionException for Teiid during high query load
Key: TEIID-3099
URL: https://issues.jboss.org/browse/TEIID-3099
Project: Teiid
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Query Engine, Server
Affects Versions: 8.7
Environment: Windows (x64) and Mainframe z/OS (x64)
Reporter: Mark Ackert
Assignee: Steven Hawkins
Occasionally, when a standalone Teiid server is under high load from concurrent queries, a RejectedExecutionException is thrown. The relevant part of the stacktrace is below. I investigated the ThreadReuseExecutor source, and I believe the issue's cause is based around the sycnhronized(poolLock) code - see below the stack trace for info, and psuedo-code snippet with my analysis below the stacktrace.
Caused by: java.util.concurrent.RejectedExecutionException: Task org.teiid.dqp.internal.process.ThreadReuseExecutor$3@c75a8114 rejected from org.teiid.dqp.internal.process.ThreadReuseExecutor$2@8b1166ec[Running, pool size = 128, active threads = 128, queued tasks = 0, completed tasks = 692637]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) [rt.jar:1.7.0]
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) [rt.jar:1.7.0]
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) [rt.jar:1.7.0]
at org.teiid.dqp.internal.process.ThreadReuseExecutor.executeDirect(ThreadReuseExecutor.java:200) [teiid-engine-8.7.0.FinalCAFix-SNAPSHOT.jar:8.7.0.FinalCAFix-SNAPSHOT]
at org.teiid.dqp.internal.process.ThreadReuseExecutor.execute(ThreadReuseExecutor.java:177) [teiid-engine-8.7.0.FinalCAFix-SNAPSHOT.jar:8.7.0.FinalCAFix-SNAPSHOT]
In the below executeDirect, the race condition that appears plausible to me is: given "activeCount" is at the thread pool size limit and a single thread is finishing execution...Let activeCount be reduced by one in the tpe.execute runnable's synchronized block. The synchronized block exits, and goes to the warnWait/logging code - at this point a thread context switch occurs, and a new PrioritizedRunnable (one which isn't waiting on the poolLock at the beginning of the executeDirect method) comes through executeDirect and proceeds forward because "poolLock" has been released, "activeCount" is now sizeLimit-1. The tpe tries to execute a new Runnable wrapping this PrioritizedRunnable, but the previous thread which hasn't completed it's logging code yet is still present in the the threadpool, and as such we get a RejectedExecutionException due to too many threads trying to be executed in a fixed size thread pool.
private void executeDirect(final PrioritizedRunnable command) {
boolean atMaxThreads = false;
synchronized (poolLock) {
.... if activeCount!=max_limit; activeCount++
}
.......
tpe.execute(.....
finally {
synchronized (poolLock) {
.......
activeCont--;
}
if (success) {
......some log code
}
}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TEIID-3041) Add support for xml document models in ddl
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3041?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3041.
-----------------------------------
Fix Version/s: (was: 8.9)
Resolution: Deferred
After discussions with Barry, we'll look to leave the existing support alone and just use index metadata for xml document models. If this becomes an inhibitor for Designer though we can revisit this issue.
> Add support for xml document models in ddl
> ------------------------------------------
>
> Key: TEIID-3041
> URL: https://issues.jboss.org/browse/TEIID-3041
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
>
> xml document model support was left out of the initial ddl design, but since the feature has not yet been retargeted from designer we should add support.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months