[jira] [Created] (ACTIVEMQ6-99) Support installing as a windows service
Hiram Chirino created ACTIVEMQ6-99: -- Summary: Support installing as a windows service Key: ACTIVEMQ6-99 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-99 Project: Apache ActiveMQ 6 Issue Type: Bug Affects Versions: 6.0.0 Reporter: Hiram Chirino Assignee: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ACTIVEMQ6-98) Make the the distro readonly and support creating mutable broker instances dirs.
Hiram Chirino created ACTIVEMQ6-98: -- Summary: Make the the distro readonly and support creating mutable broker instances dirs. Key: ACTIVEMQ6-98 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-98 Project: Apache ActiveMQ 6 Issue Type: New Feature Affects Versions: 6.0.0 Reporter: Hiram Chirino Assignee: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5652) IdGenerator not optimal in port restricted enviroments.
[ https://issues.apache.org/jira/browse/AMQ-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-5652. Resolution: Fixed > IdGenerator not optimal in port restricted enviroments. > --- > > Key: AMQ-5652 > URL: https://issues.apache.org/jira/browse/AMQ-5652 > Project: ActiveMQ > Issue Type: Bug >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5652) IdGenerator not optimal in port restricted enviroments.
[ https://issues.apache.org/jira/browse/AMQ-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14353269#comment-14353269 ] Hiram Chirino commented on AMQ-5652: In some containerized environments, the IdGenerator does not work that great. Not only does it not usually detect the hostname correctly. But binding to a dynamic port might be restricted. We should support supplying both those data values via system properties. > IdGenerator not optimal in port restricted enviroments. > --- > > Key: AMQ-5652 > URL: https://issues.apache.org/jira/browse/AMQ-5652 > Project: ActiveMQ > Issue Type: Bug >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5652) IdGenerator not optimal in port restricted enviroments.
Hiram Chirino created AMQ-5652: -- Summary: IdGenerator not optimal in port restricted enviroments. Key: AMQ-5652 URL: https://issues.apache.org/jira/browse/AMQ-5652 Project: ActiveMQ Issue Type: Bug Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.12.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5458) MBean to help testing replicated levelDB
[ https://issues.apache.org/jira/browse/AMQ-5458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14224801#comment-14224801 ] Hiram Chirino edited comment on AMQ-5458 at 11/26/14 3:58 PM: -- Implemented. New mbean will be registered with the same ObjectName as the leveldb mbean but with ',view=Test' attribute appended when the system property org.apache.activemq.leveldb.test=true'. was (Author: chirino): Implemented. New mbean will be registered with the same ObjectName as the leveldb mbean but with ',test=test' attribute appended when the system property org.apache.activemq.leveldb.test=true'. > MBean to help testing replicated levelDB > > > Key: AMQ-5458 > URL: https://issues.apache.org/jira/browse/AMQ-5458 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.11.0 > > > Would be nice if you set a system property like > 'org.apache.activemq.leveldb.test=true' that you then get a MBean for leveldb > stores that allows you to suspend/resume calls around the journal writes, > deletes and force operations so you can more easily write tests that validate > consistency and recovery. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5458) MBean to help testing replicated levelDB
[ https://issues.apache.org/jira/browse/AMQ-5458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14224801#comment-14224801 ] Hiram Chirino commented on AMQ-5458: Implemented. New mbean will be registered with the same ObjectName as the leveldb mbean but with ',test=test' attribute appended when the system property org.apache.activemq.leveldb.test=true'. > MBean to help testing replicated levelDB > > > Key: AMQ-5458 > URL: https://issues.apache.org/jira/browse/AMQ-5458 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.11.0 > > > Would be nice if you set a system property like > 'org.apache.activemq.leveldb.test=true' that you then get a MBean for leveldb > stores that allows you to suspend/resume calls around the journal writes, > deletes and force operations so you can more easily write tests that validate > consistency and recovery. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5458) MBean to help testing replicated levelDB
[ https://issues.apache.org/jira/browse/AMQ-5458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-5458: --- Fix Version/s: 5.11.0 > MBean to help testing replicated levelDB > > > Key: AMQ-5458 > URL: https://issues.apache.org/jira/browse/AMQ-5458 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.11.0 > > > Would be nice if you set a system property like > 'org.apache.activemq.leveldb.test=true' that you then get a MBean for leveldb > stores that allows you to suspend/resume calls around the journal writes, > deletes and force operations so you can more easily write tests that validate > consistency and recovery. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMQ-5458) MBean to help testing replicated levelDB
[ https://issues.apache.org/jira/browse/AMQ-5458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino reassigned AMQ-5458: -- Assignee: Hiram Chirino > MBean to help testing replicated levelDB > > > Key: AMQ-5458 > URL: https://issues.apache.org/jira/browse/AMQ-5458 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.11.0 > > > Would be nice if you set a system property like > 'org.apache.activemq.leveldb.test=true' that you then get a MBean for leveldb > stores that allows you to suspend/resume calls around the journal writes, > deletes and force operations so you can more easily write tests that validate > consistency and recovery. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5458) MBean to help testing replicated levelDB
Hiram Chirino created AMQ-5458: -- Summary: MBean to help testing replicated levelDB Key: AMQ-5458 URL: https://issues.apache.org/jira/browse/AMQ-5458 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Would be nice if you set a system property like 'org.apache.activemq.leveldb.test=true' that you then get a MBean for leveldb stores that allows you to suspend/resume calls around the journal writes, deletes and force operations so you can more easily write tests that validate consistency and recovery. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5123) Optionally support encrypted passwords in ActiveMQ users.properties file.
[ https://issues.apache.org/jira/browse/AMQ-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949621#comment-13949621 ] Hiram Chirino commented on AMQ-5123: The PropertiesLoginModule now uses the ACTIVEMQ_ENCRYPTION_PASSWORD env variable to decrypt encrypted passwords. > Optionally support encrypted passwords in ActiveMQ users.properties file. > - > > Key: AMQ-5123 > URL: https://issues.apache.org/jira/browse/AMQ-5123 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > This is going to require an enhancement of the JAAS PropertiesLoginModule -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5123) Optionally support encrypted passwords in ActiveMQ users.properties file.
[ https://issues.apache.org/jira/browse/AMQ-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-5123. Resolution: Fixed Implemented. > Optionally support encrypted passwords in ActiveMQ users.properties file. > - > > Key: AMQ-5123 > URL: https://issues.apache.org/jira/browse/AMQ-5123 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > This is going to require an enhancement of the JAAS PropertiesLoginModule -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5123) Optionally support encrypted passwords in ActiveMQ users.properties file.
[ https://issues.apache.org/jira/browse/AMQ-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-5123: --- Summary: Optionally support encrypted passwords in ActiveMQ users.properties file. (was: Optionaly support encrypted passwords in ActiveMQ users.properties file.) > Optionally support encrypted passwords in ActiveMQ users.properties file. > - > > Key: AMQ-5123 > URL: https://issues.apache.org/jira/browse/AMQ-5123 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > This is going to require an enhancement of the JAAS PropertiesLoginModule -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5124) Exception logged on startup: jolokia-agent: Cannot start discovery multicast handler
Hiram Chirino created AMQ-5124: -- Summary: Exception logged on startup: jolokia-agent: Cannot start discovery multicast handler Key: AMQ-5124 URL: https://issues.apache.org/jira/browse/AMQ-5124 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.10.0 Reporter: Hiram Chirino jolokia-agent is barfing an ugly exception on the console on activemq startup: WARN | jolokia-agent: Cannot start discovery multicast handler: java.net.SocketException: Can't assign requested address java.net.SocketException: Can't assign requested address at java.net.PlainDatagramSocketImpl.join(Native Method) at java.net.AbstractPlainDatagramSocketImpl.joinGroup(AbstractPlainDatagramSocketImpl.java:202) at java.net.MulticastSocket.joinGroup(MulticastSocket.java:402) at org.jolokia.discovery.MulticastUtil.joinMcGroupsOnAllNetworkInterfaces(MulticastUtil.java:136) at org.jolokia.discovery.MulticastUtil.newMulticastSocket(MulticastUtil.java:38) at org.jolokia.discovery.MulticastSocketListenerThread.(MulticastSocketListenerThread.java:60) at org.jolokia.discovery.DiscoveryMulticastResponder.start(DiscoveryMulticastResponder.java:75) at org.jolokia.http.AgentServlet.initDiscoveryMulticast(AgentServlet.java:176) at org.jolokia.http.AgentServlet.init(AgentServlet.java:162) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:477) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5123) Optionaly support encrypted passwords in ActiveMQ users.properties file.
Hiram Chirino created AMQ-5123: -- Summary: Optionaly support encrypted passwords in ActiveMQ users.properties file. Key: AMQ-5123 URL: https://issues.apache.org/jira/browse/AMQ-5123 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 This is going to require an enhancement of the JAAS PropertiesLoginModule -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5116) batchStatment is misspelled for JDBC adaptors
[ https://issues.apache.org/jira/browse/AMQ-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-5116. Resolution: Fixed Fix Version/s: 5.10.0 Assignee: Hiram Chirino > batchStatment is misspelled for JDBC adaptors > - > > Key: AMQ-5116 > URL: https://issues.apache.org/jira/browse/AMQ-5116 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.x >Reporter: Jeff Genender >Assignee: Hiram Chirino > Fix For: 5.10.0 > > Attachments: patch > > > batchStatment is misspelled for JDBC adaptors and causes confusion for > setting the field. It should have proper spelling as "batchStatement" - > notice the e. > Fix should provide backward compatibility, but mark it as deprecated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5115) LevelDB sync=true is not being honored.
Hiram Chirino created AMQ-5115: -- Summary: LevelDB sync=true is not being honored. Key: AMQ-5115 URL: https://issues.apache.org/jira/browse/AMQ-5115 Project: ActiveMQ Issue Type: Bug Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5115) LevelDB sync=true is not being honored.
[ https://issues.apache.org/jira/browse/AMQ-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943205#comment-13943205 ] Hiram Chirino commented on AMQ-5115: This could potential lead to data loss as writes to the journal are being done async. > LevelDB sync=true is not being honored. > --- > > Key: AMQ-5115 > URL: https://issues.apache.org/jira/browse/AMQ-5115 > Project: ActiveMQ > Issue Type: Bug >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5074) MQTT paths with empty levels are not handled correctly
[ https://issues.apache.org/jira/browse/AMQ-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-5074. Resolution: Fixed Assignee: Hiram Chirino Patch applied.. Many thanks! > MQTT paths with empty levels are not handled correctly > -- > > Key: AMQ-5074 > URL: https://issues.apache.org/jira/browse/AMQ-5074 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde >Assignee: Hiram Chirino > Fix For: 5.10.0 > > Attachments: AMQ-5074.patch > > > MQTT allows empty "" names for path levels, for example /TopicA has two > levels, "" and TopicA, similarly TopicA/ has two levels TopicA and "". The > leading and trailing '/' in MQTT is significant. > The '/' character in MQTT paths and filters is mapped to '.' in ActiveMQ, > which leads to names like '.TopicA' and 'TopicA.'. However, ActiveMQ ignores > empty path levels, although, they are just as significant for ActiveMQ. > Although these path names are not common in ActiveMQ, which maybe the reason > why the issue hasn't been discovered until now. > ActiveMQ needs to treat empty levels as significant, and pattern match > accordingly. This requires change to > ActiveMQDestination.getDestinationPaths() and some code cleanup in > DestinationMap related classes and Destination filtering classes. A patch is > attached (along with unit tests) to address this issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-5072) Support configuring a different directory for the KahaDB index files.
[ https://issues.apache.org/jira/browse/AMQ-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-5072. Resolution: Fixed kahaDB element now supports the indexDirectory attribute. If not set it falls back to using the 'directory' attribute for the location of the index files. > Support configuring a different directory for the KahaDB index files. > - > > Key: AMQ-5072 > URL: https://issues.apache.org/jira/browse/AMQ-5072 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5072) Support configuring a different directory for the KahaDB index files.
Hiram Chirino created AMQ-5072: -- Summary: Support configuring a different directory for the KahaDB index files. Key: AMQ-5072 URL: https://issues.apache.org/jira/browse/AMQ-5072 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-5054) Display the number of active transactions and age of oldest transaction on a Connection's JMX info
[ https://issues.apache.org/jira/browse/AMQ-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-5054. Resolution: Fixed Implemented. > Display the number of active transactions and age of oldest transaction on a > Connection's JMX info > -- > > Key: AMQ-5054 > URL: https://issues.apache.org/jira/browse/AMQ-5054 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > Long running transactions can affect the ability of KahaDB to gc log files. > Being able to identify which connections have the long running transactions > would operations folks deal with these problems. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5054) Display the number of active transactions and age of oldest transaction on a Connection's JMX info
Hiram Chirino created AMQ-5054: -- Summary: Display the number of active transactions and age of oldest transaction on a Connection's JMX info Key: AMQ-5054 URL: https://issues.apache.org/jira/browse/AMQ-5054 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 Long running transactions can affect the ability of KahaDB to gc log files. Being able to identify which connections have the long running transactions would operations folks deal with these problems. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (AMQ-5051) MQTTInactivityMonitor throws a NullPointerException
[ https://issues.apache.org/jira/browse/AMQ-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino reassigned AMQ-5051: -- Assignee: Hiram Chirino > MQTTInactivityMonitor throws a NullPointerException > --- > > Key: AMQ-5051 > URL: https://issues.apache.org/jira/browse/AMQ-5051 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT, Transport >Affects Versions: 5.9.0 >Reporter: Dhiraj Bokde >Assignee: Hiram Chirino > Attachments: AMQ-5051.patch > > > MQTTInactivityMonitor has a very obvious NPE issue in onException(), which > aborts propagating the exception to it's transportListener and causes > connection leaks. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-5050) Populate a 'Host' header in the WireFormatInfo of the Openwire protocol to let multi-tenant proxies route connections
[ https://issues.apache.org/jira/browse/AMQ-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-5050: --- Component/s: Broker Fix Version/s: 5.10.0 Assignee: Hiram Chirino > Populate a 'Host' header in the WireFormatInfo of the Openwire protocol to > let multi-tenant proxies route connections > - > > Key: AMQ-5050 > URL: https://issues.apache.org/jira/browse/AMQ-5050 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5050) Populate a 'Host' header in the WireFormatInfo of the Openwire protocol to let multi-tenant proxies route connections
Hiram Chirino created AMQ-5050: -- Summary: Populate a 'Host' header in the WireFormatInfo of the Openwire protocol to let multi-tenant proxies route connections Key: AMQ-5050 URL: https://issues.apache.org/jira/browse/AMQ-5050 Project: ActiveMQ Issue Type: Improvement Reporter: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5043) Improve MQTT spec compatibility
Hiram Chirino created AMQ-5043: -- Summary: Improve MQTT spec compatibility Key: AMQ-5043 URL: https://issues.apache.org/jira/browse/AMQ-5043 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-5043) Improve MQTT spec compatibility
[ https://issues.apache.org/jira/browse/AMQ-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898445#comment-13898445 ] Hiram Chirino commented on AMQ-5043: Eclipse has setup a MQTT testing suite and we are failing some of the tests. More details can be found: http://wiki.eclipse.org/Paho/MQTT_Interop_Testing_Day#Testing_Plans and http://wiki.eclipse.org/Interop_Testing_Plan > Improve MQTT spec compatibility > --- > > Key: AMQ-5043 > URL: https://issues.apache.org/jira/browse/AMQ-5043 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-5002) AMQP: If a proton client only sets the ttl, and not the message timestamp, ActiveMQ does not handle the expiration correctly
[ https://issues.apache.org/jira/browse/AMQ-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889732#comment-13889732 ] Hiram Chirino commented on AMQ-5002: To get it working when the timestamp is set, we need this issue fixed: https://issues.apache.org/jira/browse/PROTON-474 > AMQP: If a proton client only sets the ttl, and not the message timestamp, > ActiveMQ does not handle the expiration correctly > > > Key: AMQ-5002 > URL: https://issues.apache.org/jira/browse/AMQ-5002 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-5002) AMQP: If a proton client only sets the ttl, and not the message timestamp, ActiveMQ does not handle the expiration correctly
[ https://issues.apache.org/jira/browse/AMQ-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-5002. Resolution: Fixed Fix committed. > AMQP: If a proton client only sets the ttl, and not the message timestamp, > ActiveMQ does not handle the expiration correctly > > > Key: AMQ-5002 > URL: https://issues.apache.org/jira/browse/AMQ-5002 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5002) AMQP: If a proton client only sets the ttl, and not the message timestamp, ActiveMQ does not handle the expiration correctly
Hiram Chirino created AMQ-5002: -- Summary: AMQP: If a proton client only sets the ttl, and not the message timestamp, ActiveMQ does not handle the expiration correctly Key: AMQ-5002 URL: https://issues.apache.org/jira/browse/AMQ-5002 Project: ActiveMQ Issue Type: Bug Components: AMQP Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-4990) Add support for the changes in MQTT 3.1.1
Hiram Chirino created AMQ-4990: -- Summary: Add support for the changes in MQTT 3.1.1 Key: AMQ-4990 URL: https://issues.apache.org/jira/browse/AMQ-4990 Project: ActiveMQ Issue Type: New Feature Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-4837) LevelDB corrupted when in a replication cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino resolved AMQ-4837.
Resolution: Fixed
Fix Version/s: 5.10.0
Marking issue as resolved since the fix was confirmed by Guillaume. Thx!
> LevelDB corrupted when in a replication cluster
> ---
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Fix For: 5.10.0
>
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(Le
[jira] [Resolved] (AMQ-4917) LevelDB store can fail when using durable subs
[ https://issues.apache.org/jira/browse/AMQ-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4917. Resolution: Fixed Thanks for checking the fix. Resolving as fixed. > LevelDB store can fail when using durable subs > -- > > Key: AMQ-4917 > URL: https://issues.apache.org/jira/browse/AMQ-4917 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > Tenzin giatso original reported this issue in AMQ-4837 : > The broker stopped 3 times this night after about 6h50min, then 6h50 min then > 50min. > The error sounds to be the saùme (except the line number in class) but the > broker restart automaticly with the snapshot. > 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to > exception, java.io.IOException | > org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException > handler. > java.io.IOException > at > org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) > at > org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) > at > org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1244) > at org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708) > at > org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recover(LevelDBStore.scala:747) > at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:588) > at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65) > at org.apache.activemq.broker.region.Topic$6.run(Topic.java:721) > at > org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) > at java.util.TimerThread.mainLoop(Unknown Source) > at java.util.TimerThread.run(Unknown Source) > Caused by: java.lang.NullPointerException > at > org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1248) > It's not easy to reproduce. It's better with the snapshot but i can't say > that no messages are lost with leveldb. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (AMQ-4923) Replicated LevelDB: Loss of broker Quorum fails to fully stop the master
[ https://issues.apache.org/jira/browse/AMQ-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4923. Resolution: Fixed Fix Version/s: 5.10.0 Fixed. > Replicated LevelDB: Loss of broker Quorum fails to fully stop the master > > > Key: AMQ-4923 > URL: https://issues.apache.org/jira/browse/AMQ-4923 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > Master keeps reporting: > INFO | The connection to 'tcp://10.64.132.143:55732' is taking a long time to > shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4923) Replicated LevelDB: Loss of broker Quorum fails to fully stop the master
Hiram Chirino created AMQ-4923: -- Summary: Replicated LevelDB: Loss of broker Quorum fails to fully stop the master Key: AMQ-4923 URL: https://issues.apache.org/jira/browse/AMQ-4923 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Master keeps reporting: INFO | The connection to 'tcp://10.64.132.143:55732' is taking a long time to shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4922) BrokerService.addConnector(URI bindAddress) binds the port before starting the broker.
[ https://issues.apache.org/jira/browse/AMQ-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840289#comment-13840289 ] Hiram Chirino commented on AMQ-4922: I've got fix started at: https://github.com/chirino/activemq/tree/AMQ-4922 There might be some tests remaining that try to get the local port before starting the broker. Need to find and fix those tests before merging into trunk. > BrokerService.addConnector(URI bindAddress) binds the port before starting > the broker. > -- > > Key: AMQ-4922 > URL: https://issues.apache.org/jira/browse/AMQ-4922 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4922) BrokerService.addConnector(URI bindAddress) binds the port before starting the broker.
Hiram Chirino created AMQ-4922: -- Summary: BrokerService.addConnector(URI bindAddress) binds the port before starting the broker. Key: AMQ-4922 URL: https://issues.apache.org/jira/browse/AMQ-4922 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4917) LevelDB store can fail when using durable subs
[ https://issues.apache.org/jira/browse/AMQ-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839089#comment-13839089 ] Hiram Chirino commented on AMQ-4917: Ok. I think this one should be fixed now. Fix is included in the following builds for anyone who wants to double check. https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131204.171817-28-bin.tar.gz https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131204.171817-28-bin.zip > LevelDB store can fail when using durable subs > -- > > Key: AMQ-4917 > URL: https://issues.apache.org/jira/browse/AMQ-4917 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > Tenzin giatso original reported this issue in AMQ-4837 : > The broker stopped 3 times this night after about 6h50min, then 6h50 min then > 50min. > The error sounds to be the saùme (except the line number in class) but the > broker restart automaticly with the snapshot. > 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to > exception, java.io.IOException | > org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException > handler. > java.io.IOException > at > org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) > at > org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) > at > org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1244) > at org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708) > at > org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recover(LevelDBStore.scala:747) > at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:588) > at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65) > at org.apache.activemq.broker.region.Topic$6.run(Topic.java:721) > at > org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) > at java.util.TimerThread.mainLoop(Unknown Source) > at java.util.TimerThread.run(Unknown Source) > Caused by: java.lang.NullPointerException > at > org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1248) > It's not easy to reproduce. It's better with the snapshot but i can't say > that no messages are lost with leveldb. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4917) LevelDB store can fail when using durable subs
[ https://issues.apache.org/jira/browse/AMQ-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4917: --- Description: Tenzin giatso original reported this issue in AMQ-4837 : The broker stopped 3 times this night after about 6h50min, then 6h50 min then 50min. The error sounds to be the saùme (except the line number in class) but the broker restart automaticly with the snapshot. 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException | org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException handler. java.io.IOException at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) at org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) at org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) at org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) at org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1244) at org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708) at org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recover(LevelDBStore.scala:747) at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:588) at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65) at org.apache.activemq.broker.region.Topic$6.run(Topic.java:721) at org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) Caused by: java.lang.NullPointerException at org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1248) It's not easy to reproduce. It's better with the snapshot but i can't say that no messages are lost with leveldb. was: Tenzin giatso original reported this issue Hi, the broker stopped 3 times this night after about 6h50min, then 6h50 min then 50min. The error sounds to be the saùme (except the line number in class) but the broker restart automaticly with the snapshot. 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException | org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException handler. java.io.IOException at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) at org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) at org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) at org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) at org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1244) at org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708) at org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recover(LevelDBStore.scala:747) at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:588) at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65) at org.apache.activemq.broker.region.Topic$6.run(Topic.java:721) at org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) Caused by: java.lang.NullPointerException at org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1248) It's not easy to reproduce. It's better with the snapshot but i can't say that no messages are lost with leveldb. > LevelDB store can fail when using durable subs > -- > > Key: AMQ-4917 > URL: https://issues.apache.org/jira/browse/AMQ-4917 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > Tenzin giatso original reported this issue in AMQ-4837 : > The broker stopped 3 times this night after about 6h50min, then 6h50 min then > 50min. > The error sounds to be the saùme (except the line number in class) but the > broker restart automaticly with the snapshot. > 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to > exception, java.io.IOException | > org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException > handler. > java.io.IOException > at > org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) > at > org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) > at > org.apache.activemq.leveldb.LevelDBClient.queueC
[jira] [Commented] (AMQ-4837) LevelDB corrupted when in a replication cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839034#comment-13839034
]
Hiram Chirino commented on AMQ-4837:
Tenzin, since your issue seems different I opened a new issue under AMQ-4917.
It seems specifically related to durable subs.
> LevelDB corrupted when in a replication cluster
> ---
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun
[jira] [Updated] (AMQ-4917) LevelDB store can fail when using durable subs
[ https://issues.apache.org/jira/browse/AMQ-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4917: --- Description: Tenzin giatso original reported this issue Hi, the broker stopped 3 times this night after about 6h50min, then 6h50 min then 50min. The error sounds to be the saùme (except the line number in class) but the broker restart automaticly with the snapshot. 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException | org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException handler. java.io.IOException at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) at org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) at org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) at org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) at org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1244) at org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708) at org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recover(LevelDBStore.scala:747) at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:588) at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65) at org.apache.activemq.broker.region.Topic$6.run(Topic.java:721) at org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) Caused by: java.lang.NullPointerException at org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1248) It's not easy to reproduce. It's better with the snapshot but i can't say that no messages are lost with leveldb. > LevelDB store can fail when using durable subs > -- > > Key: AMQ-4917 > URL: https://issues.apache.org/jira/browse/AMQ-4917 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > > Tenzin giatso original reported this issue > Hi, > the broker stopped 3 times this night after about 6h50min, then 6h50 min then > 50min. > The error sounds to be the saùme (except the line number in class) but the > broker restart automaticly with the snapshot. > 2013-11-19 05:27:43,671 | INFO | Stopping BrokerService[localhost] due to > exception, java.io.IOException | > org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException > handler. > java.io.IOException > at > org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:554) > at > org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1021) > at > org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1320) > at > org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1244) > at org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708) > at > org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recover(LevelDBStore.scala:747) > at org.apache.activemq.broker.region.Topic.doBrowse(Topic.java:588) > at org.apache.activemq.broker.region.Topic.access$100(Topic.java:65) > at org.apache.activemq.broker.region.Topic$6.run(Topic.java:721) > at > org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) > at java.util.TimerThread.mainLoop(Unknown Source) > at java.util.TimerThread.run(Unknown Source) > Caused by: java.lang.NullPointerException > at > org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1248) > It's not easy to reproduce. It's better with the snapshot but i can't say > that no messages are lost with leveldb. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4917) LevelDB store can fail when using durable subs
Hiram Chirino created AMQ-4917: -- Summary: LevelDB store can fail when using durable subs Key: AMQ-4917 URL: https://issues.apache.org/jira/browse/AMQ-4917 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Issue Comment Deleted] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4882: --- Comment: was deleted (was: I’m experiencing the same error using the latest 5.10-SNAPSHOT build and LevelDB Replicated datastore. My testing used non-transaction clients. Test scenario procedure was to stop and restart 5.10 repeatedly, forcing recovery to other Replicated instances. Linux RHEL 5, Java 1.7 2013-11-12 20:00:53,552 | INFO | Promoted to master | org.apache.activemq.leveldb.replicated.MasterElector | main-EventThread 2013-11-12 20:00:53,568 | INFO | Using the pure java LevelDB implementation. | org.apache.activemq.leveldb.LevelDBClient | ActiveMQ BrokerService[replicating-broker] Task-3 2013-11-12 20:00:55,564 | INFO | Master started: tcp://tmi00091:55201 | org.apache.activemq.leveldb.replicated.MasterElector | ActiveMQ BrokerService[replicating-broker] Task-4 r.java:258) at org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108) at org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157) at org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875) at org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086) at org.apache.activemq.broker.region.Queue.doBrowse(Queue.java:1096) at org.apache.activemq.broker.region.Queue.expireMessages(Queue.java:905) at org.apache.activemq.broker.region.Queue.access$100(Queue.java:79) at org.apache.activemq.broker.region.Queue$2.run(Queue.java:120) at org.apache.activemq.thread.SchedulerTimerTask.run(SchedulerTimerTask.java:33) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Caused by: java.lang.NullPointerException at org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1243) at org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1239) at org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1317) at org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1316) at org.apache.activemq.leveldb.LevelDBClient$RichDB.check$4(LevelDBClient.scala:326) at org.apache.activemq.leveldb.LevelDBClient$RichDB.cursorRange(LevelDBClient.scala:328) at org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply$mcV$sp(LevelDBClient.scala:1316) at org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1316) at org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1316) at org.apache.activemq.leveldb.LevelDBClient.usingIndex(LevelDBClient.scala:1013) at org.apache.activemq.leveldb.LevelDBClient$$anonfun$might_fail_using_index$1.apply(LevelDBClient.scala:1019) at org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:551) ... 18 more 2013-11-12 20:00:50,252 | INFO | Apache ActiveMQ 5.10-SNAPSHOT (replicating-broker, ID:tmi00092-40602-1384286419875-0:1) is shutting down | org.apache.activemq.broker.BrokerService | IOExceptionHandler: stopping BrokerService[replicating-broker] ) > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. > Reproduction: > - Configure AMQ with LevelDB > - Run the attached TestClient > - Restart AMQ several times. At some time it won't start anymore and produced > the exception in the attached log file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4837) LevelDB corrupted when in a replication cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino updated AMQ-4837:
---
Summary: LevelDB corrupted when in a replication cluster (was: LevelDB
corrupted in AMQ cluster)
> LevelDB corrupted when in a replication cluster
> ---
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at
> org.apache.activ
[jira] [Updated] (AMQ-4882) LevelDB can get to a corrupt state when using XA transactions
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4882: --- Summary: LevelDB can get to a corrupt state when using XA transactions (was: LevelDB can get to a corrupt state) > LevelDB can get to a corrupt state when using XA transactions > - > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. > Reproduction: > - Configure AMQ with LevelDB > - Run the attached TestClient > - Restart AMQ several times. At some time it won't start anymore and produced > the exception in the attached log file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837905#comment-13837905
]
Hiram Chirino commented on AMQ-4837:
Tenzin, how big are the messages and are you using transactions?
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at
> org.apache.activemq.leveldb
[jira] [Comment Edited] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837814#comment-13837814
]
Hiram Chirino edited comment on AMQ-4837 at 12/3/13 4:06 PM:
-
Hi Remo,
Thanks. Tenzin, does AMQ-4882 seem like your issue?
was (Author: chirino):
Hi Remo,
FYI: seems like AMQ-4882 talks about a problem that occurs in a replication
cluster.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> or
[jira] [Commented] (AMQ-4684) LevelDB on NFS created .nfs files
[ https://issues.apache.org/jira/browse/AMQ-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837834#comment-13837834 ] Hiram Chirino commented on AMQ-4684: Could you give use the full list of .nfs files that were created? > LevelDB on NFS created .nfs files > - > > Key: AMQ-4684 > URL: https://issues.apache.org/jira/browse/AMQ-4684 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.8.0 > Environment: three linuc machines: > - one NFS server > - two activeMQ machines, both a mount on the NFS server for LevelDB >Reporter: Christiaan Willemsen >Priority: Minor > > We are currently testing levelDB on NFS for failover. We did this test with > only one ActiveMQ running. > We filled one queue with 10.000 messages via the admin console, and then > purged the queue. > After this, the LevelDB directory was filled with .nfsxx files. These > seem to be old version of the LevelDB log file. They are removed when you > stop the ActiceMQ process. You also appear to be able to remove the files > manually. > From what we can deduce, these files mean that they were still open for io, > while they were removed from the filesystem. A local filesystem will cope > with this in the background, on a NFS share however that can't be done, so > these .nfs files are created. > So it seems that the LevelDB store keeps the old logfiles open after they > were deleted. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837831#comment-13837831 ] Hiram Chirino commented on AMQ-4882: >From the logs it seems the client is using XA transactions. > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. > Reproduction: > - Configure AMQ with LevelDB > - Run the attached TestClient > - Restart AMQ several times. At some time it won't start anymore and produced > the exception in the attached log file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837825#comment-13837825 ] Hiram Chirino commented on AMQ-4882: Could you attach the sources to the test client? > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. > Reproduction: > - Configure AMQ with LevelDB > - Run the attached TestClient > - Restart AMQ several times. At some time it won't start anymore and produced > the exception in the attached log file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837814#comment-13837814
]
Hiram Chirino commented on AMQ-4837:
Hi Remo,
FYI: seems like AMQ-4882 talks about a problem that occurs in a replication
cluster.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831593#comment-13831593
]
Hiram Chirino commented on AMQ-4837:
Hi Tenzin,
Yeah if your setup is non-replicated, I'd open a new issue to track the problem
since this issue was originally opened on a problem that only affected
replicated setups.
Also it does not seem like the store gets 'corrupted' since you don't loose
messages after a restart.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCurs
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826530#comment-13826530
]
Hiram Chirino commented on AMQ-4837:
Ok.. so right now it just seems like the master is rebooting due to an error
that a new slave seems to recover from right?
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBCli
[jira] [Resolved] (AMQ-4896) MQTT does not properly restore durable subs with the Paho client.
[ https://issues.apache.org/jira/browse/AMQ-4896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4896. Resolution: Fixed > MQTT does not properly restore durable subs with the Paho client. > - > > Key: AMQ-4896 > URL: https://issues.apache.org/jira/browse/AMQ-4896 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4896) MQTT does not properly restore durable subs with the Paho client.
Hiram Chirino created AMQ-4896: -- Summary: MQTT does not properly restore durable subs with the Paho client. Key: AMQ-4896 URL: https://issues.apache.org/jira/browse/AMQ-4896 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4895) exception logged when AMQ vm transport is stopped
[ https://issues.apache.org/jira/browse/AMQ-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825360#comment-13825360 ] Hiram Chirino commented on AMQ-4895: Is the ActiveMQManagedConnection.destroy() getting called on the connection before the broker is shutdown? > exception logged when AMQ vm transport is stopped > - > > Key: AMQ-4895 > URL: https://issues.apache.org/jira/browse/AMQ-4895 > Project: ActiveMQ > Issue Type: Bug > Components: JCA Container, Transport >Affects Versions: 5.9.0 >Reporter: Romain Manni-Bucau >Priority: Minor > > Using AMQ RA when the broker is shutted down the following log is traced: > https://gist.github.com/rmannibucau/ab945546963db12365d3 > this is due to the onException of > org.apache.activemq.ra.ActiveMQManagedConnection -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825318#comment-13825318
]
Hiram Chirino edited comment on AMQ-4837 at 11/18/13 1:46 PM:
--
Tenzin,
Does it also happen with a fresh SNAPSHOT build?
http://repository.apache.org/service/local/artifact/maven/redirect?r=snapshots&g=org.apache.activemq&a=apache-activemq&v=5.10-SNAPSHOT&e=tar.gz&c=bin
was (Author: chirino):
Tenzin,
Does it also happen with the following build?
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131106.134045-17-bin.tar.gz
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825318#comment-13825318
]
Hiram Chirino commented on AMQ-4837:
Tenzin,
Does it also happen with the following build?
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131106.134045-17-bin.tar.gz
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.active
[jira] [Created] (AMQ-4892) MQTT clients disconnecting due to socket error do not publish the configured last will and testament message.
Hiram Chirino created AMQ-4892: -- Summary: MQTT clients disconnecting due to socket error do not publish the configured last will and testament message. Key: AMQ-4892 URL: https://issues.apache.org/jira/browse/AMQ-4892 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.10.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814892#comment-13814892
]
Hiram Chirino commented on AMQ-4837:
Weird. I can't reproduce anymore with the latest build. Perhaps the build I
linked to in the issue did not have the fix. Here's a link to a fresh build:
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131106.134045-17-bin.tar.g
Could you double check again?
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.a
[jira] [Comment Edited] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814892#comment-13814892
]
Hiram Chirino edited comment on AMQ-4837 at 11/6/13 1:49 PM:
-
Weird. I can't reproduce anymore with the latest build. Perhaps the build I
linked to in the issue did not have the fix. Here's a link to a fresh build:
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131106.134045-17-bin.tar.gz
Could you double check again?
was (Author: chirino):
Weird. I can't reproduce anymore with the latest build. Perhaps the build I
linked to in the issue did not have the fix. Here's a link to a fresh build:
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131106.134045-17-bin.tar.g
Could you double check again?
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
>
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811515#comment-13811515
]
Hiram Chirino commented on AMQ-4837:
Hi Guillaume,
Ok. I think I got it this time. Could you check this build for me?
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131101.162431-14-bin.tar.gz
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810473#comment-13810473
]
Hiram Chirino commented on AMQ-4837:
Ah.. hold off.. I'm still seeing the issue. Need better unit test.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at
> org.apache.activemq.leveldb.LevelDBCli
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810453#comment-13810453
]
Hiram Chirino commented on AMQ-4837:
Hi Guillaume,
I think I've fixed this issue now. If you get a chance could you verify
against the following build:
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.10-SNAPSHOT/apache-activemq-5.10-20131031.171656-11-bin.tar.gz
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClie
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810429#comment-13810429
]
Hiram Chirino commented on AMQ-4837:
unit test for this issue can be found at:
https://github.com/apache/activemq/blob/trunk/activemq-leveldb-store/src/test/java/org/apache/activemq/leveldb/test/ReplicatedLevelDBBrokerTest.java
It was intermittently failing for me.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.active
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809446#comment-13809446
]
Hiram Chirino commented on AMQ-4837:
Ok. thx. I was able to reproduce.. looking into the root cause now.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at
> org.apache.activemq.leveldb.LevelDBCli
[jira] [Updated] (AMQ-4840) Invalid STOMP frame sent on websocket connections with heartbeats.
[ https://issues.apache.org/jira/browse/AMQ-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4840: --- Description: a KEEPALIVE frame was being sent by ActiveMQ to stomp websocket clients that enabled heartbeats. > Invalid STOMP frame sent on websocket connections with heartbeats. > -- > > Key: AMQ-4840 > URL: https://issues.apache.org/jira/browse/AMQ-4840 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > > a KEEPALIVE frame was being sent by ActiveMQ to stomp websocket clients that > enabled heartbeats. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4840) Invalid STOMP frame sent on websocket connections with heartbeats.
Hiram Chirino created AMQ-4840: -- Summary: Invalid STOMP frame sent on websocket connections with heartbeats. Key: AMQ-4840 URL: https://issues.apache.org/jira/browse/AMQ-4840 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart
[ https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809334#comment-13809334 ] Hiram Chirino commented on AMQ-4354: Persisting the stats could have significant performance impact if done naively. > Persist JMX statistics so they survive a restart > > > Key: AMQ-4354 > URL: https://issues.apache.org/jira/browse/AMQ-4354 > Project: ActiveMQ > Issue Type: New Feature > Components: JMX >Affects Versions: 5.8.0 > Environment: All >Reporter: Matt Pavlovich > > It would be really handy if JMX statistics survived a restart. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4354) Persist JMX statistics so they survive a restart
[ https://issues.apache.org/jira/browse/AMQ-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809333#comment-13809333 ] Hiram Chirino commented on AMQ-4354: We could also just make the stats more consistent after a restart. For example, make the enqueue count match the queue size on restart. > Persist JMX statistics so they survive a restart > > > Key: AMQ-4354 > URL: https://issues.apache.org/jira/browse/AMQ-4354 > Project: ActiveMQ > Issue Type: New Feature > Components: JMX >Affects Versions: 5.8.0 > Environment: All >Reporter: Matt Pavlovich > > It would be really handy if JMX statistics survived a restart. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"
[ https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809331#comment-13809331 ] Hiram Chirino commented on AMQ-3621: 5.9 was just released so, its probably going to be a while before we build up enough new features to cut 5.10. > Integrate Apache Shiro with ActiveMQ as "security solution" > --- > > Key: AMQ-3621 > URL: https://issues.apache.org/jira/browse/AMQ-3621 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Cservenak, Tamas > Fix For: 5.10.0 > > > Integrate Apache Shiro with ActiveMQ as "security solution". > This would benefit for ActiveMQ to have support for a vast amount of already > existing solution (Realm implementations) that are out there for Shiro. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809313#comment-13809313
]
Hiram Chirino commented on AMQ-4837:
I failed to reproduce using the procedure outlined. I was testing on 3 Fedora
Core 18 VMs.
I was pushing messages using the example in: examples/openwire/swissarmy
and running: ant producer
-Durl='failover:(tcp://demo01:61616,tcp://demo02:61616,tcp://demo03:61616)'
-Ddurable=true -Dtopic=false -Dmax=10
I was just browsing the queue using the new hawtio web console. Not really
drilling into each of the messages.
Guillaume, could you add more details on how you you've been reproducing. How
you adding the messages? Perhaps the number and size of the messages makes a
difference.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
[jira] [Assigned] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino reassigned AMQ-4837:
--
Assignee: Hiram Chirino
Looking into it...
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1272)
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBC
[jira] [Commented] (AMQ-4833) Unable to install the feature activemq-blueprint in Karaf 2.3.3
[ https://issues.apache.org/jira/browse/AMQ-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808443#comment-13808443 ] Hiram Chirino commented on AMQ-4833: On my local machine installing in karaf 2.3.3 work but that probably because I had the dependency in my local mvn repo. Doing an install on a machine without any local mvn repo failed the same way. > Unable to install the feature activemq-blueprint in Karaf 2.3.3 > --- > > Key: AMQ-4833 > URL: https://issues.apache.org/jira/browse/AMQ-4833 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.9.0, 5.10.0 > Environment: CentOS 6.4, Java 7 Update 45, Karaf 2.3.3 >Reporter: Andreas Gies >Priority: Minor > > Hi, > with Active MQ 5.9.0 and 5.10-SNAPSHOT I was encountering a problem when I > tried to install the activemq-blueprint feature into a Karaf 2.3.3 container. > The error message was > Error executing command: URL > [mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.scala-library/2.9.1_3] > could not be resolved > My container was able to resolve all other bundles from maven central, this > was the only one failing. > Best regards > Andreas -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4833) Unable to install the feature activemq-blueprint in Karaf 2.3.3
[ https://issues.apache.org/jira/browse/AMQ-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808422#comment-13808422 ] Hiram Chirino commented on AMQ-4833: Its weird as the artifact is deployed in maven central: http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.scala-library/2.9.1_3/ > Unable to install the feature activemq-blueprint in Karaf 2.3.3 > --- > > Key: AMQ-4833 > URL: https://issues.apache.org/jira/browse/AMQ-4833 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.9.0, 5.10.0 > Environment: CentOS 6.4, Java 7 Update 45, Karaf 2.3.3 >Reporter: Andreas Gies >Priority: Minor > > Hi, > with Active MQ 5.9.0 and 5.10-SNAPSHOT I was encountering a problem when I > tried to install the activemq-blueprint feature into a Karaf 2.3.3 container. > The error message was > Error executing command: URL > [mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.scala-library/2.9.1_3] > could not be resolved > My container was able to resolve all other bundles from maven central, this > was the only one failing. > Best regards > Andreas -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (AMQ-4806) './bin/activemq console' should 'exec' java so that way scripts calling it can get the pid for the broker's java process.
[ https://issues.apache.org/jira/browse/AMQ-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4806. Resolution: Fixed > './bin/activemq console' should 'exec' java so that way scripts calling it > can get the pid for the broker's java process. > - > > Key: AMQ-4806 > URL: https://issues.apache.org/jira/browse/AMQ-4806 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4806) './bin/activemq console' should 'exec' java so that way scripts calling it can get the pid for the broker's java process.
Hiram Chirino created AMQ-4806: -- Summary: './bin/activemq console' should 'exec' java so that way scripts calling it can get the pid for the broker's java process. Key: AMQ-4806 URL: https://issues.apache.org/jira/browse/AMQ-4806 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.9.0 Reporter: Hiram Chirino Assignee: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4788) Add support for allowing the broker to partition client client load across a broker cluster using a partitioning configuraiton
Hiram Chirino created AMQ-4788: -- Summary: Add support for allowing the broker to partition client client load across a broker cluster using a partitioning configuraiton Key: AMQ-4788 URL: https://issues.apache.org/jira/browse/AMQ-4788 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: Hiram Chirino Assignee: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4788) Add support for allowing the broker to partition client client load across a broker cluster using a partitioning config
[ https://issues.apache.org/jira/browse/AMQ-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4788: --- Summary: Add support for allowing the broker to partition client client load across a broker cluster using a partitioning config (was: Add support for allowing the broker to partition client client load across a broker cluster using a partitioning configuraiton) > Add support for allowing the broker to partition client client load across a > broker cluster using a partitioning config > --- > > Key: AMQ-4788 > URL: https://issues.apache.org/jira/browse/AMQ-4788 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: Hiram Chirino >Assignee: Hiram Chirino > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4744) Support using LevelDB as a nested store in mKahaDB
[ https://issues.apache.org/jira/browse/AMQ-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779911#comment-13779911 ] Hiram Chirino commented on AMQ-4744: This is now mostly working. A couple of failing tests n mLevelDBXARecoveryBrokerTest have been disabled. > Support using LevelDB as a nested store in mKahaDB > -- > > Key: AMQ-4744 > URL: https://issues.apache.org/jira/browse/AMQ-4744 > Project: ActiveMQ > Issue Type: Bug >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: Unscheduled > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4310) Add composite persistence adapter to support multiple storages for different destinations
[ https://issues.apache.org/jira/browse/AMQ-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779910#comment-13779910 ] Hiram Chirino commented on AMQ-4310: Issue AMQ-4744 will track adding support for nested LevelDB store in mKahaDB > Add composite persistence adapter to support multiple storages for different > destinations > - > > Key: AMQ-4310 > URL: https://issues.apache.org/jira/browse/AMQ-4310 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Affects Versions: 5.x >Reporter: SuoNayi >Assignee: Hiram Chirino > Fix For: 5.9.0 > > > Supposing we need the queue A to give us the best performance and it's > acceptable for low chance of losing messages while the other queue B provides > the most reliable message delivery and it's better it's store has no > single-point failure. > If we can assign the store of the queue A to kahadb while for the queue B is > jdbc(database cluster) it's easy to solve this problem. > In other words,different destinations can assign different store to meet > different requirements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4310) Add composite persistence adapter to support multiple storages for different destinations
[ https://issues.apache.org/jira/browse/AMQ-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779907#comment-13779907 ] Hiram Chirino commented on AMQ-4310: mKahaDB has now been generalized to support different nested store types. Currently only KahaDB is supported but LevelDB will be supported shortly too. > Add composite persistence adapter to support multiple storages for different > destinations > - > > Key: AMQ-4310 > URL: https://issues.apache.org/jira/browse/AMQ-4310 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Affects Versions: 5.x >Reporter: SuoNayi >Assignee: Hiram Chirino > Fix For: Unscheduled > > > Supposing we need the queue A to give us the best performance and it's > acceptable for low chance of losing messages while the other queue B provides > the most reliable message delivery and it's better it's store has no > single-point failure. > If we can assign the store of the queue A to kahadb while for the queue B is > jdbc(database cluster) it's easy to solve this problem. > In other words,different destinations can assign different store to meet > different requirements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4744) Support using LevelDB as a nested store in mKahaDB
Hiram Chirino created AMQ-4744: -- Summary: Support using LevelDB as a nested store in mKahaDB Key: AMQ-4744 URL: https://issues.apache.org/jira/browse/AMQ-4744 Project: ActiveMQ Issue Type: Bug Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: Unscheduled -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4310) Add composite persistence adapter to support multiple storages for different destinations
[ https://issues.apache.org/jira/browse/AMQ-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4310. Resolution: Fixed Fix Version/s: (was: Unscheduled) 5.9.0 > Add composite persistence adapter to support multiple storages for different > destinations > - > > Key: AMQ-4310 > URL: https://issues.apache.org/jira/browse/AMQ-4310 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Affects Versions: 5.x >Reporter: SuoNayi >Assignee: Hiram Chirino > Fix For: 5.9.0 > > > Supposing we need the queue A to give us the best performance and it's > acceptable for low chance of losing messages while the other queue B provides > the most reliable message delivery and it's better it's store has no > single-point failure. > If we can assign the store of the queue A to kahadb while for the queue B is > jdbc(database cluster) it's easy to solve this problem. > In other words,different destinations can assign different store to meet > different requirements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (AMQ-4310) Add composite persistence adapter to support multiple storages for different destinations
[ https://issues.apache.org/jira/browse/AMQ-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino reassigned AMQ-4310: -- Assignee: Hiram Chirino > Add composite persistence adapter to support multiple storages for different > destinations > - > > Key: AMQ-4310 > URL: https://issues.apache.org/jira/browse/AMQ-4310 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Affects Versions: 5.x >Reporter: SuoNayi >Assignee: Hiram Chirino > Fix For: Unscheduled > > > Supposing we need the queue A to give us the best performance and it's > acceptable for low chance of losing messages while the other queue B provides > the most reliable message delivery and it's better it's store has no > single-point failure. > If we can assign the store of the queue A to kahadb while for the queue B is > jdbc(database cluster) it's easy to solve this problem. > In other words,different destinations can assign different store to meet > different requirements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770812#comment-13770812 ] Hiram Chirino edited comment on AMQ-4718 at 9/18/13 2:27 PM: - documented on the wiki: https://cwiki.apache.org/confluence/display/ACTIVEMQ/Failover+Transport+Reference#FailoverTransportReference-PassingextraoptionstothenestedURLs. was (Author: chirino): documented on the wiki. > Extra options added to a failover/discovery URL that don't map to failover > configuration settings, should get passed to the nested URLs. > > > Key: AMQ-4718 > URL: https://issues.apache.org/jira/browse/AMQ-4718 > Project: ActiveMQ > Issue Type: New Feature > Components: JMS client >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.9.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770812#comment-13770812 ] Hiram Chirino commented on AMQ-4718: documented on the wiki. > Extra options added to a failover/discovery URL that don't map to failover > configuration settings, should get passed to the nested URLs. > > > Key: AMQ-4718 > URL: https://issues.apache.org/jira/browse/AMQ-4718 > Project: ActiveMQ > Issue Type: New Feature > Components: JMS client >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.9.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4718. Resolution: Fixed Fixed. > Extra options added to a failover/discovery URL that don't map to failover > configuration settings, should get passed to the nested URLs. > > > Key: AMQ-4718 > URL: https://issues.apache.org/jira/browse/AMQ-4718 > Project: ActiveMQ > Issue Type: New Feature > Components: JMS client >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.9.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4723) HTTP Discovery agent should only poll for broker URLs while attempting to connect a transport.
[ https://issues.apache.org/jira/browse/AMQ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4723. Resolution: Fixed Fix Version/s: 5.9.0 > HTTP Discovery agent should only poll for broker URLs while attempting to > connect a transport. > -- > > Key: AMQ-4723 > URL: https://issues.apache.org/jira/browse/AMQ-4723 > Project: ActiveMQ > Issue Type: New Feature > Components: JMS client >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.9.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4718. Resolution: Fixed > Extra options added to a failover/discovery URL that don't map to failover > configuration settings, should get passed to the nested URLs. > > > Key: AMQ-4718 > URL: https://issues.apache.org/jira/browse/AMQ-4718 > Project: ActiveMQ > Issue Type: New Feature > Components: JMS client >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.9.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4723) HTTP Discovery agent should only poll for broker URLs while attempting to connect a transport.
Hiram Chirino created AMQ-4723: -- Summary: HTTP Discovery agent should only poll for broker URLs while attempting to connect a transport. Key: AMQ-4723 URL: https://issues.apache.org/jira/browse/AMQ-4723 Project: ActiveMQ Issue Type: New Feature Components: JMS client Reporter: Hiram Chirino Assignee: Hiram Chirino -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4718: --- Issue Type: New Feature (was: Bug) > Extra options added to a failover/discovery URL that don't map to failover > configuration settings, should get passed to the nested URLs. > > > Key: AMQ-4718 > URL: https://issues.apache.org/jira/browse/AMQ-4718 > Project: ActiveMQ > Issue Type: New Feature > Components: JMS client >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.9.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
Hiram Chirino created AMQ-4718: -- Summary: Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs. Key: AMQ-4718 URL: https://issues.apache.org/jira/browse/AMQ-4718 Project: ActiveMQ Issue Type: Bug Components: JMS client Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.9.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4717) populateJMSXUserID is not setting the JMSXUserID property on the JMS message in JMX
[ https://issues.apache.org/jira/browse/AMQ-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4717: --- Issue Type: New Feature (was: Bug) > populateJMSXUserID is not setting the JMSXUserID property on the JMS message > in JMX > --- > > Key: AMQ-4717 > URL: https://issues.apache.org/jira/browse/AMQ-4717 > Project: ActiveMQ > Issue Type: New Feature >Affects Versions: 5.5.1, 5.6.0, 5.8.0 > Environment: OSX > java version "1.7.0_25" >Reporter: Jason Sherman >Assignee: Hiram Chirino > Labels: authentication > Fix For: 5.9.0 > > > When setting the attribute populateJMSXUserID="true" as documented [1] the > broker should populate the JMS message with the JMSXUserID property. > However, this is not the case. > I have configured the broker to require authentication and sent a message to > a Queue using the JMS producer shipped with the distribution. The message is > then inspected via JMX and the JMSXUserID property is not set. > [1] http://activemq.apache.org/jmsxuserid.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4717) populateJMSXUserID is not setting the JMSXUserID property on the JMS message in JMX
[ https://issues.apache.org/jira/browse/AMQ-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4717: --- Issue Type: Bug (was: New Feature) > populateJMSXUserID is not setting the JMSXUserID property on the JMS message > in JMX > --- > > Key: AMQ-4717 > URL: https://issues.apache.org/jira/browse/AMQ-4717 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.1, 5.6.0, 5.8.0 > Environment: OSX > java version "1.7.0_25" >Reporter: Jason Sherman >Assignee: Hiram Chirino > Labels: authentication > Fix For: 5.9.0 > > > When setting the attribute populateJMSXUserID="true" as documented [1] the > broker should populate the JMS message with the JMSXUserID property. > However, this is not the case. > I have configured the broker to require authentication and sent a message to > a Queue using the JMS producer shipped with the distribution. The message is > then inspected via JMX and the JMSXUserID property is not set. > [1] http://activemq.apache.org/jmsxuserid.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4717) populateJMSXUserID is not setting the JMSXUserID property on the JMS message in JMX
[ https://issues.apache.org/jira/browse/AMQ-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino resolved AMQ-4717. Resolution: Fixed Fix Version/s: 5.9.0 > populateJMSXUserID is not setting the JMSXUserID property on the JMS message > in JMX > --- > > Key: AMQ-4717 > URL: https://issues.apache.org/jira/browse/AMQ-4717 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.1, 5.6.0, 5.8.0 > Environment: OSX > java version "1.7.0_25" >Reporter: Jason Sherman >Assignee: Hiram Chirino > Labels: authentication > Fix For: 5.9.0 > > > When setting the attribute populateJMSXUserID="true" as documented [1] the > broker should populate the JMS message with the JMSXUserID property. > However, this is not the case. > I have configured the broker to require authentication and sent a message to > a Queue using the JMS producer shipped with the distribution. The message is > then inspected via JMX and the JMSXUserID property is not set. > [1] http://activemq.apache.org/jmsxuserid.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4717) populateJMSXUserID is not setting the JMSXUserID property on the JMS message in JMX
[ https://issues.apache.org/jira/browse/AMQ-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763100#comment-13763100 ] Hiram Chirino commented on AMQ-4717: The JMSXUserID was being set in the message but just not showing up when browsed via JMX. I've applied fix so that JMSXUserID shows up in JMX too. > populateJMSXUserID is not setting the JMSXUserID property on the JMS message > in JMX > --- > > Key: AMQ-4717 > URL: https://issues.apache.org/jira/browse/AMQ-4717 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.1, 5.6.0, 5.8.0 > Environment: OSX > java version "1.7.0_25" >Reporter: Jason Sherman >Assignee: Hiram Chirino > Labels: authentication > > When setting the attribute populateJMSXUserID="true" as documented [1] the > broker should populate the JMS message with the JMSXUserID property. > However, this is not the case. > I have configured the broker to require authentication and sent a message to > a Queue using the JMS producer shipped with the distribution. The message is > then inspected via JMX and the JMSXUserID property is not set. > [1] http://activemq.apache.org/jmsxuserid.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4717) populateJMSXUserID is not setting the JMSXUserID property on the JMS message in JMX
[ https://issues.apache.org/jira/browse/AMQ-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated AMQ-4717: --- Summary: populateJMSXUserID is not setting the JMSXUserID property on the JMS message in JMX (was: populateJMSXUserID is not setting the JMSXUserID property on the JMS message) > populateJMSXUserID is not setting the JMSXUserID property on the JMS message > in JMX > --- > > Key: AMQ-4717 > URL: https://issues.apache.org/jira/browse/AMQ-4717 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.1, 5.6.0, 5.8.0 > Environment: OSX > java version "1.7.0_25" >Reporter: Jason Sherman >Assignee: Hiram Chirino > Labels: authentication > > When setting the attribute populateJMSXUserID="true" as documented [1] the > broker should populate the JMS message with the JMSXUserID property. > However, this is not the case. > I have configured the broker to require authentication and sent a message to > a Queue using the JMS producer shipped with the distribution. The message is > then inspected via JMX and the JMSXUserID property is not set. > [1] http://activemq.apache.org/jmsxuserid.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (AMQ-4717) populateJMSXUserID is not setting the JMSXUserID property on the JMS message
[ https://issues.apache.org/jira/browse/AMQ-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino reassigned AMQ-4717: -- Assignee: Hiram Chirino > populateJMSXUserID is not setting the JMSXUserID property on the JMS message > > > Key: AMQ-4717 > URL: https://issues.apache.org/jira/browse/AMQ-4717 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.1, 5.6.0, 5.8.0 > Environment: OSX > java version "1.7.0_25" >Reporter: Jason Sherman >Assignee: Hiram Chirino > Labels: authentication > > When setting the attribute populateJMSXUserID="true" as documented [1] the > broker should populate the JMS message with the JMSXUserID property. > However, this is not the case. > I have configured the broker to require authentication and sent a message to > a Queue using the JMS producer shipped with the distribution. The message is > then inspected via JMX and the JMSXUserID property is not set. > [1] http://activemq.apache.org/jmsxuserid.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
