At this point I'd recommend managing the JMS connection yourself and
disabling any reconnection in the core JMS client. This will eliminate the
need to use implementation-specific classes (e.g. SessionFailureListener)
and will mean your code remains portable between JMS client & broker
implementations.
Justin
On Wed, Sep 20, 2023 at 12:27 PM Westpfal, Thomas <
thomas.westpf...@saabinc.com> wrote:
> Justin,
>
> Thank you for your response, it was quite helpful. I also want to thank
> David for his response, I think he hit the nail on the head, that is
> excatly what I'm trying to achieve. Part of the requrements that I am
> trying to meet is that I give the user visibility into the connection at
> all times. This includes: when a connection attempt is made, when a
> connection attempt fails, when a connection attempt is sucessful, and when
> a connected connection is broken. I can view some of this information using
> the library implementation as is, however I don't believe the library
> implementation covers all my bases. I understand the desire for
> transparency in the JMS implementaitons, however I think this may be
> hidering me in this instance. I know it kind of defeats the purpose of the
> transparency aspect of the library, but I am not opposed to putting a
> wrapper around it to get the visiblity into to connections that I require.
> Do you have any thoughts on how I would be able to achive this sort of
> visiblity?
>
> Regards,
> Tom
>
>
> This message is marked Public.
>
> -----Original Message-----
> From: David Sargrad Saab <davidsarg...@hotmail.com>
> Sent: Wednesday, September 20, 2023 4:35 AM
> To: users@activemq.apache.org
> Subject: {EXTERNAL MAIL} Re: Unable to Get Connection Info From
> ActiveMQConnectionFactory
>
> Relative to Justin's question: "Could you provide an explanation of why
> you want this information? Perhaps
> there is another way to accomplish your overall goal or perhaps there's an
> underlying assumption that needs adjustment."
>
> I think he may be looking for this detail to ensure his application is
> dealing with fault monitoring and fault recovery monitoring requirements.
>
> I've dealt with similar systems where the criticality of the brokering
> functionality requires immediate knowledge of failed connections, so that
> remedies can be taken. Such systems also benefit from the ability to detect
> successful reconnection, and attempts to successfully reconnect.
>
> ________________________________
> From: Justin Bertram <jbert...@apache.org>
> Sent: Tuesday, September 19, 2023 1:59 PM
> To: users@activemq.apache.org <users@activemq.apache.org>
> Subject: Re: Unable to Get Connection Info From ActiveMQConnectionFactory
>
> > Is there any way for me to be able to determine how many times the
> ActiveMQConnectionFactory attempted a reconnect?
>
> No. That data is not exposed.
>
> > Is there a way to see immediately when a connection is broken and not
> after reconnection attempts have been made?
>
> Via JMS, no. However, you could potentially use a SessionFailureListener
> [1] on the underlying ClientSession.
>
> > One solution I thought of was to set reconnection attempts to "0" and
> when I receive an exception via the ExceptionListener I manually close the
> connection and try to establish a new one. However this doesn't seem like
> the right way to do this, and also seems really inefficient.
>
> This is actually a fairly common pattern as it's the only mechanism built
> directly into JMS to deal with asynchronous connection failures. Frameworks
> like Spring which integrate with JMS employ patterns like this.
>
> The reconnection functionality provided by the core JMS client shipped with
> ActiveMQ Artemis is designed to be transparent to applications which is the
> main reason why there's not much visibility into it. And even if there were
> visibility it would require implementation-specific code since this
> functionality goes beyond JMS. Using implementation-specific code is
> generally discouraged as it nullifies one of the main benefits of using an
> API like JMS in the first place - application portability.
>
> > I feel like I am not quite using the library in the right way. What I'm
> looking for is to be able to see when a connection is broken, how many
> reconnection attempts have been made, and when I am successfully
> reconnected. Any help/guidance would be greatly appreciated.
>
> Could you provide an explanation of why you want this information? Perhaps
> there is another way to accomplish your overall goal or perhaps there's an
> underlying assumption that needs adjustment.
>
>
> Justin
>
> [1]
>
> https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/api/core/client/SessionFailureListener.html
>
> On Mon, Sep 18, 2023 at 1:32 PM Westpfal, Thomas <
> thomas.westpf...@saabinc.com> wrote:
>
> > Hello,
> >
> > I am working on a Java application using
> > "org.apache.activemq:artemis-jms-client:2.11.0" which connects to
> multiple
> > Artemis brokers. An important part of my application is the ability to be
> > able to monitor the connections with the Artemis brokers. I am having
> > trouble determining some of the information I am looking for.
> >
> > The first thing I am trying to monitor is how many reconnection attempts
> > have been made after a connection has been broken. I have set my
> > reconnection attempts to "-1" on an ActiveMQConnectionFactory to try to
> > reconnect infinitely. The problem that I am having is that the
> > ActiveMQConnectionFactory doesn't appear to expose the number of
> > reconnection attempts that have been made. Is there any way for me to be
> > able to determine how many times the ActiveMQConnectionFactory attempted
> a
> > reconnect?
> >
> > The next thing I am trying to monitor is the number of broken connections
> > with a given broker. The javax JMS Connection allows you to configure a
> > ExceptionListener, however I find that this listener is only triggered
> once
> > the number of reconnection attempts has been exceeded. Is there a way to
> > see immediately when a connection is broken and not after reconnection
> > attempts have been made?
> >
> > One solution I thought of was to set reconnection attempts to "0" and
> when
> > I receive an exception via the ExceptionListener I manually close the
> > connection and try to establish a new one. However this doesn't seem like
> > the right way to do this, and also seems really inefficient.
> >
> > Finally, I am trying to determine if a connection has been reestablished.
> > There doesn't appear to be a way to determine if a connection has been
> > reestablished other than being able to successfully send or receive a
> > message. Is there a way to see this without first sending or receiving a
> > message?
> >
> > I feel like I am not quite using the library in the right way. What I'm
> > looking for is to be able to see when a connection is broken, how many
> > reconnection attempts have been made, and when I am successfully
> > reconnected. Any help/guidance would be greatly appreciated.
> >
> > Regards,
> > Tom
> >
> >
> > This message is marked Public.
> >
> > This e-mail (including attachments) contains contents owned by Saab Group
> > AB and/or its subsidiaries, affiliated companies or customers and covered
> > by the laws of Sweden, the US, or Canada (federal, state or provincial).
> > The information is intended to be confidential and may be legally
> > privileged. If you are not the intended recipient, you are hereby
> notified
> > that any retention, dissemination, distribution, interception or copying
> of
> > this communication is strictly prohibited and may subject you to further
> > legal action. Reply to the sender if you received this email by accident,
> > and then delete the email and any attachments.
> >
> This e-mail (including attachments) contains contents owned by Saab Group
> AB and/or its subsidiaries, affiliated companies or customers and covered
> by the laws of Sweden, the US, or Canada (federal, state or provincial).
> The information is intended to be confidential and may be legally
> privileged. If you are not the intended recipient, you are hereby notified
> that any retention, dissemination, distribution, interception or copying of
> this communication is strictly prohibited and may subject you to further
> legal action. Reply to the sender if you received this email by accident,
> and then delete the email and any attachments.
>
