ERROR msg with stomp 1.1 about stomp

[gmallard]

Publish should / can not read anything back. That is attempting to make STOMP into a totally synchronous protocol, which it is not.

Are you using a Connection interface (not a Client)?? Sounds like it ..... if so, periodically do something like:

msg = conn.poll # Returns nil if there is nothing to receive, otherwise a message frame
if msg
    if msg.command == "ERROR"
        raise "kaboom #{msg.inspect}"
    end
end

[dbroeglin]

Hello!

I see your point about publish being asynchronous, but it is not exactly what I meant to ask. I stumbled on the issue by making a mistake in my queue name. Basically I just do a :

c.publish('wrong_queue_name', 'message')

with c being either a client or a connection. In that case, the queue being wrong, HornetQ sends back an ERROR frame with a message header indicating that I do not have access to wrong_queue_name. Which seems consistent with the last line of the paragraph about the SEND frame in the specification:

http://stomp.github.com//stomp-specification-1.1.html#SEND :

If the sever cannot successfully process the SEND frame frame for any reason, the server MUST send the client an ERROR frame and disconnect the client.

(Except that the client does not get disconnected…)

However, publish just does a transmit and does not check the connection for the presence of an ERROR frame. The error is ignored silently. If I understand you correctly, shouldn't publish do a conn.poll after doing the transmit in order to be able to raise an exception about the fact that it was not able to successfully SEND the message to the broker ?

Sorry if I'm still beside the point. I'm willing to understand both STOMP and the stomp gem better so please bear with me :-)

Best regards,
Dominique

On May 11, 2012, at 8:08 PM, Guy M. Allard wrote:

Publish should / can not read anything back. That is attempting to make STOMP into a totally synchronous protocol, which it is not.

Are you using a Connection interface (not a Client)?? Sounds like it ..... if so, periodically do something like:

msg = conn.poll # Returns nil if there is nothing to receive, otherwise a message frame
if msg
   if msg.command == "ERROR"
       raise "kaboom #{msg.inspect}"
   end
end

---

Reply to this email directly or view it on GitHub:
#42 (comment)

[gmallard]

Hi Dominique - I think you are misinterpreting .... something(s) ....

In what you describe the SEND was successful. There were no network / transfer errors encountered during the write to the connection. The gem would report that to you, with an exception.

SEND has absolutely no relation to the notion of 'receive'. Note: the spec does not even define a 'RECEIVE' frame.

