I sent a commit to update the docs in the repo, and I also updated the
website.
Out of curiosity, how is your MySQL replication configured? Are you using
the default asynchronous, semisynchronous, or fully synchronous NDB cluster?
Justin
On Tue, May 31, 2022 at 4:09 PM Stephen Baker <
stephen.b
Understood thank you. We (the company I work for) are definitely getting more
value out of the product than we are contributing, so that point is taken. The
JDBC replication route was recommended by a consultant from Savoir as more
established/reliable than mirroring when delivery guarantees are
> I am a little concerned about how this reflects production readiness...
I just wanted to address this point generally before moving to the
specifics...
The ActiveMQ community (and Apache in general) is dedicated to producing
high-quality, production-ready software, but mistakes inevitably are m
Thanks,
I am a little concerned about how this reflects production readiness given
there are no schema changes mentioned in the upgrade notes and it looks to me
like it’s backwards incompatible so it couldn’t be done live before the upgrade?
If this were a production system what would the recom
It looks like the change came from ARTEMIS-3679 [1]. The
HOLDER_EXPIRATION_TIME column changed from a TIMESTAMP to a BIGINT on the
NODE_MANAGER_STORE table.
Justin
[1] https://issues.apache.org/jira/browse/ARTEMIS-3679
On Tue, May 31, 2022 at 11:04 AM Stephen Baker <
stephen.ba...@rmssoftwarein
it looks like you may need to delete the lock table, that column has
changed type in 2.22
see:
https://github.com/apache/activemq-artemis/commit/101c0d2cd0f4127592f1817c52ab595359bc9b85#diff-6b567f39f4a9afa111f142768da46e6139b53ac2879517ca2c3745c2481b5f07R40
On Tue, 31 May 2022 at 17:04, Stephen
We have an Artemis MQ instance in our QA environment that we are using to
evaluate JDBC persistence.
It was running with Artemis 2.20, and we recently updated to 2.22. Since then
the instance has failed to start with the following error:
2022-05-31 10:16:55,512 WARN
[org.apache.activemq.artemi
Your second email in this thread is the only email with any attachments,
and it has 3:
- local-server-log-snippet.txt
- cloud-server-log-snippet.txt
- broker.xml
I don't see any attachment named "ArtemisHTTPDebug.java" on any email in
this thread.
Justin
On Tue, May 31, 2022 at 10:23 AM Sun
Hi Justin
The JMS client code "ArtemisHTTPDebug.java" & the server configuration
file "broker.xml" have already been attached in my previous mail along with
the logs. Let me know if you need anything else.
Thanks.
On Tue, 31 May 2022 at 16:11, Justin Bertram wrote:
> Can you also provide the J
Can you also provide the JMS client code and configuration you're using as
requested previously?
Justin
On Fri, May 27, 2022 at 7:04 AM Sunil Varma wrote:
> Hi Justin
> Thanks for responding.
> We are using Artemis (version 2.13.0) to send "notifications" to
> interested consumers when data is
Typically one would see these WARN messages (i.e. AMQ222107 & AMQ222061)
when a client connected and then exited the application without properly
closing the connection. The broker monitors client connections to see if
they are still active and closes dead connections so they don't build up
and con
Hello,
I'm running ActiveMQ using the operator on Openshift.
I have a broker running in 1 namespace and an 'activemq-client' pod with
the artemis cli runing in another namespace. When I try to connect from the
activemq-client to the broker the client quickly comes back with a 'killed'
message. Wh
12 matches
Mail list logo
