On Sun, Jan 17, 2010 at 11:35 PM, Jon Watte <[email protected]> wrote: > I'm looking at the C++ broker/exchange. > > When I have an ACL, the documentation seems to indicate that the ACL is > parsed for each message sent. Is this the case? If I have a very long ACL > (say a million entries), would this be a performance problem?
Even if ACL is enabled in the broker, If you don't have ACL for publish (message transfer) then we don't check ACL at all. If you have ACL for publish then we do check ACL. Therefore If you don't have publish ACL then there want be any impact on performance during message transfers. I haven't tested ACL with a large amount of entries. Once the file is parsed we have to keep the data in memory. So it will likely take a bit of memory as well. Also such a large amount of entries are definitely going to increase broker startup (where we parse the file) Also if your ACL involves publish ACL, then the current mechanism will likely have a huge performance impact. (See some of the suggestion below to mitigate this). > Also, when is the ACL file re-read? If I have a system that adds new users > all the time, and each user needs a separate ACL rule, how can that be > expressed? You can use the management module to reload the ACL file. However this could affect the performance as the file is going to be huge. You will likely need to add,delete,modify user privileges, each time requiring a reload. So given your situation, I don't think using the file based approach is a good idea. You might have to write a custom module. Below are some options. 1.) A fragmented ACL file. So when you add a new user you only read the fragment that was modified, instead of reloading all million entries. 2.) You have a custom ACL model which gets updated via a 3rd party system using a simple RPC call. Ex addUser(...) which add/delete/modify a user in the memory structures contained within the ACL abstraction in the broker. 3.) Another option is to partition your users among your broker instances. That would likely require a load balancing/routing mechanism (for your connections) which has explicit knowledge about how you have partitioned your users. Your use case is very interesting. Please keep us posted with your progress. > > Sincerely, > > jw > > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. Nevertheless, > whether we get there willingly or not, we shall soon have lower consumption > rates, because our present rates are unsustainable. > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
