AD248 - ch08s06

Bookmark this page

Guided Exercise: Configuring the Journals and Other Settings

Configure a custom dead letter queue and change journal parameters.

Resources
Files:	`/home/student/AD248/labs/messaging-journal/standalone`
	`/home/student/AD248/labs/messaging-journal/mdb-client.war`
	`/home/student/AD248/labs/messaging-journal/helloworld-mdb.jar`
Application URL:	`http://localhost:8080/mdb-client/`

Outcomes

You should be able to configure a custom dead letter queue for an application queue and change the number and size of message journal files.

This exercise uses two applications:

mdb-client.war is a web application that receives messages on the queue path, connects to the java:/jms/CustomCF JMS ConnectionFactory, and publishes the messages it receives to the java:/jms/queue/AD248TestQueue JMS Queue. It accepts text from the user to use as message properties and the message body.
helloworld-mdb.jar is a Message-Driven Bean (MDB) that connects to the same JMS ConnectionFactory and consumes messages from the same JMS Queue as the previous application. It shows the message properties and body in the Red Hat JBoss Enterprise Application Platform (JBoss EAP) server log.

Before beginning the guided exercise, run the following command to prepare the environment:

[student@workstation ~]$ lab start messaging-journal

Instructions

Start a JBoss EAP standalone server.
Start an JBoss EAP instance using the /home/student/AD248/labs/messaging-journal/standalone directory as the base directory. Use the standalone-full.xml configuration file.
Use the following commands:
```
[student@workstation ~]$ /opt/jboss-eap-7.4/bin/standalone.sh \
--server-config=standalone-full.xml \
-Djboss.server.base.dir=/home/student/AD248/labs/messaging-journal/standalone/
```
Leave this terminal running the JBoss EAP standalone server instance.

Create a JMS queue to be used as a dead-letter queue (DLQ).

Open another terminal window and start the management CLI:

[student@workstation ~]$ /opt/jboss-eap-7.4/bin/jboss-cli.sh --connect
[standalone@localhost:9990 /]

Create a jms-queue named TestDLQ mapped to the JNDI name java:/jms/AD248TestDLQ:

[standalone@localhost:9990 /] cd /subsystem=messaging-activemq/server=default
[standalone@localhost:9990 server=default] ./jms-queue=TestDLQ:add(\
entries=[java:/jms/AD248TestDLQ])
{"outcome" => "success"}

Inspect TestDLQ to get its internal ActiveMQ address:

[standalone@localhost:9990 server=default] ./jms-queue=TestDLQ:\
read-attribute(name=queue-address)
{
    "outcome" => "success",
    "result" => "jms.queue.TestDLQ"
}

Configure the new queue as the DLQ for TestQueue.

Inspect TestQueue to get its internal ActiveMQ address:

[standalone@localhost:9990 server=default] ./jms-queue=TestQueue:\
read-attribute(name=queue-address)
{
    "outcome" => "success",
    "result" => "jms.queue.TestQueue"
}

Configure TestDLQ as the DLQ for TestQueue alone, and to move messages after a single failed delivery attempt.
Use the internal addresses queried in the previous steps to identify the queues when creating the address-setting configuration:
```
[standalone@localhost:9990 server=default] ./address-setting=\
jms.queue.TestQueue:add(dead-letter-address=jms.queue.TestDLQ,\
max-delivery-attempts=1)
{"outcome" => "success"}
```

Inspect the address-setting configuration to see that, although it defines dead letter and related redelivery attributes, it does not specify any expiration queue and delay:

