You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Dejan Bosanac <de...@ttmsolutions.com> on 2008/09/23 16:40:54 UTC

Stomp v1.1 Thoughts

Hi,

in a thread some time ago we discussed new features which could go into
version 1.1 of Stomp protocol.

Since I'm cross-posting this, I've summarized all these features in a
blog http://www.nighttale.net/stomp/stomp-v11-thoughts.html

It's basically an invitation to a discussion on whether we should go
with v1.1 or these should be implemented as ActiveMQ-related stuff.
Also, if some of you have items on the wish list, I would like to hear them.

Cheers

-- 
Dejan Bosanac


http://www.ttmsolutions.com - get a free ActiveMQ user guide

ActiveMQ in Action - http://www.manning.com/snyder/
Scripting in Java - http://www.scriptinginjava.net


Re: Stomp v1.1 Thoughts

Posted by Dejan Bosanac <de...@ttmsolutions.com>.
Added to wiki wishlist.

Thanks

-- 
Dejan Bosanac


http://www.ttmsolutions.com - get a free ActiveMQ user guide

ActiveMQ in Action - http://www.manning.com/snyder/
Scripting in Java - http://www.scriptinginjava.net



Hiram Chirino wrote:
> +1
>
> On Thu, Sep 25, 2008 at 4:22 AM, Dexter Tad-y <de...@yahoo.com> wrote:
>   
>> To add to the discussion, how about standardizing AMQ-1874 as part of the official Stomp specs. The patch is thankfully part of 5.2.0 now but of course this is ActiveMQ specific. It would be great if it becomes part of Stomp v1.1 and other Stomp brokers could follow suit.
>>
>>
>> --- On Wed, 9/24/08, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>
>>     
>>> From: Hiram Chirino <hi...@hiramchirino.com>
>>> Subject: Re: Stomp v1.1 Thoughts
>>> To: dev@activemq.apache.org
>>> Date: Wednesday, September 24, 2008, 9:25 PM
>>> On Wed, Sep 24, 2008 at 8:18 AM, Dejan Bosanac
>>> <de...@ttmsolutions.com> wrote:
>>>       
>>>>> How about you also put those ideas somewhere on
>>>>>           
>>> the wiki at:
>>>       
>>>>> http://stomp.codehaus.org/
>>>>>
>>>>>           
>>>> Done. Here's a page for this kind of material
>>>>
>>>> http://stomp.codehaus.org/Stomp+v1.1+Ideas
>>>>
>>>>         
>>>>> Some of the things I see missing in STOMP are:
>>>>> - Optional Keep Alive protocol.  Right now we have
>>>>>           
>>> to depend on the OS
>>>       
>>>>> to detect socket failure to time out a dead
>>>>>           
>>> client.  Would be nice if
>>>       
>>>>> the client could optionally agree to send a Keep
>>>>>           
>>> Alive commands when
>>>       
>>>>> the connection is idle.  That way the sever can
>>>>>           
>>> detect dead clients
>>>       
>>>>> quicker.
>>>>>
>>>>>           
>>>> I'd definitely keep this optional, since most
>>>>         
>>> Stomp clients implement
>>>       
>>>> just basic blocked reading of the socket (waiting for
>>>>         
>>> the next frame).
>>>       
>>>>> - Perhaps standardize a 'host' header in
>>>>>           
>>> the CONNECT frame to specify
>>>       
>>>>> the host name that the client is connecting to.
>>>>>           
>>> This would allow
>>>       
>>>>> implementing virtual hosting where multiple DNS
>>>>>           
>>> host entries point at
>>>       
>>>>> the same STOMP server.
>>>>>
>>>>>           
>>>> This would rock. I wonder how we could support virtual
>>>>         
>>> hosting in
>>>       
>>>> ActiveMQ ... Should it be done, by allocating a
>>>>         
>>> different path hierarchy
>>>       
>>>> for each host, so for example /queue/A on host1 would
>>>>         
>>> physically be
>>>       
>>>> queue://host1/A, etc?
>>>>
>>>>         
>>> Could be.  Ideally we would have a separate broker per
>>> virtual host,
>>> that way you get more isolation.  But even if we don't
>>> implement it
>>> initially, I think it's important we reserve that
>>> header.
>>>
>>>       
>>>> Cheers
>>>>
>>>> --
>>>> Dejan Bosanac
>>>>
>>>>
>>>> http://www.ttmsolutions.com - get a free ActiveMQ user
>>>>         
>>> guide
>>>       
>>>> ActiveMQ in Action - http://www.manning.com/snyder/
>>>> Scripting in Java - http://www.scriptinginjava.net
>>>>
>>>>
>>>>         
>>>
>>> --
>>> Regards,
>>> Hiram
>>>
>>> Blog: http://hiramchirino.com
>>>
>>> Open Source SOA
>>> http://open.iona.com
>>>       
>>
>>
>>     
>
>
>
>   



Re: Stomp v1.1 Thoughts

Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1

