tag:blogger.com,1999:blog-2813261110497121234.post6685789891568502491..comments2007-08-25T13:38:00.397-07:00Shane Harviehttp://www.blogger.com/profile/01016971334424471677noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-2813261110497121234.post-21255966289314836892007-08-25T13:38:00.000-07:002007-08-25T13:38:00.000-07:00I've finally gotten around to testing the JMS implementation again. With only 100 messages, only one thread opens up. (I just did puts "Thread id: #{Thread.current.id}" within the onMessage method, and only saw one thread. So I think the testing method, whilst not perfect (because of all of the puts statements) is ok. I think jruby JMS is much faster.Shane Harviehttp://www.blogger.com/profile/01016971334424471677noreply@blogger.comtag:blogger.com,1999:blog-2813261110497121234.post-39589680026752868552007-07-07T17:24:00.000-07:002007-07-07T17:24:00.000-07:00I think that a more instructive benchmark would be to start as many poller instances as there are Java threads. As Jon and Andrew said, activemessaging is architected to avoid threading issues with rails.<BR/><BR/>The good news is that I'm still massaging the JMS adapter in ActiveMessaging and my goal is to make it run in a number of different scenarios. Feel free to browse the a13g discussion group, I'll be posting some of my thoughts on the JMS adapter there shortly. Thanks.Cliff Moonhttp://www.blogger.com/profile/15447163373902589465noreply@blogger.comtag:blogger.com,1999:blog-2813261110497121234.post-76519432775142094652007-07-07T10:29:00.000-07:002007-07-07T10:29:00.000-07:00That is some interesting stuff - but I am with Jon, the linear graph for the poller is consistent with serial processing of each message, whereas if it was processing with multiple threads, you would get a flattened curve like the jms curve.<BR/><BR/>Are you using the jruby jms adapter in active messaging, or stomp? <BR/><BR/>Ola contrbuted a grest jruby only adapter which needs no poller - <BR/><BR/>http://groups.google.com/group/activemessaging-discuss/browse_thread/thread/d3cfc1a4c25f3ce7<BR/><BR/>This was the basis of the jms adapter now in activemessaging, I think all it is missing is that the one in activemessaging does use a jruby specific poller, and the jndi lookup stuff - more info about it here:<BR/><BR/>http://groups.google.com/group/activemessaging-discuss/browse_thread/thread/f040badd01d6cbee/bb272bd28db7967a<BR/><BR/>cool stuff, I'm gonna have to watch your blog more closely.<BR/><BR/>-Andrew Kuklewiczkooksterhttp://www.blogger.com/profile/02981489803973809446noreply@blogger.comtag:blogger.com,1999:blog-2813261110497121234.post-75532573105769058772007-07-06T03:30:00.000-07:002007-07-06T03:30:00.000-07:00That's a very interesting benchmark!<BR/><BR/>My theory is that the JMS solution achieves much higher throughput by utilizing multiple threads, where as a13g has been specifically designed to prevent multiple threads in Rails. It's really interesting that Rails doesn't fall over when getting exposed to multiple threads.<BR/><BR/>Have you measured how many connections gets opened up to the database? I think this solution could benefit from connection pooling.<BR/><BR/>It would be interesting to integrate this approach into a13g so you could benefit from the higher throughput and still be able to use a higher level programming model.tirsenhttp://www.blogger.com/profile/07016235297221856738noreply@blogger.com