> Does e.g. <journal-type> and <paging-directory> have any effect at all
when using a database?

No.

> Which configurations are not relevant (ignored) when using a database?

Basically any journal configuration properties that have anything to do
with files (e.g. paths, names, sizes, timeouts, etc.) are ignored when
using a database.

> AMQ224088: Timeout (10 seconds) on acceptor "artemis" during protocol
handshake with /XXX:XXX:XXX.XXX:XXXXX has occurred.

This indicates a client made a TCP connection to the broker, but that it
didn't complete a messaging protocol handshake (e.g. core, OpenWire, AMQP,
STOMP, MQTT).

> AMQ224126: Failure during protocol handshake...

This indicates a client made a TCP connection to the broker, but that
something went wrong during the messaging protocol handshake. The error
message should be accompanied by a stack-trace to provide more details on
what went wrong.

> AMQ224014: Failed to close session

This indicates the broker had a problem closing its internal server
session. Again, there should be a stack-trace providing more details on the
nature of the failure.

> AMQ212037: Connection failure to /XXX:XXX:XXX.XXX:XXXXX has been
detected...

This indicates that a client connection essentially timed out. This could
be because the client crashed before it could close its connection, etc.
The broker cleans up abandoned connections so that it doesn't run out of
resources.

> AMQ222103: transaction with xid XidImpl XXX timed out...

This indicates that an XA transaction was not completed (either rolled back
or committed) within the allotted time (i.e. 5 minutes by default).

> Any ideas on how to troubleshoot this? Any particular areas where we
should pay particular attention?

I'd start with network connectivity since many of these issues seem network
related.

> Could the problems depend on the old resource adapters?

It's hard to rule anything out at this point, but I wouldn't expect old
clients to manifest problems in these ways.

>  Could a bad database connection cause the problems?

No. I don't think so.


Justin

On Tue, Dec 5, 2023 at 4:16 PM Calle Andersson <calleanders...@hotmail.com>
wrote:

> Hi,
>
> We are replacing an old (5.9) remote ActiveMQ Classic broker with a remote
> Artemis broker and have a few questions.
>
> 1. The Artemis broker is configured to persist messages in a database.
> Does e.g. <journal-type> and <paging-directory> have any effect at all when
> using a database? Which configurations are not relevant (ignored) when
> using a database?
>
> 2. We have a lot of old client applications which used to connect to the
> old Classic broker by using an antique resource adapter (5.9). We are
> trying to avoid changing anything in the client applications by simply
> redirecting the old host to the new Artemis broker (which has an OpenWire
> acceptor). At some of the time everything seems to work as expected
> (messages are delivered and consumed) but we are also seeing a lot of
> connectivity issues, e.g:
>
> ERROR [org.apache.activemq.artemis.core.server] AMQ224088: Timeout (10
> seconds) on acceptor "artemis" during protocol handshake with
> /XXX:XXX:XXX.XXX:XXXXX has occurred.
>
> ERROR [org.apache.activemq.artemis.core.server] AMQ224126: Failure during
> protocol handshake on connection to /XXX:XXX:XXX.XXX:XXXXX from
> /XXX:XXX:XXX.XXX:XXXXX
>
> ERROR [org.apache.activemq.artemis.core.server] AMQ224014: Failed to close
> session
>
> WARN  [org.apache.activemq.artemis.core.client] AMQ212037: Connection
> failure to /XXX:XXX:XXX.XXX:XXXXX has been detected: AMQ229014: Did not
> receive data from /XXX:XXX:XXX.XXX:XXXXX within the 30000ms connection TTL.
> The connection will now be closed. [code=CONNECTION_TIMEDOUT]
>
> WARN  [org.apache.activemq.artemis.core.server] AMQ222103: transaction
> with xid XidImpl XXX timed out
>
> Any ideas on how to troubleshoot this? Any particular areas where we
> should pay particular attention? Could the problems depend on the old
> resource adapters? Could a bad database connection cause the problems?
>
> Any suggestions are welcome.
>
> Thanks in advance
> Calle
>

Reply via email to