Unfortunately, we only have 6.8 available. I will see if there is anyway to
get a RHEL7 machine setup.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
-
To unsubscribe, e-mail: users-unsubscr...
Any other thoughts? It doesn't seem to be an issue on earlier versions of
glibc. Is that correct? If so, is there an OS patch or something? We may
have to abandon the qpid broker and go to something else if we can't figure
this out.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid
I ran overnight and the leak still appears to be present after setting the
MALLOC_ARENA_MAX environment variable.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
-
To unsubscribe, e-mail: users-u
Thanks. I will try it and let you know if it works.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: u
I have used the qpidd C++ broker on several projects over the years. I
started using 0.7 about 6 years ago, used 0.20 about 4 years ago, and I am
currently using 0.34. I have noticed a memory leak when running on the
system. qpidd starts out at about 10mb resident memory and the resident
memory
But how does the old "MASTER" that failed know what port to connect to as the
HelperHostPort? Is the new HelperHostPort the new "MASTER":5001 even though
the jconsole still displays it as the old "MASTER".
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-Mast
Thanks for the detailed response. In the case where my master node fails, I
can set the DesignatedPrimary flag to true in the Replica node. I see the
NodeState transition to "MASTER". In the original configuration, the
replica node was pointing to the master host's 5001 port for the
HelperHostP
We are using Java Broker .20. Would there be any reason it would not work in
.20 but may work in .22?
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-Master-Failure-and-Recovery-tp7596360p7596572.html
Sent from the Apache Qpid users mailing list archive at N
There is a DbGroupAdmin class that comes with BerkeleyDB that allows for a
master transfer. Should we use this instead of trying to set attributes on
the BDBHAMessageStore bean?
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-Master-Failure-and-Recovery-tp75
Both nodes in the cluster are running. First node comes up as Master, second
node comes up as Replica. I was trying to swap the roles with both nodes
running. I thought I would be able to tell the master to become the replica
and replica to become the master. In our production environment, we w
Keith,
I can successfully set the DesignatedPrimary attribute to true on the
passive node and nothing changes. It still thinks the original master is
the master. The NodeState attribute never changes when I toggle the
DesignatedPrimary back and forth. I also attempted to set the
DesignatedPri
Rob,
When you say the Broker will evict the messages, what exactly happens
behind the scenes? Does it evict the messages from the heap and also delete
from the Berkeley DB store? Do it evict the messages from the heap and
retain the message in the Berkeley DB store so that the peristent messa
We do persist some queues using Berkeley DB, but we don't want to persist
everything, so it sounds like we may need to start setting ttl on all of our
messages. We currently have ttl set on most of the messages but not all the
messages. Once we have it set on everything, it sounds like that shoul
Keith,
We have increased it to 2GB in the qpid-server. We could continue to
increase it, but we wanted to figure out if there was a way to get the Qpid
broker to cleanup. We are using Berkeley DB as the message store and we
only have two queues marked as durable right now. The errors I see righ
In our test environment, we bring applications up and down quite a bit.
Sometimes we will leave applications that are producing Qpid messages up for
an extended period of time and we may or may not have the Qpic client
applications up a running. When we do this, we notice that the Java Broker
wil
In your High Availability documentation for the Java Broker, section "1.6.3.2
- Depictions of cluster operation" has a section called "Master Failure and
Recovery" which describes the sequence of events for a master failover and
the replica taking over the master's role. One of the items states th
I was missing the jar. I can now see the bean in jconsole. Thanks for the
quick response.
--
View this message in context:
http://qpid.2158936.n2.nabble.com/JMX-interface-with-Java-Broker-20-tp7596278p7596329.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---
My active node's configuration looks like the following:
test
org.apache.qpid.server.store.berkeleydb.BDBHAMessageStore
${QPID_WORK}/bdbhastore/eutilrhs1
ReplicationGroup
eutilrhs1
eutilrhs1:5001
e
I was reading the "Qpid JMX API for HA" section today at
http://qpid.apache.org/releases/qpid-0.22/java-broker/book/Java-Broker-High-Availability-JMXAPI.html
and it looked like it would be fairly simple to get Berkeley DB state
infomration using the JMX Java API. I can get information from other M
I got it working. The virtualhosts.xml didn't like have multiple Berkeley DB
store entries under different environments. I put it under the test
environment only and it had no problems reloading the messages. Thanks for
the quick response. The LVQ quote was from an older C++ word document and I
It looks like Berkeley DB is storing the messages in the .jdb binary file.
When I cycle the broker, I see the following WARN messages in the log:
Message id 1 in log references queue with id
ea4Id34a-352c-329d-a877-485b02215a7b which is not in the configuration,
entry will be discarded
Message i
Is there a JMS property to set on the message to make the message durable?
In the C++ code, I found a qpid::messaging::Message.setDurable flag that
doesn't seem to be persisting the data. I am using Berkeley DB as the
message store.
--
View this message in context:
http://qpid.2158936.n2.nabb
I added the following to virtualhosts.xml
TestQueue
amq.direct
true
TestKey
true
I didn't realize the durable flag was outside fo the TestQueue element. I
moved it inside the TestQueue element and it works. Sorry for the
inconvenience.
--
View this me
I am using Qpid Java Broker .20 and I am trying to persist messages for a
last value queue. I set the "durable" flag to true cycled the broker. When
I went to the management console, I noticed that the durable flag on the
queue was still set to false. I then came across the following statement
"
We are going to use the active/passive mode of operation along with Berkeley
DB to support our high availability design. On top of that, we were
thinking of using Redhat Cluster software to monitor the two machines and
assign a virtual IP to whichever machine is the true "active".
In your Java Bro
The ruby client API we are using came with the .20 version of Qpid. Thanks
for the quick response.
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Ruby-clients-and-C-broker-tp7594086p7594097.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
--
I was looking at the "Interop table by AMQP specification version" table on
the Qpid home Page. It only has the Ruby client listed as begin compatible
with AMQP spec 0-10 and not with AMQP 1.0. Is there a configuration
parameter or makefile flag to run the C++ broker as either AMQP version.
The
27 matches
Mail list logo
