Org apache activemq

Org apache activemq DEFAULT

Java Code Examples for org.apache.activemq.command.ConsumerInfo

The following examples show how to use org.apache.activemq.command.ConsumerInfo. These examples are extracted from open source projects. You can vote up the ones you like or vote down the ones you don't like, and go to the original project or source file by following the links above each example. You may check out the related API usage on the sidebar.

Example 1

/** * Add new message consumer. * * @param context * @param info * @return * @throws Exception * @see org.apache.activemq.broker.BrokerFilter#addConsumer(org.apache.activemq.broker.ConnectionContext, org.apache.activemq.command.ConsumerInfo) */ public Subscription addConsumer(ConnectionContext context, ConsumerInfo info) throws Exception { ActiveMQDestination dest = info.getDestination(); Connection conn = context.getConnection(); if (dest != null) { String destName = info.getDestination().getPhysicalName(); String clientId = context.getClientId(); String allowedDest = userMap.get(clientId); logger.info(">>> Got Consumer Add request { Destination: " + destName + ", Remote Address: " + conn.getRemoteAddress() + ", ClientID: " + clientId + " }"); if (allowedDest != null && (allowedDest.equals("*") || allowedDest.equals(destName) || destName.startsWith("ActiveMQ"))) { logger.info(">>> Subscription allowed"); } else { logger.error(">>> Destination not allowed. Subscription denied!"); throw new CmsAuthException(">>> Subscription denied!"); } } else { logger.error("<<< Got Consumer Add request from Remote Address:" + conn.getRemoteAddress() + ". But destination is NULL."); } return super.addConsumer(context, info); }

Example 2

protected void displayRemoveInfo(final RemoveInfo removeInfo, final String startAdvisoryMsg) { switch(removeInfo.getObjectId().getDataStructureType()) { case CommandTypes.PRODUCER_INFO: ProducerInfo pi = (ProducerInfo)removeInfo.getObjectId(); output("Removed producer " + startAdvisoryMsg + pi.getProducerId().getConnectionId() + " that produced to destination: " + pi.getDestination().toString() ); break; case CommandTypes.CONSUMER_INFO: ConsumerInfo ci = (ConsumerInfo)removeInfo.getObjectId(); output("Removed consumer " + startAdvisoryMsg + ci.getConsumerId().getConnectionId() + " that consumed destination: " + ci.getDestination().toString()); break; case CommandTypes.CONNECTION_INFO: ConnectionInfo connInfo = (ConnectionInfo) removeInfo.getObjectId(); String connStr = connInfo.getUserName() != null ? connInfo.getUserName() + "@" + connInfo.getClientIp() : connInfo.getClientIp(); output("Removed connection " + startAdvisoryMsg + connInfo.getClientId() + " that connected from: " + connStr); break; } }

Example 3

public void testSendingSmallMessage() throws Exception { ConsumerInfo expected = new ConsumerInfo(); expected.setSelector("Cheese"); expected.setExclusive(true); expected.setExclusive(true); expected.setPrefetchSize(); try { LOG.info("About to send: " + expected); producer.oneway(expected); Command received = assertCommandReceived(); assertTrue("Should have received a ConsumerInfo but was: " + received, received instanceof ConsumerInfo); ConsumerInfo actual = (ConsumerInfo) received; assertEquals("Selector", expected.getSelector(), actual.getSelector()); assertEquals("isExclusive", expected.isExclusive(), actual.isExclusive()); assertEquals("getPrefetchSize", expected.getPrefetchSize(), actual.getPrefetchSize()); } catch (Exception e) { LOG.info("Caught: " + e); e.printStackTrace(); fail("Failed to send to transport: " + e); } }

Example 4

private AMQConsumer getConsumer(int prefetchSize) throws Exception { ServerSession coreSession = Mockito.mock(ServerSession.class); Mockito.when(coreSession.createConsumer(ArgumentMatchers.anyLong(), ArgumentMatchers.nullable(SimpleString.class), ArgumentMatchers.nullable(SimpleString.class), ArgumentMatchers.anyInt(), ArgumentMatchers.anyBoolean(), ArgumentMatchers.anyBoolean(), ArgumentMatchers.nullable(Integer.class))).thenReturn(Mockito.mock(ServerConsumerImpl.class)); AMQSession session = Mockito.mock(AMQSession.class); Mockito.when(session.getConnection()).thenReturn(Mockito.mock(OpenWireConnection.class)); Mockito.when(session.getCoreServer()).thenReturn(Mockito.mock(ActiveMQServer.class)); Mockito.when(session.getCoreSession()).thenReturn(coreSession); Mockito.when(session.convertWildcard(ArgumentMatchers.any(ActiveMQDestination.class))).thenReturn(""); ConsumerInfo info = new ConsumerInfo(); info.setPrefetchSize(prefetchSize); AMQConsumer consumer = new AMQConsumer(session, new ActiveMQTopic("TEST"), info, Mockito.mock(ScheduledExecutorService.class), false); consumer.init(Mockito.mock(SlowConsumerDetectionListener.class), 0); return consumer; }

Example 5

@Override public Response processRemoveConsumer(ConsumerId id, long lastDeliveredSequenceId) throws Exception { if (destroyed) { return null; } SessionId sessionId = id.getParentId(); SessionState ss = state.getSessionState(sessionId); if (ss == null) { throw new IllegalStateException("Cannot remove a consumer from a session that had not been registered: " + sessionId); } ConsumerState consumerState = ss.removeConsumer(id); if (consumerState == null) { throw new IllegalStateException("Cannot remove a consumer that had not been registered: " + id); } ConsumerInfo info = consumerState.getInfo(); info.setLastDeliveredSequenceId(lastDeliveredSequenceId); AMQConsumerBrokerExchange consumerBrokerExchange = consumerExchanges.remove(id); consumerBrokerExchange.removeConsumer(); return null; }

Example 6

public AMQConsumer(AMQSession amqSession, org.apache.activemq.command.ActiveMQDestination d, ConsumerInfo info, ScheduledExecutorService scheduledPool, boolean internalAddress) { this.session = amqSession; this.openwireDestination = d; this.hasNotificationDestination = d.toString().contains(AMQ_NOTIFICATIONS_DESTINATION); this.info = info; this.scheduledPool = scheduledPool; this.prefetchSize = info.getPrefetchSize(); this.currentWindow = new AtomicInteger(prefetchSize); this.deliveredAcks = 0; if (prefetchSize == 0) { messagePullHandler.set(new MessagePullHandler()); } this.internalAddress = internalAddress; this.rolledbackMessageRefs = null; }

Example 7

