You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by snacktime <sn...@gmail.com> on 2006/10/13 22:05:34 UTC
Alternatives to stomp
Stomp support is broken. I can't see how anyone would be using it with
activemq given what I've encountered when using it. Frankly, it should be
taken off the list of supported methods of connecting until someone fixes
it, so others don't waste hours of time like I did only to find bug after
bug. At least that's my 2 cents..
In any case, what would be the next best option for connecting to activemq
from perl or ruby? Are the REST connectors stable?
Chris
Payment Online Inc
--
View this message in context: http://www.nabble.com/Alternatives-to-stomp-tf2439624.html#a6802932
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Alternatives to stomp
Posted by snacktime <sn...@gmail.com>.
On 10/14/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> I would highly recommend we focus on fixing any stomp issues that may be
> left since it's like 500% easier to understand than the openwire versions.
Well if there is anything I can do to assist let me know, keeping in
mind I'm not java developer. I have spent quite a bit of time with
stomp and the JMX console though and can make things misbehave pretty
much on queue. If I take out the issue of large numbers of messages
in the queue, then all I'm really seeing is that when I disconnect a
stomp consumer in a bad way, activemq still has the consumer and part
of the messages get assigned to the phantom consumer and you can't
ever get them back. The memory issues and negative queue numbers
don't seem to be an issue unless I try to put 20,000 or so messages in
a queue, and that's probably more of a core activemq issue then stomp
related I imagine.
Chris
Re: Alternatives to stomp
Posted by sileshi <si...@yahoo.com>.
Hiram Chirino wrote:
>
> Who maintains the Net::Stomp stuff?? Perhaps I can help fix this.
> It is maitained by Leon Brocard on cpan:
> http://search.cpan.org/dist/Net-Stomp/
>
> I'm using Version Net-Stomp-0.31 and so far this is the best
> Perl Stomp protocol implementation module. I have tried two
> other Stomp modules which are not on CPAN. I'm sticking with
> Net-Stomp-0.31 module.
>
> -Sileshi
>
>
> On 10/19/06, sileshi <si...@yahoo.com> wrote:
>>
>>
>> I now know the reason why Java JMS client message I was sending to
>> Perl Stomp client did not get to Perl side. The reason is the Java JMS
>> client sending Bytes message and The Net::Stomp module's receive_frame()
>> could not read the socket. Everytime it reads zero length bytes.
>>
>> But if I sent Text message from the JMS client, no problem.
>> Thanks for the help.
>>
>> -Sileshi
>>
>>
>> James.Strachan wrote:
>> >
>> > On 10/16/06, sileshi <si...@yahoo.com> wrote:
>> >>
>> >> The two weeks I have been working on Stomp, I have found it simple and
>> >> powerful messaging protocol.
>> >> It is an http of the messaging domain. After saying that, I'm a bit
>> >> disappointed by ActiveMQ stomp
>> >> server implementation, but like Hiram said that could be fixed.
>> >>
>> >> For those who use Stomp on Perl, I highly recommend the Net::Stomp
>> 0.31
>> >> perl
>> >> module from CPAN.
>> >> I have the same issues regarding JMX info about Enqueued and Dequeued
>> >> message being incorrect
>> >> and sometimes confusing. But the biggest problem I have with it is
>> that
>> >> when
>> >> I mix Java and Perl producers/consumers, it seems no message is being
>> >> passed
>> >> from Java client to Perl or the other way.
>> >> If I use producer/consumer Perl-to-Perl or Java-to-Java, no problem,
>> but
>> >> if
>> >> I mix, no message gets delivered.
>> >>
>> >> Unless I miss something, the default server and stomp server are
>> separate
>> >> domains and message arrived
>> >> to a topic on default server, can not be delivered to subscribers of
>> >> stomp
>> >> side of the same topic.
>> >
>> > No - there is just 1 domain. It doesn't matter what transport,
>> > protocol or client you use.
>> >
>> >
>> >> I may be mistaken, but it seems that ActiveMQ default connector and
>> stomp
>> >> connector have their
>> >> own destination space.
>> >
>> > I'm afraid you are mistaken :)
>> >
>> >
>> >> My understanding was message sent a
>> >> destination(queue, topic) will be
>> >> delivered to consumers of thsoe destination(queue, topic),
>> irrespective
>> >> of
>> >> how they connected
>> >> to activemq or which server(default, stomp) they connected to.
>> >>
>> >> May be someone in the deveolpment team could tell us some of the
>> design
>> >> points regarding these
>> >> issues. Well, it is late at night...I will stop now.
>> >
>> > The most likely reason is mismatch in the JMS destination names and
>> > the ones used in the Stomp protocol. The quickest way to disagnose the
>> > issue is to start with queues, then use the JMX console to look at the
>> > destination names being used by Java and Perl clients to check you've
>> > got the naming conventions correct etc.
>> >
>> > --
>> >
>> > James
>> > -------
>> > http://radio.weblogs.com/0112098/
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Alternatives-to-stomp-tf2439624.html#a6896969
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
>
--
View this message in context: http://www.nabble.com/Alternatives-to-stomp-tf2439624.html#a6901038
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Alternatives to stomp
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Who maintains the Net::Stomp stuff?? Perhaps I can help fix this.
On 10/19/06, sileshi <si...@yahoo.com> wrote:
>
>
> I now know the reason why Java JMS client message I was sending to
> Perl Stomp client did not get to Perl side. The reason is the Java JMS
> client sending Bytes message and The Net::Stomp module's receive_frame()
> could not read the socket. Everytime it reads zero length bytes.
>
> But if I sent Text message from the JMS client, no problem.
> Thanks for the help.
>
> -Sileshi
>
>
> James.Strachan wrote:
> >
> > On 10/16/06, sileshi <si...@yahoo.com> wrote:
> >>
> >> The two weeks I have been working on Stomp, I have found it simple and
> >> powerful messaging protocol.
> >> It is an http of the messaging domain. After saying that, I'm a bit
> >> disappointed by ActiveMQ stomp
> >> server implementation, but like Hiram said that could be fixed.
> >>
> >> For those who use Stomp on Perl, I highly recommend the Net::Stomp 0.31
> >> perl
> >> module from CPAN.
> >> I have the same issues regarding JMX info about Enqueued and Dequeued
> >> message being incorrect
> >> and sometimes confusing. But the biggest problem I have with it is that
> >> when
> >> I mix Java and Perl producers/consumers, it seems no message is being
> >> passed
> >> from Java client to Perl or the other way.
> >> If I use producer/consumer Perl-to-Perl or Java-to-Java, no problem,
> but
> >> if
> >> I mix, no message gets delivered.
> >>
> >> Unless I miss something, the default server and stomp server are
> separate
> >> domains and message arrived
> >> to a topic on default server, can not be delivered to subscribers of
> >> stomp
> >> side of the same topic.
> >
> > No - there is just 1 domain. It doesn't matter what transport,
> > protocol or client you use.
> >
> >
> >> I may be mistaken, but it seems that ActiveMQ default connector and
> stomp
> >> connector have their
> >> own destination space.
> >
> > I'm afraid you are mistaken :)
> >
> >
> >> My understanding was message sent a
> >> destination(queue, topic) will be
> >> delivered to consumers of thsoe destination(queue, topic), irrespective
> >> of
> >> how they connected
> >> to activemq or which server(default, stomp) they connected to.
> >>
> >> May be someone in the deveolpment team could tell us some of the design
> >> points regarding these
> >> issues. Well, it is late at night...I will stop now.
> >
> > The most likely reason is mismatch in the JMS destination names and
> > the ones used in the Stomp protocol. The quickest way to disagnose the
> > issue is to start with queues, then use the JMX console to look at the
> > destination names being used by Java and Perl clients to check you've
> > got the naming conventions correct etc.
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Alternatives-to-stomp-tf2439624.html#a6896969
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Alternatives to stomp
Posted by James Strachan <ja...@gmail.com>.
Great! Thanks for letting us know!
On 10/19/06, sileshi <si...@yahoo.com> wrote:
>
> I now know the reason why Java JMS client message I was sending to
> Perl Stomp client did not get to Perl side. The reason is the Java JMS
> client sending Bytes message and The Net::Stomp module's receive_frame()
> could not read the socket. Everytime it reads zero length bytes.
>
> But if I sent Text message from the JMS client, no problem.
> Thanks for the help.
>
> -Sileshi
>
>
> James.Strachan wrote:
> >
> > On 10/16/06, sileshi <si...@yahoo.com> wrote:
> >>
> >> The two weeks I have been working on Stomp, I have found it simple and
> >> powerful messaging protocol.
> >> It is an http of the messaging domain. After saying that, I'm a bit
> >> disappointed by ActiveMQ stomp
> >> server implementation, but like Hiram said that could be fixed.
> >>
> >> For those who use Stomp on Perl, I highly recommend the Net::Stomp 0.31
> >> perl
> >> module from CPAN.
> >> I have the same issues regarding JMX info about Enqueued and Dequeued
> >> message being incorrect
> >> and sometimes confusing. But the biggest problem I have with it is that
> >> when
> >> I mix Java and Perl producers/consumers, it seems no message is being
> >> passed
> >> from Java client to Perl or the other way.
> >> If I use producer/consumer Perl-to-Perl or Java-to-Java, no problem, but
> >> if
> >> I mix, no message gets delivered.
> >>
> >> Unless I miss something, the default server and stomp server are separate
> >> domains and message arrived
> >> to a topic on default server, can not be delivered to subscribers of
> >> stomp
> >> side of the same topic.
> >
> > No - there is just 1 domain. It doesn't matter what transport,
> > protocol or client you use.
> >
> >
> >> I may be mistaken, but it seems that ActiveMQ default connector and stomp
> >> connector have their
> >> own destination space.
> >
> > I'm afraid you are mistaken :)
> >
> >
> >> My understanding was message sent a
> >> destination(queue, topic) will be
> >> delivered to consumers of thsoe destination(queue, topic), irrespective
> >> of
> >> how they connected
> >> to activemq or which server(default, stomp) they connected to.
> >>
> >> May be someone in the deveolpment team could tell us some of the design
> >> points regarding these
> >> issues. Well, it is late at night...I will stop now.
> >
> > The most likely reason is mismatch in the JMS destination names and
> > the ones used in the Stomp protocol. The quickest way to disagnose the
> > issue is to start with queues, then use the JMX console to look at the
> > destination names being used by Java and Perl clients to check you've
> > got the naming conventions correct etc.
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Alternatives-to-stomp-tf2439624.html#a6896969
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Alternatives to stomp
Posted by sileshi <si...@yahoo.com>.
I now know the reason why Java JMS client message I was sending to
Perl Stomp client did not get to Perl side. The reason is the Java JMS
client sending Bytes message and The Net::Stomp module's receive_frame()
could not read the socket. Everytime it reads zero length bytes.
But if I sent Text message from the JMS client, no problem.
Thanks for the help.
-Sileshi
James.Strachan wrote:
>
> On 10/16/06, sileshi <si...@yahoo.com> wrote:
>>
>> The two weeks I have been working on Stomp, I have found it simple and
>> powerful messaging protocol.
>> It is an http of the messaging domain. After saying that, I'm a bit
>> disappointed by ActiveMQ stomp
>> server implementation, but like Hiram said that could be fixed.
>>
>> For those who use Stomp on Perl, I highly recommend the Net::Stomp 0.31
>> perl
>> module from CPAN.
>> I have the same issues regarding JMX info about Enqueued and Dequeued
>> message being incorrect
>> and sometimes confusing. But the biggest problem I have with it is that
>> when
>> I mix Java and Perl producers/consumers, it seems no message is being
>> passed
>> from Java client to Perl or the other way.
>> If I use producer/consumer Perl-to-Perl or Java-to-Java, no problem, but
>> if
>> I mix, no message gets delivered.
>>
>> Unless I miss something, the default server and stomp server are separate
>> domains and message arrived
>> to a topic on default server, can not be delivered to subscribers of
>> stomp
>> side of the same topic.
>
> No - there is just 1 domain. It doesn't matter what transport,
> protocol or client you use.
>
>
>> I may be mistaken, but it seems that ActiveMQ default connector and stomp
>> connector have their
>> own destination space.
>
> I'm afraid you are mistaken :)
>
>
>> My understanding was message sent a
>> destination(queue, topic) will be
>> delivered to consumers of thsoe destination(queue, topic), irrespective
>> of
>> how they connected
>> to activemq or which server(default, stomp) they connected to.
>>
>> May be someone in the deveolpment team could tell us some of the design
>> points regarding these
>> issues. Well, it is late at night...I will stop now.
>
> The most likely reason is mismatch in the JMS destination names and
> the ones used in the Stomp protocol. The quickest way to disagnose the
> issue is to start with queues, then use the JMX console to look at the
> destination names being used by Java and Perl clients to check you've
> got the naming conventions correct etc.
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
View this message in context: http://www.nabble.com/Alternatives-to-stomp-tf2439624.html#a6896969
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Alternatives to stomp
Posted by James Strachan <ja...@gmail.com>.
On 10/16/06, sileshi <si...@yahoo.com> wrote:
>
> The two weeks I have been working on Stomp, I have found it simple and
> powerful messaging protocol.
> It is an http of the messaging domain. After saying that, I'm a bit
> disappointed by ActiveMQ stomp
> server implementation, but like Hiram said that could be fixed.
>
> For those who use Stomp on Perl, I highly recommend the Net::Stomp 0.31 perl
> module from CPAN.
> I have the same issues regarding JMX info about Enqueued and Dequeued
> message being incorrect
> and sometimes confusing. But the biggest problem I have with it is that when
> I mix Java and Perl producers/consumers, it seems no message is being passed
> from Java client to Perl or the other way.
> If I use producer/consumer Perl-to-Perl or Java-to-Java, no problem, but if
> I mix, no message gets delivered.
>
> Unless I miss something, the default server and stomp server are separate
> domains and message arrived
> to a topic on default server, can not be delivered to subscribers of stomp
> side of the same topic.
No - there is just 1 domain. It doesn't matter what transport,
protocol or client you use.
> I may be mistaken, but it seems that ActiveMQ default connector and stomp
> connector have their
> own destination space.
I'm afraid you are mistaken :)
> My understanding was message sent a
> destination(queue, topic) will be
> delivered to consumers of thsoe destination(queue, topic), irrespective of
> how they connected
> to activemq or which server(default, stomp) they connected to.
>
> May be someone in the deveolpment team could tell us some of the design
> points regarding these
> issues. Well, it is late at night...I will stop now.
The most likely reason is mismatch in the JMS destination names and
the ones used in the Stomp protocol. The quickest way to disagnose the
issue is to start with queues, then use the JMX console to look at the
destination names being used by Java and Perl clients to check you've
got the naming conventions correct etc.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Alternatives to stomp
Posted by sileshi <si...@yahoo.com>.
The two weeks I have been working on Stomp, I have found it simple and
powerful messaging protocol.
It is an http of the messaging domain. After saying that, I'm a bit
disappointed by ActiveMQ stomp
server implementation, but like Hiram said that could be fixed.
For those who use Stomp on Perl, I highly recommend the Net::Stomp 0.31 perl
module from CPAN.
I have the same issues regarding JMX info about Enqueued and Dequeued
message being incorrect
and sometimes confusing. But the biggest problem I have with it is that when
I mix Java and Perl producers/consumers, it seems no message is being passed
from Java client to Perl or the other way.
If I use producer/consumer Perl-to-Perl or Java-to-Java, no problem, but if
I mix, no message gets delivered.
Unless I miss something, the default server and stomp server are separate
domains and message arrived
to a topic on default server, can not be delivered to subscribers of stomp
side of the same topic.
I have filed bug report: AMQ-978 to address the issue. ActiveMQ is a great
messaging middleware, and
should address this concerns when it touches the core of its functionality.
A message from any source,
using any protocol, transport, or language should be delivered to all
listeners of that message topic or
queue.
I may be mistaken, but it seems that ActiveMQ default connector and stomp
connector have their
own destination space. My understanding was message sent a
destination(queue, topic) will be
delivered to consumers of thsoe destination(queue, topic), irrespective of
how they connected
to activemq or which server(default, stomp) they connected to.
May be someone in the deveolpment team could tell us some of the design
points regarding these
issues. Well, it is late at night...I will stop now.
Hiram Chirino wrote:
>
> I would highly recommend we focus on fixing any stomp issues that may be
> left since it's like 500% easier to understand than the openwire versions.
>
> On 10/14/06, snacktime <sn...@gmail.com> wrote:
>>
>> Ok I found the C source. What's not easy to see though is the message
>> structure. Is there a way to have activemq log raw messages?
>>
>> Chris
>>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
>
--
View this message in context: http://www.nabble.com/Alternatives-to-stomp-tf2439624.html#a6827990
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Alternatives to stomp
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I would highly recommend we focus on fixing any stomp issues that may be
left since it's like 500% easier to understand than the openwire versions.
On 10/14/06, snacktime <sn...@gmail.com> wrote:
>
> Ok I found the C source. What's not easy to see though is the message
> structure. Is there a way to have activemq log raw messages?
>
> Chris
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Alternatives to stomp
Posted by snacktime <sn...@gmail.com>.
Ok I found the C source. What's not easy to see though is the message
structure. Is there a way to have activemq log raw messages?
Chris
Re: Alternatives to stomp
Posted by snacktime <sn...@gmail.com>.
On 10/13/06, Rob Davies <ra...@gmail.com> wrote:
> This is a community project - If something's "useless" - you could
> always jump in and help :)
If I had any java skills I absolutely would. As a matter of fact it
looks like a lot of activemq is very solid, just not stomp(:
I was also looking to see how the openwire protocol works, but the
links on the website are broken, and the openwire c/c++ stuff isn't in
the source distribution for the latest RC. Is openwire text based,
binary, serialized to a specific format, or what? Where is the best
place to get a handle on the openwire protocol?
Chris
Re: Alternatives to stomp
Posted by Rob Davies <ra...@gmail.com>.
This is a community project - If something's "useless" - you could
always jump in and help :)
cheers,
Rob
On 14 Oct 2006, at 01:13, Matt Chambers wrote:
>
>
> I agree. As far as I can tell, there is no decent python/perl/ruby
> <-> JMS system out there. Stomp
> is useless.
>
> snacktime wrote:
>> Stomp support is broken. I can't see how anyone would be using it
>> with
>> activemq given what I've encountered when using it. Frankly, it
>> should be
>> taken off the list of supported methods of connecting until
>> someone fixes
>> it, so others don't waste hours of time like I did only to find
>> bug after
>> bug. At least that's my 2 cents..
>> In any case, what would be the next best option for connecting to
>> activemq
>> from perl or ruby? Are the REST connectors stable?
>>
>> Chris
>> Payment Online Inc
>
>
> --
> *Matt Chambers <ch...@imageworks.com>*
> *Sony Pictures Imageworks*
> Software Engineer
>
Re: Alternatives to stomp
Posted by Matt Chambers <ch...@imageworks.com>.
I agree. As far as I can tell, there is no decent python/perl/ruby <->
JMS system out there. Stomp
is useless.
snacktime wrote:
> Stomp support is broken. I can't see how anyone would be using it with
> activemq given what I've encountered when using it. Frankly, it should be
> taken off the list of supported methods of connecting until someone fixes
> it, so others don't waste hours of time like I did only to find bug after
> bug. At least that's my 2 cents..
>
> In any case, what would be the next best option for connecting to activemq
> from perl or ruby? Are the REST connectors stable?
>
> Chris
> Payment Online Inc
>
--
*Matt Chambers <ch...@imageworks.com>*
*Sony Pictures Imageworks*
Software Engineer