On Thu, Sep 25, 2008 at 4:22 AM, Dexter Tad-y <de...@yahoo.com> wrote:
> To add to the discussion, how about standardizing AMQ-1874 as part of the official Stomp specs. The patch is thankfully part of 5.2.0 now but of course this is ActiveMQ specific. It would be great if it becomes part of Stomp v1.1 and other Stomp brokers could follow suit.
>
>
> --- On Wed, 9/24/08, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
>> From: Hiram Chirino <hi...@hiramchirino.com>
>> Subject: Re: Stomp v1.1 Thoughts
>> To: dev@activemq.apache.org
>> Date: Wednesday, September 24, 2008, 9:25 PM
>> On Wed, Sep 24, 2008 at 8:18 AM, Dejan Bosanac
>> <de...@ttmsolutions.com> wrote:
>> >
>> >> How about you also put those ideas somewhere on
>> the wiki at:
>> >> http://stomp.codehaus.org/
>> >>
>> > Done. Here's a page for this kind of material
>> >
>> > http://stomp.codehaus.org/Stomp+v1.1+Ideas
>> >
>> >> Some of the things I see missing in STOMP are:
>> >> - Optional Keep Alive protocol.  Right now we have
>> to depend on the OS
>> >> to detect socket failure to time out a dead
>> client.  Would be nice if
>> >> the client could optionally agree to send a Keep
>> Alive commands when
>> >> the connection is idle.  That way the sever can
>> detect dead clients
>> >> quicker.
>> >>
>> > I'd definitely keep this optional, since most
>> Stomp clients implement
>> > just basic blocked reading of the socket (waiting for
>> the next frame).
>> >
>> >> - Perhaps standardize a 'host' header in
>> the CONNECT frame to specify
>> >> the host name that the client is connecting to.
>> This would allow
>> >> implementing virtual hosting where multiple DNS
>> host entries point at
>> >> the same STOMP server.
>> >>
>> > This would rock. I wonder how we could support virtual
>> hosting in
>> > ActiveMQ ... Should it be done, by allocating a
>> different path hierarchy
>> > for each host, so for example /queue/A on host1 would
>> physically be
>> > queue://host1/A, etc?
>> >
>>
>> Could be.  Ideally we would have a separate broker per
>> virtual host,
>> that way you get more isolation.  But even if we don't
>> implement it
>> initially, I think it's important we reserve that
>> header.
>>
>> >
>> > Cheers
>> >
>> > --
>> > Dejan Bosanac
>> >
>> >
>> > http://www.ttmsolutions.com - get a free ActiveMQ user
>> guide
>> >
>> > ActiveMQ in Action - http://www.manning.com/snyder/
>> > Scripting in Java - http://www.scriptinginjava.net
>> >
>> >
>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>
>
>
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Re: Stomp v1.1 Thoughts

Posted by Dexter Tad-y <de...@yahoo.com>.
To add to the discussion, how about standardizing AMQ-1874 as part of the official Stomp specs. The patch is thankfully part of 5.2.0 now but of course this is ActiveMQ specific. It would be great if it becomes part of Stomp v1.1 and other Stomp brokers could follow suit.


--- On Wed, 9/24/08, Hiram Chirino <hi...@hiramchirino.com> wrote:

> From: Hiram Chirino <hi...@hiramchirino.com>
> Subject: Re: Stomp v1.1 Thoughts
> To: dev@activemq.apache.org
> Date: Wednesday, September 24, 2008, 9:25 PM
> On Wed, Sep 24, 2008 at 8:18 AM, Dejan Bosanac
> <de...@ttmsolutions.com> wrote:
> >
> >> How about you also put those ideas somewhere on
> the wiki at:
> >> http://stomp.codehaus.org/
> >>
> > Done. Here's a page for this kind of material
> >
> > http://stomp.codehaus.org/Stomp+v1.1+Ideas
> >
> >> Some of the things I see missing in STOMP are:
> >> - Optional Keep Alive protocol.  Right now we have
> to depend on the OS
> >> to detect socket failure to time out a dead
> client.  Would be nice if
> >> the client could optionally agree to send a Keep
> Alive commands when
> >> the connection is idle.  That way the sever can
> detect dead clients
> >> quicker.
> >>
> > I'd definitely keep this optional, since most
> Stomp clients implement
> > just basic blocked reading of the socket (waiting for
> the next frame).
> >
> >> - Perhaps standardize a 'host' header in
> the CONNECT frame to specify
> >> the host name that the client is connecting to. 
> This would allow
> >> implementing virtual hosting where multiple DNS
> host entries point at
> >> the same STOMP server.
> >>
> > This would rock. I wonder how we could support virtual
> hosting in
> > ActiveMQ ... Should it be done, by allocating a
> different path hierarchy
> > for each host, so for example /queue/A on host1 would
> physically be
> > queue://host1/A, etc?
> >
> 
> Could be.  Ideally we would have a separate broker per
> virtual host,
> that way you get more isolation.  But even if we don't
> implement it
> initially, I think it's important we reserve that
> header.
> 
> >
> > Cheers
> >
> > --
> > Dejan Bosanac
> >
> >
> > http://www.ttmsolutions.com - get a free ActiveMQ user
> guide
> >
> > ActiveMQ in Action - http://www.manning.com/snyder/
> > Scripting in Java - http://www.scriptinginjava.net
> >
> >
> 
> 
> 
> -- 
> Regards,
> Hiram
> 
> Blog: http://hiramchirino.com
> 
> Open Source SOA
> http://open.iona.com


      

