Closed thedebugger closed 10 years ago
Let me take those one at a time. :hbser => true would not be seen during a message publish. The only place it is used is in the heartbeat sender routine.
Setting that to true is really a debugging / trouble shooting option. Primary usefulness is:
If you have a valid use case for it in normal application operation, I would like to hear the details.
heart-beat=5,10 give a 5 millisecond window, not 5 seconds. The following connect parameters:
were added between versions 1.2.9 and 1.2.10.
They both exist in logic which allows proper and functional fail over attempts to be initiated from the heartbeat threads. This was all done in May of 2013 or so.
Gem versions 1.2.9 and previous did not support failovers from the heartbeat threads.
For some details, see:
Yes, the gem is pure 1.0 unless you the client ask for something different. It is intentional, and it can not change for a several reasons.
Unclear why you would use wireshark to figure that out. Broker logs should be sufficient.
Indeed this may not be documented well unless you read example code and gem code. It is noted in some example comments. I will look at a documentation update if you wish to provide one.
Consider this situation:
And that ignores how the gem could possibly guess what to send for a broker vhost value.
A default of 1.0 is a backwards compatibility consideration, for clients and brokers.
Thanks for answering all the queries. That helps.
My understanding is that the clients are mostly abstracted from the protocol. Right? Unclear why would subscribe will fail if the client and server both are on 1.2. I guess I've to read the spec more closely. However, if there are breaking changes old clients have an option to set the version to 1.0 and everything works as expected.
I think, by default, stomp gem should send all the supported versions and defaults to 1.2 (if broker supports 1.2). If you are not using 1.2 or 1.1., you can't use stomp over WAN as load balancers will drop tcp connection after every few seconds of in-activity. And, the old clients can choose to stay on 1.0 by setting the accept-version to only 1.0 explicitly.
Thoughts?
The abstraction is minimal. You the client programmer need to understand the protocol (and the specification details).
Old clients can not change their code to use 1.0, as stated in my previous message. They do not have people or money to do that.
There is no way for the gem to 'know' what a particular broker supports
and what it does not until a CONNECTED frame is received from the
broker. The protocol is already established at that point in time.
Read the spec sections on protocol negotiation.
Please read in detail all three versions of the specification, available here:
And see my inline comments below .....
On 02/27/2014 04:00 PM, Sumit Vij wrote:
Thanks for answering all the queries. That helps.
My understanding is that the clients are mostly abstracted from the protocol. Right?
No. Programmers are expected to know and understand the protocol levels, and the differences between them. And to write client code appropriately.
Unclear why would subscribe will fail if the client and server both are on 1.2. I guess I've to read the spec more closely. However, if there are breaking changes old clients have an option to set the version to 1.0 and everything works as expected. I think, by default, stomp gem should send all the supported versions and defaults to 1.2 (if broker supports 1.2).
The client is not in your example. It is on 1.0, no code changes. But the broker thinks 1.2. Look at the required headers for SUBSCRIBE, UNSUBSCRIBE, ACK, and NACK. They are different for all three protocol versions.
Before a CONNECT / CONNECTED request and response how would the gem know what the broker supports and what it does not? How would the gem know what host name to use in the required 'host' header?
If you are not using 1.2 or 1.1., you can't use stomp over WAN as load balancers will drop tcp connection after every few seconds of in-activity.
That statement is incorrect. There are a number of gem clients that do exactly that: use stomp 1.0 over the WAN. The gem existed and was in world wide use long before STOMP 1.1 or 1.2 existed. If your load balancers are dropping connections after a 'few seconds' they are not configured correctly. ..... How would for browsers or e-mail clients work if WAN connections got dropped after a few idle seconds?
And, the old clients can choose to stay on 1.0 by setting the accept-version to only 1.0 explicitly.
They can not change their code, for reasons stated.
Thoughts?
— Reply to this email directly or view it on GitHub https://github.com/stompgem/stomp/issues/94#issuecomment-36290801.
@gmallard it seems to me that heartbeats are enabled only if version 1.0 of the protocol is used: https://github.com/stompgem/stomp/blob/dev/lib/connection/utils.rb#L86
but my understanding of the specification is that heartbeat is part of version 1.1 and 1.2 of STOMP.
Could you please clarify? Thx
@pic please post short examples that prove your supposition.
I sincerely doubt that it is correct.
Thanks.
@gmallard
sorry, it is a different different "problem".
The point is that it is necessary to specify the :host parameter, this works:
{
:hosts => [
{
:host => "127.0.0.1",
:port => 61613,
}
],
:connect_headers => {
"accept-version" => "1.1",
'heart-beat' => "15000,0",
'max_hbrlck_fails' => 10,
'host' => 'stomp://127.0.0.1:61613'
}
}
but this
{
:hosts => [
{
:host => "127.0.0.1",
:port => 61613,
}
],
:connect_headers => {
"accept-version" => "1.1",
'heart-beat' => "15000,0",
'max_hbrlck_fails' => 10
}
}
raises "STOMP 1.1+ CONNECT error, missing/incorrect CONNECT headers" which misled me. Could not the :host parameter be derived from :hosts if missing?
The host
header in the connnect_headers
hash is used by the client to identify a virtual host it wishes to connect to. Does the broker you're connecting to support virtual hosting? It not, set the value of this header to be anything you want as its value won't matter; it just cannot be empty.
See the STOMP 1.1 spec for more details.
I do not need virtual hosting and I can set it to any value. It is a bit confusing because I have not noticed that it was required until I tried to enable heartbeat. Thanks
Closed. No program changes required for this.
Some of the connection settings are un-clear in the documentation
The other weird thing about is that by default gem uses Stomp 1.0 even if the server supports 1.0 or higher. After tracing using wireshirk, client doesn't send accept-header unless you manually add it into the connection hash, and there is no documentation for it as well. I don't understand why stomp gem can't send all the versions in accept-version header? I can fix it and submit a pull request but just wanted to check if that is intentional? And why?