You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Jason Dillon <ja...@planet57.com> on 2011/11/08 02:45:31 UTC
HTTP transport
... is this any good? I keep getting folks in the backseat making tunneling over HTTP a meta-requirement. Are there any significant issues with using the http[s] transport in the activemq-optional module for this? Will use of it totally kill performance?
Documentation is a bit weak here, I've just found this:
http://activemq.apache.org/http-and-https-transports-reference.html
Which points to a bunch of other places which point out issues. I'm unsure what is resolved and what is still pending.
I'm going to play with it and run some tests, but I was curious if the community has collected any intel on use of this transport already?
--jason
Re: HTTP transport
Posted by Dejan Bosanac <de...@nighttale.net>.
No, http transport is JMS compliant
Regards
--
Dejan Bosanac - http://twitter.com/dejanb
-----------------
The experts in open source integration and messaging - http://fusesource.com
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Wed, Nov 9, 2011 at 1:47 PM, James Green <ja...@gmail.com>wrote:
> Are there operational disadvantages to using HTTP transport?
>
> I am thinking in terms of things like acknowledgements - behavioural
> changes like Stomp vs Openwire.
>
> James
>
> On 8 November 2011 10:14, Dejan Bosanac <de...@nighttale.net> wrote:
>
> > Hi there are quite some folks that are using it in production, so it's
> > stable enough.
> >
> > The main reason to use this protocol is if you need to go through some
> > firewall and you can't let regular openwire traffic through it. It will
> > basically use XStream to marshal messages to XML and send them using http
> > to the broker.
> >
> > Hope this helps.
> >
> > Regards
> > --
> > Dejan Bosanac - http://twitter.com/dejanb
> > -----------------
> > The experts in open source integration and messaging -
> > http://fusesource.com
> > ActiveMQ in Action - http://www.manning.com/snyder/
> > Blog - http://www.nighttale.net
> >
> >
> > On Tue, Nov 8, 2011 at 8:56 AM, James Green <james.mk.green@gmail.com
> > >wrote:
> >
> > > This is of interest to me too.
> > >
> > > Could use a description of it's behaviour which that page does not
> > provide.
> > >
> > > James
> > >
> > > On 8 November 2011 01:45, Jason Dillon <ja...@planet57.com> wrote:
> > >
> > > > ... is this any good? I keep getting folks in the backseat making
> > > > tunneling over HTTP a meta-requirement. Are there any significant
> > issues
> > > > with using the http[s] transport in the activemq-optional module for
> > > this?
> > > > Will use of it totally kill performance?
> > > >
> > > > Documentation is a bit weak here, I've just found this:
> > > >
> > > > http://activemq.apache.org/http-and-https-transports-reference.html
> > > >
> > > > Which points to a bunch of other places which point out issues. I'm
> > > > unsure what is resolved and what is still pending.
> > > >
> > > > I'm going to play with it and run some tests, but I was curious if
> the
> > > > community has collected any intel on use of this transport already?
> > > >
> > > > --jason
> > >
> >
>
Re: HTTP transport
Posted by James Green <ja...@gmail.com>.
Are there operational disadvantages to using HTTP transport?
I am thinking in terms of things like acknowledgements - behavioural
changes like Stomp vs Openwire.
James
On 8 November 2011 10:14, Dejan Bosanac <de...@nighttale.net> wrote:
> Hi there are quite some folks that are using it in production, so it's
> stable enough.
>
> The main reason to use this protocol is if you need to go through some
> firewall and you can't let regular openwire traffic through it. It will
> basically use XStream to marshal messages to XML and send them using http
> to the broker.
>
> Hope this helps.
>
> Regards
> --
> Dejan Bosanac - http://twitter.com/dejanb
> -----------------
> The experts in open source integration and messaging -
> http://fusesource.com
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
>
>
> On Tue, Nov 8, 2011 at 8:56 AM, James Green <james.mk.green@gmail.com
> >wrote:
>
> > This is of interest to me too.
> >
> > Could use a description of it's behaviour which that page does not
> provide.
> >
> > James
> >
> > On 8 November 2011 01:45, Jason Dillon <ja...@planet57.com> wrote:
> >
> > > ... is this any good? I keep getting folks in the backseat making
> > > tunneling over HTTP a meta-requirement. Are there any significant
> issues
> > > with using the http[s] transport in the activemq-optional module for
> > this?
> > > Will use of it totally kill performance?
> > >
> > > Documentation is a bit weak here, I've just found this:
> > >
> > > http://activemq.apache.org/http-and-https-transports-reference.html
> > >
> > > Which points to a bunch of other places which point out issues. I'm
> > > unsure what is resolved and what is still pending.
> > >
> > > I'm going to play with it and run some tests, but I was curious if the
> > > community has collected any intel on use of this transport already?
> > >
> > > --jason
> >
>
Re: HTTP transport
Posted by artnaseef <ar...@artnaseef.com>.
Note that I have personally seen the HTTP transport consuming significant CPU
resources in the past. Be sure to measure performance and watch CPU
utilization. IIRC that's because the implementation frequently polls.
I recommend looking to an alternate approach. One I've implemented with
great results in the past uses websockets to provide long-lived connections
over HTTP-compliant connections that are supported by a large number of
firewalls and proxies, while giving low message delivery latency.
--
View this message in context: http://activemq.2283324.n4.nabble.com/HTTP-transport-tp4014555p4704936.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: HTTP transport
Posted by Tim Bain <tb...@alumni.duke.edu>.
I suspect that the slowness has more to do with needing to set up and tear
down a new HTTP connection for each message than with Jetty, though I'm
still surprised it's that slow.
When you monitor the client and broker processes, what resource (CPU,
memory, disk I/O, etc.) is the bottleneck, and for which process?
On Dec 12, 2015 10:22 AM, "neo.li" <ne...@arcserve.com> wrote:
> hello,
> I am using http protocol for AMQ, but I find it is slower than using
> tcp. I guess that the cause are these dependencise, like jetty.
> I do no know how to optimize it, can u help me?
>
> Thanks
> Neo.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/HTTP-transport-tp4014555p4704907.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: HTTP transport
Posted by "neo.li" <ne...@arcserve.com>.
hello,
I am using http protocol for AMQ, but I find it is slower than using
tcp. I guess that the cause are these dependencise, like jetty.
I do no know how to optimize it, can u help me?
Thanks
Neo.
--
View this message in context: http://activemq.2283324.n4.nabble.com/HTTP-transport-tp4014555p4704907.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: HTTP transport
Posted by Dejan Bosanac <de...@nighttale.net>.
Hi,
http transport is in an optional package for the exact reason of not
"polluting" activemq-core with a lot of dependencies, as it requires quite
some of them, like jetty (on the server side), http-client (on the client
side), xstream (and xml libs xstream needs) on both sides. Although there's
room for cleaning deprecated stuff from activemq-optional module a bit. All
patches and contributions are more then welcomed :)
Test units for throughput are messages/sec
Regards
--
Dejan Bosanac - http://twitter.com/dejanb
-----------------
The experts in open source integration and messaging - http://fusesource.com
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Wed, Nov 9, 2011 at 1:27 AM, Jason Dillon <ja...@planet57.com> wrote:
> BTW... can anyone explain what the units of these value are? Is "System
> Average Throughput" per-???
>
> --jason
>
>
> On Nov 8, 2011, at 1:39 PM, Jason Dillon wrote:
>
> > FYI, some performance numbers I collected if any one is interested.
> >
> > * * *
> >
> > Used default configuration of
> http://activemq.apache.org/activemq-performance-module-users-manual.html(slightly massaged pom to get it to build, yay maven)
> >
> > Run on quad-core i7 2.93 mac 10.7.2
> >
> > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
> > java version "1.6.0_26"
> > Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
> > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)
> >
> > Ending memory use all roughly: 6M/81M
> >
> > HTTP Transport - Consumer
> > =========================
> >
> > System Total Throughput: 127673
> > System Total Clients: 1
> > System Average Throughput: 531.9708333333333
> > System Average Throughput Excluding Min/Max: 527.7083333333334
> > System Average Client Throughput: 531.9708333333333
> > System Average Client Throughput Excluding Min/Max: 527.7083333333334
> > Min Client Throughput Per Sample: clientName=JmsConsumer0, value=484
> > Max Client Throughput Per Sample: clientName=JmsConsumer0, value=539
> > Min Client Total Throughput: clientName=JmsConsumer0, value=127673
> > Max Client Total Throughput: clientName=JmsConsumer0, value=127673
> > Min Average Client Throughput: clientName=JmsConsumer0,
> value=531.9708333333333
> > Max Average Client Throughput: clientName=JmsConsumer0,
> value=531.9708333333333
> > Min Average Client Throughput Excluding Min/Max:
> clientName=JmsConsumer0, value=527.7083333333334
> > Max Average Client Throughput Excluding Min/Max:
> clientName=JmsConsumer0, value=527.7083333333334
> >
> > HTTP Transport - Producer
> > =========================
> >
> > System Total Throughput: 129874
> > System Total Clients: 1
> > System Average Throughput: 541.1416666666667
> > System Average Throughput Excluding Min/Max: 536.8041666666667
> > System Average Client Throughput: 541.1416666666667
> > System Average Client Throughput Excluding Min/Max: 536.8041666666667
> > Min Client Throughput Per Sample: clientName=JmsProducer0, value=488
> > Max Client Throughput Per Sample: clientName=JmsProducer0, value=553
> > Min Client Total Throughput: clientName=JmsProducer0, value=129874
> > Max Client Total Throughput: clientName=JmsProducer0, value=129874
> > Min Average Client Throughput: clientName=JmsProducer0,
> value=541.1416666666667
> > Max Average Client Throughput: clientName=JmsProducer0,
> value=541.1416666666667
> > Min Average Client Throughput Excluding Min/Max:
> clientName=JmsProducer0, value=536.8041666666667
> > Max Average Client Throughput Excluding Min/Max:
> clientName=JmsProducer0, value=536.8041666666667
> >
> > TCP Transport - Consumer
> > ========================
> >
> > System Total Throughput: 7697735
> > System Total Clients: 1
> > System Average Throughput: 32073.895833333332
> > System Average Throughput Excluding Min/Max: 31803.916666666668
> > System Average Client Throughput: 32073.895833333332
> > System Average Client Throughput Excluding Min/Max: 31803.916666666668
> > Min Client Throughput Per Sample: clientName=JmsConsumer0, value=30656
> > Max Client Throughput Per Sample: clientName=JmsConsumer0, value=34139
> > Min Client Total Throughput: clientName=JmsConsumer0, value=7697735
> > Max Client Total Throughput: clientName=JmsConsumer0, value=7697735
> > Min Average Client Throughput: clientName=JmsConsumer0,
> value=32073.895833333332
> > Max Average Client Throughput: clientName=JmsConsumer0,
> value=32073.895833333332
> > Min Average Client Throughput Excluding Min/Max:
> clientName=JmsConsumer0, value=31803.916666666668
> > Max Average Client Throughput Excluding Min/Max:
> clientName=JmsConsumer0, value=31803.916666666668
> >
> > TCP Transport - Producer
> > ========================
> >
> > System Total Throughput: 7694119
> > System Total Clients: 1
> > System Average Throughput: 32058.829166666666
> > System Average Throughput Excluding Min/Max: 31799.15
> > System Average Client Throughput: 32058.829166666666
> > System Average Client Throughput Excluding Min/Max: 31799.15
> > Min Client Throughput Per Sample: clientName=JmsProducer0, value=28449
> > Max Client Throughput Per Sample: clientName=JmsProducer0, value=33874
> > Min Client Total Throughput: clientName=JmsProducer0, value=7694119
> > Max Client Total Throughput: clientName=JmsProducer0, value=7694119
> > Min Average Client Throughput: clientName=JmsProducer0,
> value=32058.829166666666
> > Max Average Client Throughput: clientName=JmsProducer0,
> value=32058.829166666666
> > Min Average Client Throughput Excluding Min/Max:
> clientName=JmsProducer0, value=31799.15
> > Max Average Client Throughput Excluding Min/Max:
> clientName=JmsProducer0, value=31799.15
> >
> > TCP was consuming a good portion of the CPU constantly:
> >
> > 4013 - Broker 251% 50th
> > 4060 - Consumer 126% 26th
> > 4069 - Producer 63% 35th
> >
> > HTTP consumed considerably less:
> >
> > 4084 - Broker 56% 50th
> > 4093 - Consumer 37% 37th
> > 4102 - Producer 24% 34th
> >
> > This perf harness does not have a built in option for binary messages
> (that I could find, looks like its hard coded to TextMessage) so I'd
> imagine that a BytesMessage w/BASE64 encoding for http transport would
> degrade performance even more.
> >
> > --jason
> >
> >
>
>
Re: HTTP transport
Posted by Jason Dillon <ja...@planet57.com>.
BTW... can anyone explain what the units of these value are? Is "System Average Throughput" per-???
--jason
On Nov 8, 2011, at 1:39 PM, Jason Dillon wrote:
> FYI, some performance numbers I collected if any one is interested.
>
> * * *
>
> Used default configuration of http://activemq.apache.org/activemq-performance-module-users-manual.html (slightly massaged pom to get it to build, yay maven)
>
> Run on quad-core i7 2.93 mac 10.7.2
>
> Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)
>
> Ending memory use all roughly: 6M/81M
>
> HTTP Transport - Consumer
> =========================
>
> System Total Throughput: 127673
> System Total Clients: 1
> System Average Throughput: 531.9708333333333
> System Average Throughput Excluding Min/Max: 527.7083333333334
> System Average Client Throughput: 531.9708333333333
> System Average Client Throughput Excluding Min/Max: 527.7083333333334
> Min Client Throughput Per Sample: clientName=JmsConsumer0, value=484
> Max Client Throughput Per Sample: clientName=JmsConsumer0, value=539
> Min Client Total Throughput: clientName=JmsConsumer0, value=127673
> Max Client Total Throughput: clientName=JmsConsumer0, value=127673
> Min Average Client Throughput: clientName=JmsConsumer0, value=531.9708333333333
> Max Average Client Throughput: clientName=JmsConsumer0, value=531.9708333333333
> Min Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=527.7083333333334
> Max Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=527.7083333333334
>
> HTTP Transport - Producer
> =========================
>
> System Total Throughput: 129874
> System Total Clients: 1
> System Average Throughput: 541.1416666666667
> System Average Throughput Excluding Min/Max: 536.8041666666667
> System Average Client Throughput: 541.1416666666667
> System Average Client Throughput Excluding Min/Max: 536.8041666666667
> Min Client Throughput Per Sample: clientName=JmsProducer0, value=488
> Max Client Throughput Per Sample: clientName=JmsProducer0, value=553
> Min Client Total Throughput: clientName=JmsProducer0, value=129874
> Max Client Total Throughput: clientName=JmsProducer0, value=129874
> Min Average Client Throughput: clientName=JmsProducer0, value=541.1416666666667
> Max Average Client Throughput: clientName=JmsProducer0, value=541.1416666666667
> Min Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=536.8041666666667
> Max Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=536.8041666666667
>
> TCP Transport - Consumer
> ========================
>
> System Total Throughput: 7697735
> System Total Clients: 1
> System Average Throughput: 32073.895833333332
> System Average Throughput Excluding Min/Max: 31803.916666666668
> System Average Client Throughput: 32073.895833333332
> System Average Client Throughput Excluding Min/Max: 31803.916666666668
> Min Client Throughput Per Sample: clientName=JmsConsumer0, value=30656
> Max Client Throughput Per Sample: clientName=JmsConsumer0, value=34139
> Min Client Total Throughput: clientName=JmsConsumer0, value=7697735
> Max Client Total Throughput: clientName=JmsConsumer0, value=7697735
> Min Average Client Throughput: clientName=JmsConsumer0, value=32073.895833333332
> Max Average Client Throughput: clientName=JmsConsumer0, value=32073.895833333332
> Min Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=31803.916666666668
> Max Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=31803.916666666668
>
> TCP Transport - Producer
> ========================
>
> System Total Throughput: 7694119
> System Total Clients: 1
> System Average Throughput: 32058.829166666666
> System Average Throughput Excluding Min/Max: 31799.15
> System Average Client Throughput: 32058.829166666666
> System Average Client Throughput Excluding Min/Max: 31799.15
> Min Client Throughput Per Sample: clientName=JmsProducer0, value=28449
> Max Client Throughput Per Sample: clientName=JmsProducer0, value=33874
> Min Client Total Throughput: clientName=JmsProducer0, value=7694119
> Max Client Total Throughput: clientName=JmsProducer0, value=7694119
> Min Average Client Throughput: clientName=JmsProducer0, value=32058.829166666666
> Max Average Client Throughput: clientName=JmsProducer0, value=32058.829166666666
> Min Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=31799.15
> Max Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=31799.15
>
> TCP was consuming a good portion of the CPU constantly:
>
> 4013 - Broker 251% 50th
> 4060 - Consumer 126% 26th
> 4069 - Producer 63% 35th
>
> HTTP consumed considerably less:
>
> 4084 - Broker 56% 50th
> 4093 - Consumer 37% 37th
> 4102 - Producer 24% 34th
>
> This perf harness does not have a built in option for binary messages (that I could find, looks like its hard coded to TextMessage) so I'd imagine that a BytesMessage w/BASE64 encoding for http transport would degrade performance even more.
>
> --jason
>
>
Re: HTTP transport
Posted by Jason Dillon <ja...@planet57.com>.
FYI, some performance numbers I collected if any one is interested.
* * *
Used default configuration of http://activemq.apache.org/activemq-performance-module-users-manual.html (slightly massaged pom to get it to build, yay maven)
Run on quad-core i7 2.93 mac 10.7.2
Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)
Ending memory use all roughly: 6M/81M
HTTP Transport - Consumer
=========================
System Total Throughput: 127673
System Total Clients: 1
System Average Throughput: 531.9708333333333
System Average Throughput Excluding Min/Max: 527.7083333333334
System Average Client Throughput: 531.9708333333333
System Average Client Throughput Excluding Min/Max: 527.7083333333334
Min Client Throughput Per Sample: clientName=JmsConsumer0, value=484
Max Client Throughput Per Sample: clientName=JmsConsumer0, value=539
Min Client Total Throughput: clientName=JmsConsumer0, value=127673
Max Client Total Throughput: clientName=JmsConsumer0, value=127673
Min Average Client Throughput: clientName=JmsConsumer0, value=531.9708333333333
Max Average Client Throughput: clientName=JmsConsumer0, value=531.9708333333333
Min Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=527.7083333333334
Max Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=527.7083333333334
HTTP Transport - Producer
=========================
System Total Throughput: 129874
System Total Clients: 1
System Average Throughput: 541.1416666666667
System Average Throughput Excluding Min/Max: 536.8041666666667
System Average Client Throughput: 541.1416666666667
System Average Client Throughput Excluding Min/Max: 536.8041666666667
Min Client Throughput Per Sample: clientName=JmsProducer0, value=488
Max Client Throughput Per Sample: clientName=JmsProducer0, value=553
Min Client Total Throughput: clientName=JmsProducer0, value=129874
Max Client Total Throughput: clientName=JmsProducer0, value=129874
Min Average Client Throughput: clientName=JmsProducer0, value=541.1416666666667
Max Average Client Throughput: clientName=JmsProducer0, value=541.1416666666667
Min Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=536.8041666666667
Max Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=536.8041666666667
TCP Transport - Consumer
========================
System Total Throughput: 7697735
System Total Clients: 1
System Average Throughput: 32073.895833333332
System Average Throughput Excluding Min/Max: 31803.916666666668
System Average Client Throughput: 32073.895833333332
System Average Client Throughput Excluding Min/Max: 31803.916666666668
Min Client Throughput Per Sample: clientName=JmsConsumer0, value=30656
Max Client Throughput Per Sample: clientName=JmsConsumer0, value=34139
Min Client Total Throughput: clientName=JmsConsumer0, value=7697735
Max Client Total Throughput: clientName=JmsConsumer0, value=7697735
Min Average Client Throughput: clientName=JmsConsumer0, value=32073.895833333332
Max Average Client Throughput: clientName=JmsConsumer0, value=32073.895833333332
Min Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=31803.916666666668
Max Average Client Throughput Excluding Min/Max: clientName=JmsConsumer0, value=31803.916666666668
TCP Transport - Producer
========================
System Total Throughput: 7694119
System Total Clients: 1
System Average Throughput: 32058.829166666666
System Average Throughput Excluding Min/Max: 31799.15
System Average Client Throughput: 32058.829166666666
System Average Client Throughput Excluding Min/Max: 31799.15
Min Client Throughput Per Sample: clientName=JmsProducer0, value=28449
Max Client Throughput Per Sample: clientName=JmsProducer0, value=33874
Min Client Total Throughput: clientName=JmsProducer0, value=7694119
Max Client Total Throughput: clientName=JmsProducer0, value=7694119
Min Average Client Throughput: clientName=JmsProducer0, value=32058.829166666666
Max Average Client Throughput: clientName=JmsProducer0, value=32058.829166666666
Min Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=31799.15
Max Average Client Throughput Excluding Min/Max: clientName=JmsProducer0, value=31799.15
TCP was consuming a good portion of the CPU constantly:
4013 - Broker 251% 50th
4060 - Consumer 126% 26th
4069 - Producer 63% 35th
HTTP consumed considerably less:
4084 - Broker 56% 50th
4093 - Consumer 37% 37th
4102 - Producer 24% 34th
This perf harness does not have a built in option for binary messages (that I could find, looks like its hard coded to TextMessage) so I'd imagine that a BytesMessage w/BASE64 encoding for http transport would degrade performance even more.
--jason
Re: HTTP transport
Posted by moodboom <mo...@gmail.com>.
dejanb wrote
> Hi,
>
> there's a difference between Camel http component and ActiveMQ http
> transport. Both are solid for what they've been designed to do.
Thanks dejanb, and a huge thanks for all the mailing list answers over the
years, they've helped me get started.
Can I ask for a quick nudge on my problem? I just want the simplest way to
automatically process a queue, sending messages that arrive back out to a
RESTful provider. I assume that means I need Camel, right? Is there a
working example of a Camel route that send to an HTTP provider?
Thanks,
Michael
--
View this message in context: http://activemq.2283324.n4.nabble.com/HTTP-transport-tp4014555p4669713.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: HTTP transport
Posted by Dejan Bosanac <de...@nighttale.net>.
Hi,
there's a difference between Camel http component and ActiveMQ http
transport. Both are solid for what they've been designed to do.
Regards
--
Dejan Bosanac
----------------------
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosanac@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Wed, Jul 24, 2013 at 5:18 AM, moodboom <mo...@gmail.com> wrote:
> Jason did you arrive at a compact way to include http support?
>
> Sorry to revive this old thread, but it seems relevant to my problem. I'm
> new to this, using a pretty vanilla ActiveMQ config with a camel route, and
> getting "No component found with scheme: http4".
>
> So I'm wondering what the minimal is I have to do to enable http route
> targets. Apologies, it might be a basic question but I'm very new to this,
> appreciate any help.
>
> Jason Dillon wrote
> > If there are folks using this in production, then why isn't this feature
> > in its own module and not lumped together with all the other fluff in
> > activemq-optional?
> >
> > I have ~12 dependency excludes when depending on that module to keep out
> > unwanted/unused stuff which is needed by other "optional" features
> > provided by that module.
> >
> > :-(
> >
> > --jason
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/HTTP-transport-tp4014555p4669671.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: HTTP transport
Posted by moodboom <mo...@gmail.com>.
Jason did you arrive at a compact way to include http support?
Sorry to revive this old thread, but it seems relevant to my problem. I'm
new to this, using a pretty vanilla ActiveMQ config with a camel route, and
getting "No component found with scheme: http4".
So I'm wondering what the minimal is I have to do to enable http route
targets. Apologies, it might be a basic question but I'm very new to this,
appreciate any help.
Jason Dillon wrote
> If there are folks using this in production, then why isn't this feature
> in its own module and not lumped together with all the other fluff in
> activemq-optional?
>
> I have ~12 dependency excludes when depending on that module to keep out
> unwanted/unused stuff which is needed by other "optional" features
> provided by that module.
>
> :-(
>
> --jason
--
View this message in context: http://activemq.2283324.n4.nabble.com/HTTP-transport-tp4014555p4669671.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: HTTP transport
Posted by Jason Dillon <ja...@planet57.com>.
If there are folks using this in production, then why isn't this feature in its own module and not lumped together with all the other fluff in activemq-optional?
I have ~12 dependency excludes when depending on that module to keep out unwanted/unused stuff which is needed by other "optional" features provided by that module.
:-(
--jason
On Nov 8, 2011, at 2:14 AM, Dejan Bosanac wrote:
> Hi there are quite some folks that are using it in production, so it's
> stable enough.
>
> The main reason to use this protocol is if you need to go through some
> firewall and you can't let regular openwire traffic through it. It will
> basically use XStream to marshal messages to XML and send them using http
> to the broker.
>
> Hope this helps.
>
> Regards
> --
> Dejan Bosanac - http://twitter.com/dejanb
> -----------------
> The experts in open source integration and messaging - http://fusesource.com
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
>
>
> On Tue, Nov 8, 2011 at 8:56 AM, James Green <ja...@gmail.com>wrote:
>
>> This is of interest to me too.
>>
>> Could use a description of it's behaviour which that page does not provide.
>>
>> James
>>
>> On 8 November 2011 01:45, Jason Dillon <ja...@planet57.com> wrote:
>>
>>> ... is this any good? I keep getting folks in the backseat making
>>> tunneling over HTTP a meta-requirement. Are there any significant issues
>>> with using the http[s] transport in the activemq-optional module for
>> this?
>>> Will use of it totally kill performance?
>>>
>>> Documentation is a bit weak here, I've just found this:
>>>
>>> http://activemq.apache.org/http-and-https-transports-reference.html
>>>
>>> Which points to a bunch of other places which point out issues. I'm
>>> unsure what is resolved and what is still pending.
>>>
>>> I'm going to play with it and run some tests, but I was curious if the
>>> community has collected any intel on use of this transport already?
>>>
>>> --jason
>>
Re: HTTP transport
Posted by Dejan Bosanac <de...@nighttale.net>.
Hi there are quite some folks that are using it in production, so it's
stable enough.
The main reason to use this protocol is if you need to go through some
firewall and you can't let regular openwire traffic through it. It will
basically use XStream to marshal messages to XML and send them using http
to the broker.
Hope this helps.
Regards
--
Dejan Bosanac - http://twitter.com/dejanb
-----------------
The experts in open source integration and messaging - http://fusesource.com
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Tue, Nov 8, 2011 at 8:56 AM, James Green <ja...@gmail.com>wrote:
> This is of interest to me too.
>
> Could use a description of it's behaviour which that page does not provide.
>
> James
>
> On 8 November 2011 01:45, Jason Dillon <ja...@planet57.com> wrote:
>
> > ... is this any good? I keep getting folks in the backseat making
> > tunneling over HTTP a meta-requirement. Are there any significant issues
> > with using the http[s] transport in the activemq-optional module for
> this?
> > Will use of it totally kill performance?
> >
> > Documentation is a bit weak here, I've just found this:
> >
> > http://activemq.apache.org/http-and-https-transports-reference.html
> >
> > Which points to a bunch of other places which point out issues. I'm
> > unsure what is resolved and what is still pending.
> >
> > I'm going to play with it and run some tests, but I was curious if the
> > community has collected any intel on use of this transport already?
> >
> > --jason
>
Re: HTTP transport
Posted by James Green <ja...@gmail.com>.
This is of interest to me too.
Could use a description of it's behaviour which that page does not provide.
James
On 8 November 2011 01:45, Jason Dillon <ja...@planet57.com> wrote:
> ... is this any good? I keep getting folks in the backseat making
> tunneling over HTTP a meta-requirement. Are there any significant issues
> with using the http[s] transport in the activemq-optional module for this?
> Will use of it totally kill performance?
>
> Documentation is a bit weak here, I've just found this:
>
> http://activemq.apache.org/http-and-https-transports-reference.html
>
> Which points to a bunch of other places which point out issues. I'm
> unsure what is resolved and what is still pending.
>
> I'm going to play with it and run some tests, but I was curious if the
> community has collected any intel on use of this transport already?
>
> --jason