Uploaded image for project: 'JBoss Enterprise SOA Platform'
  1. JBoss Enterprise SOA Platform
  2. SOA-3363

Permisssions for Hornetq are cached and the cache is not being invalidated under some circumstances

    XMLWordPrintable

Details

    • Hide

      To reproduce the issue it is possible to use jms_secured quickstart with Hornetq installed.

      1. deploy, runtest
      2. quickly delete this security settings <permission type="send" roles="gatewayrole"/>
      3. quickly runtest again, now you can runtest how many times you want provided you interval between each message doesn't exceed security-invalidation-interval
      Show
      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

    Description

      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:

      1. QueueA gets deployed and admin sets permission SEND permission for RoleX
      2. RoleX sends into the QueueA (thus makes cache valid for at least security-invalidation-interval)
      3. Permission SEND is deleted from hornetq-configuration.xml and security settings are automatically redeployed
      4. RoleX happens to send into QueueA before cache invalidates
      5. 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.

      Attachments

        Issue Links

          Activity

            People

              csuconic@redhat.com Clebert Suconic
              fnguyen_jira Filip Nguyen (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: