Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of torsten@fusesource.com
 designates 74.125.245.80 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [org.apache.activemq.transport.failover.FailoverTransport]
 (ActiveMQ Task-55) Successfully connected to
From: Torsten Mielke <torsten@fusesource.com>
In-Reply-To: 
 <CAKze-OuJqXEebdoa3C=KQa_fAwuqPRjASxKMeoj74fJ+XXou4w@mail.gmail.com>
Date: Wed, 11 Apr 2012 11:59:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CCD2720-1EA7-4ACE-AD2E-AB8A00C09744@fusesource.com>
References: 
 <CAKze-OuJqXEebdoa3C=KQa_fAwuqPRjASxKMeoj74fJ+XXou4w@mail.gmail.com>
To: users@activemq.apache.org

Hello,

Correct, these log lines indicate that your JBoss client has reconnected =
to the broker.=20
As to why that happened, I don't know. However a reconnect once a day =
does not sound like a bigger problem.=20
Is there any information in the broker log as to why the connection was =
shut down?


Cheers,

Torsten Mielke
torsten@fusesource.com
tmielke@blogspot.com


On Apr 11, 2012, at 12:58 AM, qt4x11 wrote:

> We have ActiveMQ clustering between our two servers configured as a =
network
> of brokers.  Our config files look like
>=20
>    <broker xmlns=3D"http://activemq.apache.org/schema/core"
> brokerName=3D"receiver" persistent=3D"false" useJmx=3D"false"
> dataDirectory=3D"${activemq.base}/data"
> destroyApplicationContextOnStop=3D"true">
>=20
>        <networkConnectors>
>=20
>       <networkConnector
> uri=3D"static:(ssl://le2.comt:61616<http://le1.liveexpert.net:61616/>
> )"/>
>=20
>       </networkConnectors>
>=20
>=20
> and
>=20
>=20
>        <networkConnectors>
>       <networkConnector
> uri=3D"static:(ssl://le1.comt:61616<http://le1.liveexpert.net:61616/>
> )"/>
>       </networkConnectors>
>=20
>=20
> We're starting to see some errors in our JBoss logs that look like
>=20
>=20
>=20
> 14:53:37,812 INFO
> [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ
> Task-55) Successfully connected to ssl://le2.com:61616?keepAlive=3Dtrue
>=20
>=20
> 14:54:30,213 INFO
> [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ
> Task-57) Successfully connected to ssl://le2.com:61616?keepAlive=3Dtrue
>=20
>=20
>=20
> I took a look at the source for
> org.apache.activemq.transport.failover.FailoverTransport - this =
message
> gets written to log when a successfully reconnection event has been =
made
> from the client - in this case, Java/JBoss.  Since JBoss is configured =
with
> jms_url as a static list of brokers, i.e.,
>=20
>=20
> failover:(
> ssl://le1.com:61616?keepAlive=3Dtrue,ssl://le2.com:61616?keepAlive=3Dtru=
e)
>=20
>=20
> JBoss attempts to connect to one of the brokers upon startup, the
> connection logic randomizes which broker to connect to by default.  =
What I
> think is happening when these messages get written is the client has =
lost
> connection to the broker it has connected to initially, due to hitting =
the
> inactivityTimeoutThreshold of 30 seconds somehow - and is attempting =
to
> reconnect to one of the nodes in our network of brokers.  Is this a =
correct
> assumption?  Is it correct that the Java code running in our JBoss
> container is writing these types of 'reconnect' messages to the logs?  =
We
> see these messages about once a day, is that too frequent for that =
period
> of time?  The reason I ask is that some clients are reporting errors, =
and
> we were able to correlate that to when these 'reconnecton' events =
appear in
> our logs.
>=20
>=20
> The reason the client needs to reconnect to the failover cluster is =
unclear
> to me.  There are no indications of an ActiveMQ server restart at this
> time, just that connection between client and broker needs to be
> reestablished.  Can anyone recommend anything we can do to prevent =
these
> types of reconnection events from happening as much as possible, given =
our
> setup?  Or anything we can reconfigure that may be causing frequent
> reconnection events?  Thanks.