Hello all
I've been getting a few queries about this issue from various people
off-list, so I thought I'd reply here with some useful ideas for future
generations struggling with this issue.
My advice:
If I remember correctly, you should check your Spring XML, the ActiveMQ
schema and the sc
Are you using the high performance disk journal?
On 21/11/2007, Erlend Aakre <[EMAIL PROTECTED]> wrote:
I changed the persistenceAdapter to JDBC and a mysql database and
user has
been set up (tables has been automatically generated). But when I add
messages to the queue nothing is saved in
What does your producer code look like?
On 21/11/2007, Erlend Aakre <[EMAIL PROTECTED]> wrote:
>
> I changed the persistenceAdapter to JDBC and a mysql database and user has
> been set up (tables has been automatically generated). But when I add
> messages to the queue nothing is saved in the data
I changed the persistenceAdapter to JDBC and a mysql database and user has
been set up (tables has been automatically generated). But when I add
messages to the queue nothing is saved in the database.
The messages can be retrieved OK from the queue, but are not saved when
added, or when activemq
James,
I use the following to create the destinations when starting the broker:
public void startBroker() throws Exception {
BrokerService broker = new BrokerService();
ActiveMQQueue d1 = (ActiveMQQueue)
ActiveMQDestination.createDestination("Consumer.module1.VirtualTopic.mytopic",
Activ
BTW are you positive that the consumer queues are actually created in
each of the test cases you're doing? i.e. when you start/stop the
broker are they created up front before you send any messages? If not
you might wanna use this...
http://activemq.apache.org/configure-startup-destinations.html
I have a problem with VirtualTopics and persistency.
Consider the following setup:
I have a producer which produces messages to virtualtopic:
VirtualTopic.mytopic
I have a manager with an embedded broker and two statically defined queues:
Consumer.module1.VirtualTopic.mytopic and
Consumer.module
I registered on JIRA and submitetd AMQCPP-155 Nate...
nmittler wrote:
>
> Hi John,
> That sounds like the correct use case. Even if it wasn't, it
> shouldn't core dump :)
>
> Would you mind capturing this in a JIRA issue
> (http://issues.apache.org/activemq/browse/AMQCPP
> ) and attachin
I'm having problems with my client application, not beeing able to
send/receive messages (queue blocked) after a certain amount of messages
have been send (DeliveryMode::PERSISTENT, Session::CLIENT_ACKNOWLEDGE - all
messages get acknowledged upon receiving). Also, there seems to be problems
with m
Hi John,
That sounds like the correct use case. Even if it wasn't, it
shouldn't core dump :)
Would you mind capturing this in a JIRA issue (http://issues.apache.org/activemq/browse/AMQCPP
) and attaching a sample that causes the problem?
Thanks,
Nate
On Nov 21, 2007, at 5:52 AM, JohnOldma
Hi
Using:
CMS 2.1.1
ActiveMQ 4.1.1
SUSE 10.2
Based on the sample code, have set up a simple client/server queue, using
createSession with AUTO_ACKNOWLEDGE.
Messages appear to work as expected.
However, I want to eventually end up with a failover setup, with two
servers, and therefore need to l
On 21/11/2007, bbray <[EMAIL PROTECTED]> wrote:
>
> The BrokerService is exactly what I was looking for. I initially had trouble
> with it, but I realized looking at your example that I was mistakenly
> calling addConnector() before I called setPersistanceAdapter(). When I
> swapped them around i
The reason for master/slave is to avoid catastrophic hardware failure
loosing messages. i.e. if you loose an active broker's hardware
machine (its disk or its data centre entirely) you've lost the
messages - with Master/Slave the slave is kept in sync so has all of
the messages the master had to av
The BrokerService is exactly what I was looking for. I initially had trouble
with it, but I realized looking at your example that I was mistakenly
calling addConnector() before I called setPersistanceAdapter(). When I
swapped them around it worked great!
Thanks,
Brian
rajdavies wrote:
>
>
>
14 matches
Mail list logo