-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERROR msg with stomp 1.1 #42
Comments
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:
|
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 :
(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, On May 11, 2012, at 8:08 PM, 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 |
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:
Regards, Guy |
You have pointed out a shortcoming. If you wish to contribute, and I hope you do, try to implement a fix for: Regards, Guy |
Hello Guy! On May 12, 2012, at 4:47 AM, Guy M. Allard wrote:
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,
|
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, On May 12, 2012, at 4:16 AM, Guy M. Allard wrote:
|
Hi Dominique - I appreciate your possible need for a client with 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 This gem first appeared in 2005. Since then, there have been 5-6 a) pushing that to the gem's user community would very likely break a Stomp 1.1 is actually very new. The specification was approved not much http://groups.google.com/group/stomp-spec Agreed that something is not quite correct with HornetQ, at least for I know nothing about Torquebox, but would guess that it is perfectly A side comment on predefined queues in a message broker: imagine an Regards, Guy On 05/15/2012 02:22 AM, Dominique Broeglin wrote:
|
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. |
Hello Guy! On May 15, 2012, at 9:35 PM, Guy M. Allard wrote:
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.
I understand that.
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.
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.
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,
|
This is more a question than a bug report.
When I send a message to a wrong queue, the server answer's back an ERROR frame. However, this is never returned to the caller as the publish method just does a transmit and does not read back the server answers. Is this the expected behavior ? If so, how can one access the information that the message was not delivered ?
The text was updated successfully, but these errors were encountered: