[jira] [Commented] (AMQ-3816) Broker does not retain messages for a STOMP durable consumer if the broker restarts while the consumer was running
[ https://issues.apache.org/jira/browse/AMQ-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264701#comment-13264701 ] Buchi Reddy B commented on AMQ-3816: @Timothy I have tried with 'client' ack mode as well and also tried by setting prefetch limit to 1 but I'm still seeing this issue. Can you please check this? Broker does not retain messages for a STOMP durable consumer if the broker restarts while the consumer was running -- Key: AMQ-3816 URL: https://issues.apache.org/jira/browse/AMQ-3816 Project: ActiveMQ Issue Type: Bug Components: Broker, stomp Affects Versions: 5.5.1 Environment: Perl STOMP clients on UNIX OS. Reporter: Buchi Reddy B We have noticed that the broker does not deliver some messages to a durable consumer in the following scenario. 1/ Start ActiveMQ broker, Perl STOMP producer on topics with persistence and Perl STOMP consumer with durable topics. 2/ Kill the broker while the consumer and producer are running. 3/ Kill the consumer. We have kept the producer running all these while. 4/ Restart the broker and producer will connect to it and continue to send the messages. 5/ Restart the consumer. We have noticed that the consumer was missing big chunk of messages sent by the producer when the consumer was down. But, we expect the consumer to receive these messages since it's a durable consumer and did not unsubscribe from these topics. I have enabled TRACE level logging for the broker and checked that the broker is recovering the durable subscription information from the kaha db logs when it restarts and marks the durable consumer as inactive durable subscription. However, broker does not seem to retain the messages for this durable consumer until the consumer comes up again. Is this expected? Does not broker guarantee message redelivery for durable consumers when the broker itself restarts? Please let me know if we have any configurations on the broker/client side to avoid these kind of issues. -- 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-3811) Slave broker in the Master/Slave configuration doesn't process acks of running STOMP consumer and redelivers all the messages if the consumer restarts
[ https://issues.apache.org/jira/browse/AMQ-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264704#comment-13264704 ] Buchi Reddy B commented on AMQ-3811: Any update on this please? Slave broker in the Master/Slave configuration doesn't process acks of running STOMP consumer and redelivers all the messages if the consumer restarts -- Key: AMQ-3811 URL: https://issues.apache.org/jira/browse/AMQ-3811 Project: ActiveMQ Issue Type: Bug Components: Broker, stomp Affects Versions: 5.5.1 Environment: Linux operating system and Perl/Python STOMP clients. Reporter: Buchi Reddy B Hi, I am running ActiveMQ brokers with Shared file system Master/Slave configuration and I am seeing the following issue. 1. Start Master and slave brokers. 2. Start a durable STOMP consumer (Perl/Python) and a producer (Perl/Python) with persistence. 3. Kill the master broker while the producer is still sending messages. 4. Our STOMP library takes care of failing over to the new broker automatically and the consumer replays all its subscriptions. So, producer continues to send to the slave broker and consumer also receives all the messages from slave broker. 5. Stop the producer and consumer. 6. Restart the consumer with same client-id and subscription name. After this, I see that the consumer received some messages which were already delivered. This is easily reproducible with the above mentioned steps. I can clearly see in the broker logs that the slave broker has received acks from the consumer but for some reason it doesn't purge these messages and thinks that the consumer didn't ack them. The messages which were sent to the master broker (before it was killed) were actually getting removed and are not delivered multiple times. Any help here is greatly appreciated. Thanks a lot!! -- 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
Re: [VOTE] Apache ActiveMQ 5.6.0
+1 On 25 April 2012 11:39, Dejan Bosanac de...@nighttale.net wrote: Hi all, I've just cut a release candidate for the 5.6.0 release. This is a long-waited release with some 400 bug fixes and improvements. It also contains a lot of new features which are summarized here: https://cwiki.apache.org/confluence/display/ACTIVEMQ/New+Features+in+5.6 Could you review the artifacts and vote? The list of resolved issues is here (430 issues fixed) https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+AMQ+AND+fixVersion+%3D+12317974+AND+status+in+%28Resolved%2C+Closed%29+ORDER+BY+priority+DESC A bit better (release note) view: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210version=12317974 You can get binary distributions here: https://repository.apache.org/content/repositories/orgapacheactivemq-099/org/apache/activemq/apache-activemq/5.6.0/ Source archives are here: https://repository.apache.org/content/repositories/orgapacheactivemq-099/org/apache/activemq/activemq-parent/5.6.0/ Maven2 repository is at: https://repository.apache.org/content/repositories/orgapacheactivemq-099/ Source SVN tag: https://svn.apache.org/repos/asf/activemq/tags/activemq-5.6.0/ Please vote to approve this release [ ] +1 Release the binary as Apache ActiveMQ 5.6.0 [ ] -1 Veto the release (provide specific comments) Here's my +1 Regards -- Dejan Bosanac Senior Software Engineer | FuseSource Corp. dej...@fusesource.com | fusesource.com skype: dejan.bosanac | twitter: @dejanb blog: http://www.nighttale.net ActiveMQ in Action: http://www.manning.com/snyder/ -- http://fusesource.com http://blog.garytully.com
[jira] [Commented] (AMQ-3542) Using failover: with static discovery in a network connector to choose from a master/slave tuple leads to hangs and invalid states
[
https://issues.apache.org/jira/browse/AMQ-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264860#comment-13264860
]
Martin Serrano commented on AMQ-3542:
-
note: Make sure you do not have randomize=false on your failover uri as I did.
I copied it from a place where that makes sense. In this situation, it means
the {{a}} part of the failover would always be chosen when recovery occurs and
it will never fail over. That was a wasted day.
Using failover: with static discovery in a network connector to choose from a
master/slave tuple leads to hangs and invalid states
--
Key: AMQ-3542
URL: https://issues.apache.org/jira/browse/AMQ-3542
Project: ActiveMQ
Issue Type: Bug
Components: Connector, Transport
Affects Versions: 5.4.2, 5.5.0
Reporter: Gary Tully
Assignee: Gary Tully
Labels: failover, master, network, slave
Fix For: 5.6.0
static discovery will try to connect to all provided urls. When the list is a
master/slave pair with shared storage, only one will active, leading log
messages indicating repeated failure to connect.
A potential solution is to use failover: just to pick a url but let it
delegate failover to the network connector such that the network bridge is
correctly stopped/restarted.
{{static:(failover:(tcp://a:61616,tcp://slave:61616)?maxReconnectAttempts=..)}}
This does not work reliably atm, due to inconsistency in the failover
reconnect logic, a network connectors interest in transport
interruption/resumption and the lack of thread safety in tracking existing
bridges.
--
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-3816) Broker does not retain messages for a STOMP durable consumer if the broker restarts while the consumer was running
[ https://issues.apache.org/jira/browse/AMQ-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264898#comment-13264898 ] Timothy Bish commented on AMQ-3816: --- Recommend you try and create a JUnit test that demonstrates the issue, testing here indicates that things are working as expected. Broker does not retain messages for a STOMP durable consumer if the broker restarts while the consumer was running -- Key: AMQ-3816 URL: https://issues.apache.org/jira/browse/AMQ-3816 Project: ActiveMQ Issue Type: Bug Components: Broker, stomp Affects Versions: 5.5.1 Environment: Perl STOMP clients on UNIX OS. Reporter: Buchi Reddy B We have noticed that the broker does not deliver some messages to a durable consumer in the following scenario. 1/ Start ActiveMQ broker, Perl STOMP producer on topics with persistence and Perl STOMP consumer with durable topics. 2/ Kill the broker while the consumer and producer are running. 3/ Kill the consumer. We have kept the producer running all these while. 4/ Restart the broker and producer will connect to it and continue to send the messages. 5/ Restart the consumer. We have noticed that the consumer was missing big chunk of messages sent by the producer when the consumer was down. But, we expect the consumer to receive these messages since it's a durable consumer and did not unsubscribe from these topics. I have enabled TRACE level logging for the broker and checked that the broker is recovering the durable subscription information from the kaha db logs when it restarts and marks the durable consumer as inactive durable subscription. However, broker does not seem to retain the messages for this durable consumer until the consumer comes up again. Is this expected? Does not broker guarantee message redelivery for durable consumers when the broker itself restarts? Please let me know if we have any configurations on the broker/client side to avoid these kind of issues. -- 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-3819) high cpu with stomp+nio+ssl and many subscriptions
[
https://issues.apache.org/jira/browse/AMQ-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264985#comment-13264985
]
Dejan Bosanac commented on AMQ-3819:
I created a fix in svn revision 1332230 and created a new snapshot
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.7-SNAPSHOT/
It fixes the problem that transport get stuck in serviceRead() method and from
my local test it looks pretty much the same as plain stomp+ssl implementation.
Can you take it for a spin and let us know if it improves your use case.
high cpu with stomp+nio+ssl and many subscriptions
--
Key: AMQ-3819
URL: https://issues.apache.org/jira/browse/AMQ-3819
Project: ActiveMQ
Issue Type: Bug
Components: stomp
Affects Versions: 5.6.0
Environment: CentOS 6, RC of 5.6.0
java version 1.6.0_22
OpenJDK Runtime Environment (IcedTea6 1.10.6) (rhel-1.43.1.10.6.el6_2-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
Reporter: R.I.Pienaar
Attachments: StompLoadTest.java, StompNIOSSLLoadTest.java
Switching an existing workload from a transport:
{quote}
transportConnector name=verified_stompssl
uri=stomp+ssl://0.0.0.0:6165?needClientAuth=true/
{quote}
to
{quote}
transportConnector name=verified_stompssl
uri=stomp+nio+ssl://0.0.0.0:6165?needClientAuth=true/
{quote}
showed the CPU profile to go from 1-5% to 300% constantly on a 8 core server
I was able to recreate this using a ruby client @
http://devco.net/rip/amq_560_stomp_nio_ssl_tester.rb
The important combinations are:
* I am connecting to a stomp+nio+ssl port
* I am creating the subscriptions to the 10 queus and topics
If I change either of these variables - like just commenting out the loop
that does those subscriptions - then the CPU load is acceptable.
I analysed the running VM with VisualVM and found that
transport.nio.NIOSSLTransport.serviceRead() is the busy thread.
My activemq.xml is:
{noformat}
beans
xmlns=http://www.springframework.org/schema/beans;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd
http://activemq.apache.org/camel/schema/spring
http://activemq.apache.org/camel/schema/spring/camel-spring.xsd;
broker xmlns=http://activemq.apache.org/schema/core; brokerName=amq1
useJmx=true persistent=true schedulePeriodForDestinationPurge=6
destinationPolicy
policyMap
policyEntries
policyEntry topic= producerFlowControl=false/
policyEntry queue=*.reply. gcInactiveDestinations=true
inactiveTimoutBeforeGC=12 /
/policyEntries
/policyMap
/destinationPolicy
managementContext
managementContext connectorPort=1099
jmxDomainName=org.apache.activemq/
/managementContext
plugins
statisticsBrokerPlugin/
simpleAuthenticationPlugin
users
authenticationUser username=test password=test
groups=admins,everyone/
/users
/simpleAuthenticationPlugin
authorizationPlugin
map
authorizationMap
authorizationEntries
authorizationEntry queue= write=admins read=admins
admin=admins /
authorizationEntry topic= write=admins read=admins
admin=admins /
/authorizationEntries
/authorizationMap
/map
/authorizationPlugin
/plugins
sslContext
sslContext
keyStore=keystore.jks keyStorePassword=ohshahCu
trustStore=truststore.jks trustStorePassword=ohshahCu
/
/sslContext
systemUsage
systemUsage
memoryUsage
memoryUsage limit=200 mb /
/memoryUsage
storeUsage
storeUsage limit=1 gb /
/storeUsage
tempUsage
tempUsage limit=1 gb /
/tempUsage
/systemUsage
/systemUsage
transportConnectors
transportConnector name=openwire uri=tcp://0.0.0.0:6166/
transportConnector name=stomp+nio
uri=stomp+nio://0.0.0.0:6163/
transportConnector name=stompssl
uri=stomp+ssl://0.0.0.0:6164/
transportConnector name=verified_stompssl
uri=stomp+nio+ssl://0.0.0.0:6165?needClientAuth=true/
/transportConnectors
/broker
[VOTE] Release Apache.NMS.ActiveMQ 1.5.5
Hello This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.5.5. New in this release: * Sending to non-existent temp queue causes consumer to shutdown * Consumers frequently fail to reconnect after broker outage/failover. * FailoverTransport doesn't trigger a reconnect on send of a Tracked Command. * ActiveMQ.NMS hangs sometimes due to concurrency problems while accessing static IDictionary * Apache.NMS.ActiveMQ discovery protocol throwing ArgumentOutOfRangeException The binaries and source bundles for the Release Candidate can be found here: http://people.apache.org/~tabish/nms-1.5.0/ The Wiki Page for this release is here: http://activemq.apache.org/nms/apachenmsactivemq-v155.html The list of issues resolved is here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201styleName=Htmlversion=12320740 Please cast your votes (the vote will be open for 72 hrs): [ ] +1 Release the source as Apache NMS.ActiveMQ v1.5.5 [ ] -1 Veto the release (provide specific comments) Here's my +1 -- Tim Bish Sr Software Engineer | FuseSource Corp tim.b...@fusesource.com | www.fusesource.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
[jira] [Commented] (AMQ-3819) high cpu with stomp+nio+ssl and many subscriptions
[
https://issues.apache.org/jira/browse/AMQ-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264993#comment-13264993
]
Timothy Bish commented on AMQ-3819:
---
Tested here with the fix Dejan posted and the NIO+SSL test works as expected
now on my machine. Would be good confirmation to see if that ruby client test
is working now.
high cpu with stomp+nio+ssl and many subscriptions
--
Key: AMQ-3819
URL: https://issues.apache.org/jira/browse/AMQ-3819
Project: ActiveMQ
Issue Type: Bug
Components: stomp
Affects Versions: 5.6.0
Environment: CentOS 6, RC of 5.6.0
java version 1.6.0_22
OpenJDK Runtime Environment (IcedTea6 1.10.6) (rhel-1.43.1.10.6.el6_2-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
Reporter: R.I.Pienaar
Attachments: StompLoadTest.java, StompNIOSSLLoadTest.java
Switching an existing workload from a transport:
{quote}
transportConnector name=verified_stompssl
uri=stomp+ssl://0.0.0.0:6165?needClientAuth=true/
{quote}
to
{quote}
transportConnector name=verified_stompssl
uri=stomp+nio+ssl://0.0.0.0:6165?needClientAuth=true/
{quote}
showed the CPU profile to go from 1-5% to 300% constantly on a 8 core server
I was able to recreate this using a ruby client @
http://devco.net/rip/amq_560_stomp_nio_ssl_tester.rb
The important combinations are:
* I am connecting to a stomp+nio+ssl port
* I am creating the subscriptions to the 10 queus and topics
If I change either of these variables - like just commenting out the loop
that does those subscriptions - then the CPU load is acceptable.
I analysed the running VM with VisualVM and found that
transport.nio.NIOSSLTransport.serviceRead() is the busy thread.
My activemq.xml is:
{noformat}
beans
xmlns=http://www.springframework.org/schema/beans;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd
http://activemq.apache.org/camel/schema/spring
http://activemq.apache.org/camel/schema/spring/camel-spring.xsd;
broker xmlns=http://activemq.apache.org/schema/core; brokerName=amq1
useJmx=true persistent=true schedulePeriodForDestinationPurge=6
destinationPolicy
policyMap
policyEntries
policyEntry topic= producerFlowControl=false/
policyEntry queue=*.reply. gcInactiveDestinations=true
inactiveTimoutBeforeGC=12 /
/policyEntries
/policyMap
/destinationPolicy
managementContext
managementContext connectorPort=1099
jmxDomainName=org.apache.activemq/
/managementContext
plugins
statisticsBrokerPlugin/
simpleAuthenticationPlugin
users
authenticationUser username=test password=test
groups=admins,everyone/
/users
/simpleAuthenticationPlugin
authorizationPlugin
map
authorizationMap
authorizationEntries
authorizationEntry queue= write=admins read=admins
admin=admins /
authorizationEntry topic= write=admins read=admins
admin=admins /
/authorizationEntries
/authorizationMap
/map
/authorizationPlugin
/plugins
sslContext
sslContext
keyStore=keystore.jks keyStorePassword=ohshahCu
trustStore=truststore.jks trustStorePassword=ohshahCu
/
/sslContext
systemUsage
systemUsage
memoryUsage
memoryUsage limit=200 mb /
/memoryUsage
storeUsage
storeUsage limit=1 gb /
/storeUsage
tempUsage
tempUsage limit=1 gb /
/tempUsage
/systemUsage
/systemUsage
transportConnectors
transportConnector name=openwire uri=tcp://0.0.0.0:6166/
transportConnector name=stomp+nio
uri=stomp+nio://0.0.0.0:6163/
transportConnector name=stompssl
uri=stomp+ssl://0.0.0.0:6164/
transportConnector name=verified_stompssl
uri=stomp+nio+ssl://0.0.0.0:6165?needClientAuth=true/
/transportConnectors
/broker
import resource=jetty.xml/
/beans
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] [Commented] (AMQ-3819) high cpu with stomp+nio+ssl and many subscriptions
[
https://issues.apache.org/jira/browse/AMQ-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264996#comment-13264996
]
R.I.Pienaar commented on AMQ-3819:
--
Thanks guys, I'll test 'morrow UK time.
high cpu with stomp+nio+ssl and many subscriptions
--
Key: AMQ-3819
URL: https://issues.apache.org/jira/browse/AMQ-3819
Project: ActiveMQ
Issue Type: Bug
Components: stomp
Affects Versions: 5.6.0
Environment: CentOS 6, RC of 5.6.0
java version 1.6.0_22
OpenJDK Runtime Environment (IcedTea6 1.10.6) (rhel-1.43.1.10.6.el6_2-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
Reporter: R.I.Pienaar
Attachments: StompLoadTest.java, StompNIOSSLLoadTest.java
Switching an existing workload from a transport:
{quote}
transportConnector name=verified_stompssl
uri=stomp+ssl://0.0.0.0:6165?needClientAuth=true/
{quote}
to
{quote}
transportConnector name=verified_stompssl
uri=stomp+nio+ssl://0.0.0.0:6165?needClientAuth=true/
{quote}
showed the CPU profile to go from 1-5% to 300% constantly on a 8 core server
I was able to recreate this using a ruby client @
http://devco.net/rip/amq_560_stomp_nio_ssl_tester.rb
The important combinations are:
* I am connecting to a stomp+nio+ssl port
* I am creating the subscriptions to the 10 queus and topics
If I change either of these variables - like just commenting out the loop
that does those subscriptions - then the CPU load is acceptable.
I analysed the running VM with VisualVM and found that
transport.nio.NIOSSLTransport.serviceRead() is the busy thread.
My activemq.xml is:
{noformat}
beans
xmlns=http://www.springframework.org/schema/beans;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd
http://activemq.apache.org/camel/schema/spring
http://activemq.apache.org/camel/schema/spring/camel-spring.xsd;
broker xmlns=http://activemq.apache.org/schema/core; brokerName=amq1
useJmx=true persistent=true schedulePeriodForDestinationPurge=6
destinationPolicy
policyMap
policyEntries
policyEntry topic= producerFlowControl=false/
policyEntry queue=*.reply. gcInactiveDestinations=true
inactiveTimoutBeforeGC=12 /
/policyEntries
/policyMap
/destinationPolicy
managementContext
managementContext connectorPort=1099
jmxDomainName=org.apache.activemq/
/managementContext
plugins
statisticsBrokerPlugin/
simpleAuthenticationPlugin
users
authenticationUser username=test password=test
groups=admins,everyone/
/users
/simpleAuthenticationPlugin
authorizationPlugin
map
authorizationMap
authorizationEntries
authorizationEntry queue= write=admins read=admins
admin=admins /
authorizationEntry topic= write=admins read=admins
admin=admins /
/authorizationEntries
/authorizationMap
/map
/authorizationPlugin
/plugins
sslContext
sslContext
keyStore=keystore.jks keyStorePassword=ohshahCu
trustStore=truststore.jks trustStorePassword=ohshahCu
/
/sslContext
systemUsage
systemUsage
memoryUsage
memoryUsage limit=200 mb /
/memoryUsage
storeUsage
storeUsage limit=1 gb /
/storeUsage
tempUsage
tempUsage limit=1 gb /
/tempUsage
/systemUsage
/systemUsage
transportConnectors
transportConnector name=openwire uri=tcp://0.0.0.0:6166/
transportConnector name=stomp+nio
uri=stomp+nio://0.0.0.0:6163/
transportConnector name=stompssl
uri=stomp+ssl://0.0.0.0:6164/
transportConnector name=verified_stompssl
uri=stomp+nio+ssl://0.0.0.0:6165?needClientAuth=true/
/transportConnectors
/broker
import resource=jetty.xml/
/beans
{noformat}
--
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
Re: [VOTE] Release Apache.NMS.ActiveMQ 1.5.5
+1 On Mon, Apr 30, 2012 at 8:53 AM, Timothy Bish tabish...@gmail.com wrote: Hello This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.5.5. New in this release: * Sending to non-existent temp queue causes consumer to shutdown * Consumers frequently fail to reconnect after broker outage/failover. * FailoverTransport doesn't trigger a reconnect on send of a Tracked Command. * ActiveMQ.NMS hangs sometimes due to concurrency problems while accessing static IDictionary * Apache.NMS.ActiveMQ discovery protocol throwing ArgumentOutOfRangeException The binaries and source bundles for the Release Candidate can be found here: http://people.apache.org/~tabish/nms-1.5.0/ The Wiki Page for this release is here: http://activemq.apache.org/nms/apachenmsactivemq-v155.html The list of issues resolved is here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201styleName=Htmlversion=12320740 Please cast your votes (the vote will be open for 72 hrs): [ ] +1 Release the source as Apache NMS.ActiveMQ v1.5.5 [ ] -1 Veto the release (provide specific comments) Here's my +1 -- Tim Bish Sr Software Engineer | FuseSource Corp tim.b...@fusesource.com | www.fusesource.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
[jira] [Created] (AMQ-3822) The current sslContext element does not provide the ability to define the keystore key password key.
Claudio Corsi created AMQ-3822: -- Summary: The current sslContext element does not provide the ability to define the keystore key password key. Key: AMQ-3822 URL: https://issues.apache.org/jira/browse/AMQ-3822 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.5.1 Environment: All Reporter: Claudio Corsi Priority: Trivial Fix For: 5.x The current use of the sslContext element does not provide the ability to use a keystore that requires two separate passwords, one for the store password and another for the key password. This ticket is being created to include another attribute of the sslContext element that you can use to define the keystore key password. -- 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-3822) The current sslContext element does not provide the ability to define the keystore key password key.
[ https://issues.apache.org/jira/browse/AMQ-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claudio Corsi updated AMQ-3822: --- Attachment: client.ts keystore.ks sslcontext.diffs This is the patch that adds the keyStoreKeyPassword attribute to the sslContext element that can be used to pass the keystore key password. The current sslContext element does not provide the ability to define the keystore key password key. Key: AMQ-3822 URL: https://issues.apache.org/jira/browse/AMQ-3822 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.5.1 Environment: All Reporter: Claudio Corsi Priority: Trivial Labels: activemq, sslContext Fix For: 5.x Attachments: client.ts, keystore.ks, sslcontext.diffs The current use of the sslContext element does not provide the ability to use a keystore that requires two separate passwords, one for the store password and another for the key password. This ticket is being created to include another attribute of the sslContext element that you can use to define the keystore key password. -- 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
Re: [VOTE] Release Apache.NMS.ActiveMQ 1.5.5
+1 On Mon, Apr 30, 2012 at 5:53 PM, Timothy Bish tabish...@gmail.com wrote: Hello This is a call for a vote on the release of Apache.NMS.ActiveMQ v1.5.5. New in this release: * Sending to non-existent temp queue causes consumer to shutdown * Consumers frequently fail to reconnect after broker outage/failover. * FailoverTransport doesn't trigger a reconnect on send of a Tracked Command. * ActiveMQ.NMS hangs sometimes due to concurrency problems while accessing static IDictionary * Apache.NMS.ActiveMQ discovery protocol throwing ArgumentOutOfRangeException The binaries and source bundles for the Release Candidate can be found here: http://people.apache.org/~tabish/nms-1.5.0/ The Wiki Page for this release is here: http://activemq.apache.org/nms/apachenmsactivemq-v155.html The list of issues resolved is here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311201styleName=Htmlversion=12320740 Please cast your votes (the vote will be open for 72 hrs): [ ] +1 Release the source as Apache NMS.ActiveMQ v1.5.5 [ ] -1 Veto the release (provide specific comments) Here's my +1 -- Tim Bish Sr Software Engineer | FuseSource Corp tim.b...@fusesource.com | www.fusesource.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/ -- Claus Ibsen - CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
