The following error occurs when the JBI message processor thread pool is exhausted, and no more message is processed:
Exception in thread "petals-bc-soap -JBI Acceptor Thread #2" java.lang.StackOverflowError
at sun.misc.Unsafe.compareAndSwapInt(Native Method)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.compareAndSetState(AbstractQueuedSynchronizer.java:537)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:183)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
at java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(ThreadPoolExecutor.java:718)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:657)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
...
Reproducer, with a service proxy based on the BC SOAP
The following error occurs when the JBI message processor thread pool is exhausted, and no more message is processed:
Exception in thread "petals-bc-soap -JBI Acceptor Thread #2" java.lang.StackOverflowError
at sun.misc.Unsafe.compareAndSwapInt(Native Method)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.compareAndSetState(AbstractQueuedSynchronizer.java:537)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:183)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
at java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(ThreadPoolExecutor.java:718)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:657)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)
at java.util.concurrent.ThreadPoolExecutor$DiscardOldestPolicy.rejectedExecution(ThreadPoolExecutor.java:1813)
...
Reproducer, with a service proxy based on the BC SOAP
The JBI message processor thread pool defines a rejection policy discarding the oldest request. IMO, it is more efficient to reject the message that can be processed, because the service consumer receives a fault instead of a timeout. If a time out occurs, we will never looking for a problem in the sizing of the pool.
Christophe DENEUX added a comment - Thu, 5 Apr 2012 - 11:43:45 +0200 The JBI message processor thread pool defines a rejection policy discarding the oldest request. IMO, it is more efficient to reject the message that can be processed, because the service consumer receives a fault instead of a timeout. If a time out occurs, we will never looking for a problem in the sizing of the pool.
The JBI message processor thread pool defines a rejection policy discarding the oldest request. IMO, it is more efficient to reject the message that can be processed, because the service consumer receives a fault instead of a timeout. If a time out occurs, we will never looking for a problem in the sizing of the pool.