Hello,
I have an application with a limited memory size. I run with persistence
on. There are times when a long running consumer transaction will cause all
memory to be consumed in the broker. This eventually leads to Producer
blockage (or error -- I've sometimes configured it that way). Since
We're running 5.3.1 in production, and 5.4.1 in test. We're seeing different
behaviors related to properties and selectors in queues between the 2
versions.
In 5.3.1, if we have a message in a queue that does not have an active
consumer because of it's properties and the selectors of current cons
the jms clientId needs to be unique, only one connection with a given
id will be allowed.
you can define the prefix for a connection id via the clientIDPrefix
property. So tcp://xx:port?jms.clientIDPrefix="ID:myProject.".
The default value for the prefix is "ID: so it would be good
to keep the hos
Hi every body
I would want to be able to easily identify each of my TCP distant connection
to my brokers without having to program anything on the client side.
I imagine using the jms.clientId on the client side with
"tcp://myhost:?jms.clientID=myProject" as the connection URL, and
catching
The information in this e-mail is intended only for the person or entity to
which it is addressed.
It may contain confidential and /or privileged material. If someone other than
the intended recipient should receive this e-mail, he / she shall not be
entitle
I'm currently inspecting the depth of message queues using JMX calls. It
seems that it should be possible to do this using the Java API as well. Is
this possible and if so how?
Thanks for any info.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Inspecting-queue-depth-w
I am using ActiveMQ as an embedded broker, I have everything setup and I'm
able to receive messages from an external client to my message driven bean.
The problem I am having is injecting resources from a session bean for the
connection factory and messge queue. Glassfish is not able to resolve t
Interesting, the prefix "ID:" denotes a temp queue, it is generated
from the default connection id scheme. The consumer is doing a check
based on the connection id, it throws the exception because foo does
not match the auto generated connection id.
>From the code, it looks like there is a way aro
thanks, that's true I totally forgot that.
On Wed, Mar 23, 2011 at 12:57 PM, Dejan Bosanac wrote:
> Hi Daniele,
>
> note that activemq-security.xml also uses encrypted passwords (
> http://activemq.apache.org/encrypted-passwords.html) so you need to do
> something like
>
> export ACTIVEMQ_ENCRYP
Hi Daniele,
note that activemq-security.xml also uses encrypted passwords (
http://activemq.apache.org/encrypted-passwords.html) so you need to do
something like
export ACTIVEMQ_ENCRYPTION_PASSWORD=activemq
before you start the broker.
It's all explained in the file header
Regards
--
Dejan Bo
I add some precious information.
The behavior is the same also with the original activemq-security.xml.
I'm running AMQ 5.4.2, java 1.6.0_20 on a Ubuntu 10.10 server 2.6.32.
On Wed, Mar 23, 2011 at 12:20 PM, Daniele Dellafiore wrote:
> Hi. I was succesfull in making AMQ working with the
> 1. rem
Hi. I was succesfull in making AMQ working with the
1. removed simple-authentication and used jaas plugin instead, in the
default activemq-security.xml.Tthe rest of the config file is unaltered.
2. a login.info that used properties files for users and groups, in the
/conf folder.
3. users.propertie
Hi Gary,
On Tue, Mar 22, 2011 at 5:16 PM, Gary Tully [via ActiveMQ]
wrote:
> The test needs some mods to ensure that the slave broker listen port
> is only started when the broker becomes the baster.
>
> In code, the addition of the transportConnector needs to be:
>
> // lazy create trans
13 matches
Mail list logo