Re: Stomp v1.1 Thoughts

Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Wed, Sep 24, 2008 at 8:18 AM, Dejan Bosanac
<de...@ttmsolutions.com> wrote:
>
>> How about you also put those ideas somewhere on the wiki at:
>> http://stomp.codehaus.org/
>>
> Done. Here's a page for this kind of material
>
> http://stomp.codehaus.org/Stomp+v1.1+Ideas
>
>> Some of the things I see missing in STOMP are:
>> - Optional Keep Alive protocol.  Right now we have to depend on the OS
>> to detect socket failure to time out a dead client.  Would be nice if
>> the client could optionally agree to send a Keep Alive commands when
>> the connection is idle.  That way the sever can detect dead clients
>> quicker.
>>
> I'd definitely keep this optional, since most Stomp clients implement
> just basic blocked reading of the socket (waiting for the next frame).
>
>> - Perhaps standardize a 'host' header in the CONNECT frame to specify
>> the host name that the client is connecting to.  This would allow
>> implementing virtual hosting where multiple DNS host entries point at
>> the same STOMP server.
>>
> This would rock. I wonder how we could support virtual hosting in
> ActiveMQ ... Should it be done, by allocating a different path hierarchy
> for each host, so for example /queue/A on host1 would physically be
> queue://host1/A, etc?
>

Could be.  Ideally we would have a separate broker per virtual host,
that way you get more isolation.  But even if we don't implement it
initially, I think it's important we reserve that header.

>
> Cheers
>
> --
> Dejan Bosanac
>
>
> http://www.ttmsolutions.com - get a free ActiveMQ user guide
>
> ActiveMQ in Action - http://www.manning.com/snyder/
> Scripting in Java - http://www.scriptinginjava.net
>
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Re: Stomp v1.1 Thoughts

Posted by Dejan Bosanac <de...@ttmsolutions.com>.
> How about you also put those ideas somewhere on the wiki at:
> http://stomp.codehaus.org/
>   
Done. Here's a page for this kind of material

http://stomp.codehaus.org/Stomp+v1.1+Ideas

> Some of the things I see missing in STOMP are:
> - Optional Keep Alive protocol.  Right now we have to depend on the OS
> to detect socket failure to time out a dead client.  Would be nice if
> the client could optionally agree to send a Keep Alive commands when
> the connection is idle.  That way the sever can detect dead clients
> quicker.
>   
I'd definitely keep this optional, since most Stomp clients implement
just basic blocked reading of the socket (waiting for the next frame).

> - Perhaps standardize a 'host' header in the CONNECT frame to specify
> the host name that the client is connecting to.  This would allow
> implementing virtual hosting where multiple DNS host entries point at
> the same STOMP server.
>   
This would rock. I wonder how we could support virtual hosting in
ActiveMQ ... Should it be done, by allocating a different path hierarchy
for each host, so for example /queue/A on host1 would physically be
queue://host1/A, etc?


Cheers

-- 
Dejan Bosanac


http://www.ttmsolutions.com - get a free ActiveMQ user guide

ActiveMQ in Action - http://www.manning.com/snyder/
Scripting in Java - http://www.scriptinginjava.net


Re: Stomp v1.1 Thoughts

Posted by Hiram Chirino <hi...@hiramchirino.com>.
Good start!

How about you also put those ideas somewhere on the wiki at:
http://stomp.codehaus.org/

Some of the things I see missing in STOMP are:
- Optional Keep Alive protocol.  Right now we have to depend on the OS
to detect socket failure to time out a dead client.  Would be nice if
the client could optionally agree to send a Keep Alive commands when
the connection is idle.  That way the sever can detect dead clients
quicker.
- Perhaps standardize a 'host' header in the CONNECT frame to specify
the host name that the client is connecting to.  This would allow
implementing virtual hosting where multiple DNS host entries point at
the same STOMP server.

Regards,
Hiram


On Tue, Sep 23, 2008 at 10:40 AM, Dejan Bosanac
<de...@ttmsolutions.com> wrote:
> Hi,
>
> in a thread some time ago we discussed new features which could go into
> version 1.1 of Stomp protocol.
>
> Since I'm cross-posting this, I've summarized all these features in a
> blog http://www.nighttale.net/stomp/stomp-v11-thoughts.html
>
> It's basically an invitation to a discussion on whether we should go
> with v1.1 or these should be implemented as ActiveMQ-related stuff.
> Also, if some of you have items on the wish list, I would like to hear them.
>
> Cheers
>
> --
> Dejan Bosanac
>
>
> http://www.ttmsolutions.com - get a free ActiveMQ user guide
>
> ActiveMQ in Action - http://www.manning.com/snyder/
> Scripting in Java - http://www.scriptinginjava.net
>
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com