-
1. Re: STOMP 1.1 Support
clebert.suconic Oct 21, 2010 2:12 PM (in response to b2102095)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.
-
2. Re: STOMP 1.1 Support
gurkapa Jan 18, 2011 8:43 PM (in response to clebert.suconic)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.
-
hornetq-553-p1.zip 19.2 KB
-
-
3. Re: STOMP 1.1 Support
timfox Jan 19, 2011 3:49 AM (in response to gurkapa)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.
-
4. STOMP 1.1 Support
gurkapa Jan 21, 2011 3:07 AM (in response to timfox)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?
-
5. STOMP 1.1 Support
clebert.suconic Jan 21, 2011 11:40 AM (in response to gurkapa)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.
-
6. STOMP 1.1 Support
clebert.suconic Jan 24, 2011 9:06 PM (in response to gurkapa)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
-
7. STOMP 1.1 Support
clebert.suconic Jan 29, 2011 2:35 PM (in response to 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?
-
8. STOMP 1.1 Support
gurkapa Jan 31, 2011 5:37 AM (in response to clebert.suconic)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.
-
9. STOMP 1.1 Support
clebert.suconic Jan 31, 2011 10:44 PM (in response to gurkapa)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.
-
10. Re: STOMP 1.1 Support
gurkapa Feb 16, 2011 11:47 PM (in response to clebert.suconic)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?
-
11. Re: STOMP 1.1 Support
clebert.suconic Feb 21, 2011 11:29 AM (in response to gurkapa)Sorry, I couldn't really understand it.
can you explain what that means? :-)
-
12. Re: STOMP 1.1 Support
gurkapa Apr 26, 2011 9:15 AM (in response to clebert.suconic)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 =)