[jira] Updated: (AMQ-2962) Hanging at startup
[ https://issues.apache.org/activemq/browse/AMQ-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roelof Naude updated AMQ-2962: -- Attachment: AMQ2962.patch Patch that resolve the issue for us. This patch is ugly. Someone more knowledgeable on the order of locks may provide more insight. > Hanging at startup > -- > > Key: AMQ-2962 > URL: https://issues.apache.org/activemq/browse/AMQ-2962 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.4.1 > Environment: Fedora Core 12 > OracleSun java 1.6: > java version "1.6.0_21" > Java(TM) SE Runtime Environment (build 1.6.0_21-b06) > Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) > JBoss 4.2.3 using AMQ resource adapter. >Reporter: Roelof Naude > Attachments: amq.ra.threads.txt, AMQ2962.patch, > debug_traces_hanging.log, debug_traces_startup.log, > thread_dump_during_hang.txt > > > Noticed today the activemq was hanging during startup. Investigation revealed > that it is tied to expiration of messages at startup. The only way to recover > from this was to kill -9 the VM and delete the kahadb message store. > Further testing was done whereby message expiry time was set to longer > period. AMQ started up just fine. Another test was performed whereby: > 1. subscribe for messages > 2. send a few messages > 3. disconnect consumer > 4. send more messages (1 or 2 will do) > 5. shutdown AMQ > 6. wait for a time period exceeded the expiration time of the messages > 7. start AMQ. at this time it should be hanging > Logs and thread dumps attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQ-2965) ActiveMQ fails to start if no DNS resolution for hostname is available
[
https://issues.apache.org/activemq/browse/AMQ-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Snyder closed AMQ-2965.
-
Resolution: Fixed
Fix Version/s: 5.5.0
Fixed via revision 1028143
> ActiveMQ fails to start if no DNS resolution for hostname is available
> --
>
> Key: AMQ-2965
> URL: https://issues.apache.org/activemq/browse/AMQ-2965
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.3.0, 5.3.1, 5.3.2, 5.4.0, 5.4.1
>Reporter: Bruce Snyder
>Assignee: Bruce Snyder
> Fix For: 5.5.0
>
> Attachments: AMQ-2965-patch.txt
>
>
> ActiveMQ is installed on a physical server with two ethernet interfaces --
> the first is a 10.x.x.x network and used only for external traffic , the
> second interface is a 172.x.x.x network and is used only for internal
> (intra-cluster node) communication. ActiveMQ is configured to listen only on
> the 172.x.x.x interface. External DNS resolution exists but internal DNS
> resolution does not. While each host has a unique name, none of these names
> are resolvable. Under these circumstances, ActiveMQ fails to start up
> successfully. Below are the exceptions and stack trace:
> {panel}
> 2010-06-09 16:48:45,714 | ERROR | Failed to resolve localhost |
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:46,092 | INFO | Using Persistence Adapter:
> org.apache.activemq.store.kahadb.kahadbpersistenceadap...@47c297a3 |
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:46,928 | INFO | JMX consoles can connect to
> service:jmx:rmi://localhost:11616/jndi/rmi://localhost:1616/jmxrmi |
> org.apache.activemq.broker.jmx.ManagementContext | JMX connector
> 2010-06-09 16:48:47,036 | INFO | ActiveMQ 5.3.2 JMS Message Broker (Q01M0003)
> is starting | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:47,036 | INFO | For help or more information please see:
> http://activemq.apache.org/ | org.apache.activemq.broker.BrokerService |
> WrapperSimpleAppMain
> 2010-06-09 16:48:47,280 | WARN | could not generate unique stub |
> org.apache.activemq.util.IdGenerator | WrapperSimpleAppMain
> java.net.UnknownHostException: Q01M0003: Q01M0003
> at java.net.InetAddress.getLocalHost(Unknown Source)
> at
> org.apache.activemq.util.IdGenerator.<clinit>(IdGenerator.java:52)
>
> at
> org.apache.activemq.broker.region.RegionBroker.<clinit>(RegionBroker.java:75)
>
> at
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1734)
>
> at
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1728)
>
> at
> org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:1688)
>
> at
> org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:706)
> at
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:469)
> at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:85)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1414)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
>
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
>
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
>
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
>
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.do
[jira] Updated: (AMQ-2965) ActiveMQ fails to start if no DNS resolution for hostname is available
[
https://issues.apache.org/activemq/browse/AMQ-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Snyder updated AMQ-2965:
--
Attachment: AMQ-2965-patch.txt
> ActiveMQ fails to start if no DNS resolution for hostname is available
> --
>
> Key: AMQ-2965
> URL: https://issues.apache.org/activemq/browse/AMQ-2965
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.3.0, 5.3.1, 5.3.2, 5.4.0, 5.4.1
>Reporter: Bruce Snyder
>Assignee: Bruce Snyder
> Attachments: AMQ-2965-patch.txt
>
>
> ActiveMQ is installed on a physical server with two ethernet interfaces --
> the first is a 10.x.x.x network and used only for external traffic , the
> second interface is a 172.x.x.x network and is used only for internal
> (intra-cluster node) communication. ActiveMQ is configured to listen only on
> the 172.x.x.x interface. External DNS resolution exists but internal DNS
> resolution does not. While each host has a unique name, none of these names
> are resolvable. Under these circumstances, ActiveMQ fails to start up
> successfully. Below are the exceptions and stack trace:
> {panel}
> 2010-06-09 16:48:45,714 | ERROR | Failed to resolve localhost |
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:46,092 | INFO | Using Persistence Adapter:
> org.apache.activemq.store.kahadb.kahadbpersistenceadap...@47c297a3 |
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:46,928 | INFO | JMX consoles can connect to
> service:jmx:rmi://localhost:11616/jndi/rmi://localhost:1616/jmxrmi |
> org.apache.activemq.broker.jmx.ManagementContext | JMX connector
> 2010-06-09 16:48:47,036 | INFO | ActiveMQ 5.3.2 JMS Message Broker (Q01M0003)
> is starting | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:47,036 | INFO | For help or more information please see:
> http://activemq.apache.org/ | org.apache.activemq.broker.BrokerService |
> WrapperSimpleAppMain
> 2010-06-09 16:48:47,280 | WARN | could not generate unique stub |
> org.apache.activemq.util.IdGenerator | WrapperSimpleAppMain
> java.net.UnknownHostException: Q01M0003: Q01M0003
> at java.net.InetAddress.getLocalHost(Unknown Source)
> at
> org.apache.activemq.util.IdGenerator.<clinit>(IdGenerator.java:52)
>
> at
> org.apache.activemq.broker.region.RegionBroker.<clinit>(RegionBroker.java:75)
>
> at
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1734)
>
> at
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1728)
>
> at
> org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:1688)
>
> at
> org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:706)
> at
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:469)
> at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:85)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1414)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
>
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
>
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
>
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
>
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
>
> at
> org.springframe
[jira] Updated: (AMQ-2965) ActiveMQ fails to start if no DNS resolution for hostname is available
[
https://issues.apache.org/activemq/browse/AMQ-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Snyder updated AMQ-2965:
--
Attachment: (was: AMQ-2965.patch.txt)
> ActiveMQ fails to start if no DNS resolution for hostname is available
> --
>
> Key: AMQ-2965
> URL: https://issues.apache.org/activemq/browse/AMQ-2965
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.3.0, 5.3.1, 5.3.2, 5.4.0, 5.4.1
>Reporter: Bruce Snyder
>Assignee: Bruce Snyder
> Attachments: AMQ-2965-patch.txt
>
>
> ActiveMQ is installed on a physical server with two ethernet interfaces --
> the first is a 10.x.x.x network and used only for external traffic , the
> second interface is a 172.x.x.x network and is used only for internal
> (intra-cluster node) communication. ActiveMQ is configured to listen only on
> the 172.x.x.x interface. External DNS resolution exists but internal DNS
> resolution does not. While each host has a unique name, none of these names
> are resolvable. Under these circumstances, ActiveMQ fails to start up
> successfully. Below are the exceptions and stack trace:
> {panel}
> 2010-06-09 16:48:45,714 | ERROR | Failed to resolve localhost |
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:46,092 | INFO | Using Persistence Adapter:
> org.apache.activemq.store.kahadb.kahadbpersistenceadap...@47c297a3 |
> org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:46,928 | INFO | JMX consoles can connect to
> service:jmx:rmi://localhost:11616/jndi/rmi://localhost:1616/jmxrmi |
> org.apache.activemq.broker.jmx.ManagementContext | JMX connector
> 2010-06-09 16:48:47,036 | INFO | ActiveMQ 5.3.2 JMS Message Broker (Q01M0003)
> is starting | org.apache.activemq.broker.BrokerService | WrapperSimpleAppMain
> 2010-06-09 16:48:47,036 | INFO | For help or more information please see:
> http://activemq.apache.org/ | org.apache.activemq.broker.BrokerService |
> WrapperSimpleAppMain
> 2010-06-09 16:48:47,280 | WARN | could not generate unique stub |
> org.apache.activemq.util.IdGenerator | WrapperSimpleAppMain
> java.net.UnknownHostException: Q01M0003: Q01M0003
> at java.net.InetAddress.getLocalHost(Unknown Source)
> at
> org.apache.activemq.util.IdGenerator.<clinit>(IdGenerator.java:52)
>
> at
> org.apache.activemq.broker.region.RegionBroker.<clinit>(RegionBroker.java:75)
>
> at
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1734)
>
> at
> org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1728)
>
> at
> org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:1688)
>
> at
> org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:706)
> at
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:469)
> at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:85)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1414)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
>
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
>
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
>
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
>
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
>
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
>
> at
> org.
[jira] Commented: (AMQ-318) Allow the journal's checkpoint period to be configurable.
[
https://issues.apache.org/activemq/browse/AMQ-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62879#action_62879
]
Krishna commented on AMQ-318:
-
Looks like this is not possible in latest releases.
Could you please let me know how to configure the Journal's checkpointinterval
in the latest releases? Is it possible? Or any
workaround? We are using 5.4.0 and the config we are using is:
https://issues.apache.org/activemq/browse/AMQ-318
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Message Store
>Affects Versions: 3.0
>Reporter: Hiram Chirino
>Priority: Minor
> Fix For: 3.1
>
> Attachments: activemq.dtd.patch, JournalPersistenceAdapter.java.patch
>
>
> m...@msdservices.com reported on the user list:
> Is the journal's checkpoint periodicity configurable? Looking in
> JournalPersistenceAdapter.java, the answer appears to be no.
> I would like to request that this timing be exposed. While I am comfortable
> with 5 minutes, the people who have to administer the system I am building
> would not be.
> // Do a checkpoint periodically.
> clockTicket = getClockDaemon().executePeriodically(1000 * 60 * 5, new
> Runnable() {
> public void run() {
> checkpoint(false);
> }
> }, false);
> Matt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2736) KahaDB doesn't clean up old files
[ https://issues.apache.org/activemq/browse/AMQ-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac resolved AMQ-2736. Resolution: Fixed Fix Version/s: 5.5.0 Assignee: Dejan Bosanac That potential issue from the last comment was the false alarm. I believe that this issue should be fixed now. Please test the latest snapshot https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.5-SNAPSHOT/ and reopen if you find any problems. Thanks > KahaDB doesn't clean up old files > - > > Key: AMQ-2736 > URL: https://issues.apache.org/activemq/browse/AMQ-2736 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.2 >Reporter: Adrian Trenaman >Assignee: Dejan Bosanac >Priority: Critical > Fix For: 5.5.0 > > Attachments: AMQ-2736.zip, amq-2987-testcase.patch, amq-2987.patch, > AMQ2736Test_should_with_this_diff.txt, MyKahaDBStore.java > > > Over time, we're seeing that kahadb doesn't clean up old journal files. As a > result, we eventually run out of disk space, or rather, we hit our usage > limits and our producers are slowed down by the producer flow control > mechanism. Others have experienced this problem too (for example, see > http://mail-archives.apache.org/mod_mbox/activemq-users/201002.mbox/%3c27502591.p...@talk.nabble.com%3e) > For now, we're moving back to the old amqPersistenceStore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQCPP-204) Add the ability to package the ActiveMQ-CPP Project for distribution.
[ https://issues.apache.org/activemq/browse/AMQCPP-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62873#action_62873 ] Timothy Bish commented on AMQCPP-204: - I added an RPM spec file that can be used to create an RPM of the project on systems that employ that packaging mechanism. > Add the ability to package the ActiveMQ-CPP Project for distribution. > - > > Key: AMQCPP-204 > URL: https://issues.apache.org/activemq/browse/AMQCPP-204 > Project: ActiveMQ C++ Client > Issue Type: Improvement > Components: CMS Impl >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 3.3.0 > > > Add the tooling needed to package the library for release to various OS > packaging sites. > RPM, DEB, PKG, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AMQCPP-322) Found memory leaks in ActiveMQCPP
[ https://issues.apache.org/activemq/browse/AMQCPP-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQCPP-322. --- Resolution: Cannot Reproduce Working through some of the locations that are shown here I've not been able to find any that actually leak, the memory is released as expected. I think the leak tracker being used is confused by the smart pointers and loses track of the memory allocation / deallocation points. Older versions of valgrind had similar issues. > Found memory leaks in ActiveMQCPP > - > > Key: AMQCPP-322 > URL: https://issues.apache.org/activemq/browse/AMQCPP-322 > Project: ActiveMQ C++ Client > Issue Type: Bug >Affects Versions: 3.2.3 > Environment: Windows xp service pack 3, ActiveMQ broker 5.3.1, apr > 1.4.2, apr-util 1.3.9, apr iconv 1.2.1 >Reporter: Helen Huang >Assignee: Timothy Bish > Fix For: 3.2.4 > > Attachments: ActiveMQCPP-Memory-Leaks.zip, Memory Leaks.xml, > MemoryLeaks1.JPG, MemoryLeaks2.JPG, MemoryLeaks3.JPG > > > We found a large number of memory leaks in ActiveMQCPP and APR while we ran > DevPartner error detection. We are wondering if you can fix them in branch > 3.2.4? Thank you very much for your help in advance! > We saved a copy of the error detection report. Attached please find the file. > Also we did restart the message broker during our test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3004) Build-up of unwanted messages
[
https://issues.apache.org/activemq/browse/AMQ-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roelof Naude updated AMQ-3004:
--
Component/s: Broker
> Build-up of unwanted messages
> -
>
> Key: AMQ-3004
> URL: https://issues.apache.org/activemq/browse/AMQ-3004
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.4.1
>Reporter: Roelof Naude
>
> One of our installations have several consumers. These consumers subscribe
> for messages from a queue linked to a virtual topic. All consumers supply a
> selector. Some consumers connect, process any persisted messages, then
> disconnect. These connect/disconnect cycles are repeated a few times a day.
> What we've seen is that messages build-up for consumers. These messages does
> not match the supplied selector. The side effect of this was that we ran into
> a situation whereby message "got stuck". Increasing the _maxPageSize_
> property helped. This is unfortunately a short term solution.
> A simple test was constructed whereby *selectorAware* was set to *true*:
> {code:xml}
>
>selectorAware="true"/>
>
> {code}
> What we noticed is that:
> # Messages are correctly received by a connected consumer
> # A consumer that connects, disconnects and re-connects later will loose any
> messages that were send in the time period it was disconnected.
> This behaviour was unexpected. From the AMQ documention
> (http://activemq.apache.org/virtual-destinations.html):
> {quote}
> From version 5.4, dispatch from virtual topics to subscription queues can be
> selectorAware such that only messages that match one of the existing
> subscribers are actually dispatched. Using this option prevents the build up
> of unmatched messages when selectors are used by exclusive consumers
> {quote}
> Note: it does not state that the consumer needs to be connected for this
> feature to work.
> Given the test it looks like subscriptions itself are not persisted, thus the
> AMQ broker has no idea that it should enqueue a message for a particular
> subscription queue.
> Would it be possible to add either of:
> # Persist subscription detail, specifically for the case where the
> subscription's selector should be applied to the subscription queue
> # Propagate selectors and the attached subscription queue to the top-level
> virtual topic so that only interested messages can be delivered to the
> intended recipient?
> Anything else we can try, supply or help with?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-3004) Build-up of unwanted messages
Build-up of unwanted messages
-
Key: AMQ-3004
URL: https://issues.apache.org/activemq/browse/AMQ-3004
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.4.1
Reporter: Roelof Naude
One of our installations have several consumers. These consumers subscribe for
messages from a queue linked to a virtual topic. All consumers supply a
selector. Some consumers connect, process any persisted messages, then
disconnect. These connect/disconnect cycles are repeated a few times a day.
What we've seen is that messages build-up for consumers. These messages does
not match the supplied selector. The side effect of this was that we ran into a
situation whereby message "got stuck". Increasing the _maxPageSize_ property
helped. This is unfortunately a short term solution.
A simple test was constructed whereby *selectorAware* was set to *true*:
{code:xml}
{code}
What we noticed is that:
# Messages are correctly received by a connected consumer
# A consumer that connects, disconnects and re-connects later will loose any
messages that were send in the time period it was disconnected.
This behaviour was unexpected. From the AMQ documention
(http://activemq.apache.org/virtual-destinations.html):
{quote}
>From version 5.4, dispatch from virtual topics to subscription queues can be
>selectorAware such that only messages that match one of the existing
>subscribers are actually dispatched. Using this option prevents the build up
>of unmatched messages when selectors are used by exclusive consumers
{quote}
Note: it does not state that the consumer needs to be connected for this
feature to work.
Given the test it looks like subscriptions itself are not persisted, thus the
AMQ broker has no idea that it should enqueue a message for a particular
subscription queue.
Would it be possible to add either of:
# Persist subscription detail, specifically for the case where the
subscription's selector should be applied to the subscription queue
# Propagate selectors and the attached subscription queue to the top-level
virtual topic so that only interested messages can be delivered to the intended
recipient?
Anything else we can try, supply or help with?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2584) Massege store is not cleaned when durable topic subscribers are refusing messages
[
https://issues.apache.org/activemq/browse/AMQ-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-2584.
-
Resolution: Fixed
Fix Version/s: (was: 5.4.1)
5.5.0
A workaround for this issue, where the DLQ can receive duplicates, is to
disable the cursor message audit for the DLQ.
{code}{code}
An enhancement, to allow a DLQ per durable subscription would make it possible
to track which durable subscription rejected a message on an individual basis:
https://issues.apache.org/activemq/browse/AMQ-3003
> Massege store is not cleaned when durable topic subscribers are refusing
> messages
> --
>
> Key: AMQ-2584
> URL: https://issues.apache.org/activemq/browse/AMQ-2584
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
>Affects Versions: 5.3.0, 5.3.1, 5.4.0
> Environment: WinXP,
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)
>Reporter: Juraj Kuruc
>Assignee: Gary Tully
> Fix For: 5.5.0
>
> Attachments: 2584_test.zip, AMQ2584Test.java, AMQ2584Test.java,
> UpdatedTestCase.patch
>
>
> Hi,
> i am using activemq 5.3 (resp. 5.4 snapshot , 5.3.1 snapshot) with kahadb in
> following use-case:
> - 3 durable topic subscriber, each refuses message using session.recover(), 1
> delivery attempts
> - ActiveMQ.DLQ consumer
> - persistent message topic producer
> In such case deadletter consumer should consume every message sent, as soon
> as number of delivery attempts is reached and mmessage is sent to
> ActiveMQ.DLQ. Result is ok but kahadb data directory at the end contains all
> log files with names db-.log ever created. They aren't deleted even
> after some time.
> I can also see following massege in console:
> WARN | Duplicate message add attempt rejected. Message id:
> ID:sk1d069c-3826-1264006781626
> -0:0:1:1:13425
> If use-case is altered to use queue instead of topic log files are
> periodically deleted without WARN messages in console.
> Same behaviour (data files not cleaned) if amqPersistenceAdapter is used
> except of WARN messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-3003) Allow the option of a DLQ per durable subscription DeadLetterStrategy
Allow the option of a DLQ per durable subscription DeadLetterStrategy - Key: AMQ-3003 URL: https://issues.apache.org/activemq/browse/AMQ-3003 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.4.1 Reporter: Gary Tully Fix For: 5.5.0 >From https://issues.apache.org/activemq/browse/AMQ-2584 - with durable >subscriptions sharing the DLQ there will be duplicate sends to the dlq if more >than one durable sub rejects the message. These durables are suppressed provided they are not already acked, in which case the duplicate can hang about. The audit=false option for the DLQ works around this, but it begs the question, can I know which durable subscription refused a message. To facilitate this, having a DLQ pre durable sub is a nice option. It can use the clientId and subscriberName as the postfix, so ACTIVEMQ_DLQ.ClientId-SubscriberName - If the subscriber changes subsequent messages can go do a different DLQ. These destinations would need to be manually deleted when no longer needed. This will require additional methods in org.apache.activemq.broker.region.policy.DeadLetterStrategy so will need to a version update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3002) activemq-security.xml plugin usage
[ https://issues.apache.org/activemq/browse/AMQ-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janne Saikko updated AMQ-3002: -- Description: When starting broker with "bin/activemq start xbean:conf/activemq-security.xml" it won't start again after process is terminated with kill -9.. Error: 2010-10-27 14:12:33,063 | INFO | Scheduler using directory: activemq-data/localhost/scheduler | org.apache.activemq.broker.scheduler.SchedulerBroker | main 2010-10-27 14:12:33,185 | INFO | JMX consoles can connect to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi | org.apache.activemq.broker.jmx.ManagementContext | JMX connector 2010-10-27 14:12:33,208 | ERROR | Failed to start ActiveMQ JMS Message Broker. Reason: java.io.EOFException: Chunk stream does not exist at page: 0 | org.apache.activemq.broker.BrokerService | main java.io.EOFException: Chunk stream does not exist at page: 0 at org.apache.kahadb.page.Transaction$2.readPage(Transaction.java:454) at org.apache.kahadb.page.Transaction$2.(Transaction.java:431) at org.apache.kahadb.page.Transaction.openInputStream(Transaction.java:428) at org.apache.kahadb.page.Transaction.load(Transaction.java:404) at org.apache.kahadb.page.Transaction.load(Transaction.java:361) at org.apache.activemq.broker.scheduler.JobSchedulerStore$3.execute(JobSchedulerStore.java:250) at org.apache.kahadb.page.Transaction.execute(Transaction.java:728) at org.apache.activemq.broker.scheduler.JobSchedulerStore.doStart(JobSchedulerStore.java:239) at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:53) at org.apache.activemq.broker.scheduler.SchedulerBroker.getStore(SchedulerBroker.java:198) at org.apache.activemq.broker.scheduler.SchedulerBroker.getInternalScheduler(SchedulerBroker.java:185) at org.apache.activemq.broker.scheduler.SchedulerBroker.start(SchedulerBroker.java:85) at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:157) at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:157) at org.apache.activemq.broker.TransactionBroker.start(TransactionBroker.java:112) at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:157) at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:157) at org.apache.activemq.broker.BrokerService$3.start(BrokerService.java:1788) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:496) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1536) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1477) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1409) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:574) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) 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:96)
[jira] Created: (AMQ-3002) activemq-security.xml plugin usage
activemq-security.xml plugin usage -- Key: AMQ-3002 URL: https://issues.apache.org/activemq/browse/AMQ-3002 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.4.1 Environment: AMQ 5.4.1. Linux RH5 Reporter: Janne Saikko When starting broker with "bin/activemq start xbean:conf/activemq-security.xml" it won't start again after process is terminated with kill -9.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (AMQ-3001) Ghost durable topic subscribers
[ https://issues.apache.org/activemq/browse/AMQ-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62867#action_62867 ] Gary Tully edited comment on AMQ-3001 at 10/27/10 5:41 AM: --- Added a faq entry "I see NC- client-ids, what does that mean?" to explain: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=24184563 was (Author: gtully): Added a faq entry to explain: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=24184563 > Ghost durable topic subscribers > --- > > Key: AMQ-3001 > URL: https://issues.apache.org/activemq/browse/AMQ-3001 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.4.1 > Environment: Ubuntu 9.10 >Reporter: James Green >Assignee: Gary Tully >Priority: Minor > > Listed on the Durable Topic Subscribers within the web interface I now have: > Client ID: NC_ubuntu_inbound_blofeld > Subscription Name: NC-DS_blofeld_Account.Requests > Connection ID: ID:blofeld-37576-1288168498890-3:1 > I did have a subscription however it lacked a Client-ID, so it disconnected > and I restarted ActiveMQ. The result is shown above. There are allegedly no > such connections listed on the Connections page. > No idea what NC or NC-DS mean! This is confusing at best. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-3001) Ghost durable topic subscribers
[ https://issues.apache.org/activemq/browse/AMQ-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-3001. - Resolution: Working as Designed Assignee: Gary Tully Added a faq entry to explain: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=24184563 > Ghost durable topic subscribers > --- > > Key: AMQ-3001 > URL: https://issues.apache.org/activemq/browse/AMQ-3001 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.4.1 > Environment: Ubuntu 9.10 >Reporter: James Green >Assignee: Gary Tully >Priority: Minor > > Listed on the Durable Topic Subscribers within the web interface I now have: > Client ID: NC_ubuntu_inbound_blofeld > Subscription Name: NC-DS_blofeld_Account.Requests > Connection ID: ID:blofeld-37576-1288168498890-3:1 > I did have a subscription however it lacked a Client-ID, so it disconnected > and I restarted ActiveMQ. The result is shown above. There are allegedly no > such connections listed on the Connections page. > No idea what NC or NC-DS mean! This is confusing at best. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2736) KahaDB doesn't clean up old files
[ https://issues.apache.org/activemq/browse/AMQ-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62866#action_62866 ] Dejan Bosanac commented on AMQ-2736: AMQ-2982 and AMQ-2983 are fixed now on the trunk, so you can test out if that helps. I spotted one more potential issue in the area and I'm working on it now, so stay tuned. > KahaDB doesn't clean up old files > - > > Key: AMQ-2736 > URL: https://issues.apache.org/activemq/browse/AMQ-2736 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.3.2 >Reporter: Adrian Trenaman >Priority: Critical > Attachments: AMQ-2736.zip, amq-2987-testcase.patch, amq-2987.patch, > AMQ2736Test_should_with_this_diff.txt, MyKahaDBStore.java > > > Over time, we're seeing that kahadb doesn't clean up old journal files. As a > result, we eventually run out of disk space, or rather, we hit our usage > limits and our producers are slowed down by the producer flow control > mechanism. Others have experienced this problem too (for example, see > http://mail-archives.apache.org/mod_mbox/activemq-users/201002.mbox/%3c27502591.p...@talk.nabble.com%3e) > For now, we're moving back to the old amqPersistenceStore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2983) Sticky KahaDB log files due to concurrent consumer with local transaction
[ https://issues.apache.org/activemq/browse/AMQ-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac resolved AMQ-2983. Resolution: Fixed Fix Version/s: 5.5.0 Fixed with svn revision 1027863. Thanks for the test case > Sticky KahaDB log files due to concurrent consumer with local transaction > - > > Key: AMQ-2983 > URL: https://issues.apache.org/activemq/browse/AMQ-2983 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.4.1 > Environment: Ubuntu 10.04, Java 1.6 > Mac OS X 10.5, Java 1.6.0_20 >Reporter: Swen Moczarski >Assignee: Dejan Bosanac > Fix For: 5.5.0 > > Attachments: AMQ2983Test.patch > > > Concurrent consumer with local transactional session and session.receive() > leads to KahaDB log files which won't be deleted even if there are no > messages which are referred by the log file. > Please, see the attached test case. If only one consumer is configured it > seems to work, but with more than one concurrent consumer the test fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-3001) Ghost durable topic subscribers
[ https://issues.apache.org/activemq/browse/AMQ-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62864#action_62864 ] Gary Tully commented on AMQ-3001: - When a durable is forwarded through a network a well known durable subscriber needs to be created that can out live the original, so if there is a partition, there will be no loss of messages for the networked durable. They use the prefix,NC-DS, (network connector durable sub) prefix comprised of the the local broker and destination physical name, see org.apache.activemq.network.DurableConduitBridge#getSubscriberName The expectation is that the connection associated with the durable sub will change when the same durable again subscribes, the point being that the nc-ds can outlive the new connection. The dynamicOnly property of a network connector can controll whether the nc-ds is activated on startup, when true, the NC-DS will only be activated when the original durable sub again (dynamically) reconnects. With dynamicOnly=true, it is possible to miss messages when disconnected, so it defaults to false. The NC-DS-xx will only be deleted when the original durable sub unsubscribes. > Ghost durable topic subscribers > --- > > Key: AMQ-3001 > URL: https://issues.apache.org/activemq/browse/AMQ-3001 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.4.1 > Environment: Ubuntu 9.10 >Reporter: James Green >Priority: Minor > > Listed on the Durable Topic Subscribers within the web interface I now have: > Client ID: NC_ubuntu_inbound_blofeld > Subscription Name: NC-DS_blofeld_Account.Requests > Connection ID: ID:blofeld-37576-1288168498890-3:1 > I did have a subscription however it lacked a Client-ID, so it disconnected > and I restarted ActiveMQ. The result is shown above. There are allegedly no > such connections listed on the Connections page. > No idea what NC or NC-DS mean! This is confusing at best. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2721) Broker hangs reading KahaDB data store
[ https://issues.apache.org/activemq/browse/AMQ-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62863#action_62863 ] Dag Liodden commented on AMQ-2721: -- It's worth mentioning that the broker has moderate load (about 100 messages per minute). Most messages are very small, but about 50-150 per day are 1-3MB in size. Dennis: Are you sending big messages? > Broker hangs reading KahaDB data store > -- > > Key: AMQ-2721 > URL: https://issues.apache.org/activemq/browse/AMQ-2721 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.3.1 > Environment: Red hat enterprise >Reporter: Dennis Klinkott > Fix For: 5.5.0 > > Attachments: brokerjstack.log > > > Broker hangs on loading the data store. Happens after using the broker for 10 > hours in productive environment. > In broker log the last entries we see is a bunch of loading kahadb debug > entries. > 2010-05-05 16:06:19,462 | DEBUG | loading | > org.apache.kahadb.index.BTreeIndex | main > But the broker doesn't stall completely. It is doing something with high cpu > load. But it doesn't get the data store loaded. Even after a few hours it > doesn't get finished (usually only takes a few seconds). > I took a few jstack-dumps where we can see the broker being busy putting > something into a hashmap. > We have 2 brokers connected as network of brokers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-3001) Ghost durable topic subscribers
Ghost durable topic subscribers --- Key: AMQ-3001 URL: https://issues.apache.org/activemq/browse/AMQ-3001 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.4.1 Environment: Ubuntu 9.10 Reporter: James Green Priority: Minor Listed on the Durable Topic Subscribers within the web interface I now have: Client ID: NC_ubuntu_inbound_blofeld Subscription Name: NC-DS_blofeld_Account.Requests Connection ID: ID:blofeld-37576-1288168498890-3:1 I did have a subscription however it lacked a Client-ID, so it disconnected and I restarted ActiveMQ. The result is shown above. There are allegedly no such connections listed on the Connections page. No idea what NC or NC-DS mean! This is confusing at best. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2721) Broker hangs reading KahaDB data store
[ https://issues.apache.org/activemq/browse/AMQ-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62861#action_62861 ] Dag Liodden commented on AMQ-2721: -- We also see this issue on 5.3.1-fuse-01-00. Occasionally on restarts (graceful), Kaha hangs on startup and we have to delete the entire store (and loose messages) to get it going again. A strange and probably related symptom is that the store seems to grow indefinitely. Although there should be only a few in-flight messages, our current, corrupted store has 40 data-queue files (128MB each). The data is too sensitive to publish here, but we can arrange that privately if needed. The problem is in KahaStore.generateInterestInMapDataFiles where the while-loop is alternating between two item ids in an infinite loop. > Broker hangs reading KahaDB data store > -- > > Key: AMQ-2721 > URL: https://issues.apache.org/activemq/browse/AMQ-2721 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.3.1 > Environment: Red hat enterprise >Reporter: Dennis Klinkott > Fix For: 5.5.0 > > Attachments: brokerjstack.log > > > Broker hangs on loading the data store. Happens after using the broker for 10 > hours in productive environment. > In broker log the last entries we see is a bunch of loading kahadb debug > entries. > 2010-05-05 16:06:19,462 | DEBUG | loading | > org.apache.kahadb.index.BTreeIndex | main > But the broker doesn't stall completely. It is doing something with high cpu > load. But it doesn't get the data store loaded. Even after a few hours it > doesn't get finished (usually only takes a few seconds). > I took a few jstack-dumps where we can see the broker being busy putting > something into a hashmap. > We have 2 brokers connected as network of brokers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
