Like Jim, I think that the failover transport should be capable of doing
the reconnect for you when debugging (and it's definitely capable of doing
it when there isn't a debugger in the mix), but it's possible that this is
one of the situations that illustrate the saying, "In theory, theory and
pra
I've never tried configuring a broker with a static networkConnector
connected to itself (why would I, it's a useless configuration), but it
wouldn't surprise me if the broker rejected that self-connection, which
could result in the EOFException you saw. It's also possible that there's
something w
It seems like you reinvented the wheel a little bit there, but I'm glad you
got it to work for you.
Cheers!
On Wed, Oct 12, 2016, 8:36 AM magmasystems
wrote:
> Thanks Jim and Tim. I managed to hook up a poor-man's recover mechanism.
> Our
> application uses a framework that sits over the vario
Oh ok. Anyhow, I feel the configuration still seems fine. It still doesnt
explain the WARNING entry.
On Oct 12, 2016 8:53 PM, "Tim Bain [via ActiveMQ]" <
ml-node+s2283324n4717847...@n4.nabble.com> wrote:
> Unfortunately the use of the term "discovery" is misleading. The term is
> used as a gene
Thanks Jim and Tim. I managed to hook up a poor-man's recover mechanism. Our
application uses a framework that sits over the various low-level messaging
APIs, such ActiveMQ NMS, Tibco EMS .NET client, and the .NET RabbitMQ
client. So we actually have thin "proxy objects" sitting on top of the
nativ
Unfortunately the use of the term "discovery" is misleading. The term is
used as a generic superset over the discovery transport (which allows
dynamic discovery at runtime) and the static transport (which allows static
discovery at configuration time based on what's in your config file, but no
dyn
Another technique to try when hitting a breakpoint is to not freeze all of
your threads. Let the NMS worker threads continue running in the background
so they are able to respond to the KeepAlive requests from the broker.
Otherwise, your client will be kicked off from the broker. Visual Studio
supp
I was referring to this(static discovery section).
http://activemq.apache.org/networks-of-brokers.html
On Wed, Oct 12, 2016 at 6:44 PM, Tim Bain [via ActiveMQ] <
ml-node+s2283324n4717831...@n4.nabble.com> wrote:
> I don't see anywhere that you're using the discovery transport (
> http://activem
I don't see anywhere that you're using the discovery transport (
http://activemq.apache.org/discovery-transport-reference.html); am I just
not seeing it? Automatic broker discovery isn't the default behavior; you
have to use the discovery transport if you want that behavior.
On Oct 12, 2016 7:08
As Jim said, the failover transport should ensure that your client
reconnects even if the broker disconnects the client due to a
breakpoint-induced timeout. If you're able to isolate specific steps or
sequences of events that result in that not happening, or to gather more
detailed information abo
I wanted to configure automatic broker discovery. As of now, I just have
one broker(localhost) and that is what I configured. Isn't it how that
should be configured?
On Wed, Oct 12, 2016 at 6:02 PM, Tim Bain [via ActiveMQ] <
ml-node+s2283324n4717827...@n4.nabble.com> wrote:
> OK. And is it reall
OK. And is it really pointing to localhost (i.e. this broker is
connecting to itself)? I've never tried that myself, but I can't imagine
that resulting in good behavior... How come that URI isn't to some other
(cross-site) host?
Tim
On Oct 12, 2016 1:04 AM, "divinedragon" wrote:
> Oh my ba
Another information to add here, I don't know if it could give some
indication. For the SSL transfer, I am using my own self signed
certificate(keystore and truststore using keytool) which I have configured
via the section as below.
Could this be a problem?
On Wed
Oh my bad. Sorry about the type. The value is this.
JMS_X_SITE_CSV_URL=ssl://localhost:7031/
On Wed, Oct 12, 2016 at 12:23 PM, Tim Bain [via ActiveMQ] <
ml-node+s2283324n4717820...@n4.nabble.com> wrote:
> It looks like you're using the tcp transport to connect to an SSL
> endpoint;
> shouldn't
It looks like you're using the tcp transport to connect to an SSL endpoint;
shouldn't you either use the ssl transport or port 7029?
On Oct 12, 2016 12:38 AM, "divinedragon" wrote:
> I don't suppose the value is incorrect. Here are all the values in the
> properties file.
>
> JMS_PORT=7029
> JMS
15 matches
Mail list logo
