activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Transports available for networkConnectors
Date Tue, 06 Oct 2015 04:31:53 GMT
Raffi,

My primary goal is to document what does and doesn't work so that future
users can go to the wiki to get that answer rather than coming to the
mailing list (which has happened multiple times that I can recall for STOMP
specifically, so someone's got an interest in it).  Whether there's value
to those particular transports in a NOB context or not is a secondary (in
the sense of "follow-on", not necessarily "less important") concern for me.

But I think it's a valid question that's worth exploring here.  I don't
claim to have all the answers (or even the right ones) for that question,
but here are my initial thoughts.  I'd be curious to hear what other people
think.

First, there are multiple flavors of "transport" that can only partially be
combined.  I came up with these categories off the cuff, which might or
might not have been a valid set of groupings and which might not have hit
all the transports:

   1. network level transports: tcp, ssl, vm, peer, udp (deprecated)
   2. application level transports: http/https, REST, RSS, XMPP (deprecated)
   3. wire format transports: openwire, amqp, stomp, mqtt, auto
   4. other specialized transports: nio
   5. network definition transports (allowing combination of connections
   and/or automatic discovery of available brokers) that are often composites
   of other transports: static, failover, masterslave, discovery, fanout,
   zeroconf

Some of those obviously are too limited to perform the full set of
broker-to-broker communications (most of the ones I termed "application"
transports, for example), but I could envision scenarios where someone
might want to use most of these.  You might want to use the http transport
to get through a firewall you otherwise wouldn't be able to navigate, for
example, or the amqp wire format for performance or interoperability
reasons, or the vm transport for running a couple embedded brokers for unit
testing scenarios (though I'm not sure you'd do that in a production
scenario).  And keep in mind that sometimes bridging is between JMS brokers
that aren't all ActiveMQ and a common protocol is needed, which might not
be tcp+openwire.  So although I think it's likely that tcp or tcp+ssl is
right starting point for most people setting up a network of ActiveMQ
brokers (and all most people will need), I'm not sure that I would say that
no one needs anything but tcp between brokers.

And I think there's room for improvement in this aspect of the
documentation on the wiki, even if most people's use cases won't require
that information.  I'm happy to make the updates, but since I don't have a
lot of experience with most of those protocols, I'm looking for information
from the community about what does and doesn't work, and I'll take that
information and capture it on the wiki.  (Thanks Barry!)

Tim

On Mon, Oct 5, 2015 at 11:15 AM, <barry.barnett@wellsfargo.com> wrote:

> Just an fyi..  I am using nio+ssl with 'duplex=true' on 1 network
> connector between two brokers.  No issues in testing so far.  Everything
> looks good.
>
> Regards,
>
> Barry
>
>
>
> -----Original Message-----
> From: Basmajian, Raffi [mailto:rbasmajian@ofiglobal.com]
> Sent: Monday, October 05, 2015 11:56 AM
> To: users@activemq.apache.org
> Subject: RE: Transports available for networkConnectors
>
> Good question, but I think a more important one to ask is: why would
> broker-to-broker connections need anything other than tcp? If I configure
> transport connectors for stomp, amqp, etc., it's because I'm bridging a gap
> between clients who speak those protocols, and the broker itself. Brokers
> configured in NoB, on the other hand, talk the same language, so there's no
> technical gap to bridge and thus no need to transform from one message
> format to another.
>
> Is that a correct assessment or am I missing something?
>
> Raffi
>
> -----Original Message-----
> From: Christopher Shannon [mailto:christopher.l.shannon@gmail.com]
> Sent: Monday, October 05, 2015 10:12 AM
> To: users@activemq.apache.org
> Subject: Re: Transports available for networkConnectors [ EXTERNAL ]
> Importance: High
>
> The auto transport should work but only if the activemq-broker jar is on
> the classpath.  It would just use OpenWire.
>
> On Mon, Oct 5, 2015 at 9:50 AM, <barry.barnett@wellsfargo.com> wrote:
>
> > Ill keep you posted as to how the duplex works with ssl...
> >
> > Regards,
> >
> > Barry
> >
> >
> > -----Original Message-----
> > From: tbain98@gmail.com [mailto:tbain98@gmail.com] On Behalf Of Tim
> > Bain
> > Sent: Monday, October 05, 2015 9:45 AM
> > To: ActiveMQ Users
> > Subject: Transports available for networkConnectors
> >
> > Can someone provide a list of which transports are allowed in
> > broker-to-broker networkConnectors and which are not?
> >
> > Obviously tcp works.  Barry Barnett's recent thread made it clear that
> > ssl works (though maybe not for duplex connections), which was news to
> me.
> > http://activemq.apache.org/networks-of-brokers.html says that http and
> > multicast both work, and that "ActiveMQ also supports other transports
> > than tcp", which isn't very useful.  Previous posts to this mailing
> > list made it clear that stomp doesn't work.  What's missing (other than
> the "wrapper"
> > transports such as static, failover, etc.), and are they supported?
> > Does the new auto transport (http://activemq.apache.org/auto.html) work
> there?
> >
> > I can update the documentation to capture this information if someone
> > can provide it.
> >
> > Tim
> >
>
> This e-mail transmission may contain information that is proprietary,
> privileged and/or confidential and is intended exclusively for the
> person(s) to whom it is addressed. Any use, copying, retention or
> disclosure by any person other than the intended recipient or the intended
> recipient's designees is strictly prohibited. If you are not the intended
> recipient or their designee, please notify the sender immediately by return
> e-mail and delete all copies. OppenheimerFunds may, at its sole discretion,
> monitor, review, retain and/or disclose the content of all email
> communications.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message