Your application client code is responsible for detecting any ERROR frames emitted by any server. That type of frame is relevant to the application, not the STOMP client library. (I think you will find this to be true regardless of which client library or language you are using: Ruby, Python, PERL, Java, C#, ....)

The server decided that you sent something erroneous (wrong queue name), and sent an ERROR frame. (Inadvisable STOMP server behavior IMO, but allowed for a server implementation per specs). It is not the client gem's responsibility to check for this. It is a result of erroneous code on your part and it is your responsibility to check for such errors.

You could send me a patch that implements #poll in Client and passed it to the underlying Connection. That probably needs to be done.

In short: you need to use #poll.

Regards, Guy

[gmallard]

Dominique - A side note.

My current understanding is that HornetQ requires that queue/topic names be predefined. That is the main reason I do not test against it. If you know a way of getting around this, please let me know.

Most servers will create a new queue on the fly with the new name and no ERROR. A list of these servers include:

• Active MQ
• Apollo
• RabbitMQ
• This beast: https://github.com/gmallard/stompserver_ng

Regards, Guy

[gmallard]

You have pointed out a shortcoming. If you wish to contribute, and I hope you do, try to implement a fix for:

#43

Regards, Guy

[dbroeglin]

Hello Guy!

On May 12, 2012, at 4:47 AM, Guy M. Allard wrote:

My current understanding is that HornetQ requires that queue/topic names be predefined. That is the main reason I do not test against it. If you know a way of getting around this, please let me know.

From what I know you are right, that's exactly how it works. You can create or drop queues through the management API but I do not think it is doable through STOMP. However, to me it's a security feature not really a lack of feature.

Best regards,
Dominique

Most servers will create a new queue on the fly with the new name and no ERROR. A list of these servers include:

• Active MQ
• Apollo
• RabbitMQ
• This beast: https://github.com/gmallard/stompserver_ng

Regards, Guy

---

Reply to this email directly or view it on GitHub:
#42 (comment)

[dbroeglin]

Hi Guy!

I read carefully what you said, I think I get your point of view. However, I respectfully disagree as to the role of the Stomp client. The way I see it the application should not be bothered with the details of the protocol implementation. If an error occurs the application should not be required to understand the STOMP protocol in order to know that an error has occurred it should just get an exception or an error code. I guess I was spoiled by more high-level APIs like JMS which abstract you from the underlying protocol...

Unfortunately I do not have enough time on my hands to really dig into the subject of STOMP, the stomp gem and HornetQ. HornetQ is a requirement for me because I use torque box which has it built in. From inside Torquebox everything works fine. I agree that there is something fishy going on with the way the STOMP protocol behaves in HornetQ. I skimmed the code and it seems to implement the version header perfectly well.

For now I will see with the HornetQ people what I'm probably doing wrong and try some other client libraries. If all this fails I might come back to you with a patch.

Anyway, thanks a lot for your help it is much appreciated.

Best regards,
Dominique

On May 12, 2012, at 4:16 AM, Guy M. Allard wrote:

Hi Dominique - I think you are misinterpreting .... something(s) ....

In what you describe the SEND was successful. There were no network / transfer errors encountered during the write to the connection. The gem would report that to you, with an exception.

SEND has absolutely no relation to the notion of 'receive'. Note: the spec does not even define a 'RECEIVE' frame.

Your application client code is responsible for detecting any ERROR frames emitted by any server. That type of frame is relevant to the application, not the STOMP client library. (I think you will find this to be true regardless of which client library or language you are using: Ruby, Python, PERL, Java, C#, ....)

The server decided that you sent something erroneous (wrong queue name), and sent an ERROR frame. (Inadvisable STOMP server behavior IMO, but allowed for a server implementation per specs). It is not the client gem's responsibility to check for this. It is a result of erroneous code on your part and it is your responsibility to check for such errors.

You could send me a patch that implements #poll in Client and passed it to the underlying Connection. That probably needs to be done.

In short: you need to use #poll.

Regards, Guy

---

Reply to this email directly or view it on GitHub:
#42 (comment)

[gmallard]

Hi Dominique - I appreciate your possible need for a client with
different behavior.

You might take a look at:

https://github.com/meadvillerb/onstomp.git

I do not know whether Ian supports what you require or not, but he
certainly provides an interesting client implementation.

This gem first appeared in 2005. Since then, there have been 5-6
project leads. None have attempted support for error reporting by the
library from a SEND as far as the gem history shows. I'm sure not going
to do it now for two reasons:

a) pushing that to the gem's user community would very likely break a
bunch of production code.
b) it would put the gem 'out of spec', as the specification does not
mention it for client libraries, much less require it.

Stomp 1.1 is actually very new. The specification was approved not much
more than a year ago. If you want to join in future discussions, please
see:

http://groups.google.com/group/stomp-spec

Agreed that something is not quite correct with HornetQ, at least for
Stomp 1.1. I pulled down 2.2.14-Final, and still do not see any 1.1
required headers on a CONNECTED frame. Odd because 1.1 support is well
advertised in their site. I tried to find documentation for some
configuration parameter that indicated "must use 1.1", but could not
locate such. I saw your issue in JIRA. Let me know how that progresses
please.

I know nothing about Torquebox, but would guess that it is perfectly
content with a 1.0 protocol level.

A side comment on predefined queues in a message broker: imagine an
application requirement that queue creation date and time be part of the
queue name. I have no comment on good/poor design, but I have seen the
requirement for some applications. Seems difficult if not impossible to
do with HornetQ, and possibly other 'pure' JMS style brokers. Another
example: the formal tests for this gem usually put the test method name
in the queue name. Implementing new test methods would be onerous with
HornetQ.

