[jira] [Comment Edited] (ARTEMIS-2678) Incomplete records for pages under high load
[
https://issues.apache.org/jira/browse/ARTEMIS-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065475#comment-17065475
]
Ansgar J. Sachs edited comment on ARTEMIS-2678 at 3/24/20, 1:02 PM:
1) The broker is running on all our stages with the same version. I guess that
using the latest upstream is nothing I would want to run on any setup but a
local one.
2) The OpenWire protocol is something caused by our old Jboss EAP which
prevents us from upgrading to a more up-to-date RA (like Artemis)
3) I will checkout the read-whole-page configuration and let you know about the
results
4) So what do you suggest for max-size-bytes and page-size-bytes? The default
is using 50% of max heap and 10Mb for page. However, at least this 50% boundary
is way to high if you have more than 1 queue or do I misunderstand this setting?
was (Author: ansgars):
1) The broker is running on all our stages with the same version. I guess that
using the latest upstream is nothing I would want to run on any setup but a
local one.
2) The OpenWire protocol is something caused by our old Jboss EAP which
prevents us from upgrading to a more up-to-date RA (like Artemis)
3) I will checkout the read-whole-page configuration and let you know about the
results
4) So what do you suggest for max-size-bytes and page-size-bytes? The default
is using 50% of max heap and 20Mb for page. However, at least this 50% boundary
is way to high if you have more than 1 queue or do I misunderstand this setting?
> Incomplete records for pages under high load
>
>
> Key: ARTEMIS-2678
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2678
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Environment: Linux
>Reporter: Ansgar J. Sachs
>Priority: Major
> Attachments: Bildschirmfoto 2020-03-23 um 17.35.41.png
>
>
> {quote}As developer, I expect paging to be resource saving and resilient to
> high load{quote}
> h3. Current Situation
> During a performance test with a throughput of ~25.000 messages per second
> that run mulitple hours, some consumers were too slow to consume and messages
> piled up on the broker. For this reason, the broker started to page the
> messages of growing queues. When we reduced the load from the broker, some
> queues stopped consuming due to the following logs:
> {code}
> AMQ222033: Page file 7.page had incomplete records at position
> 39,795,399 at record number 13,952
> target message no.16146 not found from start offset 46032883 and start
> message number 16146: java.lang.RuntimeException: target message no.16146 not
> found from start offset 46032883 and start message number 16146
> {code}
> It wasnt possible to recover from this state but deleting the paging
> directory.
> h3. Expected Situation
> I would expect that the paging mechanism is resilient to any errors.
> h3. Scenario Setup
> Master configuration:
> {code:xml}
>
>
>
> true
>
>
>
>
>
> 256Mb
> 64Mb
>
> 10
> PAGE
>
> {code}
> An extract of the monitoring of the Performance Test is attached to this
> issue.
> h3. Workaround
> Right now we disabled paging at all and only use our Heap. However, the heap
> is exhausted at 5 million messages which is in our use case better than
> loosing any of them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2678) Incomplete records for pages under high load
[
https://issues.apache.org/jira/browse/ARTEMIS-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065475#comment-17065475
]
Ansgar J. Sachs commented on ARTEMIS-2678:
--
1) The broker is running on all our stages with the same version. I guess that
using the latest upstream is nothing I would want to run on any setup but a
local one.
2) The OpenWire protocol is something caused by our old Jboss EAP which
prevents us from upgrading to a more up-to-date RA (like Artemis)
3) I will checkout the read-whole-page configuration and let you know about the
results
4) So what do you suggest for max-size-bytes and page-size-bytes? The default
is using 50% of max heap and 20Mb for page. However, at least this 50% boundary
is way to high if you have more than 1 queue or do I misunderstand this setting?
> Incomplete records for pages under high load
>
>
> Key: ARTEMIS-2678
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2678
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Environment: Linux
>Reporter: Ansgar J. Sachs
>Priority: Major
> Attachments: Bildschirmfoto 2020-03-23 um 17.35.41.png
>
>
> {quote}As developer, I expect paging to be resource saving and resilient to
> high load{quote}
> h3. Current Situation
> During a performance test with a throughput of ~25.000 messages per second
> that run mulitple hours, some consumers were too slow to consume and messages
> piled up on the broker. For this reason, the broker started to page the
> messages of growing queues. When we reduced the load from the broker, some
> queues stopped consuming due to the following logs:
> {code}
> AMQ222033: Page file 7.page had incomplete records at position
> 39,795,399 at record number 13,952
> target message no.16146 not found from start offset 46032883 and start
> message number 16146: java.lang.RuntimeException: target message no.16146 not
> found from start offset 46032883 and start message number 16146
> {code}
> It wasnt possible to recover from this state but deleting the paging
> directory.
> h3. Expected Situation
> I would expect that the paging mechanism is resilient to any errors.
> h3. Scenario Setup
> Master configuration:
> {code:xml}
>
>
>
> true
>
>
>
>
>
> 256Mb
> 64Mb
>
> 10
> PAGE
>
> {code}
> An extract of the monitoring of the Performance Test is attached to this
> issue.
> h3. Workaround
> Right now we disabled paging at all and only use our Heap. However, the heap
> is exhausted at 5 million messages which is in our use case better than
> loosing any of them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2678) Incomplete records for pages under high load
[
https://issues.apache.org/jira/browse/ARTEMIS-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ansgar J. Sachs updated ARTEMIS-2678:
-
Description:
{quote}As developer, I expect paging to be resource saving and resilient to
high load{quote}
h3. Current Situation
During a performance test with a throughput of ~25.000 messages per second that
run mulitple hours, some consumers were too slow to consume and messages piled
up on the broker. For this reason, the broker started to page the messages of
growing queues. When we reduced the load from the broker, some queues stopped
consuming due to the following logs:
{code}
AMQ222033: Page file 7.page had incomplete records at position
39,795,399 at record number 13,952
target message no.16146 not found from start offset 46032883 and start message
number 16146: java.lang.RuntimeException: target message no.16146 not found
from start offset 46032883 and start message number 16146
{code}
It wasnt possible to recover from this state but deleting the paging directory.
h3. Expected Situation
I would expect that the paging mechanism is resilient to any errors.
h3. Scenario Setup
Master configuration:
{code:xml}
true
256Mb
64Mb
10
PAGE
{code}
An extract of the monitoring of the Performance Test is attached to this issue.
h3. Workaround
Right now we disabled paging at all and only use our Heap. However, the heap is
exhausted at 5 million messages which is in our use case better than loosing
any of them.
was:
{quote}As developer, I expect paging to be resource saving and resilient to
high load{quote}
h3. Current Situation
During a performance test with a throughput of ~25.000 messages per second that
run mulitple hours, some consumers were too slow to consumed and messages piled
up on the broker. For this reason, the broker started to page the messages of
growing queues. When we reduced the load from the broker, some queues stopped
consuming due to the following logs:
{code}
AMQ222033: Page file 7.page had incomplete records at position
39,795,399 at record number 13,952
target message no.16146 not found from start offset 46032883 and start message
number 16146: java.lang.RuntimeException: target message no.16146 not found
from start offset 46032883 and start message number 16146
{code}
It wasnt possible to recover from this state but deleting the paging directory.
h3. Expected Situation
I would expect that the paging mechanism is resilient to any errors.
h3. Scenario Setup
Master configuration:
{code:xml}
true
256Mb
64Mb
10
PAGE
{code}
An extract of the monitoring of the Performance Test is attached to this issue.
h3. Workaround
Right now we disabled paging at all and only use our Heap. However, the heap is
exhausted at 5 million messages which is in our use case better than loosing
any of them.
> Incomplete records for pages under high load
>
>
> Key: ARTEMIS-2678
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2678
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Environment: Linux
>Reporter: Ansgar J. Sachs
>Priority: Major
> Attachments: Bildschirmfoto 2020-03-23 um 17.35.41.png
>
>
> {quote}As developer, I expect paging to be resource saving and resilient to
> high load{quote}
> h3. Current Situation
> During a performance test with a throughput of ~25.000 messages per second
> that run mulitple hours, some consumers were too slow to consume and messages
> piled up on the broker. For this reason, the broker started to page the
> messages of growing queues. When we reduced the load from the broker, some
> queues stopped consuming due to the following logs:
> {code}
> AMQ222033: Page file 7.page had incomplete records at position
> 39,795,399 at record number 13,952
> target message no.16146 not found from start offset 46032883 and start
> message number 16146: java.lang.RuntimeException: target message no.16146 not
> found from start offset 46032883 and start message number 16146
> {code}
> It wasnt possible to recover from this state but deleting the paging
> directory.
> h3. Expected Situation
> I would expect that the paging mechanism is resilient to any errors.
> h3. Scenario Setup
> Master configuration:
> {code:xml}
>
>
>
> true
>
>
>
>
>
> 256Mb
> 64Mb
>
> 10
> PAGE
>
> {code}
> An extract of the monitoring of the Performance Test is attached to this
> issue.
> h3. Workaround
> Right now we disabled paging at all and only use our Heap. However, the heap
> is exhausted at 5 million messages which is in our use case better than
> loosing any of them.
--
[jira] [Updated] (ARTEMIS-2678) Incomplete records for pages under high load
[
https://issues.apache.org/jira/browse/ARTEMIS-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ansgar J. Sachs updated ARTEMIS-2678:
-
Description:
{quote}As developer, I expect paging to be resource saving and resilient to
high load{quote}
h3. Current Situation
During a performance test with a throughput of ~25.000 messages per second that
run mulitple hours, some consumers were too slow to consumed and messages piled
up on the broker. For this reason, the broker started to page the messages of
growing queues. When we reduced the load from the broker, some queues stopped
consuming due to the following logs:
{code}
AMQ222033: Page file 7.page had incomplete records at position
39,795,399 at record number 13,952
target message no.16146 not found from start offset 46032883 and start message
number 16146: java.lang.RuntimeException: target message no.16146 not found
from start offset 46032883 and start message number 16146
{code}
It wasnt possible to recover from this state but deleting the paging directory.
h3. Expected Situation
I would expect that the paging mechanism is resilient to any errors.
h3. Scenario Setup
Master configuration:
{code:xml}
true
256Mb
64Mb
10
PAGE
{code}
An extract of the monitoring of the Performance Test is attached to this issue.
h3. Workaround
Right now we disabled paging at all and only use our Heap. However, the heap is
exhausted at 5 million messages which is in our use case better than loosing
any of them.
was:
{quote}As developer, I expect paging to be resource saving and resilient to
high load{quote}
h3. Current Situation
During a performance test with a throughput of ~25.000 messages per second that
run mulitple hours, some consumers were too slow to consume and messages piled
up on the broker. For this reason, the broker started to page the messages of
growing queues. When we reduced the load from the broker, some queues stopped
consuming due to the following logs:
{code}
AMQ222033: Page file 7.page had incomplete records at position
39,795,399 at record number 13,952
target message no.16146 not found from start offset 46032883 and start message
number 16146: java.lang.RuntimeException: target message no.16146 not found
from start offset 46032883 and start message number 16146
{code}
It wasnt possible to recover from this state but deleting the paging directory.
h3. Expected Situation
I would expect that the paging mechanism is resilient to any errors.
h3. Scenario Setup
Master configuration:
{code:xml}
true
256Mb
64Mb
10
PAGE
{code}
An extract of the monitoring of the Performance Test is attached to this issue.
h3. Workaround
Right now we disabled paging at all and only use our Heap. However, the heap is
exhausted at 5 million messages which is in our use case better than loosing
any of them.
> Incomplete records for pages under high load
>
>
> Key: ARTEMIS-2678
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2678
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Environment: Linux
>Reporter: Ansgar J. Sachs
>Priority: Major
> Attachments: Bildschirmfoto 2020-03-23 um 17.35.41.png
>
>
> {quote}As developer, I expect paging to be resource saving and resilient to
> high load{quote}
> h3. Current Situation
> During a performance test with a throughput of ~25.000 messages per second
> that run mulitple hours, some consumers were too slow to consumed and
> messages piled up on the broker. For this reason, the broker started to page
> the messages of growing queues. When we reduced the load from the broker,
> some queues stopped consuming due to the following logs:
> {code}
> AMQ222033: Page file 7.page had incomplete records at position
> 39,795,399 at record number 13,952
> target message no.16146 not found from start offset 46032883 and start
> message number 16146: java.lang.RuntimeException: target message no.16146 not
> found from start offset 46032883 and start message number 16146
> {code}
> It wasnt possible to recover from this state but deleting the paging
> directory.
> h3. Expected Situation
> I would expect that the paging mechanism is resilient to any errors.
> h3. Scenario Setup
> Master configuration:
> {code:xml}
>
>
>
> true
>
>
>
>
>
> 256Mb
> 64Mb
>
> 10
> PAGE
>
> {code}
> An extract of the monitoring of the Performance Test is attached to this
> issue.
> h3. Workaround
> Right now we disabled paging at all and only use our Heap. However, the heap
> is exhausted at 5 million messages which is in our use case better than
> loosing any of them.
--
[jira] [Commented] (ARTEMIS-2678) Incomplete records for pages under high load
[
https://issues.apache.org/jira/browse/ARTEMIS-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064970#comment-17064970
]
Ansgar J. Sachs commented on ARTEMIS-2678:
--
- I am using version 2.11.0 of Artemis with OpenWire as protocol.
- We are using a shared-store after we had some troubles with Replication and
XA-Transactions.
- For our test setup we had two JVMs running on one node - so just separated by
process
> Incomplete records for pages under high load
>
>
> Key: ARTEMIS-2678
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2678
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Environment: Linux
>Reporter: Ansgar J. Sachs
>Priority: Major
> Attachments: Bildschirmfoto 2020-03-23 um 17.35.41.png
>
>
> {quote}As developer, I expect paging to be resource saving and resilient to
> high load{quote}
> h3. Current Situation
> During a performance test with a throughput of ~25.000 messages per second
> that run mulitple hours, some consumers were too slow to consume and messages
> piled up on the broker. For this reason, the broker started to page the
> messages of growing queues. When we reduced the load from the broker, some
> queues stopped consuming due to the following logs:
> {code}
> AMQ222033: Page file 7.page had incomplete records at position
> 39,795,399 at record number 13,952
> target message no.16146 not found from start offset 46032883 and start
> message number 16146: java.lang.RuntimeException: target message no.16146 not
> found from start offset 46032883 and start message number 16146
> {code}
> It wasnt possible to recover from this state but deleting the paging
> directory.
> h3. Expected Situation
> I would expect that the paging mechanism is resilient to any errors.
> h3. Scenario Setup
> Master configuration:
> {code:xml}
>
>
>
> true
>
>
>
>
>
> 256Mb
> 64Mb
>
> 10
> PAGE
>
> {code}
> An extract of the monitoring of the Performance Test is attached to this
> issue.
> h3. Workaround
> Right now we disabled paging at all and only use our Heap. However, the heap
> is exhausted at 5 million messages which is in our use case better than
> loosing any of them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2678) Incomplete records for pages under high load
Ansgar J. Sachs created ARTEMIS-2678:
Summary: Incomplete records for pages under high load
Key: ARTEMIS-2678
URL: https://issues.apache.org/jira/browse/ARTEMIS-2678
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Environment: Linux
Reporter: Ansgar J. Sachs
Attachments: Bildschirmfoto 2020-03-23 um 17.35.41.png
{quote}As developer, I expect paging to be resource saving and resilient to
high load{quote}
h3. Current Situation
During a performance test with a throughput of ~25.000 messages per second that
run mulitple hours, some consumers were too slow to consume and messages piled
up on the broker. For this reason, the broker started to page the messages of
growing queues. When we reduced the load from the broker, some queues stopped
consuming due to the following logs:
{code}
AMQ222033: Page file 7.page had incomplete records at position
39,795,399 at record number 13,952
target message no.16146 not found from start offset 46032883 and start message
number 16146: java.lang.RuntimeException: target message no.16146 not found
from start offset 46032883 and start message number 16146
{code}
It wasnt possible to recover from this state but deleting the paging directory.
h3. Expected Situation
I would expect that the paging mechanism is resilient to any errors.
h3. Scenario Setup
Master configuration:
{code:xml}
true
256Mb
64Mb
10
PAGE
{code}
An extract of the monitoring of the Performance Test is attached to this issue.
h3. Workaround
Right now we disabled paging at all and only use our Heap. However, the heap is
exhausted at 5 million messages which is in our use case better than loosing
any of them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2639) Lost notification properties when using OpenWire client with a divert
[
https://issues.apache.org/jira/browse/ARTEMIS-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ansgar J. Sachs updated ARTEMIS-2639:
-
Description:
{quote}As developer, I expect proper ActiveMQ Notifications, when consuming
only some of them{quote}
h3. Steps to reproduce
1a) Create a broker and add the following:
{code:java}
activemq.notifications
jms.consumer.notifications
{code}
1b) Same situation for:
{code:java}
true
{code}
2) Consume those messages with a MDB
{code:java}
@MessageDriven(
name = "Notification_Subber",
activationConfig = {
@ActivationConfigProperty(propertyName = "destination",
propertyValue = "jms.consumer.notifications"),
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "useJndi",
propertyValue = "false"),
}
)
public class NotificationMDB implements MessageListener {
public void onMessage(Message message) {
// Log message here
// The message is missing all properties as documented in
https://activemq.apache.org/components/artemis/documentation/latest/management.html
}
}
{code}
h3. Expected Behavior
I would expect the same messages that are consumed as follows:
{code:java}
@MessageDriven(
name = "Notification_Subber",
activationConfig = {
@ActivationConfigProperty(propertyName = "destination",
propertyValue = "activemq.notifications"),
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "useJndi",
propertyValue = "false"),
@ActivationConfigProperty(propertyName =
"messageSelector",propertyValue = "_AMQ_NotifType = 'CONSUMER_CREATED' OR
_AMQ_NotifType = 'CONSUMER_CLOSED'"
}
)
public class NotificationMDB implements MessageListener {
public void onMessage(Message message) {
// Log message here
// This one actually returns all properties
}
}
{code}
h3. Current behavior
I guess that the filter includes some kind of message-copy workflow which
removes all those properties?
During this copy process, all properties starting with "_" will be deleted.
h3. Workaround
Right now, the only workaround for this issue is a custom transformer, which
does the following:
{code:java}
public class NotificationsTransformer implements Transformer {
private static final Logger log =
Logger.getLogger(NotificationsTransformer.class.getName());
public Message transform(Message message) {
try {
log.finest(String.format("Transform CoreMessage: %s",
message.toString()));
message.putStringProperty("event_timestamp",
message.getStringProperty("_AMQ_NotifTimestamp"));
message.putStringProperty("address_name",
message.getStringProperty("_AMQ_Address"));
message.putStringProperty("event_type",
message.getStringProperty("_AMQ_NotifType"));
message.putStringProperty("queue_name",
message.getStringProperty("_AMQ_RoutingName"));
} catch (Exception e) {
log.warning(String.format("Failed to transform message: %s",
e.getMessage()));
}
return message;
}
}
{code}
h3. Steps to achieve victory
(/) Find the errorneous message copy
(/) Forward all message properties
was:
{quote}As developer, I expect proper ActiveMQ Notifications, when consuming
only some of them{quote}
h3. Steps to reproduce
1a) Create a broker and add the following:
{code:java}
activemq.notifications
jms.consumer.notifications
{code}
1b) Same situation for:
{code:java}
true
{code}
2) Consume those messages with a MDB
{code:java}
@MessageDriven(
name = "Notification_Subber",
activationConfig = {
@ActivationConfigProperty(propertyName = "destination",
propertyValue = "jms.consumer.notifications"),
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "useJndi",
propertyValue = "false"),
}
)
public class NotificationMDB implements MessageListener {
public void onMessage(Message message) {
// Log message here
// The message is missing all properties as documented in
https://activemq.apache.org/components/artemis/documentation/latest/management.html
}
}
{code}
h3. Expected Behavior
I would expect the same messages that are consumed as follows:
{code:java}
@MessageDriven(
name = "Notification_Subber",
activationConfig = {
[jira] [Commented] (ARTEMIS-2639) Lost notification properties when using OpenWire client with a divert
[
https://issues.apache.org/jira/browse/ARTEMIS-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051854#comment-17051854
]
Ansgar J. Sachs commented on ARTEMIS-2639:
--
Thanks for your reply :) unfortunately my company is still using Jboss 6.4
which prevents us from using the more up-to-date artemis ra.
I guess my workaround seems to be the best fit for now.
> Lost notification properties when using OpenWire client with a divert
> --
>
> Key: ARTEMIS-2639
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2639
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Affects Versions: 2.11.0
>Reporter: Ansgar J. Sachs
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {quote}As developer, I expect proper ActiveMQ Notifications, when consuming
> only some of them{quote}
> h3. Steps to reproduce
> 1a) Create a broker and add the following:
> {code:java}
>
> activemq.notifications
> jms.consumer.notifications
>
>
> {code}
> 1b) Same situation for:
> {code:java}
>
>
>
>
> true
>
>
>
>
>
> {code}
> 2) Consume those messages with a MDB
> {code:java}
> @MessageDriven(
> name = "Notification_Subber",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destination",
> propertyValue = "jms.consumer.notifications"),
> @ActivationConfigProperty(propertyName = "destinationType",
> propertyValue = "javax.jms.Topic"),
> @ActivationConfigProperty(propertyName = "useJndi",
> propertyValue = "false"),
> }
> )
> public class NotificationMDB implements MessageListener {
> public void onMessage(Message message) {
> // Log message here
> // The message is missing all properties as documented in
> https://activemq.apache.org/components/artemis/documentation/latest/management.html
> }
> }
> {code}
> h3. Expected Behavior
> I would expect the same messages that are consumed as follows:
> {code:java}
> @MessageDriven(
> name = "Notification_Subber",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destination",
> propertyValue = "activemq.notifications"),
> @ActivationConfigProperty(propertyName = "destinationType",
> propertyValue = "javax.jms.Topic"),
> @ActivationConfigProperty(propertyName = "useJndi",
> propertyValue = "false"),
> @ActivationConfigProperty(propertyName =
> "messageSelector",propertyValue = "_AMQ_NotifType = 'CONSUMER_CREATED' OR
> _AMQ_NotifType = 'CONSUMER_CLOSED'"
> }
> )
> public class NotificationMDB implements MessageListener {
> public void onMessage(Message message) {
> // Log message here
> // This one actually returns all properties
> }
> }
> {code}
> h3. Current behavior
> I guess that the filter includes some kind of message-copy workflow which
> removes all those properties?
> During this copy process, all properties starting with "_" will be deleted.
> h3. Workaround
> Right now, the only workaround for this issue is a custom transformer, which
> does the following:
> {code:java}
> public class NotificationsTransformer implements Transformer {
> private static final Logger log =
> Logger.getLogger(NotificationsTransformer.class.getName());
>
> public Message transform(Message message) {
> try {
> log.finest(String.format("Transform CoreMessage: %s",
> message.toString()));
> message.putStringProperty("event_timestamp",
> message.getStringProperty("_AMQ_NotifTimestamp"));
> message.putStringProperty("address_name",
> message.getStringProperty("_AMQ_Address"));
> message.putStringProperty("event_type",
> message.getStringProperty("_AMQ_NotifType"));
> message.putStringProperty("queue_name",
> message.getStringProperty("_AMQ_RoutingName"));
> } catch (Exception e) {
> log.warning(String.format("Failed to transform message: %s",
> e.getMessage()));
> }
> return message;
> }
> }
> {code}
> h3. Steps to achieve victory
> (x) Find the errorneous message copy
> (x) Forward all message properties
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2639) Lost activemq notification properties when using a filter
[
https://issues.apache.org/jira/browse/ARTEMIS-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051596#comment-17051596
]
Ansgar J. Sachs commented on ARTEMIS-2639:
--
The following example reproducer the error (also added in
org.apache.activemq.artemis.tests.integration.divert.DivertTest):
1) Add ActiveMQ client
{code:java}
org.apache.activemq
activemq-client
5.15.11
{code}
2) Add Testcase
{code:java}
@Test
public void testDivertedMessageProperties() throws Exception {
final String testAddress =
ActiveMQDefaultConfiguration.getDefaultManagementNotificationAddress().toString();
final String forwardAddress = "forwardAddress";
DivertConfiguration divertConf = new
DivertConfiguration().setName("divert1").setRoutingName("divert1").setAddress(testAddress).setForwardingAddress(forwardAddress).setFilterString("_AMQ_NotifType
= 'CONSUMER_CREATED' OR _AMQ_NotifType = 'CONSUMER_CLOSED'");
Configuration config =
createDefaultNettyConfig().addDivertConfiguration(divertConf);
ActiveMQServer server =
addServer(ActiveMQServers.newActiveMQServer(config, false));
server.start();
ActiveMQConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("tcp://localhost:61616?jms.rmIdFromConnectionId=true");
connectionFactory.setUserName("ACTIVEMQ.CLUSTER.ADMIN.USER");
connectionFactory.setPassword("UnitTestsClusterPassword");
connectionFactory.setClientID("testId123");
Topic forwardTopic = new ActiveMQTopic(forwardAddress);
Connection connection = connectionFactory.createConnection();
connection.start();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
TopicSubscriber subscriber =
session.createDurableSubscriber(forwardTopic, "testId123");
javax.jms.Message message = subscriber.receive(DivertTest.TIMEOUT);
Assert.assertNotNull(message);
Assert.assertEquals("CONSUMER_CREATED",
message.getStringProperty("_AMQ_NotifType"));
Assert.assertNull(subscriber.receiveNoWait());
}
{code}
It fails here:
{code:java}
Assert.assertEquals("CONSUMER_CREATED",
message.getStringProperty("_AMQ_NotifType"));
{code}
> Lost activemq notification properties when using a filter
> -
>
> Key: ARTEMIS-2639
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2639
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Affects Versions: 2.11.0
>Reporter: Ansgar J. Sachs
>Priority: Major
>
> {quote}As developer, I expect proper ActiveMQ Notifications, when consuming
> only some of them{quote}
> h3. Steps to reproduce
> 1a) Create a broker and add the following:
> {code:java}
>
> activemq.notifications
> jms.consumer.notifications
>
>
> {code}
> 1b) Same situation for:
> {code:java}
>
>
>
>
> true
>
>
>
>
>
> {code}
> 2) Consume those messages with a MDB
> {code:java}
> @MessageDriven(
> name = "Notification_Subber",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destination",
> propertyValue = "jms.consumer.notifications"),
> @ActivationConfigProperty(propertyName = "destinationType",
> propertyValue = "javax.jms.Topic"),
> @ActivationConfigProperty(propertyName = "useJndi",
> propertyValue = "false"),
> }
> )
> public class NotificationMDB implements MessageListener {
> public void onMessage(Message message) {
> // Log message here
> // The message is missing all properties as documented in
> https://activemq.apache.org/components/artemis/documentation/latest/management.html
> }
> }
> {code}
> h3. Expected Behavior
> I would expect the same messages that are consumed as follows:
> {code:java}
> @MessageDriven(
> name = "Notification_Subber",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destination",
> propertyValue = "activemq.notifications"),
> @ActivationConfigProperty(propertyName = "destinationType",
> propertyValue = "javax.jms.Topic"),
> @ActivationConfigProperty(propertyName = "useJndi",
> propertyValue = "false"),
> @ActivationConfigProperty(propertyName =
> "messageSelector",propertyValue = "_AMQ_NotifType = 'CONSUMER_CREATED' OR
> _AMQ_NotifType = 'CONSUMER_CLOSED'"
> }
> )
> public class NotificationMDB implements MessageListener {
> public void onMessage(Message message) {
> // Log message here
> // This one actually returns all properties
> }
> }
> {code}
> h3. Current behavior
> I guess that the filter includes some kind of message-copy workflow which
> removes
[jira] [Comment Edited] (ARTEMIS-2639) Lost activemq notification properties when using a filter
[
https://issues.apache.org/jira/browse/ARTEMIS-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051596#comment-17051596
]
Ansgar J. Sachs edited comment on ARTEMIS-2639 at 3/4/20, 8:29 PM:
---
The following example reproduced the error (also added in
org.apache.activemq.artemis.tests.integration.divert.DivertTest):
1) Add ActiveMQ client
{code:java}
org.apache.activemq
activemq-client
5.15.11
{code}
2) Add Testcase
{code:java}
@Test
public void testDivertedMessageProperties() throws Exception {
final String testAddress =
ActiveMQDefaultConfiguration.getDefaultManagementNotificationAddress().toString();
final String forwardAddress = "forwardAddress";
DivertConfiguration divertConf = new
DivertConfiguration().setName("divert1").setRoutingName("divert1").setAddress(testAddress).setForwardingAddress(forwardAddress).setFilterString("_AMQ_NotifType
= 'CONSUMER_CREATED' OR _AMQ_NotifType = 'CONSUMER_CLOSED'");
Configuration config =
createDefaultNettyConfig().addDivertConfiguration(divertConf);
ActiveMQServer server =
addServer(ActiveMQServers.newActiveMQServer(config, false));
server.start();
ActiveMQConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("tcp://localhost:61616?jms.rmIdFromConnectionId=true");
connectionFactory.setUserName("ACTIVEMQ.CLUSTER.ADMIN.USER");
connectionFactory.setPassword("UnitTestsClusterPassword");
connectionFactory.setClientID("testId123");
Topic forwardTopic = new ActiveMQTopic(forwardAddress);
Connection connection = connectionFactory.createConnection();
connection.start();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
TopicSubscriber subscriber =
session.createDurableSubscriber(forwardTopic, "testId123");
javax.jms.Message message = subscriber.receive(DivertTest.TIMEOUT);
Assert.assertNotNull(message);
Assert.assertEquals("CONSUMER_CREATED",
message.getStringProperty("_AMQ_NotifType"));
Assert.assertNull(subscriber.receiveNoWait());
}
{code}
It fails here:
{code:java}
Assert.assertEquals("CONSUMER_CREATED",
message.getStringProperty("_AMQ_NotifType"));
{code}
was (Author: ansgars):
The following example reproducer the error (also added in
org.apache.activemq.artemis.tests.integration.divert.DivertTest):
1) Add ActiveMQ client
{code:java}
org.apache.activemq
activemq-client
5.15.11
{code}
2) Add Testcase
{code:java}
@Test
public void testDivertedMessageProperties() throws Exception {
final String testAddress =
ActiveMQDefaultConfiguration.getDefaultManagementNotificationAddress().toString();
final String forwardAddress = "forwardAddress";
DivertConfiguration divertConf = new
DivertConfiguration().setName("divert1").setRoutingName("divert1").setAddress(testAddress).setForwardingAddress(forwardAddress).setFilterString("_AMQ_NotifType
= 'CONSUMER_CREATED' OR _AMQ_NotifType = 'CONSUMER_CLOSED'");
Configuration config =
createDefaultNettyConfig().addDivertConfiguration(divertConf);
ActiveMQServer server =
addServer(ActiveMQServers.newActiveMQServer(config, false));
server.start();
ActiveMQConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("tcp://localhost:61616?jms.rmIdFromConnectionId=true");
connectionFactory.setUserName("ACTIVEMQ.CLUSTER.ADMIN.USER");
connectionFactory.setPassword("UnitTestsClusterPassword");
connectionFactory.setClientID("testId123");
Topic forwardTopic = new ActiveMQTopic(forwardAddress);
Connection connection = connectionFactory.createConnection();
connection.start();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
TopicSubscriber subscriber =
session.createDurableSubscriber(forwardTopic, "testId123");
javax.jms.Message message = subscriber.receive(DivertTest.TIMEOUT);
Assert.assertNotNull(message);
Assert.assertEquals("CONSUMER_CREATED",
message.getStringProperty("_AMQ_NotifType"));
Assert.assertNull(subscriber.receiveNoWait());
}
{code}
It fails here:
{code:java}
Assert.assertEquals("CONSUMER_CREATED",
message.getStringProperty("_AMQ_NotifType"));
{code}
> Lost activemq notification properties when using a filter
> -
>
> Key: ARTEMIS-2639
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2639
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Affects Versions: 2.11.0
>Reporter: Ansgar J. Sachs
>Priority: Major
>
> {quote}As developer, I expect proper ActiveMQ Notifications, when consuming
> only some of them{quote}
> h3. Steps to reproduce
> 1a) Create a broker and add the
