Hi Justin,
1. To both. The broker runs in a pod and the application server runs in a
different pod. There are many application pods (for horizontal scaling).
There are two broker pods (primary and standby).
2. Yes, we will have both kinds of pods on a single node. We have a
Kubernete
> Can I make a whole new Connection/Session/Producer and send to the
replyQueue using the new Producer, even though it does not use the Session
to which the replyQueue belongs?
Yes. That shouldn't be a problem.
The session is only relevant when you're deleting temporary destinations.
Justin
On
> Asking for clarification on what could be done to “change the application
itself” as you mentioned. I’m kind of assuming that getting a whole new
Connection/Session/Producer set would be the way to go, but perhaps you
have other suggestions.
Your assumption is correct. I don't have any other su
I'm trying to wrap my head around your deployment, and I have a few
questions...
1) Are your client applications connecting to your "application server
pod" or to an ActiveMQ Artemis broker pod or both?
2) It seems like the failure case you're describing is predicated on both
kinds of pods bei
The stack trace indicates that the broker is receiving a
SESS_SEND_CONTINUATION packet from a client. This kind of packet is only
sent when a core client is sending a large message. However, based on the
information you have provided the client doesn't appear to be sending a
large message. I can on
For posterity's sake, let it be known that this conversation continued on
ARTEMIS-4629 [1].
Justin
[1] https://issues.apache.org/jira/browse/ARTEMIS-4629
On Thu, Feb 1, 2024 at 7:47 AM MILOVIDOV Aleksandr
wrote:
> Hi,
>
> I tried to insert true in different positions in the
> section of brok
