Status: Closed (View Workflow)
Resolution: Migrated to another ITS
To reproduce the issue it is possible to use jms_secured quickstart with Hornetq installed.
To reproduce the issue it is possible to use jms_secured quickstart with Hornetq installed. deploy, runtest quickly delete this security settings <permission type="send" roles="gatewayrole"/> quickly runtest again, now you can runtest how many times you want provided you interval between each message doesn't exceed security-invalidation-interval
- deploy, runtest
- quickly delete this security settings <permission type="send" roles="gatewayrole"/>
- quickly runtest again, now you can runtest how many times you want provided you interval between each message doesn't exceed security-invalidation-interval
When using Hornetq and it's security-settings (configured in hornetq-configuration.xml - but I suspect this issue occurs also with Management API) the security settings are being cached in SecurityStoreImpl.java (HashMap cache). After modifying hornetq-configuration.xml when server redeploy takes place but the cache doesn't invalidate (I thing method public onChange() is there for that reason but never get called). The worst thing is that cache is being "marked as valid" as long as security settings are checked (SecurityStoreImpl:242 -> lastCheck = now and that happens all the time (whenever anybody accesses any queue!). Implicit value for security-invalidation-interval seems to be 10 seconds.
Following can happen because of described implementation:
- QueueA gets deployed and admin sets permission SEND permission for RoleX
- RoleX sends into the QueueA (thus makes cache valid for at least security-invalidation-interval)
- Permission SEND is deleted from hornetq-configuration.xml and security settings are automatically redeployed
- RoleX happens to send into QueueA before cache invalidates
- RoleX sends as many messages int QueueA as he wants.
I think this is an integration issue becase cache is not being invalidated upon settings redeploy.