[
https://issues.apache.org/jira/browse/ARTEMIS-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723995#comment-17723995
]
Justin Bertram edited comment on ARTEMIS-4276 at 5/18/23 6:28 PM:
------------------------------------------------------------------
bq. I am not seeing it as a weakness rather than an incomplete solution...
Fair enough. I'm not looking to debate semantics here. :slightly_smiling_face:
bq. I think it is still better to have a local cache than nothing.
Assuming the cache was simple to implement and doesn't incur a meaningful
runtime cost (e.g. in CPU or memory) then I would agree. It is better than
nothing.
bq. There are some third parties that have this out-of-the box. For instance, I
have seen Kafka having idempotent consumers.
The idempotency that Kafka may provide is not what I'm talking about in this
context. There are definitely measures that client libraries and brokers can
take to help make consuming and producing messages idempotent (see [duplicate
detection|https://activemq.apache.org/components/artemis/documentation/latest/duplicate-detection.html]
for one example related to idempotent producers). However, those measures only
apply to the actual _messaging_ operations. Once you add another kind of
resource like a database or even another message broker there's nothing that
the client library can do to make the consumer idempotent _overall_. As noted,
the application developer must implement this kind of idempotency. Technologies
like XA were invented to deal with this kind use-case. It's worth noting that
Kafka does not, in fact, support XA.
was (Author: jbertram):
bq. I am not seeing it as a weakness rather than an incomplete solution...
Fair enough. I'm not looking to debate semantics here. :slightly_smiling_face:
bq. I think it is still better to have a local cache than nothing.
Assuming the cache was simple to implement and doesn't incur a meaningful
runtime cost (e.g. in CPU or memory) then I would agree. It is better than
nothing.
bq. There are some third parties that have this out-of-the box. For instance, I
have seen Kafka having idempotent consumers.
The idempotency that Kafka may provide is not what I'm talking about in this
context. There are definitely measures that client libraries can take to help
make consuming and producing messages idempotent. However, those measures only
apply to the actual _messaging_ operations. Once you add another kind of
resource like a database or even another message broker there's nothing that
the client library can do to make the consumer idempotent _overall_. As noted,
the application developer must implement this kind of idempotency. Technologies
like XA were invented to deal with this kind use-case. It's worth noting that
Kafka does not, in fact, support XA.
> Message Group does not replicate properly during failover
> ---------------------------------------------------------
>
> Key: ARTEMIS-4276
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4276
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.28.0
> Reporter: Liviu Citu
> Priority: Major
>
> Hi,
> We are currently migrating our software from Classic to Artemis and we plan
> to use failover functionality.
> We were using message group functionality by setting *JMSXGroupID* and this
> was working as expected. However after failover switch I noticed that
> messages are sent to wrong consumers.
> Our gateway/interface application is actually a collection of servers:
> * gateway adapter server: receives messages from an external systems and
> puts them on a specific/virtual topic
> * gateway loader server (can be balanced): picks up the messages from the
> topic and do processing
> * gateway fail queue: monitors all messages that failed processing and has a
> functionality of resubmitting the message (users will correct the processing
> errors and then resubmit transaction)
> *JMSXGroupID* is used to ensure that during message resubmit the same
> consumer/loader is processing the message as it was originally processed.
> However, if the message resubmit is happening during failover switch we have
> noticed that the message is not sent to the right consumer as it should.
> Basically the first available consumer is used which is not what we want.
> I have searched for configuration changes but couldn't find any relevant
> information.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
