When pool is exhausted the request is ignored instead of returning 5xx

[arinban]

This is the stack:

org.glassfish.grizzly.nio.SelectorRunner notifyConnectionException
SEVERE: doSelect exception
java.util.concurrent.RejectedExecutionException: Task org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy$WorkerThreadRunnable@1ad391bf rejected from com.mulesoft.mule.config.pool.MonitoredThreadPoolExecutor@34845b35[Running, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 1]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
	at org.mule.work.MuleWorkManager.execute(MuleWorkManager.java:210)
	at org.mule.module.http.internal.listener.grizzly.ExecutorPerServerAddressIOStrategy.executeIoEvent(ExecutorPerServerAddressIOStrategy.java:70)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
	at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414)
	at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383)
	at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347)
	at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)

I understand that if the connection pool is exhausted it doesn't make sense to allocate more resources to answer all the requests with 500 but maybe the selector could be doing that.

Affected Versions

[2.3.26]

[arinban]

@glassfishrobot Commented
Reported by alepulver

[arinban]

@glassfishrobot Commented
@rlubke said:
The problem I see is that the Selector is protocol agnostic.

We may be able to tweak the logic a bit to invoke a callback on the SelectorHandler where a custom SelectorHandler implementation could take action appropriate to their application.

Will need to think on this a bit.

[arinban]

@glassfishrobot Commented
This issue was imported from java.net JIRA GRIZZLY-1871

[arinban]

• Issue Imported From: When pool is exhausted the request is ignored instead of returning 5xx javaee/grizzly#1871
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To:@glassfishrobot