[jira] [Resolved] (AMQ-3820) Exposing subscription statistics through Statistics plug-in

2012-04-27 Thread Dejan Bosanac (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMQ-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dejan Bosanac resolved AMQ-3820.


Resolution: Fixed

Fixed with svn revision 1331372. Now you can use 
{{ActiveMQ.Statistics.Subscription}} destination to get info on all available 
queue and topic subscriptions.

  Exposing subscription statistics through Statistics plug-in
 

 Key: AMQ-3820
 URL: https://issues.apache.org/jira/browse/AMQ-3820
 Project: ActiveMQ
  Issue Type: New Feature
Affects Versions: 5.5.0
Reporter: Dejan Bosanac
Assignee: Dejan Bosanac
 Fix For: 5.6.0


 Retrieve subscription statistics from the statistics plugin. Ideally all of 
 the attributes exposed on the subscription MBeans would be returned. 

--
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

2012-04-27 Thread Timothy Bish (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263757#comment-13263757
 ] 

Timothy Bish commented on AMQ-3819:
---

Commit test cases on trunk for this scenario, one for each (TCP, SSL, NIO, 
NIO+SSL).  Only the NIO+SSL version has an issue. 

 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: 

[jira] [Commented] (AMQ-3819) high cpu with stomp+nio+ssl and many subscriptions

2012-04-27 Thread Timothy Bish (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264038#comment-13264038
 ] 

Timothy Bish commented on AMQ-3819:
---

The test case seems to indicate that its an issue with the send rate on the 
connection.  If you slow down the outbound send loop at the end of the test the 
NIO+SSL test will start passing.  It may be an issue of not properly handling 
underflow situations in the secureRead method.  When things go wrong it seems 
like we get into a state of underflow but never try reading from the ssl 
channel again. 

 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 

[jira] [Closed] (AMQ-2444) http://activemq.apache.org/redelivery-policy.html should be less vague

2012-04-27 Thread Brian Topping (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMQ-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Topping closed AMQ-2444.
--


 http://activemq.apache.org/redelivery-policy.html should be less vague
 --

 Key: AMQ-2444
 URL: https://issues.apache.org/jira/browse/AMQ-2444
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 5.2.0
Reporter: Brian Topping
Assignee: Gary Tully
 Fix For: 5.3.1, 5.4.0


 http://activemq.apache.org/redelivery-policy.html states three situations 
 under which a message is redelivered, but is not specific as to whether one 
 or all are 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