The reasons we need to delete were given as item 3 and 4. So will the method Andrew gave work? The method was: "add another method to AbstractRegion class, called removeDestinations(List<String> destsToRemove) that would remove destinations which match the provided names in one single acquire-release-destinations-mutex step, and thus to avoid waiting for destinationsMutex during one by one deletion of destinations. "
Regarding security, am I incorrect in thinking that giving untrusted clients the credentials to access the AMQ broker and (dynamically) create queues is a security risk? If I have thousands of clients and any hacker acquires these credentials then they can stage an attack on the AMQ. My business case is such that regular queues are the best fit, and surely other people working with AMQ, who are using regular queues widely (meaning AMQ is available over the Internet), are taking a security risk of attack with the current implementation. Am I wrong in my thinking? James.Strachan wrote: > > On 5/15/07, bhartsb <[EMAIL PROTECTED]> wrote: >> >> >> We have a couple of issues that seem to preclude using temporary queues: >> >> 1. Our C++ clients that use the queues are utilizing STOMP to do so (we >> can't afford the time to retrofit the C++ apps for openwire at this >> juncture). STOMP as I understand does not support temporary queues. >> >> 2. Our C++ clients may temporarily lose a connection to the queues, but >> reconnect quickly. In this case we don't want to lose any messages. It >> seems from posts that a loss of connection would mean that the msgs in >> the >> queues (or still being added) are lost, because the queue connection >> would >> not be re-established. (Note: if the connection is lost for a long >> period >> then we do want to create a new queue). >> >> 3. We have our server telling the client applications, what queues to >> connect to. The Clients have no knowledge themselves of the queue they >> need >> to connect to, and it can be that a producer will connect before a >> consumer >> or vice versa. >> >> 4. We don't want client applications to be able to create queues >> themselves >> (only publish or consume). If we did allow them create/destroy >> priviledge >> then we would have to give the clients the proper JAAS credentials to >> allow >> this. But the client apps. will be in the public domain. If they have >> such >> credentials then there is a risk that a hacker could get one Client's >> credentials and gain access to the AMQ broker. This leaves the AMQ >> vulnerable to attack. This is not a risk we want to take. >> >> Now if I am wrong about 4 being a security/attack risk, then we could >> have >> the server pass the temporary queue name to the producer and consumer >> apps. >> But am I wrong? >> >> Finally, you mentioned to Andrew that AMQ queues are dynamic, but I don't >> see this as being the case if they can't be programatically deleted. I >> assume you weren't just talking about temporary queues when you said >> queues >> are dynamic. > > Any messaging client can talk to any new dynamic destination whenever > they like (assuming the security allows this) - there is no > administration required to create a queue - thats why I said they were > dynamic. > >> Please respond if you can to this and Andrews' prior question about his >> method of deleting queues (see his last post), and thank you. > > So i still don't get why you insist on deleting queues, rather than > just purging them. > > -- > James > ------- > http://macstrac.blogspot.com/ > > -- View this message in context: http://www.nabble.com/Correct-way-to-removeDestinations%28%29-tf3732843s2354.html#a10630854 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
