Petals CDK

StackOverflowError occurs when the JBI message processor thread pool is exhausted

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 5.1.3
  • Fix Version/s: 5.1.4, 5.3.0
  • Component/s: runtime
  • Security Level: Public
  • Description:
    Hide

    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

    • configure the BC SOAP with:
      <ns2:acceptor-pool-size>2</ns2:acceptor-pool-size>
      <ns2:processor-pool-size>2</ns2:processor-pool-size>
      <ns2:processor-max-pool-size>4</ns2:processor-max-pool-size>
    • using SOAPUI, send several requests concurrently (~15 requests should be sufficient to get the error
    Show
    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
    • configure the BC SOAP with:
      <ns2:acceptor-pool-size>2</ns2:acceptor-pool-size>
      <ns2:processor-pool-size>2</ns2:processor-pool-size>
      <ns2:processor-max-pool-size>4</ns2:processor-max-pool-size>
    • using SOAPUI, send several requests concurrently (~15 requests should be sufficient to get the error
  • Environment:
    -

Issue Links

Activity

Hide
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.

Show
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.
Hide
Christophe DENEUX added a comment - Thu, 5 Apr 2012 - 14:45:45 +0200

Fixed in trunk

Show
Christophe DENEUX added a comment - Thu, 5 Apr 2012 - 14:45:45 +0200 Fixed in trunk
Hide
Christophe DENEUX added a comment - Thu, 19 Apr 2012 - 16:43:33 +0200

To backport in petals-enterprise-3.1.x

Show
Christophe DENEUX added a comment - Thu, 19 Apr 2012 - 16:43:33 +0200 To backport in petals-enterprise-3.1.x
Hide
Christophe DENEUX added a comment - Thu, 19 Apr 2012 - 16:43:55 +0200

Backported in petals-enterprise-3.1.x

Show
Christophe DENEUX added a comment - Thu, 19 Apr 2012 - 16:43:55 +0200 Backported in petals-enterprise-3.1.x

People

Dates

  • Created:
    Thu, 5 Apr 2012 - 11:38:49 +0200
    Updated:
    Thu, 19 Apr 2012 - 16:43:55 +0200
    Resolved:
    Thu, 19 Apr 2012 - 16:43:55 +0200