Some news on that: in the meantime, we have switched to only using static
bridges in our project for connection of the mobile brokers to the back
office. Is much more stable now.
However, there is still some problem which shows up now and then: sometimes
the back office broker "forgets" to start t
Saw it again.
- The backoffice broker had shut down the connection (Channel was inactive
for too (>3) long).
- The mobile broker logged "Transport failed, not attempting to
automatically reconnect; java.io.EOFException" and "bridge to stopped"
- One second later, the mobile broker tries r
I'll check this next time the issue shows up. But I'm pretty sure that if the
connection is there on TCP level, it can be to nothing else than one of the
two backoffice brokers, since only these are defined in the connection URI
for the network connection. But anyways a good idea to check whether t
So I was thinking about something more like netstat, to answer the question
at the TCP layer. I've never used Karaf, but the documentation doesn't seem
to provide a way to do that from within the container, but at a minimum you
can run netstat on the host on which Karaf is running.
I'm wondering w
Hello,
found the right command: activemq:query | grep -A 10 -B 10
networkConnectors.
And the problem occurred again, so I could check this. The network connector
is present on the mobile broker, but the web console of the backoffice
broker doesn't show a connection.
Regards,
Jochen
--
View th
Hi Tim,
how can I see the outbound connection on the mobile broker? I only have the
activemq commands in the karaf shell, and neither activemq:bstat nore
activemq:dstat show the connections. On the backoffice broker, I'm not sure,
but I think that no connection was shown (I will have to wait until
When the problem occurs, do you see an outbound network connection from the
mobile broker to the backoffice broker? Does it go to the right host (i.e.
backoffice1) at the right IP address? And do you see a corresponding
inbound connection on the backoffice1 broker?
Also, is it expected that the
Hi Tim,
first the respectve lines from karaf.log (the mobile broker is running in
Karaf). You can see the successful connection at 04:46:01,955. Then, bit
before 05:37:11, the mobile radio connection obviously was lost (I can also
see this from a process which monitors the ppp connection - reporte
Just to be clear: you get "Successfully
connected to ssl://..." each time the connection fails, and never when it
succeeds. Right?
Can you please provide the filename and line number from that log line?
Tim
On Nov 14, 2016 5:33 AM, "jochenw" wrote:
> Hi,
>
> in the meantime, I have digged bit
Also, can you please give the couple of lines that precede the one you
quoted in the bad case, to help us see how the broker got to that point?
Tim
On Nov 14, 2016 8:29 AM, Tim Bain wrote:
Just to be clear: you get "Successfully
connected to ssl://..." each time the connection fails, and never
Hi,
in the meantime, I have digged bit deeper into that. I can see from the
logs, that when the mobile radio network connectivity breaks, after 30
seconds both brokers close the connection and the network broker bridge is
stopped. Then the network connector tries to reconnect. Most of the time,
af
11 matches
Mail list logo
