activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Correct way to removeDestinations()
Date Tue, 15 May 2007 10:03:54 GMT
On 5/15/07, bhartsb <> 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

> 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.


View raw message