public void testQueueSendThenAddConsumer() throws Exception { // Start a producer StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); destination = createDestinationInfo(connection, connectionInfo, destinationType); // Send a message to the broker. connection.send(createMessage(producerInfo, destination, deliveryMode)); // Start the consumer ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); connection.send(consumerInfo); // Make sure the message was delivered. Message m = receiveMessage(connection); assertNotNull(m); }

Example 8

@Override protected void populateObject(Object object) throws Exception { super.populateObject(object); ConsumerInfo info = (ConsumerInfo) object; info.setConsumerId(createConsumerId("ConsumerId:1")); info.setBrowser(true); info.setDestination(createActiveMQDestination("Destination:2")); info.setPrefetchSize(1); info.setMaximumPendingMessageLimit(2); info.setDispatchAsync(false); info.setSelector("Selector:3"); info.setSubscriptionName("SubcriptionName:4"); info.setNoLocal(true); info.setExclusive(false); info.setRetroactive(true); info.setPriority((byte) 1); { BrokerId value[] = new BrokerId[2]; for (int i = 0; i < 2; i++) { value[i] = createBrokerId("BrokerPath:5"); } info.setBrokerPath(value); } info.setAdditionalPredicate(createBooleanExpression("AdditionalPredicate:6")); info.setNetworkSubscription(false); info.setOptimizedAcknowledge(true); info.setNoRangeAcks(false); }

Example 9

protected ConsumerInfo createConsumerInfo(SessionInfo sessionInfo, ActiveMQDestination destination) throws Exception { ConsumerInfo info = new ConsumerInfo(sessionInfo, ++idGenerator); info.setBrowser(false); info.setDestination(destination); info.setPrefetchSize(); info.setDispatchAsync(false); return info; }

Example 10

public void testRequestResponse() throws Exception { ConsumerInfo expected = new ConsumerInfo(); expected.setSelector("Edam"); expected.setResponseRequired(true); LOG.info("About to send: " + expected); Response response = (Response) producer.request(expected, ); LOG.info("Received: " + response); assertNotNull("Received a response", response); assertTrue("Should not be an exception", !response.isException()); }

Example 11

public void testAddConsumerThenSend() throws Exception { // Start a producer on local broker StubConnection connection1 = createConnection(); ConnectionInfo connectionInfo1 = createConnectionInfo(); SessionInfo sessionInfo1 = createSessionInfo(connectionInfo1); ProducerInfo producerInfo = createProducerInfo(sessionInfo1); connection1.send(connectionInfo1); connection1.send(sessionInfo1); connection1.send(producerInfo); destination = createDestinationInfo(connection1, connectionInfo1, destinationType); // Start a consumer on a remote broker StubConnection connection2 = createRemoteConnection(); ConnectionInfo connectionInfo2 = createConnectionInfo(); SessionInfo sessionInfo2 = createSessionInfo(connectionInfo2); connection2.send(connectionInfo2); connection2.send(sessionInfo2); ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo2, destination); connection2.send(consumerInfo); Thread.sleep(); // Give forwarding bridge a chance to finish setting up try { Thread.sleep(); } catch (InterruptedException ie) { ie.printStackTrace(); } // Send the message to the local boker. connection1.send(createMessage(producerInfo, destination, deliveryMode)); // Make sure the message was delivered via the remote. Message m = receiveMessage(connection2); assertNotNull(m); }

Example 12

@Test public void verifyNoRemoveOnOneConduitRemove() throws Exception { EasyMock.expect(localBroker.request(EasyMock.isA(ConsumerInfo.class))).andReturn(null); control.replay(); remoteListener.onCommand(path2Msg); remoteListener.onCommand(path1Msg); remoteListener.onCommand(removePath2Msg); control.verify(); }

Example 13

private Message createConsumerAndReceiveMessage(ActiveMQDestination destination) throws Exception { // Now create remote consumer that should cause message to move to this // remote consumer. ConsumerInfo consumerInfo = createConsumerInfo(consumerSessionInfo, destination); consumerConnection.send(consumerInfo); Message m = receiveMessage(consumerConnection); return m; }

Example 14

protected ConsumerInfo createConsumerInfo(SessionInfo sessionInfo, ActiveMQDestination destination) throws Exception { ConsumerInfo info = new ConsumerInfo(sessionInfo, ++idGenerator); info.setBrowser(false); info.setDestination(destination); info.setPrefetchSize(); info.setDispatchAsync(false); return info; }

Example 15

public void testQueueAckRemovesMessage() throws Exception { // Start a producer and consumer StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); destination = createDestinationInfo(connection, connectionInfo, destinationType); Message message1 = createMessage(producerInfo, destination, deliveryMode); Message message2 = createMessage(producerInfo, destination, deliveryMode); connection.send(message1); connection.send(message2); // Make sure the message was delivered. ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); connection.request(consumerInfo); Message m = receiveMessage(connection); assertNotNull(m); assertEquals(m.getMessageId(), message1.getMessageId()); ArtemisBrokerWrapper wrapper = (ArtemisBrokerWrapper) broker.getBroker(); long messageCount = wrapper.getAMQueueMessageCount(destination); assertTrue(messageCount == 2); connection.send(createAck(consumerInfo, m, 1, MessageAck.DELIVERED_ACK_TYPE)); messageCount = wrapper.getAMQueueMessageCount(destination); assertTrue(messageCount == 2); connection.send(createAck(consumerInfo, m, 1, MessageAck.STANDARD_ACK_TYPE)); //give some time for broker to count down Thread.sleep(); messageCount = wrapper.getAMQueueMessageCount(destination); assertTrue(messageCount == 1); }

Example 16

public void testConsumerPrefetchAndDeliveredAck() throws Exception { // Start a producer and consumer StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); destination = createDestinationInfo(connection, connectionInfo, destinationType); ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); consumerInfo.setPrefetchSize(1); connection.request(consumerInfo); // Send 3 messages to the broker. connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.request(createMessage(producerInfo, destination, deliveryMode)); // Make sure only 1 message was delivered. Message m1 = receiveMessage(connection); assertNotNull(m1); assertNoMessagesLeft(connection); // Acknowledge the first message. This should cause the next message to // get dispatched. connection.request(createAck(consumerInfo, m1, 1, MessageAck.DELIVERED_ACK_TYPE)); Message m2 = receiveMessage(connection); assertNotNull(m2); connection.request(createAck(consumerInfo, m2, 1, MessageAck.DELIVERED_ACK_TYPE)); Message m3 = receiveMessage(connection); assertNotNull(m3); connection.request(createAck(consumerInfo, m3, 1, MessageAck.DELIVERED_ACK_TYPE)); }

Example 17

public void testConsumerPrefetchAtOne() throws Exception { // Start a producer and consumer StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); destination = createDestinationInfo(connection, connectionInfo, destinationType); ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); consumerInfo.setPrefetchSize(1); connection.send(consumerInfo); // Send 2 messages to the broker. connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.send(createMessage(producerInfo, destination, deliveryMode)); // Make sure only 1 message was delivered. Message m = receiveMessage(connection); assertNotNull(m); assertNoMessagesLeft(connection); }

Example 18

public void testQueueNonPersistentMessagesLostOnRestart() throws Exception { ActiveMQDestination destination = new ActiveMQQueue("TEST"); // Setup the producer and send the message. StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); Message message = createMessage(producerInfo, destination); message.setPersistent(false); connection.send(message); // restart the broker. restartBroker(); // Setup the consumer and receive the message. connection = createConnection(); connectionInfo = createConnectionInfo(); sessionInfo = createSessionInfo(connectionInfo); connection.send(connectionInfo); connection.send(sessionInfo); ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); connection.send(consumerInfo); // Message should have been dropped due to broker restart. assertNoMessagesLeft(connection); }

Example 19

public List<AMQConsumer> createConsumer(ConsumerInfo info, SlowConsumerDetectionListener slowConsumerDetectionListener) throws Exception { //check destination ActiveMQDestination dest = info.getDestination(); ActiveMQDestination[] dests = null; if (dest.isComposite()) { dests = dest.getCompositeDestinations(); } else { dests = new ActiveMQDestination[]{dest}; } List<AMQConsumer> consumersList = new java.util.LinkedList<>(); for (ActiveMQDestination openWireDest : dests) { boolean isInternalAddress = false; if (AdvisorySupport.isAdvisoryTopic(dest)) { if (!connection.isSuppportAdvisory()) { continue; } isInternalAddress = connection.isSuppressInternalManagementObjects(); } if (openWireDest.isQueue()) { openWireDest = protocolManager.virtualTopicConsumerToFQQN(openWireDest); SimpleString queueName = new SimpleString(convertWildcard(openWireDest)); if (!checkAutoCreateQueue(queueName, openWireDest.isTemporary())) { throw new InvalidDestinationException("Destination doesn't exist: " + queueName); } } AMQConsumer consumer = new AMQConsumer(this, openWireDest, info, scheduledPool, isInternalAddress); long nativeID = consumerIDGenerator.generateID(); consumer.init(slowConsumerDetectionListener, nativeID); consumersList.add(consumer); } return consumersList; }

Example 20

protected ConsumerInfo createConsumerInfo(SessionInfo sessionInfo, ActiveMQDestination destination) throws Exception { ConsumerInfo info = new ConsumerInfo(sessionInfo, ++idGenerator); info.setBrowser(false); info.setDestination(destination); info.setPrefetchSize(); info.setDispatchAsync(false); return info; }

Example 21

public void testSelectorSkipsMessages() throws Exception { // Start a producer and consumer StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); destination = createDestinationInfo(connection, connectionInfo, destinationType); ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); consumerInfo.setSelector("JMSType='last'"); connection.send(consumerInfo); Message message1 = createMessage(producerInfo, destination, deliveryMode); message1.setType("first"); Message message2 = createMessage(producerInfo, destination, deliveryMode); message2.setType("last"); connection.send(message1); connection.send(message2); // Use selector to skip first message. Message m = receiveMessage(connection); assertNotNull(m); assertEquals(m.getMessageId(), message2.getMessageId()); connection.send(createAck(consumerInfo, m, 1, MessageAck.STANDARD_ACK_TYPE)); connection.send(closeConsumerInfo(consumerInfo)); assertNoMessagesLeft(connection); }

Example 22

protected ConsumerInfo createConsumerInfo(SessionInfo sessionInfo, ActiveMQDestination destination) throws Exception { ConsumerInfo info = new ConsumerInfo(sessionInfo, ++idGenerator); info.setBrowser(false); info.setDestination(destination); info.setPrefetchSize(); info.setDispatchAsync(false); return info; }

Example 23

protected MessageAck createAck(ConsumerInfo consumerInfo, Message msg, int count, byte ackType) { MessageAck ack = new MessageAck(); ack.setAckType(ackType); ack.setConsumerId(consumerInfo.getConsumerId()); ack.setDestination(msg.getDestination()); ack.setLastMessageId(msg.getMessageId()); ack.setMessageCount(count); return ack; }

Example 24

public void testTopicConsumerOnlySeeMessagesAfterCreation() throws Exception { ActiveMQDestination destination = new ActiveMQTopic("TEST"); // Setup a first connection StubConnection connection1 = createConnection(); ConnectionInfo connectionInfo1 = createConnectionInfo(); connectionInfo1.setClientId("A"); SessionInfo sessionInfo1 = createSessionInfo(connectionInfo1); ProducerInfo producerInfo1 = createProducerInfo(sessionInfo1); connection1.send(connectionInfo1); connection1.send(sessionInfo1); connection1.send(producerInfo1); // Send the 1st message connection1.send(createMessage(producerInfo1, destination, deliveryMode)); // Create the durable subscription. ConsumerInfo consumerInfo1 = createConsumerInfo(sessionInfo1, destination); if (durableConsumer) { consumerInfo1.setSubscriptionName("test"); } consumerInfo1.setPrefetchSize(); connection1.send(consumerInfo1); Message m = createMessage(producerInfo1, destination, deliveryMode); connection1.send(m); connection1.send(createMessage(producerInfo1, destination, deliveryMode)); // Subscription should skip over the first message Message m2 = receiveMessage(connection1); assertNotNull(m2); assertEquals(m.getMessageId(), m2.getMessageId()); m2 = receiveMessage(connection1); assertNotNull(m2); assertNoMessagesLeft(connection1); }

Example 25

public void testWildcardConsume() throws Exception { // Setup a first connection StubConnection connection1 = createConnection(); ConnectionInfo connectionInfo1 = createConnectionInfo(); SessionInfo sessionInfo1 = createSessionInfo(connectionInfo1); ProducerInfo producerInfo1 = createProducerInfo(sessionInfo1); connection1.send(connectionInfo1); connection1.send(sessionInfo1); connection1.send(producerInfo1); // setup the wildcard consumer. ActiveMQDestination compositeDestination = ActiveMQDestination.createDestination("WILD.*.TEST", destinationType); ConsumerInfo consumerInfo1 = createConsumerInfo(sessionInfo1, compositeDestination); consumerInfo1.setPrefetchSize(); connection1.send(consumerInfo1); // These two message should NOT match the wild card. connection1.send(createMessage(producerInfo1, ActiveMQDestination.createDestination("WILD.CARD", destinationType), deliveryMode)); connection1.send(createMessage(producerInfo1, ActiveMQDestination.createDestination("WILD.TEST", destinationType), deliveryMode)); // These two message should match the wild card. ActiveMQDestination d1 = ActiveMQDestination.createDestination("WILD.CARD.TEST", destinationType); connection1.send(createMessage(producerInfo1, d1, deliveryMode)); Message m = receiveMessage(connection1); assertNotNull(m); assertEquals(d1, m.getDestination()); ActiveMQDestination d2 = ActiveMQDestination.createDestination("WILD.FOO.TEST", destinationType); connection1.request(createMessage(producerInfo1, d2, deliveryMode)); m = receiveMessage(connection1); assertNotNull(m); assertEquals(d2, m.getDestination()); assertNoMessagesLeft(connection1); connection1.send(closeConnectionInfo(connectionInfo1)); }

Example 26

protected ConsumerInfo createConsumerInfo(SessionInfo sessionInfo, ActiveMQDestination destination) throws Exception { ConsumerInfo info = new ConsumerInfo(sessionInfo, ++idGenerator); info.setBrowser(false); info.setDestination(destination); info.setPrefetchSize(); info.setDispatchAsync(false); return info; }

Example 27

public void testConsumerPrefetchAtTwo() throws Exception { // Start a producer and consumer StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); destination = createDestinationInfo(connection, connectionInfo, destinationType); ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); consumerInfo.setPrefetchSize(2); connection.send(consumerInfo); // Send 3 messages to the broker. connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.send(createMessage(producerInfo, destination, deliveryMode)); // Make sure only 1 message was delivered. Message m = receiveMessage(connection); assertNotNull(m); m = receiveMessage(connection); assertNotNull(m); assertNoMessagesLeft(connection); }

Example 28

public void testQueueBrowseMessages() throws Exception { // Start a producer and consumer StubConnection connection = createConnection(); ConnectionInfo connectionInfo = createConnectionInfo(); SessionInfo sessionInfo = createSessionInfo(connectionInfo); ProducerInfo producerInfo = createProducerInfo(sessionInfo); connection.send(connectionInfo); connection.send(sessionInfo); connection.send(producerInfo); destination = createDestinationInfo(connection, connectionInfo, destinationType); connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.send(createMessage(producerInfo, destination, deliveryMode)); connection.send(createMessage(producerInfo, destination, deliveryMode)); // Use selector to skip first message. ConsumerInfo consumerInfo = createConsumerInfo(sessionInfo, destination); consumerInfo.setBrowser(true); connection.send(consumerInfo); for (int i = 0; i < 4; i++) { Message m = receiveMessage(connection); assertNotNull(m); connection.send(createAck(consumerInfo, m, 1, MessageAck.DELIVERED_ACK_TYPE)); } assertNoMessagesLeft(connection); }

Example 29

@BeforeClass /** * sets up mocks which get re-used in the tests */ public void setUp() { //set up the mock for CMSClient cmsClient = mock(CMSClient.class); //- and the mock data that mock will return CmsCISimple cmsCISimple = new CmsCISimple(); Map<String,String> ciAttributes = new HashMap<String,String>(1); ciAttributes.put(AUTH_ATTR_KEY, AUTH_KEY_VALUE); cmsCISimple.setCiAttributes(ciAttributes); //for getCloud(user-name,cloud-name) when(cmsClient.getCloudCi(CLOUD_NAME, CLOUD_NAME)).thenReturn(cmsCISimple); when(cmsClient.getCloudCi("user", CLOUD_NAME)).thenReturn(cmsCISimple); //set up the mock for ConnectionInfo: system/blahblah connectionInfoSystem = mock(ConnectionInfo.class); when(connectionInfoSystem.getClientId()).thenReturn(SYSTEM_CLIENT_ID); when(connectionInfoSystem.getUserName()).thenReturn(SYSTEM_CLIENT_ID + ":" + CLOUD_NAME); when(connectionInfoSystem.getPassword()).thenReturn(AUTH_KEY_VALUE); //and another ConnectionInfo stubbedClientId/foobarbizbat connectionBadInfo = mock(ConnectionInfo.class); when(connectionBadInfo.getClientId()).thenReturn(MOCK_CLIENT_ID); when(connectionBadInfo.getUserName()).thenReturn(CLOUD_NAME + ":" + CLOUD_NAME); when(connectionBadInfo.getPassword()).thenReturn(CONN_INFO_PASS_BAD); //to cause fail paasword check //and another ConnectionInfo stubbedClientId/blahblah connectionInfoUser = mock(ConnectionInfo.class); when(connectionInfoUser.getClientId()).thenReturn(MOCK_CLIENT_ID); when(connectionInfoUser.getUserName()).thenReturn("user" + ":" + CLOUD_NAME); when(connectionInfoUser.getPassword()).thenReturn("blahblah"); //to cause fail paasword check // construct ConnectionContext, passing it the system's connection info connectionContextSystem = new ConnectionContext(connectionInfoSystem); //create a mock ConnectionContext connectionContextMock = mock(ConnectionContext.class); final Connection connectionMock = mock(Connection.class); when(connectionMock.getRemoteAddress()).thenReturn(MOCK_REMOTE_ADDR); when(connectionContextMock.getClientId()).thenReturn(MOCK_CLIENT_ID); when(connectionContextMock.getConnection()).thenAnswer(new Answer<Connection>() { @Override public Connection answer(InvocationOnMock invocation) throws Throwable { return connectionMock; } }); //set up mock for ConsumerInfo activeMQDestination = ActiveMQDestination.createDestination("mockMQDestionation", (byte) 1 ); activeMQDestination.setPhysicalName(MOCK_PHYSICAL_NAME); consumerInfo = mock(ConsumerInfo.class); when(consumerInfo.getDestination()).thenReturn(activeMQDestination); }

Example 30

@Override public Object createObject() throws Exception { ConsumerInfo info = new ConsumerInfo(); populateObject(info); return info; }
Sours: https://www.programcreek.com/java-api-examples/?api=org.apache.activemq.command.ConsumerInfo

JMS and ActiveMQ exception

Well I'm on Linux right now, but I bet it has to be:

D:\Programming\JMS\ActiveMQ\apache-activemqjar

Also, if you run it with Eclipse and go to Project -> Build Path and this jar then there shouldn't be any problems. Anyhow can you post the CLASSPATH variable?

EDIT

I can't help you if you can't help me. This is related to any other future questions or work in general, provide details - it is always helpful. Will be much helpful if you would provide the EXACT command that you are running in CMD and the code of the class where this happens.

java.lang.NoSuchMethodError

generally it means that the jar is in place, class also, BUT the method is not. It happens when you compile with one version of the jar and at runtime provide a jar where this method was removed, thus the JRE can't find it throwing the error.

I just tested on my computer

I do not understand why it does not work for you, but it does for me. Here is my class:

Everything is fine if I run it from eclipse with one single dependency in Maven:

Then I do it with java and javac

Notice that the only thing I added is the two jars.

Then java:

I added a few needed jars to the classpath and run it - it works perfectly.

Cheers, Eugene.

Sours: https://stackoverflow.com/questions//jms-and-activemq-exception
  1. Heroes sonic
  2. Rust patio cushions
  3. T9 bulb dimensions
  4. Medium shag

Welcome to Apache ActiveMQ

Apache ActiveMQ is a high performance Apache licensed Message Broker and JMS implementation.

To help you get started, try the following links:

Getting Started

Building

Examples

We welcome contributions of all kinds, for details of how you can help https://activemq.apache.org/contributing.html

Please refer to the website for details of finding the issue tracker, email lists, wiki or IRC channel at https://activemq.apache.org/

Please help us make Apache ActiveMQ better - we appreciate any feedback you may have.

Enjoy!

This software is licensed under the terms you may find in the file named "LICENSE" in this directory.

This distribution includes cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted. See https://www.wassenaar.org/ for more information.

The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5DC.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms. The form and manner of this Apache Software Foundation distribution makes it eligible for export under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section ) for both object code and source code.

The following provides more details on the included cryptographic software:

ActiveMQ supports the use of SSL TCP connections when used with with a JVM supporting the Java Cryptography extensions https://www.oracle.com/java/technologies/javase/javase-tech-security.html. ActiveMQ does not include these libraries itself, but is designed to use them.

Sours: https://github.com/apache/activemq
Hướng Dẫn Cài Đặt Apache ActiveMQ

ActiveMQ architecture and key metrics

monitoring guide / apache / architecture / activemq / message queue

Editor’s note (September ): This post has been updated to include new information about ActiveMQ Artemis.

Apache ActiveMQ is message-oriented middleware (MOM), a category of software that sends messages between applications. Using standards-based, asynchronous communication, ActiveMQ allows loose coupling of the services that make up an application, which is often foundational to enterprise messaging and distributed applications.

ActiveMQ is a Java-based open source project developed by the Apache Software Foundation. Apache currently offers two versions of ActiveMQ: Classic and Artemis. Once Artemis evolves to include all of the features available in the Classic version, Apache will support only a single version.

ActiveMQ is comparable to other messaging systems, such as Apache Kafka, RabbitMQ, and Amazon Simple Queue Service. Amazon also offers Amazon MQ, a managed implementation of ActiveMQ Classic. Essentially, each of these technologies supports enterprise messaging through a loosely coupled infrastructure.

In this post, we’ll look at how ActiveMQ works and explore some key ActiveMQ metrics you can monitor to understand the performance of your messaging infrastructure.

How does ActiveMQ work?

ActiveMQ sends messages between client applications—producers, which create messages and submit them for delivery, and consumers, which receive and process messages. The ActiveMQ broker routes each message through a messaging endpoint called a destination (in ActiveMQ Classic) or an address (in Artemis). Both ActiveMQ versions are capable of point-to-point messaging—in which the broker routes each message to one of the available consumers in a round-robin pattern—and publish/subscribe (or “pub/sub”) messaging—in which the broker delivers each message to every consumer that is subscribed to the topic (in ActiveMQ Classic) or address (in ActiveMQ Artemis). The diagram below illustrates the components in an ActiveMQ Classic deployment.

As shown above, Classic sends point-to-point messages via queues and pub/sub messages via topics. Artemis, on the other hand, uses queues to support both types of messaging and uses routing types to impose the desired behavior. In the case of point-to-point messaging, the broker sends a message to an address configured with the routing type, and the message is placed into a queue where it will be retrieved by a single consumer. (Any address typically has a single queue, but it can contain multiple queues if necessary, for example to support a cluster of ActiveMQ servers.) In the case of pub/sub messaging, the address contains a queue for each topic subscription and the broker uses the routing type to send a copy of each message to each subscription queue.

ActiveMQ implements the functionality specified in the Java Message Service (JMS) API, which defines a standard for creating, sending, and receiving messages. ActiveMQ client applications—producers and consumers—written in Java can use the JMS API to send and receive messages. Additionally, both Classic and Artemis support non-JMS clients written in Node.js, Ruby, PHP, Python, and other languages, which can connect to the ActiveMQ broker via the AMQP, MQTT, and STOMP protocols.

ActiveMQ sends messages asynchronously, so consumers don’t necessarily receive messages immediately. The producer’s task of composing and sending a message is disconnected from the consumer’s task of fetching it. Because ActiveMQ uses a broker as an intermediary, producers and consumers are independent (and even unaware) of each other. As soon as a producer sends a message to a broker, its task is complete, regardless of whether or when a consumer receives the message. Conversely, when a consumer receives a message from a broker, it does so without knowledge of the producer that created the message.

This type of arrangement, in which clients function without knowledge of one another, is known as loose coupling. The benefits of loose coupling include:

  • High throughput: Because producers don’t need to wait for acknowledgment from the consumer or broker, they can send messages quickly. ActiveMQ can achieve throughput of thousands of messages per second.
  • Flexibility: Clients can be temporarily unavailable, dynamically added to the environment, and even rewritten in a new language without affecting other clients or causing errors in the messaging process.
  • Heterogeneity: Clients operate independently, communicating with the ActiveMQ broker but not directly with one another. As a result, they may be written in any of the languages ActiveMQ supports.

Because the components of the ActiveMQ architecture are decoupled, you need to monitor producers, consumers, destinations, addresses, and brokers holistically to understand the context of any issues that may arise. For example, if you notice that a producer’s output has paused, it may not indicate a problem—but if it correlates with a destination’s rising memory usage, it can reveal a bottleneck in the larger system. Later, we’ll look at some specific metrics that contribute to the big picture of ActiveMQ monitoring. But first, we’ll examine ActiveMQ’s fundamental unit of work—the message.

Messages

Each message ActiveMQ sends is based on the JMS specification, and is made up of headers, optional properties, and a body.

JMS message headers contain metadata about the message. Headers are defined in the JMS specification, and their values are set either when the producer creates the message, or when ActiveMQ sends it.

Headers convey qualities of the message that affect how the broker and clients behave. Let’s take a look at two key characteristics that ActiveMQ takes into account when delivering messages: expiration and persistence.

Message expiration

Depending on its content and purpose, a message may lose its value after a certain amount of time. When a producer creates a message, it can set an expiration value in the message header. If it does not, the header value remains empty and the message never expires.

ActiveMQ discards any expired messages from its queues and topics rather than delivering them, and consumer code is expected to disregard any message that remains unprocessed after its expiration.

Message persistence

ActiveMQ messages are persistent by default, but you can configure persistence on a per-message or per-producer basis. When you send a persistent message, the broker saves the message to disk before attempting delivery. If the broker were to crash at that point, a copy of the message would remain and the process of sending the message could recover when the broker restarted. A non-persistent message, on the other hand, usually exists only in the broker’s memory and would be lost in an event that caused the broker to restart.

Sending non-persistent messages is usually faster because it doesn’t require the broker to execute expensive write operations. Non-persistent messaging is appropriate for short-lived data that gets replaced at frequent intervals, such as a once-a-minute update of an item’s location.

Properties

Properties provide a way of adding optional metadata to a message. ActiveMQ supports some properties that are defined in the JMS spec, and also implements some properties that aren’t part of the spec.

Producers can also define properties—arbitrarily and outside the JMS spec—and apply them to each message. Consumers can implement selectors to filter messages based on values present in the message properties. For example, you can configure an ActiveMQ producer to attach a property to each message, with a value of either or , and send them all to the same topic. You can write two consumers—a consumer and a consumer—that subscribe to that topic but that only receive messages with their selected value of the property.

Body

The content of an ActiveMQ message is the body. The body of a message can be text or binary data. (It’s also acceptable for a message’s body to be empty.) The value of the message header, which is set explicitly by the producer when the message is created, determines what can be carried in the body of the message: a file, a byte stream, a Java object, a stream of Java primitives, a set of name-value pairs, or a string of text.

For more information about message types, see this JMS documentation.

Memory and storage

ActiveMQ uses memory to store messages awaiting dispatch to consumers. Each message occupies some memory (how much depends on the size of the message) until it is dequeued and delivered to a consumer. At that point, ActiveMQ frees up the memory that had been used for that message. When producers are faster than consumers—there’s more enqueuing than dequeuing over a given time period—ActiveMQ’s memory use increases.

ActiveMQ also writes messages to disk for storage. Classic and Artemis both use paging to move messages to disk when memory is exhausted. When ActiveMQ needs to send those messages, they’re paged from disk back into memory. Paging messages to and from disk adds latency, but it allows ActiveMQ to process a large volume of messages without requiring enough memory to hold them all. Paging is enabled by default, but is optional—you can configure an address to discard messages when there is no memory available to store them.

In this section, we’ll look at how ActiveMQ uses memory and disk to store messages.

Memory

The host system dedicates some of its memory as heap memory for the JVM in which ActiveMQ runs. ActiveMQ’s default maximum heap size varies across versions and JVMs. To specify the maximum percentage of the JVM’s heap memory that ActiveMQ Classic can use, adjust the child of the element in the broker configuration file (activemq.xml). You can express this as a percentage of the JVM’s heap memory (e.g., ), or as a number of bytes, as shown below. (Note that your element may look different than the one in this example, depending on your configuration.)

activemq.xml

The memory specified on the element must be shared amongst all of the broker’s queues and topics. Each destination may also be configured with an explicit memory limit, designated in the element inside an optional in the activemq.xml file:

activemq.xml

ActiveMQ Artemis uses half of the memory available to the JVM unless you adjust this memory allotment by setting the parameter in the broker configuration file (broker.xml). If the messages held in all of the broker’s addresses require all of the space specified by , Artemis will page new messages to disk as they arrive. You can optionally control the memory available to any single Artemis address by setting in the element in broker.xml. Without a value, an address shares the available broker-wide memory resources with all other addresses, up to the default limit or the defined .

The code snippet below shows the element from an example file in the ActiveMQ Artemis source code. This configures the paging behavior of two addresses (named “pagingQueue” and “exampleQueue”) and includes a catch-all configuration that will apply to all other addresses (designated by ). Each address’s value determines the maximum amount of memory that will be used to store messages for the address. Artemis uses the value to determine the size of each page file on disk that will store an address’s paged messages. As more messages are paged, Artemis will create additional page files of the same size.

broker.xml

Both ActiveMQ Classic and Artemis use memory differently for non-persistent messages than they do for persistent messages. Each non-persistent message is stored in memory as it arrives. When the available memory is full, Classic moves all messages to disk, but Artemis leaves existing messages in memory and pages new messages to disk. Each persistent message is also stored in memory as it arrives, and is also written to the message store on disk. If no more memory is available, incoming persistent messages are written directly into the message store.

As long as the memory available to the destination or address isn’t exhausted, incoming messages can be dispatched directly from memory without incurring any latency related to disk activity. If the message is not available in memory (either because it got flushed from memory to the temp store or because it was written to the message store when available memory was full), the broker must page the message data from disk in order to dispatch it to a consumer.

Storage

You can specify the amount of storage your Classic brokers will use for persistent messages in the activemq.xml file’s element, as in the example below:

activemq.xml

Storage for ActiveMQ Classic’s non-persistent messages is specified separately. Non-persistent messages are written to storage only after available memory is exhausted. You can specify the amount of storage to be used for non-persistent messages in the activemq.xml file’s element, which defaults to 50 GB. You can configure this as a percentage of available disk space () or as a number of bytes (as shown below):

activemq.xml

ActiveMQ Classic uses KahaDB as its default message storage mechanism. It stores both persistent and non-persistent messages.

Artemis’s primary message store is the file journal. To allow ActiveMQ to manage messages efficiently, the file journal is designed to minimize the movement required of the disk head when HDD storage is used (although ActiveMQ supports SSD storage as well). You can configure the file journal via the broker.xml file, as described in the Artemis documentation.

Both versions also support storing messages via JDBC. Using this configuration, you can choose from a number of SQL databases to find the storage mechanism that best meets your needs for scalability and support. See the documentation for ActiveMQ Classic and ActiveMQ Artemis for more information about using the JDBC message store.

We’ve looked at some characteristics of JMS messages, and at some different ways ActiveMQ stores and sends them. But ActiveMQ’s work isn’t done until a message is delivered to a consumer. In the next section we’ll look at how consumers handle messages.

Consumers

Consumers are the applications that receive the messages ActiveMQ sends. In this section, we’ll look at some key characteristics that influence the behavior of consumers: subscriptions and acknowledgment.

Durable vs. nondurable subscriptions

A consumer can subscribe to a topic as either a durable or nondurable subscriber. (Durability applies only to messages within a topic, not within a queue.) In the case of a durable subscription, ActiveMQ will retain messages if the subscriber is unavailable. When that subscriber reconnects, it receives new messages that arrived during the time it was disconnected. A nondurable subscriber would not receive any messages published to the topic during the time it was disconnected from the broker.

Message acknowledgment

To ensure that messages are received and—if necessary—to avoid sending messages more than once, ActiveMQ supports message acknowledgment. Each consumer is configured to use an acknowledgment mode that determines when and how it will acknowledge a message—either automatically upon receipt, or by making an explicit call to an method. ActiveMQ metrics for both Classic and Artemis show information about the number of messages acknowledged and not yet acknowledged, but the meaning of those metrics depends on the consumer’s acknowledgment mode. A spike in unacknowledged messages could mean that the consumer is offline and unable to receive messages, or that the consumer is failing to successfully execute its manual call.

So far, we’ve covered what ActiveMQ is, and how it works. In the next section, we’ll introduce some useful metrics to help you understand how to monitor ActiveMQ.

Key metrics for ActiveMQ monitoring

By tracking ActiveMQ metrics, you can effectively monitor resource usage, broker performance, and message activity. Monitoring these metrics can help you understand the performance of your messaging infrastructure and detect potential problems that might affect your services.

ActiveMQ metrics come from:

Because ActiveMQ is written in Java, you can query destination, address, broker, and JVM metrics via Java Management Extensions (JMX). You can view these metrics using JConsole, a GUI that’s included in the JDK, or with other JMX-compliant monitoring systems. In Part 2 of this series, we’ll look at JConsole and other tools available to help you collect and view ActiveMQ metrics.

In this section, we’ll explore key ActiveMQ metrics—where to find them, and the reasons you might want to collect them. This builds on our Monitoring series, which discusses how to identify high-value monitoring data, how to create a smart strategy for alerting, and how to investigate the issues your monitoring uncovers.

Destination and address metrics

ActiveMQ Classic and ActiveMQ Artemis use different types of endpoints to route messages to consumers. Monitoring these endpoints—destinations and addresses—can give you information about the speed, volume, and resource usage of your messaging system.

VersionJMX attributeDescriptionMBeanMetric type
ClassicPercentage of configured memory used by the destinationorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>,destinationType=(Queue|Topic),destinationName=<MY_DESTINATION>Resource: Utilization
ArtemisMemory used (in bytes) by the addressorg.apache.activemq.artemis:broker="<MY_BROKER>",component=addresses,address=<MY_ADDRESS>Resource: Utilization
ClassicThe number of consumers currently subscribed to the destinationorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>,destinationType=(Queue|Topic),destinationName=<MY_DESTINATION>Other
ArtemisThe number of consumers consuming messages from the queueorg.apache.activemq.artemis:broker="<MY_BROKER>",component=addresses,address=<MY_ADDRESS>,subcomponent=queues,routing-type=“anycast”,queue="<MY_QUEUE>"Other
ClassicThe number of producers currently attached to the destinationorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>,destinationType=(Queue|Topic),destinationName=<MY_DESTINATION>Other
ClassicThe number of messages (per destination) that have not been acknowledged by a consumer. Includes those not yet dispatchedorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>,destinationType=(Queue|Topic),destinationName=<MY_DESTINATION>Resource: Saturation
ArtemisThe number of messages currently in the queue. Includes scheduled, paged, and in-delivery messagesorg.apache.activemq.artemis:broker="<MY_BROKER>",component=addresses,address=<MY_ADDRESS>,subcomponent=queues,routing-type=“anycast”,queue="<MY_QUEUE>Resource: Saturation
ClassicThe number of messages in the destination that expired before they could be deliveredorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>,destinationType=(Queue|Topic),destinationName=<MY_DESTINATION>Other
ArtemisThe number of messages in the queue that expired before they could be deliveredorg.apache.activemq.artemis.addresses.<MY_BROKER>.addresses.queues.“anycast”.<MY_ADDRESS>,subcomponent=queues,routing-type=“anycast”,queue="<MY_QUEUE>Other

Metrics to alert on: MemoryPercentUsage (Classic) / AddressSize (Artemis)

ActiveMQ Classic’s metric represents the percentage of the destination’s currently in use. If you haven’t set a for the destination, it inherits the broker’s configured , and the metric represents the percentage of that value currently being used by the destination. (See the Memory and storage section for more details.)

ActiveMQ Artemis’s metric measures the memory used by the address.

As the memory usage of a destination or address rises, you may see a decrease in the rate at which your producers send messages. This is thanks to Producer Flow Control (PFC), which reduces the rate at which brokers send messages in both versions of ActiveMQ.

PFC is triggered in ActiveMQ Classic when a destination’s memory usage is at or above the (which defaults to 70 percent of the available memory—either the broker’s limit or, if defined, the destination’s ). You can change this value by adding an attribute to the relevant element in activemq.xml. The code snippet below shows how you would set to 80 percent of the broker’s memory for a queue named and 50 percent for a topic named .

activemq.xml

See the ActiveMQ documentation for more information about configuring memory limits in ActiveMQ Classic.

If you’re using ActiveMQ Artemis, PFC is triggered when an address’s memory usage reaches its configured value. The sample code below adds an of to the configuration we created earlier in this post. This policy prevents producers from sending messages to this address when memory is exhausted:

broker.xml

Whichever version of ActiveMQ you’re using, PFC could have a noticeable effect on the performance of your messaging system. If you’re using ActiveMQ Classic, you should create an alert to notify you when a destination’s value approaches its value so you can take action before PFC is activated. With ActiveMQ Artemis, you should create an alert that triggers when the value of an address’s metric approaches its limit.

If you are using point-to-point messaging, you can reduce memory pressure by scaling out your consumer fleet to dequeue messages more quickly. If your pub/sub messaging system is using durable subscribers, make sure those consumers are available often enough to prevent a backlog of messages. In either case, increasing memory available to your destinations will help, too.

Metric to watch: ConsumerCount

Sooner or later, each destination or address needs to deliver messages to consumers. Consumers may come and go (for example, as your infrastructure dynamically scales), and a fluctuating consumer count could be normal in some cases. You should be able to identify a normal range in the number of connected consumers, and both ActiveMQ versions produce a metric you can monitor for abnormalities. If your value changes unexpectedly, your consumer fleet may have scaled out more than usual, or some hosts may have become unavailable.

Metric to watch: ProducerCount

This metric tracks the number of producers currently attached to an ActiveMQ Classic broker. Whether a of zero indicates a problem depends on your expected pattern of activity. If your producers are typically active only sporadically (e.g., if they send a batch of messages once a day), this may be normal. However, if you expect to have active producers at all times, you should investigate a of zero, as it could indicate a service interruption.

Metrics to watch: QueueSize (Classic) / MessageCount (Artemis)

These metrics track the number of messages that have not been acknowledged by consumers. If you see this metric consistently increasing, it could indicate that the producers are publishing messages faster than consumers are processing them, or that consumers are failing to acknowledge the messages they receive. This could cause the destination or address to run out of memory (which could even affect the performance of the broker’s other destinations or addresses), so you should monitor memory usage metrics alongside these.

In the case of a queue, you may be able to reduce the or by scaling out your consumer fleet so that more hosts are available to read from the queue. In ActiveMQ Classic, a topic’s could rise if durable consumers are unavailable to fetch messages—you can address this by decreasing the expiration time of new messages or by removing durable subscribers that are consistently unavailable.

Metrics to watch: ExpiredCount (Classic) / MessagesExpired (Artemis)

These metrics represent the number of messages that expired before they could be delivered. If you expect all messages to be delivered and acknowledged within a certain amount of time, you can set an expiration for each message, and investigate if the number of expiring messages rises above zero.

In some cases, though, expired messages may not be a sign of trouble. For example, if your environment includes consumers with durable subscriptions but an unreliable network, some messages could expire while those consumers are disconnected. When the consumers reconnect, they’ll request all messages published in the interim, but if some of those messages contain information that frequently gets updated (e.g., status updates at one-minute intervals), it’s better to discard them than deliver them.

Broker metrics

As mentioned earlier, the ActiveMQ broker has configurable limits on the amount of memory and disk space it’s allowed to use. Here are some of the metrics you should monitor to ensure that your broker is working properly within its resource limits.

VersionJMX attributeDescriptionMBeanMetric type
ClassicPercentage of available memory used by all destinations on the brokerorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>Resource: Utilization
ArtemisPercentage of the broker’s available memory () used by all the addresses on the brokerorg.apache.activemq.artemis:broker=<MY_BROKER>Resource: Utilization
ClassicPercentage of available disk space () used for persistent message storageorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>Resource: Utilization
ArtemisPercentage of total disk store usedorg.apache.activemq.artemis:broker=<MY_BROKER>Resource: Utilization
ClassicPercentage of available disk space () used for non-persistent message storageorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>Resource: Utilization
ClassicThe total number of messages sent to the brokerorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>Work: Throughput
ArtemisThe total number of messages sent to the brokerorg.apache.activemq.artemis:broker=<MY_BROKER>Work: Throughput
ClassicThe total number of messages the broker has delivered to consumersorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>Work: Throughput
ArtemisThe total number of messages consumers have acknowledged from all queues on this brokerorg.apache.activemq.artemis:broker=<MY_BROKER>Work: Throughput
ClassicA count of topics currently attached to this brokerorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>Other
ClassicA count of queues currently attached to this brokerorg.apache.activemq:type=Broker,brokerName=<MY_BROKER>Other
ArtemisThe number of queues created on this serverorg.apache.activemq.artemis:broker="<MY_BROKER>Other
ArtemisThe number of clients connected to the brokerorg.apache.activemq.artemis:broker="<MY_BROKER>"Other

Metrics to alert on: MemoryPercentUsage (Classic) / AddressMemoryUsagePercentage (Artemis)

If you find that a broker’s memory usage is rising, there are a few steps you can take to prevent resource constraints from affecting your application’s performance.

  • Scale out your consumers. This can increase the rate at which messages are consumed, allowing the broker to reclaim memory and disk space.
  • Increase the memory available to the broker. (See the Memory and storage section of this post for information.) To do this, you may need to scale up the amount of memory allocated to the JVM, which could require adding memory to the host.
  • Reduce the memory available to the destinations associated with the broker (particularly if you have a large number of destinations). Although this will force the broker to persist messages to disk sooner, it also reduces the possibility of triggering PFC and enables producers to continue sending messages even when consumers are falling behind. See the ActiveMQ documentation for more information.

If your host runs services in addition to ActiveMQ, comparing ActiveMQ memory usage to overall host-level usage may help you troubleshoot resource constraints by showing you specifically how your host’s memory is being consumed.

Metrics to alert on: StorePercentUsage (Classic) / DiskStoreUsage (Artemis)

This is the percentage of available disk space used by the broker’s persistent message store. The broker can reach its persistent storage limit if consumers are slow or unavailable, and if messages are large. It’s important to monitor this metric because if a broker runs out of persistent storage, PFC may cause producers to stop sending messages.

Metric to watch: TempPercentUsage

When an ActiveMQ Classic broker runs out of memory to store non-persistent messages, it moves those messages to a temp location on the file system. If that temporary storage space fills up, producers will stop sending messages until storage space is freed up (assuming PFC is enabled).

You might run out of temporary storage space for any number of reasons, including:

  • Slow or absent consumers.
  • Specifying a value that is smaller than the broker’s . In this case, the memory holds more message data than the temp store has room for, and will exceed percent as soon as memory fills and messages are sent to the temp store.
  • Specifying a value that is smaller than KahaDB’s (which is 32 MB by default). This could cause the temp store to fill up because the broker will create a 32 MB journal file to hold the message data on disk, regardless of the amount of message data in memory.

If PFC is activated, your messaging throughput will drop, so it’s important to monitor your value. You should alert on a value that gives you enough time to remove messages or add disk space before reaches percent and triggers PFC.

Metrics to watch: TotalEnqueueCount (Classic) / TotalMessagesAdded (Artemis) and TotalDequeueCount (Classic) / TotalMessagesAcknowledged (Artemis)

and track the number of messages sent to the broker. You can monitor these metrics to understand the volume of messages emitted by your producers. and show the number of messages that have been delivered by the broker and acknowledged by your consumers. (All of these metrics are cumulative counts calculated over the entire time the broker has been running, and reset to zero when the broker is restarted.)

You should monitor the rate of messages enqueued alongside the dequeue rate to understand your system’s overall message volume and the degree to which consumers are keeping up with producers.

Metrics to watch: Topics and Queues (Classic) / QueueCount (Artemis)

There’s no correct number of topics or queues for any given ActiveMQ deployment, but you probably have expectations about what’s right for your environment. You can monitor ActiveMQ Classic to see the count of your broker’s topics and queues, and you can see the total number of queues on an Artemis broker. These metrics may help you troubleshoot any misbehavior like missing messages or producer errors, which could occur if a destination isn’t available as expected.

Metric to watch: ConnectionCount

The number of producers and consumers connected to your Artemis broker might be dynamic, but this metric can be useful for troubleshooting. If falls to zero unexpectedly, it could indicate a networking problem preventing clients from reaching your ActiveMQ server.

JVM metrics

ActiveMQ runs within the JVM, so metrics that inform you of the health of the JVM can be critical in monitoring your messaging. In this section, we’ll look at some key JVM metrics.

JMX attributeDescriptionMBeanMetric type
The total amount of time (in milliseconds) the JVM has spent executing garbage collection processesjava.lang:type=GarbageCollector,name=(Copy|MarkSweepCompact|PS MarkSweep|PS Scavenge|G1 Old Generation|G1 Young Generation)Other
The total count of garbage collection processes executed by the JVMjava.lang:type=GarbageCollector,name=(Copy|MarkSweepCompact|PS MarkSweep|PS Scavenge|G1 Old Generation|G1 Young Generation)Other
This contains values for the heap’s , , , and metricsjava.lang:type=MemoryResource: Utilization
Threads currently used by the JVMjava.lang:type=ThreadingOther

Metric to alert on: CollectionTime

Because ActiveMQ runs in the JVM, its memory is managed by Java’s garbage collection (GC) process. A running Java application requires memory to create the objects it uses, and the Java garbage collector periodically evaluates memory usage and frees up unused memory. As ActiveMQ’s message volume increases, it will use more memory. As a result, the JVM will execute garbage collection more frequently, which could slow down messaging overall.

You can use JMX to query metrics that show the overall time spent on garbage collection. Any time the JVM spends on GC will have some effect on the applications running there (like ActiveMQ), though it may not always be perceptible. GC metrics are cumulative, so you should expect to see them rise continually, returning to zero only when the JVM restarts. You should use a monitoring tool to track how frequently garbage collection is happening, and how long each process takes.

In Part 2 of this series, we’ll look at some of the tools that use JMX to monitor ActiveMQ. You can use tools like these to watch for an increase in the frequency of GC activity. You can correlate GC activity with any corresponding spikes in the broker’s that could explain a slowdown in your messaging activity.

Metric to watch: HeapMemoryUsage

The HeapMemoryUsage metric is a JSON object made up of , , , and values.

  • is set when the JVM starts, and designates the initial amount of heap memory available.
  • holds the value of the maximum possible size of the heap.
  • is set by the JVM, and fluctuates. This value indicates how much memory is guaranteed to be available for the JVM to use.
  • represents the amount of JVM heap memory currently in use.

You should watch and together to ensure that the JVM isn’t running out of available memory. Java will throw an exception if the JVM’s memory is exhausted. See the Java documentation and the ActiveMQ FAQ for guidance on resolving this problem.

Metric to watch: ThreadCount

Synchronous messaging requires a greater number of threads than asynchronous delivery. Using more threads causes the broker to incur the overhead of context switching, which requires more work from the host’s CPU. This could cause a slowdown in the queueing and dispatching of messages, and ultimately could lead to lower message throughput.

As described in the ActiveMQ documentation, you can reduce the number of threads ActiveMQ Classic requires by using thread pooling, enabling optimized dispatch on your queues, or using the NIO protocol.

Host-level metrics

Your host is the foundation of all the processes involved in ActiveMQ’s messaging activities. To understand bottlenecks that may arise, and to make informed decisions about when to scale out, look to your host-level metrics.

NameDescriptionMetric type
Disk usageThe percentage of the host’s available disk space currently in useResource: Utilization
Disk I/OThe rate of read and write operations per secondResource: Utilization

Metric to alert on: Disk usage

ActiveMQ uses disk space to store persistent messages, as well as non-persistent messages that get paged to disk when memory fills up. After a message has been acknowledged by a consumer, ActiveMQ Classic deletes it during a periodic cleanup task. ActiveMQ Artemis automatically deletes queues that have no queued messages and no subscribers. (By default, both versions execute their cleanup cycles every 30 seconds.)

If a Classic broker’s is higher than its , or if an Artemis broker’s rate outpaces , your host’s disk could fill up. You can correlate host-level disk usage metrics with the and metrics on ActiveMQ Classic and the metric on Artemis to verify that your disk is filling up with message data instead of, for example, log files from an unrelated process. You can create a forecast alert to notify you that your host is running out of disk space so you can take action in time to prevent performance problems.

Metric to watch: Disk I/O

ActiveMQ Classic brokers store messages on disk in a message store and a temp store. Similarly, Artemis brokers may page message data to disk as memory fills up. As a result, different brokers on the same host may compete for the chance to write messages to the disk. Rising disk I/O could lead to queued write operations, reducing message throughput overall.

If you see high disk activity, it could mean that your broker is very busy, especially if you also see high (from ActiveMQ Classic) or (from Artemis). If this is the case, you should consider distributing messaging activity across multiple nodes by creating a network of ActiveMQ Classic brokers or a cluster of Artemis servers.

Making meaning of the metrics

ActiveMQ metrics can help you proactively maintain your messaging infrastructure, providing you with information you need to investigate errors, missing messages, and unexpected latency. In this post, we’ve looked at the metrics you can collect from ActiveMQ, and highlighted some that are particularly valuable to monitor. In Part 2 of this series, we’ll show you some of the tools you can use to gather metrics from your ActiveMQ brokers, destinations, and addresses.

Acknowledgments

We’d like to thank Gary Tully of Red Hat for his technical review of this series.

Source Markdown for this post is available on GitHub. Questions, corrections, additions, etc.? Please let us know.


Want to work with us? We're hiring!

Sours: https://www.datadoghq.com/blog/activemq-architecture-and-metrics/

Activemq org apache

Apache ActiveMQ

Software message broker

Apache ActiveMQ is an open sourcemessage broker written in Java together with a full Java Message Service (JMS) client. It provides "Enterprise Features" which in this case means fostering the communication from more than one client or server. Supported clients include Java via JMS as well as several other "cross language" clients.[2] The communication is managed with features such as computer clustering and ability to use any database as a JMS persistence provider besides virtual memory, cache, and journal persistency.[3]

ActiveMQ is currently in major version 5, minor version [1]

There's another broker under the ActiveMQ umbrella code-named Artemis. It is based on the HornetQ code-base which was donated[4] from the JBoss community to the Apache ActiveMQ community in Artemis is the "next generation" broker from ActiveMQ and will ultimately become the next major version of ActiveMQ.[5]

History[edit]

The ActiveMQ project was originally created by its founders from LogicBlaze[6] in , as an open source message broker, hosted by CodeHaus. The code and ActiveMQ trademark were donated to the Apache Software Foundation in , where the founders continued to develop the codebase with the extended Apache community.

Technical features[edit]

ActiveMQ employs several modes for high availability, including both file-system and database row-level locking mechanisms, sharing of the persistence store via a shared filesystem, or true replication using Apache ZooKeeper. A horizontal scaling mechanism called a Network of Brokers,[7] is also supported out of the box. ActiveMQ supports a relatively large number of transport protocols, including OpenWire, STOMP, MQTT, AMQP, REST, and WebSockets.[8]

Usage[edit]

ActiveMQ is used in enterprise service bus implementations such as Apache ServiceMix[9] and Mule.[10] Other projects using ActiveMQ include Apache Camel[11] and Apache CXF[12] in SOA infrastructure projects.[13]

Benchmark[edit]

Coinciding with the release of Apache ActiveMQ , the world's first results for the SPECjms industry standard benchmark were announced. Four results were submitted to the SPEC and accepted for publication. The results cover different topologies to analyze the scalability of Apache ActiveMQ in two dimensions.[14][15]

Commercial support[edit]

Apache offers limited ActiveMQ support on a volunteer basis. Commercial companies specializing in ActiveMQ are recommended for users needing more extensive support.[16]

See also[edit]

References[edit]

Bibliography[edit]

  • Snyder, Bruce; Bosanac, Dejan; Davies, Rob (March 28, ), ActiveMQ in Action (1st&#;ed.), Manning Publications, p.&#;, ISBN&#;, OCLC&#;
  • Bish, Timothy (May 23, ), Instant Apache ActiveMQ Messaging Application Development How-to (1st&#;ed.), Packt Publishing, p.&#;80, ISBN&#;, OCLC&#;

External links[edit]

Sours: https://en.wikipedia.org/wiki/Apache_ActiveMQ
How to Download and Install Apache ActiveMQ on Windows? - ActiveMQ tutorial

Helen said, freeing her mouth. Can I please. Helen asked, jerking her head. Helen began to put her head on the teacher's cock, his oily hairy body began to convulse. I saw Helen squeeze Tom's testicles during Tom's orgasm.

Now discussing:

Work long after midnight, and the black goddess, with a magnificent big chest, took possession of all my thoughts, went to the exit, I, having finished work, went out after her. I watched as she said goodbye to her friends and walked to the nearest metro station alone. It was time for me to go home, and my route was supposed to lead me directly in the opposite direction, but why At first, Roma came almost every.



12945 12946 12947 12948 12949