Scenario on client:
1. Employing RedeliveryPolicy with exponential backoff (keeping maximum
redeliveries at default 6)
2. Enabled non-blocking redelivery
3. Receiving e.g. 100 consecutive poison messages (which eventually
should DLQ after max redeliveries)
This will result in massive redelivery delays due to a logic bug.
The reason is that redeliveryDelay is a field variable kept on the
ActiveMQMessageConsumer, instead of being a property on the message - or
that the redelivery delay was calculated per message based on the
redelivery count.
When consecutive messages rollbacks multiple times, the redeliveryDelay
field is continuously multiplied by the backoff multiplier, resulting in
enormous delays.
Fix: Ditch the field variable, instead calculating the redeliveryDelay
per delivery from the redelivery count. (This happens to be identical to
how it is done in afterRollback() in ActiveMQSession:1004.)
Test is added - which fails with the previous code, and passes with
this. Added a debug log line for the calculated delay.
Inside ActiveMQSslConnectionFactory the passwords should be checked for
null so a NPE isn't thrown. Null will be passed to the factories instead
and the keystore/truststore factories will try and load the keystores
using null for the password which may or may not work depending on the
implementation and if password is set.
- Handle in the OpenWireFormat class
- Add unit tests to confirm
- Verify compression is accounted for
- Verify the ability to disable using wireFormat.maxFrameSizeEnabled=false
- [cshannon] Reworked max frame size test case to add in all transports and all client/server cases
- Store maxFrameSize on client-side
- Check messages on outbound send to send an actionable exception to the caller
- Add a reason code for max message size exceeded (client-side)
- API update only
- Throw UnsupportedOperationException
- Disable activemq-camel from build
- Formatting fixes
- Use geronimo-jms for osgi-related artifacts
- Fix features.xml invalid xml header
- Add a unit test to confirm JMS 2.0 methods for phase 1 (throw UnsupportedOperationException)
- Add deliveryTime field to Message
- Minor formatting fixes
deadlocks
Switch to using a dedicated lock to initialize the Scheduler object
inside of ActiveMQConnection to prevent a deadlock scenario that occurs
when using the intrinsic ActiveMQConnection lock. This is using double
checked locking so this lock will only be contended with during lazy
creation and then will rely on the volatile reference for future reads
and when stopping/closing.
This narrows the lock that was added to serviceRead() to secureRead()
which prevents processing commands while locked which should solve the
deadlock issues
This makes sure the nio transport thread properly terminates if
maxFrameSize is exceeded with OpenWire to prevent an infinite loop that
uses up all the cpu
