questions: stomp connection settings

thedebugger commented 10 years ago

Some of the connection settings are un-clear in the documentation

if :hbser => true, then how would client get this exception? During message publish?
if heart-beat = 5,10 (assuming client and server has acknowledged it) then is there a use for :max_hbread_fails? Coz, client can find out if the server is not responding b/w 5 sec window.
I'm un-clear what this flag do - :max_hbrlck_fails?

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?

gmallard commented 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:

troubleshooting a notoriously poor connection
helpful debugging information if the heartbeat logic is being changed/modified

If you have a valid use case for it in normal application operation, I would like to hear the details.

gmallard commented 10 years ago

heart-beat=5,10 give a 5 millisecond window, not 5 seconds. The following connect parameters:

:max_hbread_fails
:max_hbrlck_fails

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:

https://gist.github.com/gmallard/9257145

gmallard commented 10 years ago

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:

You are a large user of the gem, and have been for many years
All of your code is written for spec level 1.0
You do not have people or money resources to upgrade your client code to 1.1 or 1.2
You are using ActiveMQ as a broker
Suddenly the gem suddenly starts sending '1.0,1.1,1.2' connect headers
The resulting connection will be 1.2 level
Most of your SUBSCRIBEs will likely fail with a broker ERROR frame
All of your UNSUBSCRIBEs will certainly fail with a broker ERROR frame
And perhaps other broker errors as well

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.

thedebugger commented 10 years ago

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?

gmallard commented 10 years ago

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:

http://stomp.github.io/

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.

pic commented 10 years ago

@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

gmallard commented 10 years ago

@pic please post short examples that prove your supposition.

I sincerely doubt that it is correct.

Thanks.

pic commented 10 years ago

@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?

PaulGale commented 10 years ago

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.

pic commented 10 years ago

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

gmallard commented 10 years ago

Closed. No program changes required for this.

stompgem / stomp

questions: stomp connection settings #94