search

stompgem / stomp

A ruby gem for sending and receiving messages from a Stomp protocol compliant message queue. Includes: failover logic, ssl support.
http://stomp.github.com
Apache License 2.0
152 stars 80 forks source link

Default to version 1.1 if none is returned by the server #41

Closed dbroeglin closed 12 years ago

dbroeglin commented 12 years ago

HornetQ's stomp implementation does not return the "version" header, this hack ensures the @protocol instance variable is always set to something that makes sense and allows the gem to work with HornetQ. I already opened a bug with them but in the meantime this should solve the issue.

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

gmallard commented 12 years ago

Sorry, can not accept that. Consider:

Your patch would allow that connection to actually succeed, resulting in:

I suggest either:

a) Rethink how that might be handled considering the above, and rewrite it b) Just patch the gem locally, and wait for the HornetQ folks to fix their server

If you have any flexibility on the server in use, I suggest taking a look at Apollo. The 1.1 support is excellent.

dbroeglin commented 12 years ago

Hello!

You are right, if I understand you right, the lack of "version" header should be interpreted by the client as a 1.0 server, is that correct ?

If so, that's too bad. I cannot see a simple way around the issue. The simplest I can see would be something resembling:

@protocol = cfh[:version] || @parameters[:"forced-version"]

and then when I initialize the connection pass the "forced-version" with the initialization hash. It would be passed to the server and it would be the user of the connection's choice not the stomp gem's.

Would that make more sense ?

Best regards, Dominique

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

Sorry, can not accept that. Consider:

  • I Send a 1.1 connect sequence to Active MQ by mistake (wrong port)
  • I get a Stomp::Error::UnsupportedProtocolError

Your patch would allow that connection to actually succeed, resulting in:

  • A client operating in 1.1 mode
  • Connected to a server that does not support 1.1

I suggest either:

a) Rethink how that might be handled considering the above, and rewrite it b) Just patch the gem locally, and wait for the HornetQ folks to fix their server

If you have any flexibility on the server in use, I suggest taking a look at Apollo. The 1.1 support is excellent.

Reply to this email directly or view it on GitHub: https://github.com/stompgem/stomp/pull/41#issuecomment-5658070

gmallard commented 12 years ago

Hi Dominique - Yes, lack of a "version" header in a server CONNECTED reply must be interpreted as a 1.0 server. The specifications:

http://stomp.github.com/

imply that.

If the client has requested a 1.1 connection to a 1.0 server, that is a (hard) error. This behavior matches the intent of the specs.

You are essentially asking the gem to provide a hack to 'get around' a fault in some unknown version of HornetQ.

If the HornetQ version claims support of 1.1, and is not returning a "version" header, they are clearly out of spec for 1.1. They need to fix this. Then we have no problem.

I think you should pressure HornetQ to provide real 1.1 compatibility.

I am very close to just saying 'no' to this request. The HornetQ folks need to fix this. I advise you to use an Apollo or RabbitMQ server at present.

I am willing to consider a hack like this if:

In short, any suggested hack MUST be very robust, non-intrusive and well documented.

Regards, Guy

gmallard commented 12 years ago

I ran some connection tests with HornetQ 2.2.5 final this morning.

I see zero evidence that HornetQ actually supports the 1.1 protocol level. None of the required headers are returned in a CONNECTED frame.

The gem will not support erroneous logic about the protocol level.

You have identified an interesting bug in this gem. Please contribute by fixing:

https://github.com/stompgem/stomp/issues/44

Regards, Guy