Regards, Guy

On 05/15/2012 02:22 AM, Dominique Broeglin wrote:

Hi Guy!

I read carefully what you said, I think I get your point of view. However, I respectfully disagree as to the role of the Stomp client. The way I see it the application should not be bothered with the details of the protocol implementation. If an error occurs the application should not be required to understand the STOMP protocol in order to know that an error has occurred it should just get an exception or an error code. I guess I was spoiled by more high-level APIs like JMS which abstract you from the underlying protocol...

Unfortunately I do not have enough time on my hands to really dig into the subject of STOMP, the stomp gem and HornetQ. HornetQ is a requirement for me because I use torque box which has it built in. From inside Torquebox everything works fine. I agree that there is something fishy going on with the way the STOMP protocol behaves in HornetQ. I skimmed the code and it seems to implement the version header perfectly well.

For now I will see with the HornetQ people what I'm probably doing wrong and try some other client libraries. If all this fails I might come back to you with a patch.

Anyway, thanks a lot for your help it is much appreciated.

Best regards,
Dominique

On May 12, 2012, at 4:16 AM, Guy M. Allard wrote:

Hi Dominique - I think you are misinterpreting .... something(s) ....

In what you describe the SEND was successful. There were no network / transfer errors encountered during the write to the connection. The gem would report that to you, with an exception.

SEND has absolutely no relation to the notion of 'receive'. Note: the spec does not even define a 'RECEIVE' frame.

Your application client code is responsible for detecting any ERROR frames emitted by any server. That type of frame is relevant to the application, not the STOMP client library. (I think you will find this to be true regardless of which client library or language you are using: Ruby, Python, PERL, Java, C#, ....)

The server decided that you sent something erroneous (wrong queue name), and sent an ERROR frame. (Inadvisable STOMP server behavior IMO, but allowed for a server implementation per specs). It is not the client gem's responsibility to check for this. It is a result of erroneous code on your part and it is your responsibility to check for such errors.

You could send me a patch that implements #poll in Client and passed it to the underlying Connection. That probably needs to be done.

In short: you need to use #poll.

Regards, Guy

---

Reply to this email directly or view it on GitHub:

#42 (comment)

Reply to this email directly or view it on GitHub:
#42 (comment)

[gmallard]

So ... I just looked at updates to:

https://issues.jboss.org/browse/HORNETQ-923

and 1.1 support is actually ... in 2.2.16 .... in the Maven repo .... only ...

How interesting.

[dbroeglin]

Hello Guy!

On May 15, 2012, at 9:35 PM, Guy M. Allard wrote:

Hi Dominique - I appreciate your possible need for a client with
different behavior.

You might take a look at:

https://github.com/meadvillerb/onstomp.git

I do not know whether Ian supports what you require or not, but he
certainly provides an interesting client implementation.

Yes I took a quick look at it but I had a much bigger change in mind, meaning using JRuby and a java client library to HornetQ. Reliable delivery is really a huge requirement for me.

This gem first appeared in 2005. Since then, there have been 5-6
project leads. None have attempted support for error reporting by the
library from a SEND as far as the gem history shows. I'm sure not going
to do it now for two reasons:

a) pushing that to the gem's user community would very likely break a
bunch of production code.
b) it would put the gem 'out of spec', as the specification does not
mention it for client libraries, much less require it.

I understand that.

Stomp 1.1 is actually very new. The specification was approved not much
more than a year ago. If you want to join in future discussions, please
see:

http://groups.google.com/group/stomp-spec

Agreed that something is not quite correct with HornetQ, at least for
Stomp 1.1. I pulled down 2.2.14-Final, and still do not see any 1.1
required headers on a CONNECTED frame. Odd because 1.1 support is well
advertised in their site. I tried to find documentation for some
configuration parameter that indicated "must use 1.1", but could not
locate such. I saw your issue in JIRA. Let me know how that progresses
please.

