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.barn...@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:rbasmaj...@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.shan...@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.barn...@wellsfargo.com> wrote: > > > Ill keep you posted as to how the duplex works with ssl... > > > > Regards, > > > > Barry > > > > > > -----Original Message----- > > From: tbai...@gmail.com [mailto:tbai...@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. >
