[jira] [Commented] (AMQ-4867) Plugins do not get initialized in a failover broker until it takes over
[ https://issues.apache.org/jira/browse/AMQ-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13823470#comment-13823470 ] Bhanu commented on AMQ-4867: Thanks Gary, Probably for now I'll contend with initializing the monitoring client in a separate bean (not the plugin way) before the persistent adapters block the broker. > Plugins do not get initialized in a failover broker until it takes over > --- > > Key: AMQ-4867 > URL: https://issues.apache.org/jira/browse/AMQ-4867 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.9.0 > Environment: linux >Reporter: Bhanu > > Hi, > We have a requirement where we want to initialize a plugin in the failover > broker. The problem is that the plugin is not initialized until the failover > broker takes over and becomes primary. Can some configuration be added to > make this work ? > Thanks & Regards, > Bhanu -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4867) Plugins do not get initialized in a failover broker until it takes over
[ https://issues.apache.org/jira/browse/AMQ-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821227#comment-13821227 ] Bhanu commented on AMQ-4867: Hi Gary, Thanks for your response and explanation. I need to monitor both the brokers. The monitoring team has provided us with Client APIs which initializes and establishes a connection with the monitoring server and does its heartbeating or whatever thing. Our both and primary and failover brokers run under extremely critical production environment and we *need* to *aggressively* monitor *even* the *failover* broker. Since if it goes down, we want to be notified at the earliest and take appropriate steps. That said we have a bunch of other ideas that we might want to implement via plugins and they again involve both the brokers. > Plugins do not get initialized in a failover broker until it takes over > --- > > Key: AMQ-4867 > URL: https://issues.apache.org/jira/browse/AMQ-4867 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.9.0 > Environment: linux >Reporter: Bhanu > > Hi, > We have a requirement where we want to initialize a plugin in the failover > broker. The problem is that the plugin is not initialized until the failover > broker takes over and becomes primary. Can some configuration be added to > make this work ? > Thanks & Regards, > Bhanu -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4867) Plugins do not get initialized in a failover broker until it takes over
Bhanu created AMQ-4867: -- Summary: Plugins do not get initialized in a failover broker until it takes over Key: AMQ-4867 URL: https://issues.apache.org/jira/browse/AMQ-4867 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.9.0 Environment: linux Reporter: Bhanu Hi, We have a requirement where we want to initialize a plugin in the failover broker. The problem is that the plugin is not initialized until the failover broker takes over and becomes primary. Can some configuration be added to make this work ? Thanks & Regards, Bhanu -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4830) ActiveMQ Mbeans do not show attributes consistently
[ https://issues.apache.org/jira/browse/AMQ-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813829#comment-13813829 ] Bhanu commented on AMQ-4830: Can anybody respond here please. > ActiveMQ Mbeans do not show attributes consistently > --- > > Key: AMQ-4830 > URL: https://issues.apache.org/jira/browse/AMQ-4830 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, JMX >Affects Versions: 5.8.0, 5.9.0 > Environment: Linux >Reporter: Bhanu > Attachments: jconsole_mbeans.PNG > > > Hi, > ActiveMQ Queues and Topics mbeans do not show the attributes consistently. > What I mean to say is if you would see the attached jconsole snippet, you > would find that some queues have attributes and operations, some have > attributes, operations and consumers but some have *only consumers* ! I use > the activemq-admin utility to retrieve these mbeans and the fact that not > every queue (or topic) has an attribute affects a lot of my scripts. > Can somebody please fix this or at least provide a plausible explanation for > this weird behavior ? > Thanks, > Bhanu -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4830) ActiveMQ Mbeans do not show attributes consistently
[ https://issues.apache.org/jira/browse/AMQ-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808802#comment-13808802 ] Bhanu commented on AMQ-4830: Ping !! > ActiveMQ Mbeans do not show attributes consistently > --- > > Key: AMQ-4830 > URL: https://issues.apache.org/jira/browse/AMQ-4830 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, JMX >Affects Versions: 5.8.0, 5.9.0 > Environment: Linux >Reporter: Bhanu > Attachments: jconsole_mbeans.PNG > > > Hi, > ActiveMQ Queues and Topics mbeans do not show the attributes consistently. > What I mean to say is if you would see the attached jconsole snippet, you > would find that some queues have attributes and operations, some have > attributes, operations and consumers but some have *only consumers* ! I use > the activemq-admin utility to retrieve these mbeans and the fact that not > every queue (or topic) has an attribute affects a lot of my scripts. > Can somebody please fix this or at least provide a plausible explanation for > this weird behavior ? > Thanks, > Bhanu -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4830) ActiveMQ Mbeans do not show attributes consistently
[ https://issues.apache.org/jira/browse/AMQ-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhanu updated AMQ-4830: --- Attachment: jconsole_mbeans.PNG > ActiveMQ Mbeans do not show attributes consistently > --- > > Key: AMQ-4830 > URL: https://issues.apache.org/jira/browse/AMQ-4830 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, JMX >Affects Versions: 5.8.0, 5.9.0 > Environment: Linux >Reporter: Bhanu > Attachments: jconsole_mbeans.PNG > > > Hi, > ActiveMQ Queues and Topics mbeans do not show the attributes consistently. > What I mean to say is if you would see the attached jconsole snippet, you > would find that some queues have attributes and operations, some have > attributes, operations and consumers but some have *only consumers* ! I use > the activemq-admin utility to retrieve these mbeans and the fact that not > every queue (or topic) has an attribute affects a lot of my scripts. > Can somebody please fix this or at least provide a plausible explanation for > this weird behavior ? > Thanks, > Bhanu -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4830) ActiveMQ Mbeans do not show attributes consistently
Bhanu created AMQ-4830: -- Summary: ActiveMQ Mbeans do not show attributes consistently Key: AMQ-4830 URL: https://issues.apache.org/jira/browse/AMQ-4830 Project: ActiveMQ Issue Type: Bug Components: Broker, JMX Affects Versions: 5.9.0, 5.8.0 Environment: Linux Reporter: Bhanu Attachments: jconsole_mbeans.PNG Hi, ActiveMQ Queues and Topics mbeans do not show the attributes consistently. What I mean to say is if you would see the attached jconsole snippet, you would find that some queues have attributes and operations, some have attributes, operations and consumers but some have *only consumers* ! I use the activemq-admin utility to retrieve these mbeans and the fact that not every queue (or topic) has an attribute affects a lot of my scripts. Can somebody please fix this or at least provide a plausible explanation for this weird behavior ? Thanks, Bhanu -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.
[ https://issues.apache.org/jira/browse/AMQ-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790377#comment-13790377 ] Bhanu commented on AMQ-796: --- Ping! Any updates here ? > Client may shtudown when failover connection is reconnecting. We need to > maintain at least 1 non-daemon thread alive. > -- > > Key: AMQ-796 > URL: https://issues.apache.org/jira/browse/AMQ-796 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0, 5.3.0 >Reporter: Hiram Chirino >Assignee: Rob Davies > Fix For: 5.6.0, 4.0.3 > > Attachments: AMQ-796.cmd, jstack_amq_5.6.0, jstack_v5.8.0 > > > Dejan Reported on the User lists: > Hi, > after some experiments I found that this problem only exists if there are no > other threads in the application. It seems like connection thread dies > before it manages to reconnect. By starting another thread in the > application, it succeeds to recover from master failure and reconnect to the > slave broker. So I have a workaround for now, but it would be nice to make > this work even for simple (single-threaded) clients. > Regards, > Dejan -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.
[ https://issues.apache.org/jira/browse/AMQ-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhanu updated AMQ-796: -- Attachment: jstack_v5.8.0 Attaching the jstack output for v5.8. The only non-daemon thread is the main thread which I stopped from exiting only for the purpose of taking a jstack snapshot. > Client may shtudown when failover connection is reconnecting. We need to > maintain at least 1 non-daemon thread alive. > -- > > Key: AMQ-796 > URL: https://issues.apache.org/jira/browse/AMQ-796 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0, 5.3.0 >Reporter: Hiram Chirino >Assignee: Rob Davies > Fix For: 5.6.0, 4.0.3 > > Attachments: AMQ-796.cmd, jstack_amq_5.6.0, jstack_v5.8.0 > > > Dejan Reported on the User lists: > Hi, > after some experiments I found that this problem only exists if there are no > other threads in the application. It seems like connection thread dies > before it manages to reconnect. By starting another thread in the > application, it succeeds to recover from master failure and reconnect to the > slave broker. So I have a workaround for now, but it would be nice to make > this work even for simple (single-threaded) clients. > Regards, > Dejan -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.
[ https://issues.apache.org/jira/browse/AMQ-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13789122#comment-13789122 ] Bhanu commented on AMQ-796: --- Still an issue with ActiveMQ v5.8 !! Can somebody resolve this please... > Client may shtudown when failover connection is reconnecting. We need to > maintain at least 1 non-daemon thread alive. > -- > > Key: AMQ-796 > URL: https://issues.apache.org/jira/browse/AMQ-796 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0, 5.3.0 >Reporter: Hiram Chirino >Assignee: Rob Davies > Fix For: 5.6.0, 4.0.3 > > Attachments: AMQ-796.cmd, jstack_amq_5.6.0 > > > Dejan Reported on the User lists: > Hi, > after some experiments I found that this problem only exists if there are no > other threads in the application. It seems like connection thread dies > before it manages to reconnect. By starting another thread in the > application, it succeeds to recover from master failure and reconnect to the > slave broker. So I have a workaround for now, but it would be nice to make > this work even for simple (single-threaded) clients. > Regards, > Dejan -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4693) Add kerberos [SASL] authentication for TCP connectors
[ https://issues.apache.org/jira/browse/AMQ-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhanu updated AMQ-4693: --- Summary: Add kerberos [SASL] authentication for TCP connectors (was: Add kerberos [SASL] authentcation for TCP connectors) > Add kerberos [SASL] authentication for TCP connectors > - > > Key: AMQ-4693 > URL: https://issues.apache.org/jira/browse/AMQ-4693 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.8.0 > Environment: linux, solaris >Reporter: Bhanu >Priority: Minor > Fix For: 5.10.0 > > > Hi, > Can kerberos based authentication be added to ActiveMQ's TCP connectors. > Thanks, > Bhanu -- 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-4693) Add kerberos authentcation for TCP connectors
[ https://issues.apache.org/jira/browse/AMQ-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754427#comment-13754427 ] Bhanu commented on AMQ-4693: Alright folks ! So can we conclude that adding a security plugin to do kerberos based authentication is NOT an option here? Tim, Christian -- Can we broaden the scope here and try add an SASL framework? The out-of-the-box implementation should provide GSSAPI based kerberos authentication and others like BASIC, PLAIN, DIGEST, MD5 could be added later. I understand that most ActiveMQ devs are too occupied in other stuff but I think its time that ActiveMQ be made more secure & robust in this regard since some of the other MQ products already support these things. > Add kerberos authentcation for TCP connectors > - > > Key: AMQ-4693 > URL: https://issues.apache.org/jira/browse/AMQ-4693 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.8.0 > Environment: linux, solaris >Reporter: Bhanu >Priority: Minor > > Hi, > Can kerberos based authentication be added to ActiveMQ's TCP connectors. > Thanks, > Bhanu -- 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-4693) Add kerberos authentcation for TCP connectors
[ https://issues.apache.org/jira/browse/AMQ-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753400#comment-13753400 ] Bhanu commented on AMQ-4693: It would be nice to have this in the v5.9. Also, currently only BASIC authentication mechanism is supported with AMQP SASL. Can kerberos based authentication added there too (just like QPID supports it.) Thanks, Bhanu > Add kerberos authentcation for TCP connectors > - > > Key: AMQ-4693 > URL: https://issues.apache.org/jira/browse/AMQ-4693 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.8.0 > Environment: linux, solaris >Reporter: Bhanu >Priority: Minor > > Hi, > Can kerberos based authentication be added to ActiveMQ's TCP connectors. > Thanks, > Bhanu -- 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-4693) Add kerberos authentcation for TCP connectors
Bhanu created AMQ-4693: -- Summary: Add kerberos authentcation for TCP connectors Key: AMQ-4693 URL: https://issues.apache.org/jira/browse/AMQ-4693 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.8.0 Environment: linux, solaris Reporter: Bhanu Hi, Can kerberos based authentication be added to ActiveMQ's TCP connectors. Thanks, Bhanu -- 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-4603) Errors while creating directory tmp_storage
[ https://issues.apache.org/jira/browse/AMQ-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhanu updated AMQ-4603: --- Description: Hi, I am time and again running into this error which says that Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'. Even though the reported error says cannot create activemq-data/amqProdBroker/tmp_storage'. Please note that this happens when I send a reply on a temp queue (say 2 out of 5 times). Is this some race condition with temp queues. Also Can someone please tell me or document somewhere what this tmp_storage is used for. Is it something do with temp queues?? My understanding was that broekr uses tmp_storage to offload non-persistent messages to disk when the configured in-memory limits are breached. Attaching detailed error log in a moment. Thanks, Bhanu was: Hi, I am time and again running into this error which says that Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'. Even though the reported error says cannot create activemq-data/amqProdBroker/tmp_storage' directory but actually the Directory that its not able to create is activemq-data/delayedDB. Now I have no clue about this delayedDB directory. Attaching detailed error log in a moment. Thanks, Bhanu > Errors while creating directory tmp_storage > --- > > Key: AMQ-4603 > URL: https://issues.apache.org/jira/browse/AMQ-4603 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 > Environment: Linux >Reporter: Bhanu > > Hi, > I am time and again running into this error which says that Failed to create > directory 'activemq-data/amqProdBroker/tmp_storage'. > Even though the reported error says cannot create > activemq-data/amqProdBroker/tmp_storage'. Please note that this happens when > I send a reply on a temp queue (say 2 out of 5 times). Is this some race > condition with temp queues. > Also Can someone please tell me or document somewhere what this tmp_storage > is used for. Is it something do with temp queues?? My understanding was that > broekr uses tmp_storage to offload non-persistent messages to disk when the > configured in-memory limits are breached. > Attaching detailed error log in a moment. > Thanks, > Bhanu -- 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-4603) Errors while creating directory tmp_storage
[ https://issues.apache.org/jira/browse/AMQ-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhanu updated AMQ-4603: --- Description: Hi, I am time and again running into this error which says that Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'. Even though the reported error says cannot create activemq-data/amqProdBroker/tmp_storage' directory but actually the Directory that its not able to create is activemq-data/delayedDB. Now I have no clue about this delayedDB directory. Attaching detailed error log in a moment. Thanks, Bhanu was: Hi, I am time and again running into this error which says that Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'. I went into the code and it seems like a bug to me. In IOHelper.mkdirs, broker simply throws an exception based on the return value of Java.io.File.mkdirs function. The java mkdirs returns false if the directory is already present. In my case activemq-data//tmp_storage is already present. So I run into this exception. Can this be handled more gracefully please. Attaching detailed error log in a moment. Thanks, Bhanu > Errors while creating directory tmp_storage > --- > > Key: AMQ-4603 > URL: https://issues.apache.org/jira/browse/AMQ-4603 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 > Environment: Linux >Reporter: Bhanu > > Hi, > I am time and again running into this error which says that Failed to create > directory 'activemq-data/amqProdBroker/tmp_storage'. > Even though the reported error says cannot create > activemq-data/amqProdBroker/tmp_storage' directory but actually the Directory > that its not able to create is activemq-data/delayedDB. Now I have no clue > about this delayedDB directory. > Attaching detailed error log in a moment. > Thanks, > Bhanu -- 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-4603) Errors while creating directory tmp_storage
[ https://issues.apache.org/jira/browse/AMQ-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13693932#comment-13693932 ] Bhanu commented on AMQ-4603: 2013-06-24 02:00:22,114 | ERROR | Caught an IO Exception getting the DiskList 29184_TopicSubscription:29127[ID:duke.hyd..com-31932-1370775167622-0:2:-1:1] | org.apache.activemq.broker.region.cursors.FilePendingMessageCursor | ActiveMQ Transport: tcp:///10.77.31.20:44101@61613 java.io.IOException: Failed to create directory 'activemq-data/amqProdBroker/tmp_storage' at org.apache.activemq.util.IOHelper.mkdirs(IOHelper.java:294) at org.apache.activemq.store.kahadb.plist.PListStoreImpl.intialize(PListStoreImpl.java:278) at org.apache.activemq.store.kahadb.plist.PListStoreImpl.getPList(PListStoreImpl.java:223) at org.apache.activemq.store.kahadb.plist.PListStoreImpl.getPList(PListStoreImpl.java:49) at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.getDiskList(FilePendingMessageCursor.java:463) at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.flushToDisk(FilePendingMessageCursor.java:441) at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:228) at org.apache.activemq.broker.region.TopicSubscription.add(TopicSubscription.java:149) at org.apache.activemq.broker.region.policy.SimpleDispatchPolicy.dispatch(SimpleDispatchPolicy.java:48) at org.apache.activemq.broker.region.Topic.dispatch(Topic.java:688) at org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:499) at org.apache.activemq.broker.region.Topic.send(Topic.java:435) at org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:406) at org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:392) at org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:282) at org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:550) at org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:481) at org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:476) at org.apache.activemq.advisory.AdvisoryBroker.addDestinationInfo(AdvisoryBroker.java:195) at org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) at org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) at org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) at org.apache.activemq.broker.MutableBrokerFilter.addDestinationInfo(MutableBrokerFilter.java:223) at org.apache.activemq.broker.util.LoggingBrokerPlugin.addDestinationInfo(LoggingBrokerPlugin.java:476) at org.apache.activemq.broker.MutableBrokerFilter.addDestinationInfo(MutableBrokerFilter.java:223) at org.apache.activemq.broker.TransportConnection.processAddDestination(TransportConnection.java:527) at org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:122) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:329) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:184) at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45) at org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:288) at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:84) at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:195) at org.apache.activemq.transport.stomp.ProtocolConverter.createTempDestination(ProtocolConverter.java:898) at org.apache.activemq.transport.stomp.LegacyFrameTranslator.convertDestination(LegacyFrameTranslator.java:195) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompSubscribe(ProtocolConverter.java:554) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:245) at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:73) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196) at java.lang.Thread.run(Thread.java:722) 2013-06-24 02:00:22,114 | ERROR | Caught an Exception adding a message: Message ID:txnref1.nyc..com-57965-1370699365762-1:1:0:0:1635050 dropped=false acked=false locked=false first to FilePendingMessageCursor | org.apache
[jira] [Created] (AMQ-4603) Errors while creating directory tmp_storage
Bhanu created AMQ-4603: -- Summary: Errors while creating directory tmp_storage Key: AMQ-4603 URL: https://issues.apache.org/jira/browse/AMQ-4603 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Linux Reporter: Bhanu Hi, I am time and again running into this error which says that Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'. I went into the code and it seems like a bug to me. In IOHelper.mkdirs, broker simply throws an exception based on the return value of Java.io.File.mkdirs function. The java mkdirs returns false if the directory is already present. In my case activemq-data//tmp_storage is already present. So I run into this exception. Can this be handled more gracefully please. Attaching detailed error log in a moment. Thanks, Bhanu -- 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-4551) WebClients should be able to send persistent messages
Bhanu created AMQ-4551: -- Summary: WebClients should be able to send persistent messages Key: AMQ-4551 URL: https://issues.apache.org/jira/browse/AMQ-4551 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.8.0 Environment: linux Reporter: Bhanu Hi guys, I am not able to send persistent messages from amq.js to the broker. The message intercepted and forwarded by the AjaxServlet and super classes set the persistence mode to false. Can we send persistent messages to ActiveMQ broker from browsers? Thanks, Bhanu -- 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-4545) ActiveMQ Ajax API does not provide support for setting JMS properties.
Bhanu created AMQ-4545: -- Summary: ActiveMQ Ajax API does not provide support for setting JMS properties. Key: AMQ-4545 URL: https://issues.apache.org/jira/browse/AMQ-4545 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.8.0 Reporter: Bhanu ActiveMQ Ajax API i.e amq.js does not have any support for setting message properties. The sendMessage() call accepts only two parameters:- destination and message. Can this be enhanced to support sending message properties like JMSReplyTo, JMSCorrelationID etc. Thanks, Bhanu -- 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-4425) Tomcat support in ActiveMQ
Bhanu created AMQ-4425: -- Summary: Tomcat support in ActiveMQ Key: AMQ-4425 URL: https://issues.apache.org/jira/browse/AMQ-4425 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.8.0 Environment: linux Reporter: Bhanu The AjaxServlet is tightly coupled with Jetty due to Jetty continuations. Now with Servlet 3.0 specification of suspendable requests, can something be done to make ActiveMQ easily be plugged with other servlet containers like tomcat? -- 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-3779) Allow logging broker plugin to use a log per destination
[ https://issues.apache.org/jira/browse/AMQ-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609203#comment-13609203 ] Bhanu commented on AMQ-3779: Hi Gary, I Was looking for exactly the same functionality for one of our new use cases. Was happy to found a request but seems like this has been long forgotten. Can this be taken up for the next version please? Thanks, Bhanu > Allow logging broker plugin to use a log per destination > > > Key: AMQ-3779 > URL: https://issues.apache.org/jira/browse/AMQ-3779 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.5.1 >Reporter: Gary Tully >Priority: Minor > Labels: logging, plugin > > Re: > http://activemq.2283324.n4.nabble.com/How-to-log-all-incoming-msgs-of-Queue-quot-hello-quot-into-a-separate-logfile-td4487917.html > Would be nice to configure the > http://activemq.apache.org/logging-interceptor.html to use a send message log > per destination so that destination messages can be easily partitioned. > A logPerDestination boolean attribute, that would cause the plugin to use a > logger of the form: > org.apache.activemq.broker.util.LoggingBrokerPlugin. for > producer send events > -- > Query on composites? > For the simplest implementation, composites, they would have their unique log > rather than parsing the composite and repeating the log message per > destination. -- 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-4381) Broker throwing exception "Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'"
[ https://issues.apache.org/jira/browse/AMQ-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13608793#comment-13608793 ] Bhanu commented on AMQ-4381: Yep, permissions were all fine. Yep it was on a network drive. Another interesting thing was broker did not die after throwing this. > Broker throwing exception "Failed to create directory > 'activemq-data/amqProdBroker/tmp_storage'" > > > Key: AMQ-4381 > URL: https://issues.apache.org/jira/browse/AMQ-4381 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.6.0 > Environment: Linux >Reporter: Bhanu > > We saw the below reported exception with broker today. The interesting thing > was the directory "activemq-data/amqProdBroker/tmp_storage" was already > present and accessible by broker. Can anyone shed a little light on this > weird broker behavior? > Async error occurred: java.lang.RuntimeException: java.lang.RuntimeException: > java.io.IOException: Failed to create direc > tory 'activemq-data/amqProdBroker/tmp_storage' | > org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: > tcp:///10.77.27.214:37710 > java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: > Failed to create directory 'activemq-data/amqProdBroker/tmp_storage' > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:239) > at > org.apache.activemq.broker.region.TopicSubscription.add(TopicSubscription.java:136) > at > org.apache.activemq.broker.region.policy.SimpleDispatchPolicy.dispatch(SimpleDispatchPolicy.java:48) > at org.apache.activemq.broker.region.Topic.dispatch(Topic.java:669) > at > org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:481) > at org.apache.activemq.broker.region.Topic.send(Topic.java:417) > at > org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:407) > at > org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:503) > at > org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:305) > at > org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:533) > at > org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:464) > at > org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:459) > at > org.apache.activemq.advisory.AdvisoryBroker.addDestinationInfo(AdvisoryBroker.java:182) > at > org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) > at > org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) > at > org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) > at > org.apache.activemq.broker.MutableBrokerFilter.addDestinationInfo(MutableBrokerFilter.java:223) > at > org.apache.activemq.broker.util.LoggingBrokerPlugin.addDestinationInfo(LoggingBrokerPlugin.java:476) > at > org.apache.activemq.broker.MutableBrokerFilter.addDestinationInfo(MutableBrokerFilter.java:223) > at > org.apache.activemq.broker.TransportConnection.processAddDestination(TransportConnection.java:477) > at > org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:122) > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292) > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:150) > at > org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45) > at > org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:229) > at > org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:87) > at > org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:126) > at > org.apache.activemq.transport.stomp.ProtocolConverter.createTempDestination(ProtocolConverter.java:742) > at > org.apache.activemq.transport.stomp.LegacyFrameTranslator.convertDestination(LegacyFrameTranslator.java:189) > at > org.apache.activemq.transport.stomp.ProtocolConverter.onStompSubscribe(ProtocolConverter.java:448) > at > org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:176) > at > org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:76) > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSu
[jira] [Commented] (AMQ-4383) ActiveMQ dependency not present in central maven repository ??
[ https://issues.apache.org/jira/browse/AMQ-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13608789#comment-13608789 ] Bhanu commented on AMQ-4383: Upgrading to Maven3 solved the issue. With Maven 1, the dependencies were not searched from repo.fusesource.com automatically. Thanks for the help guys. > ActiveMQ dependency not present in central maven repository ?? > -- > > Key: AMQ-4383 > URL: https://issues.apache.org/jira/browse/AMQ-4383 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 > Environment: Linux >Reporter: Bhanu > > We're facing issues while trying to upgrade to ActiveMQ v5.8. The maven build > is failing with the following error:- > > org.apache.activemq > activemq-all > 5.8.0 > > mvn package -Dmaven.test.skip=true > [INFO] Scanning for projects... > [INFO] > > [INFO] Building common > [INFO]task-segment: [package] > [INFO] > > [INFO] [resources:resources] > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory > /prod/desflow-qa/dflowdev/test/desflow/common/src/main/resources > Downloading: > http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.pom > Downloading: > http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.pom > Downloading: > http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.pom > Downloading: > http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar > Downloading: > http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar > Downloading: > http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar > Downloading: > http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.qpid:proton-jms:jar:0.3.0-fuse-2 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.qpid > -DartifactId=proton-jms -Dversion=0.3.0-fuse-2 -Dpackaging=jar > -Dfile=/path/to/file > Is something broken here ? > Thanks, > Bhanu -- 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-4383) ActiveMQ dependency not present in central maven repository ??
Bhanu created AMQ-4383: -- Summary: ActiveMQ dependency not present in central maven repository ?? Key: AMQ-4383 URL: https://issues.apache.org/jira/browse/AMQ-4383 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Linux Reporter: Bhanu We're facing issues while trying to upgrade to ActiveMQ v5.8. The maven build is failing with the following error:- org.apache.activemq activemq-all 5.8.0 mvn package -Dmaven.test.skip=true [INFO] Scanning for projects... [INFO] [INFO] Building common [INFO]task-segment: [package] [INFO] [INFO] [resources:resources] [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /prod/desflow-qa/dflowdev/test/desflow/common/src/main/resources Downloading: http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.pom Downloading: http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.pom Downloading: http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.pom Downloading: http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar Downloading: http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar Downloading: http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar Downloading: http://maven/deshaw/org/apache/qpid/proton-jms/0.3.0-fuse-2/proton-jms-0.3.0-fuse-2.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.qpid:proton-jms:jar:0.3.0-fuse-2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.qpid -DartifactId=proton-jms -Dversion=0.3.0-fuse-2 -Dpackaging=jar -Dfile=/path/to/file Is something broken here ? Thanks, Bhanu -- 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-4381) Broker throwing exception "Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'"
Bhanu created AMQ-4381: -- Summary: Broker throwing exception "Failed to create directory 'activemq-data/amqProdBroker/tmp_storage'" Key: AMQ-4381 URL: https://issues.apache.org/jira/browse/AMQ-4381 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.6.0 Environment: Linux Reporter: Bhanu We saw the below reported exception with broker today. The interesting thing was the directory "activemq-data/amqProdBroker/tmp_storage" was already present and accessible by broker. Can anyone shed a little light on this weird broker behavior? Async error occurred: java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: Failed to create direc tory 'activemq-data/amqProdBroker/tmp_storage' | org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: tcp:///10.77.27.214:37710 java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: Failed to create directory 'activemq-data/amqProdBroker/tmp_storage' at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:239) at org.apache.activemq.broker.region.TopicSubscription.add(TopicSubscription.java:136) at org.apache.activemq.broker.region.policy.SimpleDispatchPolicy.dispatch(SimpleDispatchPolicy.java:48) at org.apache.activemq.broker.region.Topic.dispatch(Topic.java:669) at org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:481) at org.apache.activemq.broker.region.Topic.send(Topic.java:417) at org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:407) at org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:503) at org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:305) at org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:533) at org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:464) at org.apache.activemq.advisory.AdvisoryBroker.fireAdvisory(AdvisoryBroker.java:459) at org.apache.activemq.advisory.AdvisoryBroker.addDestinationInfo(AdvisoryBroker.java:182) at org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) at org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) at org.apache.activemq.broker.BrokerFilter.addDestinationInfo(BrokerFilter.java:217) at org.apache.activemq.broker.MutableBrokerFilter.addDestinationInfo(MutableBrokerFilter.java:223) at org.apache.activemq.broker.util.LoggingBrokerPlugin.addDestinationInfo(LoggingBrokerPlugin.java:476) at org.apache.activemq.broker.MutableBrokerFilter.addDestinationInfo(MutableBrokerFilter.java:223) at org.apache.activemq.broker.TransportConnection.processAddDestination(TransportConnection.java:477) at org.apache.activemq.command.DestinationInfo.visit(DestinationInfo.java:122) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:150) at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45) at org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:229) at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:87) at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:126) at org.apache.activemq.transport.stomp.ProtocolConverter.createTempDestination(ProtocolConverter.java:742) at org.apache.activemq.transport.stomp.LegacyFrameTranslator.convertDestination(LegacyFrameTranslator.java:189) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompSubscribe(ProtocolConverter.java:448) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:176) at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:76) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:222) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:204) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.RuntimeException: java.io.IOException: Failed to create directory 'activemq-data/amqProdBroker/tmp_storage' at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.getDiskList(FilePendingMessageCursor.java:463) at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor
[jira] [Created] (AMQ-4267) Huge tx-*.tmp file in the kahadb directory
Bhanu created AMQ-4267: -- Summary: Huge tx-*.tmp file in the kahadb directory Key: AMQ-4267 URL: https://issues.apache.org/jira/browse/AMQ-4267 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.6.0 Environment: linux Reporter: Bhanu Hi, While destroying a durable subscription via jconsole, I suddenly saw broker dumping a 7.5 GB tx-1370965-1358923245272.tmp file in the kahadb directory. It subsequently died and on restarting the tmp file got removed. Can you please tell us why that file was created and broker died? We have not seen this before but this happened in production today. Thanks, Bhanu -- 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-4264) ActiveMQ dying with exception detected missing/corrupt journal files
Bhanu created AMQ-4264: -- Summary: ActiveMQ dying with exception detected missing/corrupt journal files Key: AMQ-4264 URL: https://issues.apache.org/jira/browse/AMQ-4264 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.6.0 Environment: linux Reporter: Bhanu Hi, Yesterday, our ActiveMQ broker suddenly died with the exception pasted below. It failed to come up on repeated attempts and we could only bring it back after clearing the kahadb data and redo files. We havent seen this issue in the past. Can you suggest some pointers here on why this would have happened suddenly? Is this a known issue which is going to be fixed in future versions ? ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:98) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.activemq.console.Main.runTaskClass(Main.java:257) at org.apache.activemq.console.Main.main(Main.java:111) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml]: Invocation of init method failed; nested exception is java.io.IOException: Detected missing/corrupt journal files. 124512 messages affected. at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:64) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:52) at org.apache.activemq.xbean.XBeanBrokerFactory$1.(XBeanBrokerFactory.java:108) at org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:108) at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:72) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71) at org.apache.activemq.broker.BrokerFactory.createBroker(Brok
[jira] [Created] (AMQ-3990) Exceptions while launching activemq via init.d
Bhanu created AMQ-3990: -- Summary: Exceptions while launching activemq via init.d Key: AMQ-3990 URL: https://issues.apache.org/jira/browse/AMQ-3990 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.5.1 Environment: linux Reporter: Bhanu Hi, I am following the steps mentioned here - http://activemq.apache.org/unix-service.html to start my broker automatically on linux reboots via init.d. I am running into this weird exception :- ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 23 in X ML document from URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml] is invalid; nested exception is org.xml.sax.SAXParseException; l ineNumber: 23; columnNumber: 52; cvc-elt.1: Cannot find the declaration of element 'beans'. java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 23 in XML docu ment from URL [file:/prod/tools/base/etc/config/activemq/amq_prod_broker_config.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumb er: 23; columnNumber: 52; cvc-elt.1: Cannot find the declaration of element 'beans'. Please note that I am properly able to launch the broker using command line but I am getting this exception while launching on machine startup using init.d Please help. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.
[ https://issues.apache.org/jira/browse/AMQ-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416134#comment-13416134 ] Bhanu commented on AMQ-796: --- This issue still persists. attaching the jstack on broker. It still doesn't show any non-daemon thread which would have fixed the issue i guess. > Client may shtudown when failover connection is reconnecting. We need to > maintain at least 1 non-daemon thread alive. > -- > > Key: AMQ-796 > URL: https://issues.apache.org/jira/browse/AMQ-796 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0, 5.3.0 >Reporter: Hiram Chirino >Assignee: Rob Davies > Fix For: 5.6.0, 4.0.3 > > Attachments: AMQ-796.cmd, jstack_amq_5.6.0 > > > Dejan Reported on the User lists: > Hi, > after some experiments I found that this problem only exists if there are no > other threads in the application. It seems like connection thread dies > before it manages to reconnect. By starting another thread in the > application, it succeeds to recover from master failure and reconnect to the > slave broker. So I have a workaround for now, but it would be nice to make > this work even for simple (single-threaded) clients. > Regards, > Dejan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-796) Client may shtudown when failover connection is reconnecting. We need to maintain at least 1 non-daemon thread alive.
[ https://issues.apache.org/jira/browse/AMQ-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhanu updated AMQ-796: -- Attachment: jstack_amq_5.6.0 > Client may shtudown when failover connection is reconnecting. We need to > maintain at least 1 non-daemon thread alive. > -- > > Key: AMQ-796 > URL: https://issues.apache.org/jira/browse/AMQ-796 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 4.0, 5.3.0 >Reporter: Hiram Chirino >Assignee: Rob Davies > Fix For: 5.6.0, 4.0.3 > > Attachments: AMQ-796.cmd, jstack_amq_5.6.0 > > > Dejan Reported on the User lists: > Hi, > after some experiments I found that this problem only exists if there are no > other threads in the application. It seems like connection thread dies > before it manages to reconnect. By starting another thread in the > application, it succeeds to recover from master failure and reconnect to the > slave broker. So I have a workaround for now, but it would be nice to make > this work even for simple (single-threaded) clients. > Regards, > Dejan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3917) ActiveMQ should support multiple durable subscriptions per Stomp client
Bhanu created AMQ-3917: -- Summary: ActiveMQ should support multiple durable subscriptions per Stomp client Key: AMQ-3917 URL: https://issues.apache.org/jira/browse/AMQ-3917 Project: ActiveMQ Issue Type: Bug Components: Broker, stomp Affects Versions: 5.6.0, 5.5.1 Environment: linux, solaris Reporter: Bhanu This is coming from AMQ-3802. Quoting Timothy - "This is another limitation of the Stomp support which allows for only one durable subscription since clientId and subscription name are linked. This is because the Stomp v1.0 spec didn't require that you assign unique Ids to subscriptions, so the correlation is made per connection using the matching clientId and subscription name. You can work around this by creating a connection for each durable subscriber." Now, since ActiveMQ v5.6.0 supports Stomp v1.1 which has made the id header mandatory for subscribe and unsubscribe calls, we should leverage this feature and allow for multiple durable subscriptions per stomp client. Hacks like creating a separate connection for each durable subscriber should be avoided. Let me know if you have any queries? Thanks, Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3916) ActiveMQ version 5.7.0 ??
Bhanu created AMQ-3916: -- Summary: ActiveMQ version 5.7.0 ?? Key: AMQ-3916 URL: https://issues.apache.org/jira/browse/AMQ-3916 Project: ActiveMQ Issue Type: Wish Components: Broker Affects Versions: 5.6.0 Environment: solaris, linux Reporter: Bhanu Hi, Given that multi kahadb is broken in version 5.6.0 which was one of the major features in this version, when can we expect ActiveMQ 5.7.0 to be out ?? Can you guys release a 5.6.1 since mKahadb has been fixed in trunk i believe. Please refer https://issues.apache.org/jira/browse/AMQ-3841 Thanks, Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3910) Send fails while using STOMP
[ https://issues.apache.org/jira/browse/AMQ-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406292#comment-13406292 ] Bhanu commented on AMQ-3910: Yes the perl producer fails to send the message. I've checked the logs and broker does not report anything amiss. Is there a special configuration for message size too? We have configured the system usage and heap limits to have pretty large values. > Send fails while using STOMP > > > Key: AMQ-3910 > URL: https://issues.apache.org/jira/browse/AMQ-3910 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.1 > Environment: linux, solaris >Reporter: Bhanu > > We're using STOMP 1.0 and broker 5.5.1. We see that sometimes while sending > messages on stomp using perl client, the send calls fails. We are providing a > high enough value so that the send does not timeout. It fails half a dozen > times and eventually succeeds. > Digging in the STOMP module shows that this exception is thrown when the > output buffer is unable to write all the data to the socket. Our message size > is ~10-20mb. Can you please provide your expertise on why the socket is not > ready sometimes to send the message. > Thanks, > Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3910) Send fails while using STOMP
Bhanu created AMQ-3910: -- Summary: Send fails while using STOMP Key: AMQ-3910 URL: https://issues.apache.org/jira/browse/AMQ-3910 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.5.1 Environment: linux, solaris Reporter: Bhanu We're using STOMP 1.0 and broker 5.5.1. We see that sometimes while sending messages on stomp using perl client, the send calls fails. We are providing a high enough value so that the send does not timeout. It fails half a dozen times and eventually succeeds. Digging in the STOMP module shows that this exception is thrown when the output buffer is unable to write all the data to the socket. Our message size is ~10-20mb. Can you please provide your expertise on why the socket is not ready sometimes to send the message. Thanks, Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3874) Unable to destroy a durable subscription
[ https://issues.apache.org/jira/browse/AMQ-3874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295088#comment-13295088 ] Bhanu commented on AMQ-3874: Yes Gary, I verified on the broker side that no dangling hard connection was there. > Unable to destroy a durable subscription > > > Key: AMQ-3874 > URL: https://issues.apache.org/jira/browse/AMQ-3874 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.1 > Environment: solaris, linux >Reporter: Bhanu > > I think theres an issue that occurs sometimes while removing durable > subscriptions from the broker. This has hit us second time in a week that > when a perl durable subscriber using stomp goes down, it is not shown as > inactive in broker. Even though there were no active connections(did a > thorough lsof check) somehow broker thought that the subscriber was active. > Whats more worse is trying to destroy that subscription via jconsole gives an > error : > "Problem invoking destroy: java.rmi.UnmarshallException: Error unmarshalling > return; nested exception is java.lang.ClassNotFoundException: > javax.jms.InvalidDestinationException (no security manager: RMI class loader > disabled)" > Since we cannot destroy this subscription, the client cannot come up with the > same client Id and subscription name. This is not reproducible easily > but is some weird corner case. Can somebody please check. Let me know if you > have more queries. > Thanks & Regards > Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3874) Unable to destroy a durable subscription
Bhanu created AMQ-3874: -- Summary: Unable to destroy a durable subscription Key: AMQ-3874 URL: https://issues.apache.org/jira/browse/AMQ-3874 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.5.1 Environment: solaris, linux Reporter: Bhanu I think theres an issue that occurs sometimes while removing durable subscriptions from the broker. This has hit us second time in a week that when a perl durable subscriber using stomp goes down, it is not shown as inactive in broker. Even though there were no active connections(did a thorough lsof check) somehow broker thought that the subscriber was active. Whats more worse is trying to destroy that subscription via jconsole gives an error : "Problem invoking destroy: java.rmi.UnmarshallException: Error unmarshalling return; nested exception is java.lang.ClassNotFoundException: javax.jms.InvalidDestinationException (no security manager: RMI class loader disabled)" Since we cannot destroy this subscription, the client cannot come up with the same client Id and subscription name. This is not reproducible easily but is some weird corner case. Can somebody please check. Let me know if you have more queries. Thanks & Regards Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3802) Successful unsubscribing should not report inactive durable topic subscribers
[ https://issues.apache.org/jira/browse/AMQ-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267430#comment-13267430 ] Bhanu commented on AMQ-3802: Presto !!! Works like a charm for me :) Thanks Tim. We should let Buchi also confirm this. > Successful unsubscribing should not report inactive durable topic subscribers > - > > Key: AMQ-3802 > URL: https://issues.apache.org/jira/browse/AMQ-3802 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.1 > Environment: Solaris,Linux >Reporter: Bhanu > > An unsubscribe call should remove the client from inactive durable topic > subscribers list. In the current broker behavior, even if a durable consumer > unsubscribes & shuts down gracefully, the broker marks the durable subscriber > as inactive. If this durable subscriber was never meant to come up again(as > in my case where i am testing rigorously using unique client-ids each time > based on pid) then broker will unnecessarily mark a lot of consumers as > inactive durable. > For inactive durable subscribers, there is no distinction between a > subscriber going down abruptly or unsubscribing & going down gracefully. > This should be improved I think. Moreover, any tips on how to remove those > 1000s of inactive subscriptions dangling in my Jconsole ?? Destroying each > manually isn't an option ! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3826) Lot of unmatched ackowledge warnings
Bhanu created AMQ-3826:
--
Summary: Lot of unmatched ackowledge warnings
Key: AMQ-3826
URL: https://issues.apache.org/jira/browse/AMQ-3826
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.5.1
Reporter: Bhanu
Hello,
We are getting a lot of these kind of exceptions in broker logs.
activemq.log.2012-02-29:2012-02-29 19:10:32,872 | WARN | Async error occurred:
javax.jms.JMSException: Unmatched acknowledge: MessageAck {commandId = 80173,
responseRequired = false, ackType = 2, consumerId =
ID:desa1186.nyc.deshaw.com-61574-1329905029635-2:3:60:1, firstMessageId = null,
lastMessageId = ID:desb0444.nyc.deshaw.com-49820-1330523262004-0:618:2:1:1,
destination = queue://tca.heartbeat, transactionId = null, messageCount = 1,
poisonCause = null}; Expected message count (1) differs from count in
dispatched-list (2) | org.apache.activemq.broker.TransportConnection.Service |
ActiveMQ Transport: tcp:///10.253.127.196:46192
I did some googling and found that these can occur while using failover(either
by failover API or failover broker). But we are not using any failover in the
setup where these exceptions are occuring. I am not able to reproduce them
either. They occur during the day randomly.
Any ideas on why they are being logged?
Thanks,
Bhanu
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3826) Lot of unmatched ackowledge warnings
[
https://issues.apache.org/jira/browse/AMQ-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267401#comment-13267401
]
Bhanu commented on AMQ-3826:
We are not using any transactions either !
> Lot of unmatched ackowledge warnings
>
>
> Key: AMQ-3826
> URL: https://issues.apache.org/jira/browse/AMQ-3826
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.5.1
>Reporter: Bhanu
>
> Hello,
> We are getting a lot of these kind of exceptions in broker logs.
> activemq.log.2012-02-29:2012-02-29 19:10:32,872 | WARN | Async error
> occurred: javax.jms.JMSException: Unmatched acknowledge: MessageAck
> {commandId = 80173, responseRequired = false, ackType = 2, consumerId =
> ID:desa1186.nyc.deshaw.com-61574-1329905029635-2:3:60:1, firstMessageId =
> null, lastMessageId =
> ID:desb0444.nyc.deshaw.com-49820-1330523262004-0:618:2:1:1, destination =
> queue://tca.heartbeat, transactionId = null, messageCount = 1, poisonCause =
> null}; Expected message count (1) differs from count in dispatched-list (2) |
> org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport:
> tcp:///10.253.127.196:46192
> I did some googling and found that these can occur while using
> failover(either by failover API or failover broker). But we are not using any
> failover in the setup where these exceptions are occuring. I am not able to
> reproduce them either. They occur during the day randomly.
> Any ideas on why they are being logged?
> Thanks,
> Bhanu
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3825) Exceptions in broker logs :- Transport failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long:
Bhanu created AMQ-3825: -- Summary: Exceptions in broker logs :- Transport failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: Key: AMQ-3825 URL: https://issues.apache.org/jira/browse/AMQ-3825 Project: ActiveMQ Issue Type: Bug Components: Broker, Connector Affects Versions: 5.5.1 Reporter: Bhanu Hi, I am seeing lot of InactivityIO exceptions in my broker logs:- activemq.log.2012-03-01:2012-03-01 18:56:49,519 | INFO | Transport failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: /10.240.170.27:42813 | org.apache.activemq.broker.TransportConnection.Transport | InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@8fe952[State = 0, empty queue] activemq.log.2012-03-01:2012-03-01 19:06:52,464 | INFO | Transport failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: /10.253.127.196:62265 | org.apache.activemq.broker.TransportConnection.Transport | InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@1501b4f[State = 0, empty queue] activemq.log.2012-03-01:2012-03-01 19:27:37,074 | INFO | Transport failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: /149.77.160.18:52472 | org.apache.activemq.broker.TransportConnection.Transport | InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@19e0323[State = 0, empty queue] activemq.log.2012-03-01:2012-03-01 23:33:51,632 | INFO | Transport failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: /149.77.160.18:33558 | org.apache.activemq.broker.TransportConnection.Transport | InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@168a9ba[State = 0, empty queue] activemq.log.2012-03-01:2012-03-01 23:33:56,975 | INFO | Transport failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>3) long: /149.77.160.18:55158 | org.apache.activemq.broker.TransportConnection.Transport | InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@116f46b[State = 0, empty queue] I am trying to reproduce this with the pooled connection factory but this is not consistently reproducible. Can somebody throw light on the exact cause of this. I don't want to use the inactivityMonitor property. Thanks, Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3802) Successful unsubscribing should not report inactive durable topic subscribers
[
https://issues.apache.org/jira/browse/AMQ-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267206#comment-13267206
]
Bhanu commented on AMQ-3802:
Tim,
I was playing around with Buchi's test, made some pretty minor changes and I am
getting the below exception that durable consumer is in use !
2012-05-03 10:59:21,204 | INFO | Removing subscription :
RemoveSubscriptionInfo {commandId = 4, responseRequired = false, connectionId =
ID:desh0007.hyd.desh
aw.com-59732-1336021109112-3:8, clientId = test, subscriptionName = test} |
org.apache.activemq.broker.util.LoggingBrokerPlugin | ActiveMQ Transport:
tcp:///1
0.240.170.27:42262
2012-05-03 10:59:21,205 | WARN | Async error occurred: javax.jms.JMSException:
Durable consumer is in use | org.apache.activemq.broker.TransportConnection.S
ervice | ActiveMQ Transport: tcp:///10.240.170.27:42262
javax.jms.JMSException: Durable consumer is in use
at
org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:138)
at
org.apache.activemq.broker.region.RegionBroker.removeSubscription(RegionBroker.java:491)
at
org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
at
org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
at
org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
at
org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
at
org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
at
org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107)
at
org.apache.activemq.broker.util.LoggingBrokerPlugin.removeSubscription(LoggingBrokerPlugin.java:211)
at
org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
at
org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107)
at
org.apache.activemq.broker.TransportConnection.processRemoveSubscription(TransportConnection.java:342)
at
org.apache.activemq.command.RemoveSubscriptionInfo.visit(RemoveSubscriptionInfo.java:81)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:306)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69)
at
org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:81)
at
org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:140)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:456)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:190)
at
org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:70)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:220)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:202)
at java.lang.Thread.run(Thread.java:722)
2012-05-03 10:59:21,205 | WARN | Exception occurred processing:
null: javax.jms.JMSException: Durable consumer is in use |
org.apache.activemq.transport.stomp.ProtocolConverter | ActiveMQ Connection
Dispatcher: /10.240.170.27:42262
Any clues !?
> Successful unsubscribing should not report inactive durable topic subscribers
> -
>
> Key: AMQ-3802
> URL: https://issues.apache.org/jira/browse/AMQ-3802
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.5.1
> Environment: Solaris,Linux
>Reporter: Bhanu
>
> An unsubscribe call should remove the client from inactive durable topic
> subscribers list. In the current broker behavior, even if a durable consumer
> unsubscribes & shuts down gracefully, the broker marks the durable subscriber
> as inactive. If this durable subscriber was never meant to come up again(as
> in my case where i am testing rigorously using unique client-ids each time
> based on pid) then broker will unnecessarily mark a lot of consumers as
> inactive durable.
> For inactive durable subscribers, there is no distinction between a
> subscriber going down abruptly or unsubscribing & going down gracefully.
> This should be improved I think. Moreover, any tips on how to remove those
> 1000s of inactive subscriptions dangling in my Jconsole ?? Destroying each
> manually isn't an option !
[jira] [Commented] (AMQ-3821) activemq-admin tool showing incorrect/inconsistent output occassionaly
[ https://issues.apache.org/jira/browse/AMQ-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266345#comment-13266345 ] Bhanu commented on AMQ-3821: Okay, figured out the ID_whatever are the temp queues but the issue still holds for Advisory topics ! > activemq-admin tool showing incorrect/inconsistent output occassionaly > -- > > Key: AMQ-3821 > URL: https://issues.apache.org/jira/browse/AMQ-3821 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.5.1 > Environment: solaris, linux >Reporter: Bhanu > > Hello, > There seems to be a bug in activemq-admin tool. > I'm using the command:- > activemq-admin query --view Destination -xQTopic=ActiveMQ.Advisory.* > --jmxurl service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi > I have a job which run this command every hour and do some processing over > the output. The problem is the destinations reported by the tool are > sometimes false. > Occasionally, I'm getting these kind of destinations in the output which I > thoroughly checked that is a connection ID and absolutely not(and never was) > a destination. > Destination = ID_myhost.com-57923-1335027404174-2_49303_1 > Also, I am sometimes getting 1 or 2 Advisory topics in the output. Please > check if this is a bug in the view option of the activemq-admin utility or > goes somewhere deep in the java code. > Thanks, > Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3821) activemq-admin tool showing incorrect/inconsistent output occassionaly
Bhanu created AMQ-3821: -- Summary: activemq-admin tool showing incorrect/inconsistent output occassionaly Key: AMQ-3821 URL: https://issues.apache.org/jira/browse/AMQ-3821 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.5.1 Environment: solaris, linux Reporter: Bhanu Hello, There seems to be a bug in activemq-admin tool. I'm using the command:- activemq-admin query --view Destination -xQTopic=ActiveMQ.Advisory.* --jmxurl service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi I have a job which run this command every hour and do some processing over the output. The problem is the destinations reported by the tool are sometimes false. Occasionally, I'm getting these kind of destinations in the output which I thoroughly checked that is a connection ID and absolutely not(and never was) a destination. Destination = ID_myhost.com-57923-1335027404174-2_49303_1 Also, I am sometimes getting 1 or 2 Advisory topics in the output. Please check if this is a bug in the view option of the activemq-admin utility or goes somewhere deep in the java code. Thanks, Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3815) Hybrid Master Slave Architecture
[ https://issues.apache.org/jira/browse/AMQ-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262534#comment-13262534 ] Bhanu commented on AMQ-3815: Hello, Any updates here please ! > Hybrid Master Slave Architecture > > > Key: AMQ-3815 > URL: https://issues.apache.org/jira/browse/AMQ-3815 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.5.1 > Environment: solaris, linux >Reporter: Bhanu > > Hi, > Can we have a Hybrid Master Slave Architecture where in we can merge the > functionalities of pure master slave and shared file system master slave. > Basically, we have a disaster recovery requirement wherein we want to > simulataneously run three brokers. A master broker will serve all the client > requests, a slave broker at the same site on a different host will try to > acquire the lock on kahadb(a typical slave). And we need a third broker to > run at a *different site* which should fully replicate the state of the > current master. This slave host should only be started when both the master > and first slave are down. > Can we do it with the current ActiveMQ transports/configurations or this will > need enhancements. > Please let me know if you have any queries regarding this. > Thanks, > Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-3815) Hybrid Master Slave Architecture
Bhanu created AMQ-3815: -- Summary: Hybrid Master Slave Architecture Key: AMQ-3815 URL: https://issues.apache.org/jira/browse/AMQ-3815 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.5.1 Environment: solaris, linux Reporter: Bhanu Hi, Can we have a Hybrid Master Slave Architecture where in we can merge the functionalities of pure master slave and shared file system master slave. Basically, we have a disaster recovery requirement wherein we want to simulataneously run three brokers. A master broker will serve all the client requests, a slave broker at the same site on a different host will try to acquire the lock on kahadb(a typical slave). And we need a third broker to run at a *different site* which should fully replicate the state of the current master. This slave host should only be started when both the master and first slave are down. Can we do it with the current ActiveMQ transports/configurations or this will need enhancements. Please let me know if you have any queries regarding this. Thanks, Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
