http://permalink.gmane.org/gmane.comp.java.activemq.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.activemq.devel/31697 <pre> [ https://issues.apache.org/jira/browse/AMQCPP-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-403. --------------------------------- Resolution: Fixed Fix applied on the 3.4.x branch. Already resolved in trunk. -- 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 </pre> Timothy Bish (JIRA 2012-05-16T23:31:06 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31696 <pre>Timothy Bish created AMQCPP-403: ----------------------------------- Summary: Possible for memory to leak when using transacted producer with failover Key: AMQCPP-403 URL: https://issues.apache.org/jira/browse/AMQCPP-403 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl, Transports Affects Versions: 3.4.2 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 3.4.3 Its possible for a memory leak to occur when running a transacted producer and the failover transport is used. If the TX commit is the last command when the failure occurs the TX needs to be rolled back since there's no way to know if the command made it or not. -- 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://ww</pre> Timothy Bish (JIRA 2012-05-16T23:29:06 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31695 <pre>Chris Geer created AMQ-3847: ------------------------------- Summary: Optional import for org.apache.activemq.pool in activemq-camel should be required Key: AMQ-3847 URL: https://issues.apache.org/jira/browse/AMQ-3847 Project: ActiveMQ Issue Type: Bug Components: activemq-camel Affects Versions: 5.6.0 Reporter: Chris Geer Ref AMQ-2502 Since activemq-camel really requires pools this should be marked required. -- 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 </pre> Chris Geer (JIRA 2012-05-16T17:15:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31694 <pre>David Harp created AMQ-3846: ------------------------------- Summary: The JMX message move, copy and remove operation do not take messages in FIFO order Key: AMQ-3846 URL: https://issues.apache.org/jira/browse/AMQ-3846 Project: ActiveMQ Issue Type: Bug Components: JMX Affects Versions: 5.6.0, 5.5.1 Reporter: David Harp When a page is pulled in, it is placed in a LinkedHashMap which preserves the queue order, but the below code then pulls the values from the LinkedHashMap and puts them in a Set. This causes the FIFO order of the queue to be lost. If the number of max messages to move is smaller the the page size, then the outcome looks like random messages from the queue being moved (copied or removed). ... Set&lt;MessageReference&gt; set = new HashSet&lt;MessageReference&gt;(); ConnectionContext context = createConnectionContext(); do { doPageIn(true); pagedInMessagesLock.readLock().</pre> David Harp (JIRA 2012-05-16T16:09:03 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31693 <pre>Timothy Bish created AMQCPP-402: ----------------------------------- Summary: Fix ConnectionStateTracker processMessageAck Key: AMQCPP-402 URL: https://issues.apache.org/jira/browse/AMQCPP-402 Project: ActiveMQ C++ Client Issue Type: Bug Components: Openwire, Transports Affects Versions: 3.4.2 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 3.5.0, 3.4.3 In ConnectionStateTracker the method that processes message acks should not be processing anything, which it doesn't by accident. Remove the code in the 3.4.x branch, and remove the method on trunk. The acks will be stale so don't track them and let rollback deal with it. -- 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</pre> Timothy Bish (JIRA 2012-05-16T15:05:03 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31692 <pre>Mike Bryant created AMQ-3845: -------------------------------- Summary: CachedLDAPAuthorizationMap doesn't handle the ldap connectino dying Key: AMQ-3845 URL: https://issues.apache.org/jira/browse/AMQ-3845 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.6.0 Reporter: Mike Bryant If the ldap connection dies for some reason (ldap server restarting etc.), the broker will continue to attempt to use the old connection for authorization, resulting in all attempts to use the broker being denied. In CachedLDAPAuthorizationMap.java, the open() function just returns the context if one exists. Instead, it should check to see if the context is still valid, and if not create one. Alternatively, the caching of the ldap connection can be removed entirely, and then in the refreshInterval&gt;0 case, a new ldap connection will be made each refresh interval (default setting: every 5 minutes). i.e. delete t</pre> Mike Bryant (JIRA 2012-05-16T14:07:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31691 <pre> [ https://issues.apache.org/jira/browse/AMQ-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13276684#comment-13276684 ] Timothy Bish commented on AMQ-3816: ----------------------------------- Problem ActiveMQ can't be responsible for client code that we didn't write, and a perl module wouldn't go into the unit tests to ensure that anything that did get fixed stayed fixed in the future. I haven't had time to look any further at this but from the testing I did I could not find any issues on the broker side. You can use the numerous test cases already present in AMQ to try to create something that reproduces your problem if you want to contribute. -- 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 </pre> Timothy Bish (JIRA 2012-05-16T12:09:07 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31690 <pre> [ https://issues.apache.org/jira/browse/AMQ-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13276667#comment-13276667 ] Buchi Reddy B commented on AMQ-3816: ------------------------------------ &lt; at &gt;Timothy did you test this case with Perl code? I personally feel that there are some differences in Perl and Java STOMP implementations and some issues (like this one) might be real issues only in Perl STOMP clients. -- 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 </pre> Buchi Reddy B (JIRA 2012-05-16T11:31:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31689 <pre> [ https://issues.apache.org/jira/browse/AMQ-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Buchi Reddy B closed AMQ-3811. ------------------------------ Resolution: Not A Problem I think this was not an issue on the broker side. I fixed client side code and it started working fine. -- 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 </pre> Buchi Reddy B (JIRA 2012-05-16T11:29:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31688 <pre> [ https://issues.apache.org/jira/browse/AMQ-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=13276664#comment-13276664 ] Buchi Reddy B commented on AMQ-3834: ------------------------------------ Any updates on this? Did you get a chance to look at this? -- 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 </pre> Buchi Reddy B (JIRA 2012-05-16T11:27:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31687 <pre> [ https://issues.apache.org/jira/browse/AMQ-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio D'Errico updated AMQ-3844: ---------------------------------- Description: Sometimes off and on the ActiveMQ server, the KahaDB maintains some old transactions that try to recovery. So at start up these transactions are added to the {{xaTransactions}} map inside {{TransactionBroker}} with a null {{ConnectionId}}. This is the stack trace of the recovery at startup: {code:none} TransactionBroker.beginTransaction(ConnectionContext, TransactionId) line: 152 TransactionBroker$1.recover(XATransactionId, Message[], MessageAck[]) line: 92 KahaDBTransactionStore.recover(TransactionRecoveryListener) line: 317 TransactionBroker.start() line: 89 BrokerService$3.start() line: 1781 XBeanBrokerService(BrokerService).start() line: 489 XBeanBrokerService.afterPropertiesSet() line: 60 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native me</pre> Antonio D'Errico (JIRA 2012-05-16T10:19:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31686 <pre> [ https://issues.apache.org/jira/browse/AMQ-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio D'Errico updated AMQ-3844: ---------------------------------- Attachment: jBoss_server.log ActiveMQ_server.log -- 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 </pre> Antonio D'Errico (JIRA 2012-05-16T10:19:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31685 <pre>Antonio D'Errico created AMQ-3844: ------------------------------------- Summary: NullPointerException when removing connection info Key: AMQ-3844 URL: https://issues.apache.org/jira/browse/AMQ-3844 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.5.1, 5.4.3 Environment: Linux 2.6.18-274.12.1.el5 #1 SMP Tue Nov 29 13:37:35 EST 2011 i686 athlon i386 GNU/Linux, Java(TM) SE Runtime Environment (build 1.6.0_29-b11) Reporter: Antonio D'Errico Sometimes off and on the KahaDB maintains some old transactions that try to recovery. So at start up these transactions are added to the {{xaTransactions}} inside {{TransactionBroker}} with a null {{ConnectionId}}. This is the stack trace of the recovery {code:none} TransactionBroker.beginTransaction(ConnectionContext, TransactionId) line: 152 TransactionBroker$1.recover(XATransactionId, Message[], MessageAck[]) line: 92 KahaDBTransactio</pre> Antonio D'Errico (JIRA 2012-05-16T09:57:02 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31684 <pre>Thanks a lot for quick response, I have changed that in production, will get back to you if required. -----Original Message----- From: SuoNayi [mailto:suonayi2006-9Onoh4P/yGk&lt; at &gt;public.gmane.org] Sent: Wednesday, May 16, 2012 1:56 PM To: dev-UzBZ5Px8zVWY1pf4d8vP8EB+6BGkLq7r&lt; at &gt;public.gmane.org Subject: Reply:RE: Reply:Issue with ActiveMQ 5.5 This can cause first policy for queue will be applied. remove the second policy for queue and add the deadLetterStrategy to first policy for queue. -- Wangyin SuoNayi2006-9Onoh4P/yGk&lt; at &gt;public.gmane.org At 2012-05-16 13:09:47,Sheetal.Kulkarni-X+QBe+SqkrFBDgjK7y7TUQ&lt; at &gt;public.gmane.org wrote: </pre> Sheetal.Kulkarni-X+QBe+SqkrFBDgjK7y7TUQ< at >public.gmane.org 2012-05-16T09:22:58 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31683 <pre>This can cause first policy for queue will be applied. remove the second policy for queue and add the deadLetterStrategy to first policy for queue. -- Wangyin SuoNayi2006-9Onoh4P/yGk&lt; at &gt;public.gmane.org At 2012-05-16 13:09:47,Sheetal.Kulkarni-X+QBe+SqkrFBDgjK7y7TUQ&lt; at &gt;public.gmane.org wrote: </pre> SuoNayi 2012-05-16T08:26:17 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31682 <pre>Guilhem RAMBAL created AMQ-3843: ----------------------------------- Summary: ActiveMQ 5.6.0 requires JDK now Key: AMQ-3843 URL: https://issues.apache.org/jira/browse/AMQ-3843 Project: ActiveMQ Issue Type: Bug Components: JMX Affects Versions: 5.6.0 Reporter: Guilhem RAMBAL With this code : https://issues.apache.org/jira/browse/AMQ-2464 When you stop activemq regulary with jre instead of jdk : Connecting to pid: 3316 ERROR: java.lang.NullPointerException java.lang.NullPointerException at javax.management.remote.JMXServiceURL.&lt;init&gt;(JMXServiceURL.java:139) at org.apache.activemq.console.command.AbstractJmxCommand.handleOption(AbstractJmxCommand.java:350) at org.apache.activemq.console.command.ShutdownCommand.handleOption(ShutdownCommand.java:156) at org.apache.activemq.console.command.AbstractCommand.parseOptions(AbstractCommand.java:73) at org.apache.activemq.console.command.AbstractCommand.execute(Abstr</pre> Guilhem RAMBAL (JIRA 2012-05-16T07:12:08 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31681 <pre>Hi, This is how I configure Dead letter queues: And just one more point to add , I am using activemq in transacted mode within camel. &lt;destinationPolicy&gt; &lt;policyMap&gt; &lt;policyEntries&gt; &lt;policyEntry topic="&gt;" producerFlowControl="true" memoryLimit="1mb"&gt; &lt;pendingSubscriberPolicy&gt; &lt;vmCursor /&gt; &lt;/pendingSubscriberPolicy&gt; &lt;/policyEntry&gt; &lt;policyEntry queue="&gt;" producerFlowControl="true" memoryLimit="1mb"&gt; &lt;!-- Use VM cursor for better latency For more information, see: http://activemq.apache.org/message-cursors.html &lt;pendingQueuePolicy&gt; &lt;vmQueueCursor/&gt; &lt;/pendingQueuePolicy&gt; --&gt; &lt;/policyEntry&gt; &lt;policyEntry queue="&gt;" &gt; &lt;deadLetterStrategy&gt; </pre> Sheetal.Kulkarni-X+QBe+SqkrFBDgjK7y7TUQ< at >public.gmane.org 2012-05-16T05:09:47 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31680 <pre>misconfiguration, you'd better show your activemq.xml of broker. -- Wangyin SuoNayi2006-9Onoh4P/yGk&lt; at &gt;public.gmane.org At 2012-05-16 12:56:42,Sheetal.Kulkarni-X+QBe+SqkrFBDgjK7y7TUQ&lt; at &gt;public.gmane.org wrote: </pre> SuoNayi 2012-05-16T05:06:46 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31679 <pre> Hi, I have configured individual dead letter queues . Now when exception occurred, I expect that I get the message in individual dead letter queues. But however activemq by default sends the message to default "ActiveMQ.DLQ" and not to my individual queues. We have system in production, please tell me if it is a known issue? Thanks Sheetal </pre> Sheetal.Kulkarni-X+QBe+SqkrFBDgjK7y7TUQ< at >public.gmane.org 2012-05-16T04:56:42 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31678 <pre> [ https://issues.apache.org/jira/browse/AMQCPP-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-400. --------------------------------- Resolution: Fixed added in trunk -- 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 </pre> Timothy Bish (JIRA 2012-05-15T23:07:07 http://permalink.gmane.org/gmane.comp.java.activemq.devel/31677 <pre> [ https://issues.apache.org/jira/browse/AMQCPP-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-401. --------------------------------- Resolution: Fixed added in trunk -- 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 </pre> Timothy Bish (JIRA 2012-05-15T23:05:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.activemq.devel