[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: Stomp v1.1 Thoughts
From:       Dejan Bosanac <dejan.bosanac () ttmsolutions ! com>
Date:       2008-09-26 10:01:09
Message-ID: 48DCB2E5.5030908 () ttmsolutions ! com
[Download RAW message or body]


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 <dexterbt1@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 <hiram@hiramchirino.com> wrote:
> > 
> > 
> > > From: Hiram Chirino <hiram@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
> > > <dejan.bosanac@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
> > > 
> > 
> > 
> > 
> 
> 
> 
> 



[prev in list] [next in list] [prev in thread] [next in thread]