Future of Apollo...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Future of Apollo...

redboy1972
I tested many brokers and am very impressed with the performance characteristics of Apollo.  I work for a large company and the broker is going to be the backbone of a large infrastructure project.

The issue is that while Apollo does well in my tests, its future seems uncertain.  Especially being a subproject of a future ActiveMQ 6 release.

1) Will there be continued bug fixes should we run into something and for how long?
2) Any general timeline for inclusion of Reactor Based Thread Model into ActiveMQ?

Our ship timeline is Q4 2015.
Reply | Threaded
Open this post in threaded view
|

Re: Future of Apollo...

chirino
Well,

I've stopped working on apollo since the community aspects of it did
not seem to be getting much traction.  If your using it and find any
problems with it, please send in patches :)  You part of solving the
community problem and help maintain and push apollo forward.

On Thu, Apr 9, 2015 at 1:09 PM, redboy1972 <[hidden email]> wrote:

> I tested many brokers and am very impressed with the performance
> characteristics of Apollo.  I work for a large company and the broker is
> going to be the backbone of a large infrastructure project.
>
> The issue is that while Apollo does well in my tests, its future seems
> uncertain.  Especially being a subproject of a future ActiveMQ 6 release.
>
> 1) Will there be continued bug fixes should we run into something and for
> how long?
> 2) Any general timeline for inclusion of Reactor Based Thread Model into
> ActiveMQ?
>
> Our ship timeline is Q4 2015.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Future-of-Apollo-tp4694644.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: Future of Apollo...

redboy1972
Thanks for the response.

Very saddened to hear this but expected this to be the response.

By the way, I really appreciated your posts at:
https://github.com/apache/activemq-apollo/blob/trunk/apollo-stomp/src/test/scala/org/apache/activemq/apollo/stomp/test/UserOwnershipSecurityFactory.scala#L29
and
https://github.com/apache/activemq-apollo/blob/trunk/apollo-stomp/src/test/resources/apollo-stomp-custom-security.xml#L18

As they allowed me to figure out how to do my own custom authorization.

See: http://stackoverflow.com/questions/29424952/dynamic-destination-in-apache-apollo-mq/29527865#29527865

Back to my question:
According to https://activemq.apache.org/new-features-in-60.html, it appears as if the lessons learned in Apollo would be used to enhance a future ActiveMQ 6 line.  Is this still planned?  If so will it be something usable by my company by Q4?

I have been testing brokers for 3 weeks and Apollo's characteristics are hands down the best.  Something was done VERY right.  Gratz.
Reply | Threaded
Open this post in threaded view
|

Re: Future of Apollo...

chirino
On Friday, April 10, 2015, redboy1972 <[hidden email]> wrote:

> Thanks for the response.
>
> Very saddened to hear this but expected this to be the response.
>
> By the way, I really appreciated your posts at:
>
> https://github.com/apache/activemq-apollo/blob/trunk/apollo-stomp/src/test/scala/org/apache/activemq/apollo/stomp/test/UserOwnershipSecurityFactory.scala#L29
> and
>
> https://github.com/apache/activemq-apollo/blob/trunk/apollo-stomp/src/test/resources/apollo-stomp-custom-security.xml#L18
>
> As they allowed me to figure out how to do my own custom authorization.
>
> See:
>
> http://stackoverflow.com/questions/29424952/dynamic-destination-in-apache-apollo-mq/29527865#29527865
>
> Back to my question:
> According to https://activemq.apache.org/new-features-in-60.html, it
> appears
> as if the lessons learned in Apollo would be used to enhance a future
> ActiveMQ 6 line.  Is this still planned?  If so will it be something usable
> by my company by Q4?
>

Well that's the plan. But words are cheap. Need to find time to actually do
it!


> I have been testing brokers for 3 weeks and Apollo's characteristics are
> hands down the best.  Something was done VERY right.  Gratz.
>
>
Great!  Mind telling us more details about you liked about Apollo and
disliked about the other brokers?



>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Future-of-Apollo-tp4694644p4694737.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>


--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: Future of Apollo...

redboy1972
This post was updated on .
LOVE - Performance and ease of use.  Name is cool too!  Other than setting APOLLO_ULIMIT and transportConnector it worked out of the box.  Many other brokers I had to spend hours doing Google searches to overcome oddities.  Rabbit was the worst.

Dislike - Lack of authorization ability (was going to create a regex pattern match similar to Mosquito and hand it back to this group, but alas, it seems a dead project.  LOL - even started learning Scala to do so.)  This is ONLY due to it being an infant project and given more time / contributors would have made it in.

For my test information...
See: http://stackoverflow.com/questions/29358313/max-mqtt-connections

I basically create a custom MQTT program that binds the client side of the socket to a VIP and since there were 30 of them I was eligible to connect 1M+ from one host.  This cut down on the amazon instances needed.

When I first ran ActiveMQ, I tweaked, tweaked, tweaked until I couldn't find anything else to alter then tested for max connections, connection rate and throughput.

My client spawned 1000 threads that once they had achieved 100k connections also started to pub/sub to a topic while continuing to connect.

When I attempted apollo, the rates were so high I even thought BOTH "cat /proc/net/sockstat" and "netstat -an | grep 1883" were lying and that something was wrong with my setup.  Then the shock and finally a grin took over!

This is because other broker's pub/sub was magnitudes and I do mean a whole lot lower.

Line	Connections         Time	  Avg Conn rate    Sent		Send/s		
-------------------------------------------------------------------------------------
180		362420		0:29:50		4.94	    6767325	 4999.69   	(HiveMQ)
180		133088		0:29:50		13.46	   29113701	17020.40   	(ActiveMQ / AMQ)
180		191594		0:29:50		9.34	    8170942	 4923.72   	(Mosquitto)
180		107267		0:29:50		16.69	   36514108	21647.84   	(Rabbit)

And then there is my beloved Apollo!!!
180		632920		0:29:53		2.83	  101108694	57352.22   	(Apollo)


With no pub/sub, just connect and subscribe to private topic.
Connections in 15 min
----------------------------
Active         21062
JBoss AMQ      57611
Hive          225555
Mosquitto     244519
Rabbit *      518330
Apollo        756404

At ~950k or so we reached some O/S limit.

NOTE: Not all of the above brokers were 100% tuned and I hit a connection limit on Rabbit likely due to * Erlang 1M fd that I didn't bother to overcome as my focus was on Apollo.

HornetMQ is not something that I am currently able to evaluate due to lack of MQTT support.  It is in progress https://issues.jboss.org/browse/HORNETQ-947.  When I saw "Fix Version/s: 2.5.0.Beta2" I got eager and downloaded / compiled the 2.5.0 source and installed it but alas, no MQTT.  LOL, that's when I paid closer attention to "In Progress".