STOMP 1.1 Support

[b2102095]

There seems to be good progress with the STOMP 1.1 specification at

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

I did not see STOMP 1.1 in the HornetQ roadmap, any info on timescales?

Cheers,

Tim

[clebert.suconic]

https://jira.jboss.org/browse/HORNETQ-553

Tim Fox had an issue created last week. I didn't schedule it for a mistake only.

Do you have any experience with the protocol? That would be a nice area for a contribution if you are interested.

[gurkapa]

Hi everyone. I've been emailing with Clebert for a while about tasks to do in order to join you guys as a contributer and I've started by working on the STOMP 1.1 implementation.

I sent a patch to Clebert this weekend but I'm posting it here to as per his instructions. This is the mail I sent to him, I would really like som feedback before I proceed with more new functionality:

Ok here comes another zip with changes. This has quite a few changes

so i would really appreciate some code review and feedback on the

changes.

Basically it's the first part of changes for issue

https://issues.jboss.org/browse/HORNETQ-553 (implement stomp 1.1) and

what I've added is commands, headers and functionality for the CONNECT

command, and the version negotiation that should now take place there.

I've also added tests to confirm these changes. Here's a direct link

to the specification describing the protocol changes:

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

My plan is to take a stab on the heart-beating next but as I said I

would really appreciate some feedback on the code.

[timfox]

Good stuff

I think STOMP is going to be an increasingly important protocol going forward.

Also, If you can get STOMP to the same performance as our core protocol that would be a big win.

[gurkapa]

I'll see what I can do =)

As I said in previous post I'm taking a stab at the heart-beating functionality in 1.1 now (specification for it can be found here: http://stomp.github.com/stomp-specification-1.1.html#Heart-beating ) and since the entire thing is more or less optional I would like some input on what HornetQ should support. The questions that need answers are:

Should we allow clients to send heart-beats to us? If yes, how many miliseconds do we want between heart-beats?

Should we have functionality to send heart-beats to clients? If yes, what should we say is the smallest number of milliseconds between heart-beats that we can guarantee?

[clebert.suconic]

It would be great to have the heart-beat in. We could translate our PINGs and PONGs as heart beating on the protocol, and we would then gradually have the same guarantees we already have with the native protocol.

We should translate the TTLs parameters into what's needed by STOMP.

[clebert.suconic]

Roger Strom: Welcome as a committer! Just added you to the list.

Can you do this work on a separate branch? /branches/stomp_1_1

We (that could include you as well) can merge it after it's done.

Thanks,

Clebert

[clebert.suconic]

Roger: I see that you did a commit a few days ago...

Feel free to ask for any help if you are stuck with the code/architecture or anything. We can even talk through IRC.

How's going?

[gurkapa]

The commit I made contained the changes in the patch I posted above (in a new branch for the stomp 1.1 implementation).

I kind of got stuck trying to figure out what way I should go with the heart beating (and then I've been out of town for a while as well). The problem as I see it is that the core protocols ping's are configured with the ttl. In the case of STOMP though the time for recieving and sending heart beats are negotiated between the server and the client and my issue is that I'm not really sure if I want to change the ttl value in the ConnectionEntry, and if I do I'm not really sure what would be the nicest way to do this.

I don't know if the section above makes any sense, if not maybe we could try to schedule some time on IRC.

[clebert.suconic]

if the Stomp supports the heart bit negotiation at the client instead of being defined at the server, I guess you need to change the ConnectionEntry.

The core protocol also defined the heart bit at the client-side. So, it shouldn't be an issue.

We can talk over IRC at any time. you can look for me, AndyTaylor or Howard online on IRC at any time.

[gurkapa]

I commited heart beat changes to the stomp_1_1 branch a while ago and moving along the list of changes introduced in the 1.1 specification I came across this section regarding the CONNECT frame. It's a new header that is required and called "host"

host : The name of a virtual host that the client wishes to connect to. It is recommended clients set this to the host name that the socket was established against, or to any name of their choosing. If this header does not match a known virtual host, servers supporting virtual hosting MAY select a default virtual host or reject the connection.

This leaves some choises for the implementation, any thoughts on how we should treat it?

[clebert.suconic]

Sorry, I couldn't really understand it.

can you explain what that means? :-)

[gurkapa]

Sorry for disappearing for a while, had a lot of work and traveling to do, but things are looking up so I'll try to get back on this.

And regarding the host header above I'll try to clarify what I meant a little =)

Since the specification says "servers supporting virtual hosting MAY select a default virtual host or reject the connection." it kind of allows the server implimentation to do nothing or have a bunch of logic around handling the header. At least the way I see it.

But I'm not really sure if/how HornetQ in general supports virtual hosting, so if someone could shed some light on that matter for me that would be some great help.

Sorry if this still makes no sense =)