rzo1 opened a new pull request, #3090: URL: https://github.com/apache/tomee/pull/3090
Reproducer for the "MDB pool drops instances on RejectedExecutionException" thread on dev@. **Not meant to be merged as is. The test fails on purpose.** ## What the test does The ActiveMQ resource adapter gets `threadPoolSize=2`, `QueueSize=1` and `OfferTimeout=1 second`. 1. A blocking MDB occupies both pool threads and the single queue slot. 2. A message is sent to an MDB with `maxSessions=1`. Scheduling its `ServerSession` work is rejected after the offer timeout. 3. The blocking MDB is released, so the pool recovers. 4. Another message is sent to the `maxSessions=1` MDB. It is never consumed. With `-DofferTimeout="30 seconds"` the work only waits and is never rejected, and the test passes. The rejection is what kills the consumer. ``` mvn -pl container/openejb-core test -Dtest=MdbWorkRejectionTest mvn -pl container/openejb-core test -Dtest=MdbWorkRejectionTest -DofferTimeout="30 seconds" ``` ## Analysis The code involved is identical in 10.2.0 (activemq-ra 6.2.7, geronimo-connector 4.0.0) and on main (activemq-ra 6.3.2). - **geronimo-connector 4.0.0:** `GeronimoWorkManager.executeWork` lets `RejectedExecutionException` escape. `ServerSessionImpl.start()` only catches `WorkException`, so `running` stays `true`. The session stays in `activeSessions` without a thread and is never considered stale. With `maxSessions=1` the consumer is dead for good; with more sessions a slot leaks per rejection. Nothing is logged. - **With GERONIMO-6911** (from reading the code, not verified): `start()` fails with a `JMSException`, which reaches the exception listener of `ActiveMQEndpointWorker`. The listener disconnects and calls `connect()`, which schedules the reconnect on the same, still saturated WorkManager. On `WorkException` it sets `running = false` and logs "Work Manager did not accept work", so the endpoint never reconnects. Both holes are in activemq-ra (`ServerSessionImpl.start()` and `ActiveMQEndpointWorker.connect()`), so the fix most likely belongs upstream. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
