ActiveMQMessageStore in comparison to HighPerformanceJournal of AMQ4
Hi, some short questions on the amq message store.. Is it an enhancement of the HighPerformance Journal of the amq4x versions? Is it faster then the (Howl - like) HighPerformance Journal of amq4? Can I couple a database to it, so after a delay messages are persisted to oracle for example? I think this is not the approach of the amq message store and the configuration doesn't give me the possibility to connect JDBC... So this is only a file based solution? Best regards, Matthias -- View this message in context: http://www.nabble.com/ActiveMQMessageStore-in-comparison-to-HighPerformanceJournal-of-AMQ4-tp15607234s2354p15607234.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
org.apache.activemq Queue mbean doesn't work anymore after brokerService stop/start
Hi, I have a problem with the information about queues, given by the mbeans. We are using on of the latest snapshots of activemq5.1 I am doing the following: 1.) start embedded broker 2.) initialize connection and session 3.) init producer to a queue 4.) send messages to queue 5.) consume messages from queue I can follow all those steps with the org.apache.activemq Queue mbean. The information is correct and the counters work. 6.) close the connection and the broker Now in the same application I: 7.) start another embedded broker 8.) initialize another connection (with the same clientID) and session 3.) init another producer to the same destination as above. 4.) send messages 5.) consume messages from the same destination as above. My problem is that the mbean doesn't give me the correct information now. The counters don't work anymore (ConsumerCount, ProducerCount, QueueSize..). The messaging itself works (producing/consuming)! This looks like a bug for us.. Maybe there are any static fields that cause this behaviour? (Because we are still in the same VM.) It would be very nice if anyone could help us. Of course I can provide the source code, but it is a very simple approach. Regards, Matthias -- View this message in context: http://www.nabble.com/org.apache.activemq-Queue-mbean-doesn%27t-work-anymore-after-brokerService-stop-start-tp16118675s2354p16118675.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.1 - Re-queued msg are redelivered again after restart
Hi, in the JMS spec the following is specified: "It is possible for a listener to throw a RuntimeException; however, this is considered a client programming error. Well-behaved listeners should catch such exceptions and attempt to divert messages causing them to some form of application-specific ‘unprocessable message’ destination. The result of a listener throwing a RuntimeException depends on the session’s acknowledgment mode. • AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message will be immediately redelivered. The number of times a JMS provider will redeliver the same message before giving up is provider-dependent. The JMSRedelivered message header field will be set for a message redelivered under these circumstances" But the messages are only redelivered after restarting the broker. I also habe problems with this behaviour, becaue my colleagues are throwing RuntimExceptions into my onMessage method :-( I expected the message to be redelivered asap. What is the state about this issue? Has a jira been raised? best regards, Matthias rajdavies wrote: > > > On 29 Feb 2008, at 06:18, DinDon wrote: > >> >> Hello guys, >> >> I am new to JMS and ActiveMQ(apache- >> activemq-5.1-20080220.151243-27), and I >> have been testing ActiveMQ with SpringJMS and Jencks for a week, and >> googled >> with no luck for the following issues. >> >> - Re-queued messages only being redelivered after restarting AMQ >> - In my MessageListener.onMessage(Message message) method, I throw a >> RuntimeException() for testing redelivery. >> >> Here is the Spring Config which I followed some tutorials: >> >> > class="org.jencks.factory.TransactionManagerFactoryBean" /> >> >> > class="org.jencks.factory.ConnectionManagerFactoryBean"> >> > /> >> >> >> > class="org.apache.activemq.ra.ActiveMQResourceAdapter"> >> >> >> >> >> >> >> >> > class="org.apache.activemq.ra.ActiveMQManagedConnectionFactory"> >> >> >> >> >> >> > class="org.jencks.factory.ConnectionFactoryFactoryBean"> >> > ref="jmsManagedConnectionFactory" /> >> >> >> >> > class="org.springframework.jms.core.JmsTemplate"> >> >> >> >> >> >> > depends-on="jmsConnectionFactory"> >> > /> >> >> >> >> >> > class="com.ifshk.pms.jms.MailingQueueMessageListener" /> >> >> > >> class >> ="org.springframework.jms.listener.DefaultMessageListenerContainer" >> lazy-init="false"> >> >> > /> >> > ref="mailingQueueMessageListener" /> >> > /> >> >> >> >> >> >> Initially, I used inboundConnectorA for receiving Message, but it >> seems >> jencks doesn't rollback a message automatically when an exception >> occurs. So >> I switched to DefaultMessageListenerContainer, and rollback does >> work but >> the re-queued messages only being redelivered again after I restart >> AMQ, and >> those messages never be marked as DEAD and sent to a dead queue. >> >> Please advice. >> >> Thanks a lot & regards, >> -- >> View this message in context: >> http://www.nabble.com/AMQ-5.1---Re-queued-msg-are-redelivered-again-after-restart-tp15752828s2354p15752828.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> > > Odd - best raise a jira! > > -- View this message in context: http://www.nabble.com/AMQ-5.1---Re-queued-msg-are-redelivered-again-after-restart-tp15752828s2354p16254960.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
performance of the different amq persistence solutions
Hi,
we have a performance problem with ActiveMQ 5.0.0.
I wrote a simple Java application that stores 5000 small object messages
into a queue.
At the same time a callback is listening on the queue and consuming the
messages.
My message broker/activeMQ is started standalone, my clients are connected
by TCP:
ConnectionFactory connectionFactory =
new ActiveMQConnectionFactory("tcp://localhost:61616");
I run this test case with the different persistence mechanisms that ActiveMQ
offers.
And I meausure the time from the first producer.send() until all 5000
messages have arrived in the callback.
This tests are driven on a Windows XP machine. And our two consumer/producer
sessions are set to Session.AUTO_ACKNOWLEDGE.
-No persistence: 1610 ms (~ 1,6 sec)
This is no option for us, we need reliable messaging and persistence.
-KAHA-Persistence/amqPersistenceAdapter: 282114 ms (~ 282 sec)
This is a complete new approach? Or is it a further development of the
Journal(based on Howl)?
Is there more information about this solution then on this website:
http://activemq.apache.org/amq-message-store.html ?
Because this could be really an option for us, but we have no idea how
robust this code is.
Our whole businesslogic communication is based on JMS
-High Performance Journal mit Derby DB: 534396 ms (~ 534 sec)
Derby is no option for us.
-JDBC Persistence (Oracle) without Journaling : 767598 ms (~ 768 sec)
-High Performance Journal mit Oracle DB: 1035774 ms (~1036 sec)
The journal is being synced into the database.
I found no description when this action takes place. We guess after some
hard coded period.
When I look at the database tables there is a big fluctuation during my
test run.
It seems that every message is written into the DB and then dropped
again.
We expected that when we consume the messages very fast they will not be
synced into the database, because they are consumed before the checkpoint.
Has anybody experience with this? Is this configurable?
Because this seems to slow down the "High Performance Journal with long
term persistence storage" solution.
Of course the message broker is stressed when a lot of messages are written
and consumed at the same time.
When I first write all 5000 messages and then afterwards open the callback
every solution is very fast...
maybe someone has experience with the checkpointing from journal to long
term persistence..
bye,
m.
--
View this message in context:
http://www.nabble.com/performance-of-the-different-amq-persistence-solutions-tp16850213s2354p16850213.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
configuring the BrokerFactory, not using xbean
Hi, we want to use activemq for the messaging in our system. and we want to start it embedded(for performance reasons) with the BrokerFactory. But we don't want to use xbean to configure the broker, because we don't want the spring jars inside our classpaths only for reading a configuration. We are using version 4.1.1, the stable release. (By the way, when will version 4.2 be ready?) On this website: http://activemq.apache.org/how-do-i-embed-a-broker-inside-a-connection.html there is a description "Using the BrokerFactory" where it should be possible to use "file:" for the URI scheme. Maybe (hopefully) I misunderstood something, but this doesn't work. When I look inside the activemq code the FactoryFinder class looks up the URI scheme inside the jar file: META-INF/services/org/apache/activemq/broker/ But there is no property file for the "file" scheme. We want to configure our activemq broker to use our oracle database. Is there a way to start a BrokerService and configure this with the Java API? Or do I need a config file for specifying the database settings? And is there a way to read activemq.xml without using the spring framework?` It would be very nice if someone could help me Thank you very much!! Regards, m.b. -- View this message in context: http://www.nabble.com/configuring-the-BrokerFactory%2C-not-using-xbean-tf4575284s2354.html#a13059502 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
receiving old messages when restartin embedded broker - problem with persistence/auto_acknowledge?
Hello,
we are facing a strange problem.
I am running an embedded broker in my unit test:
URI activemqConfigurationUri = new
URI("xbean:conf/activemq.xml");
brokerService =
BrokerFactory.createBroker(activemqConfigurationUri);
brokerService.start();
I have 2 connections/sessions, from every session I create a customer to a
topic:
connection1 = connectionFactory.createConnection();
connection1.setClientID("1stID");
connection1.start();
session1 =
connection1.createSession(false,Session.AUTO_ACKNOWLEDGE);
MessageConsumer consumer1 = ((TopicSession)
session1).createDurableSubscriber((Topic) destination, subscriberName);
connection2 = connectionFactory.createConnection();
connection2.setClientID("2ndID");
connection2.start();
session2 =
connection2.createSession(false,Session.AUTO_ACKNOWLEDGE);
MessageConsumer consumer2 = ((TopicSession)
session2).createDurableSubscriber(
(Topic) destination, subscriberName);
>From a third session I create a producer and send 2 messages to the topic:
producerConnection = connectionFactory.createConnection();
producerConnection.setClientID("producer");
producerConnection.start();
producerSession =
producerConnection.createSession(false,Session.AUTO_ACKNOWLEDGE);
producer = producerSession.createProducer(destination);
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
producer.setTimeToLive(30);
javax.jms.Message msg1 =
producerSession.createObjectMessage(message1);
javax.jms.Message msg2 =
producerSession.createObjectMessage(message2);
producer.send(msg1,DeliveryMode.PERSISTENT ,
Message.DEFAULT_PRIORITY,
Message.DEFAULT_TIME_TO_LIVE);
producer.send(msg2,DeliveryMode.PERSISTENT ,
Message.DEFAULT_PRIORITY,
Message.DEFAULT_TIME_TO_LIVE);
Then I receive the 2 messages with my consumers (every consumer is receiving
2 messages):
Message msg1 = consumer1.receive(3000);
while(msg1!=null){
Object object = ((ObjectMessage)msg1).getObject();
msg1 = consumer1.receive(3000);
}
Message msg2 = consumer2.receive(3000);
while(msg2!=null){
Object object = ((ObjectMessage)msg2).getObject();
msg2 = consumer2.receive(3000);
}
I close the consumers:
consumer1.close();
consumer2.close();
And again I send 2 messages.
I close all connections and the embedded broker.
The next time I run the unittest the first consumer gets 4 messages, as
expected.
The second consumer gets 6 messages! It gets all messages that were
produced, all the time.
We're using activemq 4.1.1
When we are not running an embedded broker but an standalone broker, a
separate process, everything
is Ok as long we don't stop and restart the broker. After restarting the
second consumer again receives all the messages
the first time it calls consumer.receive(). Then the second time it receives
4 messages.
I guess there is something wrong with the persistence to the database. When
we're using our oracle I can query ACTIVMQ_ACKS.
There my 2 CLIENT_IDs are listed. And the LAST_ACKED_ID only changes for one
of the CLIENT_IDs.
Can anybody help me?
I didn't find the same problem in the forum, only alike problems:
http://www.nabble.com/-activemq-user--Re%3A-receiving-old-messages-again-after-restart-tf95738s2354.html#a265691
Regards,
Matthias
--
View this message in context:
http://www.nabble.com/receiving-old-messages-when-restartin-embedded-broker---problem-with-persistence-auto_acknowledge--tf4634882s2354.html#a13235838
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: receiving old messages when restartin embedded broker - problem with persistence/auto_acknowledge?
We solved the problem.
I debugged the activeMq code and somewhere deep in the "DefaultJDBCAdapter"
I found a batchedStatements boolean. When I insert the following snippet in
the activemq.xml
the boolean is set to false and all statements are correctly persisted:
Of course, in your persistence adapter you have to reference the db-adapter
bean:
I don't exactly know the effect of turning off batched statements, but for
my testing it is Ok at the moment. Maybe we have lost some performance now..
When we really start to use activeMQ in our system I'll have to investigate
further ..
krv wrote:
>
> I had encountered the same problem. I had a sender and a receiver which
> were running on Tomcat server. Whenever I restarted the receiver I used to
> get all the messages that I had earlier to the message broker and which
> had been processed.
>
> The only difference my code has than your code was that I am using a
> MessageListener.onMessage(Message) rather than Consumer.receive().
>
> After some investigation I found out that my code had caused the problem.
> When I had called a method in my code it encountered some exception and
> the control never returned to the MessageListener (the receiver) and hence
> the ActiveMQ session never got committed. And hence the message was never
> dequed from the queue.
>
> I am not sure if your problem is the same, but you can try the following:
> * Commit the session just after you receive the message
> * Acknowledge the message: message.acknowledge()
>
> Let me know how it goes.
>
>
> spiiff wrote:
>>
>> Hello,
>> we are facing a strange problem.
>> I am running an embedded broker in my unit test:
>>
>> URI activemqConfigurationUri = new
>> URI("xbean:conf/activemq.xml");
>> brokerService =
>> BrokerFactory.createBroker(activemqConfigurationUri);
>>
>> brokerService.start();
>>
>>
>> I have 2 connections/sessions, from every session I create a customer to
>> a topic:
>>
>> connection1 = connectionFactory.createConnection();
>> connection1.setClientID("1stID");
>> connection1.start();
>> session1 =
>> connection1.createSession(false,Session.AUTO_ACKNOWLEDGE);
>> MessageConsumer consumer1 = ((TopicSession)
>> session1).createDurableSubscriber((Topic) destination, subscriberName);
>>
>>
>> connection2 = connectionFactory.createConnection();
>> connection2.setClientID("2ndID");
>> connection2.start();
>> session2 =
>> connection2.createSession(false,Session.AUTO_ACKNOWLEDGE);
>> MessageConsumer consumer2 = ((TopicSession)
>> session2).createDurableSubscriber(
>>(Topic) destination, subscriberName);
>>
>>
>> From a third session I create a producer and send 2 messages to the
>> topic:
>>
>> producerConnection = connectionFactory.createConnection();
>> producerConnection.setClientID("producer");
>> producerConnection.start();
>> producerSession =
>> producerConnection.createSession(false,Session.AUTO_ACKNOWLEDGE);
>>
>> producer = producerSession.createProducer(destination);
>>
>> producer.setDeliveryMode(DeliveryMode.PERSISTENT);
>> producer.setTimeToLive(30);
>>
>>
>> javax.jms.Message msg1 =
>> producerSession.createObjectMessage(message1);
>> javax.jms.Message msg2 =
>> producerSession.createObjectMessage(message2);
>> producer.send(msg1,DeliveryMode.PERSISTENT ,
>> Message.DEFAULT_PRIORITY,
>> Message.DEFAULT_TIME_TO_LIVE);
>> producer.send(msg2,DeliveryMode.PERSISTENT ,
>> Message.DEFAULT_PRIORITY,
>>Message.DEFAULT_TIME_TO_LIVE);
>>
>>
>> Then I receive the 2 messages with my consumers (every consumer is
>> receiving 2 messages):
>>
>> Message msg1 = consumer1.receive(3000);
>> while(msg1!=null){
>> Object object = ((ObjectMessage)msg1).getObject();
>>
>> msg1 = consumer1.receive(
Re: receiving old messages when restartin embedded broker - problem with persistence/auto_acknowledge?
Turning off the batchedStatements did not really solve the problem.
Here is a bug description (from Jul 04, 2006 ! ):
http://www.nabble.com/Is-this-a-bug-in-DefaultJDBCAdapter.java--tf1890445s2354.html#a5168977
I think this was the reason for our problem..
With this correction in the DefaultJDBCAdapter.doSetLastAck() :
PreparedStatement s=c.getUpdateLastAckStatement();
//c.getAddMessageStatement();
our code works as expected...
Why was this bug not solved before?
Will it be solved with version 4.2?
Is this bug already tracked somewhere? How can I check this?
regards,
m.
spiiff wrote:
>
> We solved the problem.
> I debugged the activeMq code and somewhere deep in the
> "DefaultJDBCAdapter" I found a batchedStatements boolean. When I insert
> the following snippet in the activemq.xml
> the boolean is set to false and all statements are correctly persisted:
>
>class="org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter">
>
>
>
> Of course, in your persistence adapter you have to reference the
> db-adapter bean:
>
>
>createTablesOnStartup="true" dataSource="#oracle-ds" adapter="#db-adapter"
> />
>
>
>
> I don't exactly know the effect of turning off batched statements, but for
> my testing it is Ok at the moment. Maybe we have lost some performance
> now.. When we really start to use activeMQ in our system I'll have to
> investigate further ..
>
>
>
> krv wrote:
>>
>> I had encountered the same problem. I had a sender and a receiver which
>> were running on Tomcat server. Whenever I restarted the receiver I used
>> to get all the messages that I had earlier to the message broker and
>> which had been processed.
>>
>> The only difference my code has than your code was that I am using a
>> MessageListener.onMessage(Message) rather than Consumer.receive().
>>
>> After some investigation I found out that my code had caused the
>> problem. When I had called a method in my code it encountered some
>> exception and the control never returned to the MessageListener (the
>> receiver) and hence the ActiveMQ session never got committed. And hence
>> the message was never dequed from the queue.
>>
>> I am not sure if your problem is the same, but you can try the following:
>> * Commit the session just after you receive the message
>> * Acknowledge the message: message.acknowledge()
>>
>> Let me know how it goes.
>>
>>
>> spiiff wrote:
>>>
>>> Hello,
>>> we are facing a strange problem.
>>> I am running an embedded broker in my unit test:
>>>
>>> URI activemqConfigurationUri = new
>>> URI("xbean:conf/activemq.xml");
>>> brokerService =
>>> BrokerFactory.createBroker(activemqConfigurationUri);
>>>
>>> brokerService.start();
>>>
>>>
>>> I have 2 connections/sessions, from every session I create a customer to
>>> a topic:
>>>
>>> connection1 = connectionFactory.createConnection();
>>> connection1.setClientID("1stID");
>>> connection1.start();
>>> session1 =
>>> connection1.createSession(false,Session.AUTO_ACKNOWLEDGE);
>>> MessageConsumer consumer1 = ((TopicSession)
>>> session1).createDurableSubscriber((Topic) destination, subscriberName);
>>>
>>>
>>> connection2 = connectionFactory.createConnection();
>>> connection2.setClientID("2ndID");
>>> connection2.start();
>>> session2 =
>>> connection2.createSession(false,Session.AUTO_ACKNOWLEDGE);
>>> MessageConsumer consumer2 = ((TopicSession)
>>> session2).createDurableSubscriber(
>>> (Topic) destination, subscriberName);
>>>
>>>
>>> From a third session I create a producer and send 2 messages to the
>>> topic:
>>>
>>> producerConnection = connectionFactory.createConnection();
>>> producerConnection.setClientID("producer");
>>> producerConnection.start();
>>> producerSession =
>>> producerConnection.createSession(false,Session.AUTO_ACKNOWLEDGE);
>>>
>>> produ
Re: receiving old messages when restartin embedded broker - problem with persistence/auto_acknowledge?
Hi Henning, we are using the latest stable version: apache-activemq-4.1.1 and an oracle database. But in the newest unstable version (5x) the DefaultJDBCDAdapter class still has this bug inside. If you have the source code of 3.2.2 available you can check the method .doSetLastAck() inside the DefaultJDBCDAdapter class. It was not very complicated for us to reproduce this problem. It's important that you use durable subscriptions: MessageConsumer consumer = ((TopicSession) session).createDurableSubscriber( (Topic) destination, subscriberName); You create some consumers and one producer, send some messages and receive them, close (not unsubscribe) the consumers. Send some messages again. Close the producer. Close the sessions. Shut down the broker. (We're using an embedded one, very nice for unittests). If you start the test again one consumer gets the correct messages, the other one gets them all. To better understand the behaviour look inside the database table ACTIVEMQ_ACKS and watch the LAST_ACKED_ID. After shutdown, only one is updated.. bye, m. Henning Sprang wrote: > > Hi Matthias, > > spiiff wrote: >> Turning off the batchedStatements did not really solve the problem. >> Here is a bug description (from Jul 04, 2006 ! ): >> http://www.nabble.com/Is-this-a-bug-in-DefaultJDBCAdapter.java--tf1890445s2354.html#a5168977 >> I think this was the reason for our problem.. >> >> With this correction in the DefaultJDBCAdapter.doSetLastAck() : >> PreparedStatement s=c.getUpdateLastAckStatement(); >> //c.getAddMessageStatement(); >> our code works as expected... >> >> Why was this bug not solved before? >> Will it be solved with version 4.2? >> Is this bug already tracked somewhere? How can I check this? > > > It seems I am hit by the very same problem - I didn't find your post > because I rather searched for "resend", "resent" and such things, but > not receieving old messages. > So I also asked a question about similar effects some days a go, but got > no reply. > > I wonder, in which version do you have these effects(I have 3.2.2), and > with which database? > > I am still not able to reproduce the problem - it only happened to us in > production, but i don't get it happening on purpose - the very first > step I need to fulfil before trying any fixes. I tried your code (adding > some complettion to the fragments you sent here), aqnd an own test case, > but until now, I only get all messages exactly once - no resending after > the restart of the broker. > > Thanks in advance, > Henning > > > > > -- View this message in context: http://www.nabble.com/receiving-old-messages-when-restartin-embedded-broker---problem-with-persistence-auto_acknowledge--tf4634882s2354.html#a13426448 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
configure checkpoint interval?
Hi, can anybody tell me how to configure the checkpoint interval? I was searching the website and the forum and I found nothing. Is it somewhere in the API? Regards, Matthias -- View this message in context: http://www.nabble.com/configure-checkpoint-interval--tf4713523s2354.html#a13473498 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
message expiration
Hi, one question about the message expiration in combination with topics. I know how to configure the time-to-live. A message first resides inside the journal. After the checkpointing(how to configure checkpointing??), it is persisted in a database (if JDBC is configured). If the time-to-live is specified as zero the message does not expire. If the message does not expire, will it never be dropped out of the database? How are the rules? If you are using durable subscription and set the "time to live" to maybe 10 seconds and the consumer is active after 20 seconds again, then the consumer will not receive the message, because it was dropped already.. ( I tried this in my UnitTest) We thought a message is dropped out of the activemq persistence if it is received by the consumer(s). We have to make sure the consumers really receive the messages. But if we set time-to-live to zero, then our database will explode. Regards, Matthias -- View this message in context: http://www.nabble.com/message-expiration-tf4713621s2354.html#a13473823 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: message expiration
So we checked this ourselves, of course the messages are dropped out of the
activemq persistence if they are received by the consumer(s). It is
configurable in which time frame consumed messages will be dropped. And
after checkpointing the journal to the database consumed messages are also
dropped.
But in this case:
if (longTermPersistence instanceof JDBCPersistenceAdapter) {
// Disabled periodic clean up as it deadlocks with the
checkpoint
// operations.
((JDBCPersistenceAdapter)
longTermPersistence).setCleanupPeriod(0);
}
( from class JournalPersistenceAdapter)
the periodic clean up is disabled and the database is cleaned only during
checkpoint operation (I guess...)
spiiff wrote:
>
> Hi,
> one question about the message expiration in combination with topics.
> I know how to configure the time-to-live.
>
> A message first resides inside the journal. After the checkpointing(how to
> configure checkpointing??), it is persisted in a database (if JDBC is
> configured).
>
> If the time-to-live is specified as zero the message does not expire.
> If the message does not expire, will it never be dropped out of the
> database?
>
> How are the rules?
>
> If you are using durable subscription and set the "time to live" to maybe
> 10 seconds and the consumer is active after 20 seconds again, then the
> consumer will not receive the message, because it was dropped already.. (
> I tried this in my UnitTest)
>
>
> We thought a message is dropped out of the activemq persistence if it is
> received by the consumer(s). We have to make sure the consumers really
> receive the messages. But if we set time-to-live to zero, then our
> database will explode.
>
> Regards,
> Matthias
>
--
View this message in context:
http://www.nabble.com/message-expiration-tf4713621s2354.html#a13590816
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Got minus one from a read call
Hi, we're facing nearly the same problem I think... Here is my stack trace: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService' defined in class path resource [activemq.xml]: Invocation of init method failed; nested exception is java.io.IOException: Cannot create PoolableConnectionFactory (I/O Exception: Got minus one from a read call) Caused by: java.io.IOException: Cannot create PoolableConnectionFactory (I/O Exception: Got minus one from a read call) at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:45) at org.apache.activemq.store.jdbc.TransactionContext.getConnection(TransactionContext.java:61) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.createAdapter(JDBCPersistenceAdapter.java:294) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getAdapter(JDBCPersistenceAdapter.java:249) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:155) at org.apache.activemq.store.journal.JournalPersistenceAdapter.start(JournalPersistenceAdapter.java:225) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1448) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:1400) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:513) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:422) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:46) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1201) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:287) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:64) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:52) at org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:91) at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:51) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54) at activemqtest.ActivemqJunit.testFoobar(ActivemqJunit.java:90) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.apache.commons.dbcp.SQLNeste