[standalone@localhost:9990 server=default] ./address-setting=\
jms.queue.TestQueue:read-resource
{
    "outcome" => "success",
    "result" => {
        "address-full-policy" => "PAGE",
        "auto-create-jms-queues" => false,
        "auto-delete-jms-queues" => false,
        "dead-letter-address" => "jms.queue.TestDLQ",
        "expiry-address" => undefined,
        "expiry-delay" => -1L,
        "last-value-queue" => false,
        "max-delivery-attempts" => 1,
        "max-redelivery-delay" => 0L,
        "max-size-bytes" => -1L,
        "message-counter-history-day-limit" => 0,
        "page-max-cache-size" => 5,
        "page-size-bytes" => 10485760L,
        "redelivery-delay" => 0L,
        "redelivery-multiplier" => 1.0,
        "redistribution-delay" => -1L,
        "send-to-dla-on-no-route" => false,
        "slow-consumer-check-period" => 5L,
        "slow-consumer-policy" => "NOTIFY",
        "slow-consumer-threshold" => -1L
    }
}

Note the values of the expiry-delay and expiry-address attributes. This shows how defaults for a new address-setting might be unexpected. In this case, there is no expiry handling, instead of having dead letter handling.

Leave this terminal running the management CLI.

Deploy the mdb-client.war and helloworld-mdb.war applications.

Deploy the helloworld-mdb.war application.

[standalone@localhost:9990 server=default] deploy \
/home/student/AD248/labs/messaging-journal/mdb-client.war

Inspect the terminal window of your running JBoss EAP instance. You should see an output similar to the following:

...output omitted...
04:45:33,223 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 89) WFLYUT0021: Registered web context: '/mdb-client' for server 'default-server'
04:45:33,249 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "mdb-client.war" (runtime-name : "mdb-client.war")

Deploy the helloworld-mdb.war application.

[standalone@localhost:9990 server=default] deploy \
/home/student/AD248/labs/messaging-journal/helloworld-mdb.jar

Inspect the terminal window of your running JBoss EAP instance. You should see an output similar to the following:

...output omitted...
04:55:02,181 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "helloworld-mdb.jar" (runtime-name: "helloworld-mdb.jar")
04:55:02,318 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0042: Started message driven bean 'AD248TestQueueMDB' with 'activemq-ra.rar' resource adapter
04:55:02,361 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "helloworld-mdb.jar" (runtime-name : "helloworld-mdb.jar")

Send a message known to be processed without issues.

Send a message to the queue by using the following command from a new terminal:

[student@workstation ~]$ curl --data "count=1" --data "label=first" \
--data "message=test message body" \
http://localhost:8080/mdb-client/queue; echo
...output omitted...

Inspect the terminal window of your running JBoss EAP instance. You should see an output similar to the following:

...output omitted...
04:59:31,430 INFO  [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-4 (ActiveMQ-client-global-threads)) Received Message from queue: test message body
04:59:31,433 INFO  [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-4 (ActiveMQ-client-global-threads)) Message Properties: Copy #1 [first]
04:59:31,433 INFO  [class org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB] (Thread-4 (ActiveMQ-client-global-threads)) Message Body: test message body

Send a message known to trigger processing errors.

Send a failing message to the queue by using the following command:
```
[student@workstation ~]$ curl --data "count=1" --data "label=second" \
--data "message=test message - will FAIL" \
http://localhost:8080/mdb-client/queue; echo
...output omitted...
```
The implementation logic in the org.jboss.as.quickstarts.mdb.HelloWorldQueueMDB EJB triggers an error if the message contains an uppercase FAIL word.

Inspect the terminal window of your running JBoss EAP instance. You should see an output similar to the following:

