Application Server 3  4  5 and 6
  1. Application Server 3 4 5 and 6
  2. JBAS-6720

Make sure that the metrics for Topics and Queues (eg. All Message Count, Depth, Depth Delta) are marked as ViewUse.STATISTIC

    Details

    • Similar Issues:
      Show 10 results 

      Description

      Steps to reproduce:

      Create a new Topic or Queue using Embedded Jopr. Send some messages to the Topic or Queue. Navigate to the "Metrics" tab for the resource. The metrics do not get updated to reflect this change. All the values are 0.0.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            Farah Juma added a comment -

            We're also seeing some strange values for "Time Last Update". On the "Metrics" page for Queues, "Time Last Update" is defined as the timestamp of the last message add. However, after creating a new Queue, the value of "Time Last Update" shows up as 1,241,102,055,824.0 even though no messages have been added to the Queue. (embjopr r367, Branch_5_x r88068)

            Show
            Farah Juma added a comment - We're also seeing some strange values for "Time Last Update". On the "Metrics" page for Queues, "Time Last Update" is defined as the timestamp of the last message add. However, after creating a new Queue, the value of "Time Last Update" shows up as 1,241,102,055,824.0 even though no messages have been added to the Queue. (embjopr r367, Branch_5_x r88068)
            Hide
            Jason Greene added a comment -

            There will not be a 5.1.1, moving to 5.2 for now

            Show
            Jason Greene added a comment - There will not be a 5.1.1, moving to 5.2 for now
            Hide
            Ian Springer added a comment -

            Jason, is the EnableMessageCounters property from messaging-service.xml exposed for updating by a ManagedObject or an MBean? If not, can that be done? It will make it much easier for us to expose it via Jopr.

            Show
            Ian Springer added a comment - Jason, is the EnableMessageCounters property from messaging-service.xml exposed for updating by a ManagedObject or an MBean? If not, can that be done? It will make it much easier for us to expose it via Jopr.
            Hide
            Scott Stark added a comment -

            The ServerPeer managed object (name="jboss.messaging:service=ServerPeer", type=ComponentType("JMS", "ServerPeer")) exposes the enableMessageCounters property.

            1182 [main] INFO org.jboss.test.profileservice.test.JmsDestinationUnitTestCase - Properties: [defaultTopicJNDIContext, enableMessageCounters, providerVersion, postOffice, defaultExpiryQueue, suckerPassword, supportsFailover, JMSProviderName, clientAopConfig, serverAopConfig, JMSVersion, strictTck, providerMinorVersion, clusterPullConnectionFactoryName, defaultRedeliveryDelay, messageCounterSamplePeriod, defaultMessageCounterHistoryDayLimit, persistenceManager, messageStatistics, failoverCompleteTimeout, jmsUserManager, defaultQueueJNDIContext, messageCounters, serverPeerID, providerMajorVersion, version, failoverStartTimeout, useXAForMessagePull, JMSMajorVersion, recoverDeliveriesTimeout, JMSUserManager, defaultMaxDeliveryAttempts, JMSMinorVersion, defaultDLQ, securityDomain, defaultPreserveOrdering]

            Show
            Scott Stark added a comment - The ServerPeer managed object (name="jboss.messaging:service=ServerPeer", type=ComponentType("JMS", "ServerPeer")) exposes the enableMessageCounters property. 1182 [main] INFO org.jboss.test.profileservice.test.JmsDestinationUnitTestCase - Properties: [defaultTopicJNDIContext, enableMessageCounters, providerVersion, postOffice, defaultExpiryQueue, suckerPassword, supportsFailover, JMSProviderName, clientAopConfig, serverAopConfig, JMSVersion, strictTck, providerMinorVersion, clusterPullConnectionFactoryName, defaultRedeliveryDelay, messageCounterSamplePeriod, defaultMessageCounterHistoryDayLimit, persistenceManager, messageStatistics, failoverCompleteTimeout, jmsUserManager, defaultQueueJNDIContext, messageCounters, serverPeerID, providerMajorVersion, version, failoverStartTimeout, useXAForMessagePull, JMSMajorVersion, recoverDeliveriesTimeout, JMSUserManager, defaultMaxDeliveryAttempts, JMSMinorVersion, defaultDLQ, securityDomain, defaultPreserveOrdering]
            Hide
            Jason Greene added a comment -

            Farah, I looked into the questions you asked (finally)

            Count Delta
            -------------------
            This metric returns the difference in count since the last read of Count Delta. So if you call it twice quickly, and there are no messages sent between the calls, you get 0.

            Time Last Update
            -----------------------
            This value represents the last time statistics where calculated by the messaging system. It is fired off of a timer, so the message count can be zero and it will still update

            Show
            Jason Greene added a comment - Farah, I looked into the questions you asked (finally) Count Delta ------------------- This metric returns the difference in count since the last read of Count Delta. So if you call it twice quickly, and there are no messages sent between the calls, you get 0. Time Last Update ----------------------- This value represents the last time statistics where calculated by the messaging system. It is fired off of a timer, so the message count can be zero and it will still update

              People

              • Assignee:
                Jason Greene
                Reporter:
                Farah Juma
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development