Steps to Reproduce: 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 project_key: SOA 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.
Link: Added: This issue is a dependency of JBPAPP-7256
What you want? us to read the file every time? That's not practical... We just cache the setting and wait the deployer to kick in redeployment You will have the old setting until the redeployment happened. you can use the management API to change the setting in real time if you like. So I don't think this is a bug
Clebert, I think his point might be that the results of the initial security check may be cached indefinitely because of the assignment to lastCheck. The cached data may never become stale.
Steps to Reproduce: Removed: 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 don't exceed security-invalidation-interval Added: 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
Ah, I see now how "Steps to reproduce" can be interpreted ambiguously. I am sorry for not being precise enough. As Kevin pointed out the cached data may never become stale. Clebert, you said that "We just cache the setting and wait the deployer to kick in redeployment" is this really true? The behavior I observed was that redeployment *does not* clear the cache. Every time somebody sends message into queue the validity of cache is prolonged. However to answer your question (although it is not relevant what I want because I am not familiar with all business requirements of hornetq) in my opinion the easiest solution may be to just clear the cache with "onChange()" method that you already have in the code base upon redeployment.
Hi Filip, Where can I get the said jms_secured example to reproduce this issue? Thanks Howard
Hi Yong, jms_secured quickstart is packaged with SOA Platform distribution in <SOA-P>/jboss-as/samples/quickstarts/jms_secured
I am attaching the server log from session where I reproduced. Comment on the log follows. 14:39:19,997 deploying the QS. Hornetq config: {code:title=hornetq-configuration.xml|borderStyle=solid} <security-settings> <security-setting match="#"> <permission type="createNonDurableQueue" roles="guest"/> <permission type="deleteNonDurableQueue" roles="guest"/> <permission type="consume" roles="guest"/> <permission type="send" roles="guest"/> </security-setting> <security-setting match="jms.queue.quickstart_jms_secured_Request_gw"> <permission type="send" roles="esbrole,gatewayrole"/> <permission type="consume" roles="esbrole"/> </security-setting> <security-setting match="jms.queue.quickstart_jms_secured_Request_esb"> <permission type="send" roles="esbrole"/> <permission type="consume" roles="esbrole"/> </security-setting> </security-settings> {code} 14:39:46,615 runtest 14:40:08,991 deleting line <permission type="send" roles="esbrole"/> from hornetq config and save. 14:40:34,769 runtest: {noformat} javax.jms.JMSSecurityException: User: esbuser doesn't have permission='SEND' on address jms.queue.quickstart_jms_secured_Request_esb {noformat}
Attachment: Added: server.log
Hi Filip, Thanks for the info. I have another question, where can I download 5.2.0.ER3? Howard
Link: Added: This issue is related to SOA-3423
Howard, I took a look on the code, and it was really simple to fix it... the securityStore wasn't calling the registerListener. It's been fixed now.. thanks for taking a look on this.
Can't resolve until we have a fixed jar for SOA
HornetQ is technical preview, so should not hold up the 5.2.0 release.
HornetQ is a TP for SOA 5.2 and cannot block the releaase.
Related to https://issues.jboss.org/browse/JBPAPP-7256.
Verified on 5.3 but 5.2 still has this bug so this JIRA remains open.
5.2 is already release.. how can we fix in a previous release? Besides this was fixed as part of an one-off patch.. so this is definitely a close!
Ahhh... I'm sorry.... SOA EAP! I confused the 5.2 with EAP... I'm not sure how I could help you. we have fixed on HornetQ. Let me know what I can do.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.