...output omitted...
05:17:16,969 WARN  ... @797106320 has reached maximum delivery attempts, sending it to Dead Letter Address jms.queue.TestDLQ from jms.queue.TestQueue
05:17:16,975 WARN  [org.apache.activemq.artemis.core.client] (Thread-5 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure

Disable the consumer test application so that new messages remain in the queue.

Undeploy the helloworld-mdb.jar deployment. Run the following command from the management CLI:

[standalone@localhost:9990 server=default] /deployment=helloworld-mdb.jar:\
undeploy
{"outcome" => "success"}

Verify that the consumer test application stops:

[standalone@localhost:9990 server=default] /deployment=helloworld-mdb.jar:\
read-attribute(name=status)
{
    "outcome" => "success",
    "result" => "STOPPED"
}

Send another message to be processed without issues.
This message is not processed, just queued, because you disabled the consumer application.
1. Send a message to the queue by using the following command:
```
[student@workstation ~]$ curl --data "count=1" --data "label=third" \
--data "message=test message - to be queued" \
http://localhost:8080/mdb-client/queue; echo
...output omitted...
```
  Note the consumer has no way to know when the helloworld-mdb.jar application processes the message.

Verify that the second message was moved to the TestDLQ queue, and the third messages is still in TestQueue.

Go back to the terminal running the management CLI and list all messages in TestDLQ:

[standalone@localhost:9990 server=default] ./jms-queue=TestDLQ:list-messages
{
    "outcome" => "success",
    "result" => [{
        "address" => "jms.queue.TestDLQ",
        "Label" => "second",
        "messageID" => 82,
        "type" => 3,
        "JMSPriority" => 4,
        "JMSMessageID" => "ID:4cf6ae04-928e-11ee-993d-52540000fa09",
        "_AMQ_ORIG_MESSAGE_ID" => 79,
        "JMSDeliveryMode" => true,
        "__AMQ_CID" => "d1d0deed-928b-11ee-993d-52540000fa09",
        "_AMQ_ORIG_QUEUE" => "jms.queue.TestQueue",
        "Copy" => 1,
        "_AMQ_ROUTING_TYPE" => 1,
        "JMSExpiration" => 0,
        "_AMQ_ORIG_ADDRESS" => "jms.queue.TestQueue",
        "JMSTimestamp" => 1701685036931L
    }]
}

Note that the message property Label has the second value that you provided in the message with the FAIL string.

Go back to the terminal running the management CLI and list all messages in TestQueue:

[standalone@localhost:9990 server=default] ./jms-queue=TestQueue:list-messages
{
    "outcome" => "success",
    "result" => [{
        "JMSDeliveryMode" => true,
        "address" => "jms.queue.TestQueue",
        "__AMQ_CID" => "d1d0deed-928b-11ee-993d-52540000fa09",
        "Copy" => 1,
        "Label" => "third",
        "_AMQ_ROUTING_TYPE" => 1,
        "messageID" => 129,
        "JMSExpiration" => 0,
        "type" => 3,
        "JMSPriority" => 4,
        "JMSMessageID" => "ID:c86cb565-928f-11ee-993d-52540000fa09",
        "JMSTimestamp" => 1701685673561L
    }]
}

Note that the message property Label has the third value that you provided in the message you sent with the processor undeployed.

Inspect the current journal files, created according to the default JBoss EAP configuration.

In the terminal running the management CLI, inspect the default ActiveMQ server attributes related to the journal files:

[standalone@localhost:9990 server=default] :read-attribute(name=\
journal-min-files)
{
    "outcome" => "success",
    "result" => 2
}

[standalone@localhost:9990 server=default] :read-attribute(name=\
journal-file-size)
{
    "outcome" => "success",
    "result" => 10485760L
}

Open another terminal and list all files under /home/student/AD248/labs/messaging-journal/standalone/data/activemq/journal:

[student@workstation ~]$ ls -l \
/home/student/AD248/labs/messaging-journal/standalone/data/activemq/journal
total 20484
-rw-r--r--. 1 student student 10485760 Dec  4 05:27 activemq-data-1.amq
-rw-r--r--. 1 student student 10485760 Dec  4 04:37 activemq-data-2.amq
...output omitted...

Note that the number of data files and the size of each file matches the attribute values inspected in the previous step.

Change the journal file size and number of files.

In the terminal running the management CLI, increase the journal-min-files attribute value to 5 and the journal-file-size attribute value to 20 MB:

[standalone@localhost:9990 server=default] :write-attribute(\
name=journal-min-files, value=5)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

[standalone@localhost:9990 server=default] :write-attribute(\
name=journal-file-size, value=20971520)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

Changing those attributes requires reloading or restarting the server instance:
```
[standalone@localhost:9990 server=default] /:reload
...output omitted...
```
Check the log entries in the terminal running the JBoss EAP server and wait for the messages that show the server was restarted successfully.

Verify that the third message is still in TestQueue and that the journal files were changed.

Go back to the terminal running the management CLI and list all messages in TestQueue:

[standalone@localhost:9990 server=default] ./jms-queue=TestQueue:list-messages
...output omitted...

Go back to the idle terminal and check there are now five journal files, 20 MB each:

[student@workstation ~]$ ls -lh \
/home/student/AD248/labs/messaging-journal/standalone/data/activemq/journal
total 91M
-rw-r--r--. 1 student student 10M Dec  4 05:27 activemq-data-1.amq
-rw-r--r--. 1 student student 20M Dec  4 06:22 activemq-data-4.amq
-rw-r--r--. 1 student student 20M Dec  4 06:22 activemq-data-5.amq
-rw-r--r--. 1 student student 20M Dec  4 06:22 activemq-data-6.amq
-rw-r--r--. 1 student student 20M Dec  4 06:22 activemq-data-7.amq
...output omitted...

The numbers in each log file name are not important, only the number of files and their sizes.

Disable persistence for the messaging subsystem as a whole.
1. Go back to the terminal running the management CLI and change the persistence-enabled attribute to false:
```
[standalone@localhost:9990 server=default] :write-attribute(\
name=persistence-enabled,value=false)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
```
2. Changing this attributes requires reloading or restarting the server instance:
```
[standalone@localhost:9990 server=default] /:reload
...output omitted...
```
3. Check the log entries in the terminal running the JBoss EAP server and wait for the messages that show the server was restarted successfully.
Verify the third message was lost.
1. Go back to the terminal running the management CLI and list all messages in TestQueue:
```
[standalone@localhost:9990 server=default] ./jms-queue=TestQueue:list-messages
{
    "outcome" => "success",
    "result" => []
}
```
  This shows the queue is empty.
  Note
  Optionally, you can check that the journal files are still there. This is expected, but the files are not being used by JBoss EAP any more.

Clean up. Remove the test applications and JMS resources, and enable messaging persistence.

Go back to the terminal running the management CLI and remove the producer and consumer applications:

[standalone@localhost:9990 server=default] /deployment=helloworld-mdb.jar:remove
{"outcome" => "success"}

[standalone@localhost:9990 server=default] /deployment=mdb-client.war:remove
{"outcome" => "success"}

Remove the custom address-setting:

[standalone@localhost:9990 server=default] ./address-setting=\
jms.queue.TestQueue:remove
{"outcome" => "success"}

Remove the JMS custom ConnectionFactory and Queue resources:

[standalone@localhost:9990 server=default] ./pooled-connection-factory=\
custom:remove
{"outcome" => "success"}

[standalone@localhost:9990 server=default] ./jms-queue=TestDLQ:remove
{"outcome" => "success"}

[standalone@localhost:9990 server=default] ./jms-queue=TestQueue:remove
{"outcome" => "success"}

Re-enable persistence for the ActiveMQ server:

[standalone@localhost:9990 server=default] :write-attribute(\
name=persistence-enabled,value=true)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

Stop the standalone server instance:

[standalone@localhost:9990 server=default] /:shutdown

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish messaging-journal

Discuss Red Hat JBoss Enterprise Application Platform Administration I

Go to community

Welcome to the Red Hat JBoss Application Administration 1 (AD248) group!

Deanna

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat JBoss Application Administration I! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to AD248.Read more about Red Hat JBoss Application Administration I here.

270

Revision: ad248-7.4-18a9db2