At the end it seems that the blog was a little bit ahead of the releases. I got confused and thought the support for STOMP 1.1 was already in. Whereas, it will be only in the next release. Sorry for the misunderstanding.

I know nothing about Torquebox, but would guess that it is perfectly
content with a 1.0 protocol level.

Hum, in fact it goes more the way I suggested in the beginning of the mail. Because it's written on top of JRuby it can take advantage of the Java client whose semantics are richer.

A side comment on predefined queues in a message broker: imagine an
application requirement that queue creation date and time be part of the
queue name. I have no comment on good/poor design, but I have seen the
requirement for some applications. Seems difficult if not impossible to
do with HornetQ, and possibly other 'pure' JMS style brokers. Another
example: the formal tests for this gem usually put the test method name
in the queue name. Implementing new test methods would be onerous with
HornetQ.

Yes I see how this can be helpful. It could probably be implemented in HornetQ too (if it's not already present in the 1.1 code base) as long as you give enough rights to the user who is connecting to the server. It's just a matter of using the management function to create the queue if does not already exist. However, just out of curiosity, how would all those queues get deleted once they are not used anymore ? I did no see a way to do that in the STOMP protocol.

Incidentally, HornetQ also lacks support for temporary queues. Those are not really a part of the STOMP protocol but in activeMQ it is implemented as a naming convention on the queue names and I used it a lot. This one is much more bothersome for me as it kind of makes implementing a REQUEST/RESPONSE pattern much more cumbersome.

Anyway, thanks a lot for your help, I will continue to experiment with the stomp gem and the upcoming HornetQ/Torquebox releases and keep you posted on what transpires.

Best regards,
Dominique

Regards, Guy

On 05/15/2012 02:22 AM, Dominique Broeglin wrote:

Hi Guy!

I read carefully what you said, I think I get your point of view. However, I respectfully disagree as to the role of the Stomp client. The way I see it the application should not be bothered with the details of the protocol implementation. If an error occurs the application should not be required to understand the STOMP protocol in order to know that an error has occurred it should just get an exception or an error code. I guess I was spoiled by more high-level APIs like JMS which abstract you from the underlying protocol...

Unfortunately I do not have enough time on my hands to really dig into the subject of STOMP, the stomp gem and HornetQ. HornetQ is a requirement for me because I use torque box which has it built in. From inside Torquebox everything works fine. I agree that there is something fishy going on with the way the STOMP protocol behaves in HornetQ. I skimmed the code and it seems to implement the version header perfectly well.

For now I will see with the HornetQ people what I'm probably doing wrong and try some other client libraries. If all this fails I might come back to you with a patch.

Anyway, thanks a lot for your help it is much appreciated.

Best regards,
Dominique

On May 12, 2012, at 4:16 AM, Guy M. Allard wrote:

Hi Dominique - I think you are misinterpreting .... something(s) ....

In what you describe the SEND was successful. There were no network / transfer errors encountered during the write to the connection. The gem would report that to you, with an exception.

SEND has absolutely no relation to the notion of 'receive'. Note: the spec does not even define a 'RECEIVE' frame.

Your application client code is responsible for detecting any ERROR frames emitted by any server. That type of frame is relevant to the application, not the STOMP client library. (I think you will find this to be true regardless of which client library or language you are using: Ruby, Python, PERL, Java, C#, ....)

The server decided that you sent something erroneous (wrong queue name), and sent an ERROR frame. (Inadvisable STOMP server behavior IMO, but allowed for a server implementation per specs). It is not the client gem's responsibility to check for this. It is a result of erroneous code on your part and it is your responsibility to check for such errors.

You could send me a patch that implements #poll in Client and passed it to the underlying Connection. That probably needs to be done.

In short: you need to use #poll.

Regards, Guy

---

Reply to this email directly or view it on GitHub:

#42 (comment)

Reply to this email directly or view it on GitHub:
#42 (comment)

---

Reply to this email directly or view it on GitHub:
#42 (comment)