Proposal 1: For STOMP protocol spec update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal 1: For STOMP protocol spec update

sileshi
To be well founded message based protocol, Stomp protocol
should include basic entities of the messaging domain.
Yes it supports the notion of "connection", but does not address
other adminstered objects fully: TempQueue and TempTopic
There is a need to create a temporary destination: queue or topic
through Stomp protocol. When you establish a two way conversation,
the request channel uses actual Queue, but the reply channel
uses temporary queue. The requester passes reply temp queue to
the replier via reply-to header field. This will save a lot of resource
on the server side since reply queue names could be
unqueue and generated on the fly and will be used again.

Here is my proposal;
1. A new command Frame to server

CREATE
destination:temp-queue, temp-topic, queue, or topic

^@

2. A server reply frame

CREATED
destination:<destination name>

 ^@
Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

brianm
On Oct 25, 2006, at 9:48 AM, sileshi wrote:

> Here is my proposal;
> 1. A new command Frame to server
>
> CREATE
> destination:temp-queue, temp-topic, queue, or topic
>
> ^@
>
> 2. A server reply frame
>
> CREATED
> destination:<destination name>
>
>  ^@

Some initial comments:

destination should be an opaque identifier for the destination.  
Individual implementations are free to encode/decode information from  
the destination name, but from a Stomp perspective, destinations are  
just labels:

CREATE
destination: Wombats are funny animals

^@

is as valid as

CREATE
destination: temp-queue://replytomemore

^@

as

CREATE
destination: /topic/NUGGET.WOMBAT.KANGAROO

^@

If we expose CREATE should we expose DESTROY?

In general we have hadn't request/response style communication except  
on CONNECT (and I have mixed feelings about the usefulness of  
CONNECTED). The CREATED frame seems to exist for the purpose of  
communicating a destination name back to the client in the case of a  
temporary destination.

Another viable option might be to allow the client to assign a name  
to the temp destination which is mapped on the server. This would  
allow us to continue to avoid specifying server behavior (stomp isn't  
necessarily always used with traditional MQ semantics, though that  
certainly is the typical case). This does, however, make creation and  
destruction of destination implicit and unspecified, which has both  
benefits and drawbacks. The biggest drawback that comes to mind is in  
the case of an distributed server implementation which wants to  
support ~transparent client reconnects -- the mapping of the temp  
destination name associated with  given connection would need to be  
communicated to the other nodes. Most JMS implementations, at least,  
don't support this anyway as the temp destination will be destroyed  
between reconnects, but it is a valid concern.

Another alternative is to do implicit destination creation and encode  
destination type in the destination name. That is how ActiveMQ's  
implementation works right now, and could be fairly straightforwardly  
extended to encode tempqueue and temptopic destination types into its  
destination naming rules.

The CREATE verb seems most useful if you don't want to allow implicit  
destination creation, or you want the corollary, DESTROY, in order to  
cleanup messes which have been left behind.

An alternative here is to use special destinations for controlling  
the server, something like:

SEND
destination: server-control

destroy topic://WOMBAT.MARS
^@

Not beautiful, but it avoids specifying at the protocol level the  
capabilities of the server, and instead makes the client dependent on  
the server semantics. I don't know which is the ideal path (make a  
case!).

-Brian





---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

David Jones
In reply to this post by sileshi

I'm kind of new to the Messaging concept, but can you expand on why this would be a necessary mechanism? Better program structure might avoid the need for unnecessary (temporary) queues/topics. Is this sort of thing commonplace?

sileshi wrote
There is a need to create a temporary destination: queue or topic
through Stomp protocol. When you establish a two way conversation,
the request channel uses actual Queue, but the reply channel
uses temporary queue. The requester passes reply temp queue to
the replier via reply-to header field.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

sileshi
In the messaging world, Queues and Topics are called destinations and are
considered a resources on the server side. That means ActiveMQ Message Broker
will dedicate a resource whether it is in memory, disk, or database for each
queue and topic. When their number increases the size of memory also increases.

When you have a two way conversation, takes two queues and each queue is
a channnel of commnunication, the Request Queue is necessary and can stay
for long term, but the reply queue is only need for a session and can be
a temporary queue to save resource on the server side which improves
performance.
 For instance, if you build RPC over Stomp protocol and you need only
a single queue for Request which is created by the provider the service,
buthe reply queue must be created by the consumer. In case of where you
have hundreds of clients, each creates a reply queue. It makes no sense
to create a non-temp queue if you concerned about server side resource.

I hope that will help.

-Sileshi
David Jones wrote
I'm kind of new to the Messaging concept, but can you expand on why this would be a necessary mechanism? Better program structure might avoid the need for unnecessary (temporary) queues/topics. Is this sort of thing commonplace?

sileshi wrote
There is a need to create a temporary destination: queue or topic
through Stomp protocol. When you establish a two way conversation,
the request channel uses actual Queue, but the reply channel
uses temporary queue. The requester passes reply temp queue to
the replier via reply-to header field.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

sileshi
In reply to this post by brianm

Brian McCallister wrote
On Oct 25, 2006, at 9:48 AM, sileshi wrote:

> Here is my proposal;
> 1. A new command Frame to server
>
> CREATE
> destination:temp-queue, temp-topic, queue, or topic
>
> ^@
>
> 2. A server reply frame
>
> CREATED
> destination:<destination name>
>
>  ^@

>Some initial comments:
>
>destination should be an opaque identifier for the destination.  
>Individual implementations are free to encode/decode information from  
>the destination name, but from a Stomp perspective, destinations are  
>just labels:

I agree destination name should be opaqueue.


>CREATE
>destination: Wombats are funny animals
>
>^@
>
>is as valid as
>
>CREATE
>destination: temp-queue://replytomemore
>
>^@
>
>as
>
>CREATE
>destination: /topic/NUGGET.WOMBAT.KANGAROO
>
>^@
>
>If we expose CREATE should we expose DESTROY?
>

So, I like the implicit creation of non-temp destinations.
Butl,  my intention for CREATE is to just create temporary destination.
The header for CREATE should only identify the type of destination.
Therefore, I will amend it as follows:

CREATE
destination-type:<type>

^@

where <type> is type of temp destination with valid value of either "queue" or "topic".
The Stomp server creates the temp destination and returns the identifier/name.

Regarding adding DESTROY at protocol level may not be a bad idea. It becomes a NOP operation
in most implementation. In this case, temp destinations suppose to be destroyed at the ned of
the session.

>In general we have hadn't request/response style communication except  
>on CONNECT (and I have mixed feelings about the usefulness of  
>CONNECTED). The CREATED frame seems to exist for the purpose of  
>communicating a destination name back to the client in the case of a  
>temporary destination.

I think the CONNECTED frame does at least two purposes:
1. It confirms the connection is successful
2. the session-id it returns can be used as identifier for follow up operations
   that includes transaction and durable subcscriber creation.

Another alternative is the idea  have a generic RESPONSE frame that is
command context dependent. The change is disruptive.


>Another viable option might be to allow the client to assign a name  
>to the temp destination which is mapped on the server. This would  
>allow us to continue to avoid specifying server behavior (stomp isn't  
>necessarily always used with traditional MQ semantics, though that  
>certainly is the typical case). This does, however, make creation and  
>destruction of destination implicit and unspecified, which has both  
>benefits and drawbacks. The biggest drawback that comes to mind is in  
>the case of an distributed server implementation which wants to  
>support ~transparent client reconnects -- the mapping of the temp  
>destination name associated with  given connection would need to be  
>communicated to the other nodes. Most JMS implementations, at least,  
>don't support this anyway as the temp destination will be destroyed  
>between reconnects, but it is a valid concern.

may be we need to introduce the notion of core Stomp protocol which is
required, and some others that are optional. This way each problem space,
will implement the required ones and optionally implements the rest.
For Message Queue domain JMS and other traditional ones support the
temp destination. So, make it optional.


>Another alternative is to do implicit destination creation and encode  
>destination type in the destination name. That is how ActiveMQ's  
>implementation works right now, and could be fairly straightforwardly  
>extended to encode tempqueue and temptopic destination types into its  
>destination naming rules.

I like that...This could be encoded into destination fileld as follows:

destination: /tempqueue/a
                 /temptopic/b

This is better alternative and keeps the protocol simple.






---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

Alan Willis
In reply to this post by sileshi
Re: [stomp-dev] Proposal 1: For STOMP protocol spec update

As for the usefulness of the CONNECTED frame, I've been using the session identifier it returns and an iterator to uniquely identify transactions.

-alan


-----Original Message-----
From: sileshi <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Wed Oct 25 20:00:13 2006
Subject: Re: [stomp-dev] Proposal 1: For STOMP protocol spec update




Brian McCallister wrote:
>
> On Oct 25, 2006, at 9:48 AM, sileshi wrote:
>
>> Here is my proposal;
>> 1. A new command Frame to server
>>
>> CREATE
>> destination:temp-queue, temp-topic, queue, or topic
>>
>> ^@
>>
>> 2. A server reply frame
>>
>> CREATED
>> destination:<destination name>
>>
>>  ^@
>
>>Some initial comments:
>>
>>destination should be an opaque identifier for the destination. 
>>Individual implementations are free to encode/decode information from 
>>the destination name, but from a Stomp perspective, destinations are 
>>just labels:
>
> I agree destination name should be opaqueue.
>
>
>>CREATE
>>destination: Wombats are funny animals
>>
>>^@
>>
>>is as valid as
>>
>>CREATE
>>destination: temp-queue://replytomemore
>>
>>^@
>>
>>as
>>
>>CREATE
>>destination: /topic/NUGGET.WOMBAT.KANGAROO
>>
>>^@
>>
>>If we expose CREATE should we expose DESTROY?
>>
>
> So, I like the implicit creation of non-temp destinations.
> Butl,  my intention for CREATE is to just create temporary destination.
> The header for CREATE should only identify the type of destination.
> Therefore, I will amend it as follows:
>
> CREATE
> destination-type:<type>
>
> ^@
>
> where <type> is type of temp destination with valid value of either
> "queue" or "topic".
> The Stomp server creates the temp destination and returns the
> identifier/name.
>
> Regarding adding DESTROY at protocol level may not be a bad idea. It
> becomes a NOP operation
> in most implementation. In this case, temp destinations suppose to be
> destroyed at the ned of
> the session.
>
>>In general we have hadn't request/response style communication except 
>>on CONNECT (and I have mixed feelings about the usefulness of 
>>CONNECTED). The CREATED frame seems to exist for the purpose of 
>>communicating a destination name back to the client in the case of a 
>>temporary destination.
>
> I think the CONNECTED frame does at least two purposes:
> 1. It confirms the connection is successful
> 2. the session-id it returns can be used as identifier for follow up
> operations
>    that includes transaction and durable subcscriber creation.
>
> Another alternative is the idea  have a generic RESPONSE frame that is
> command context dependent. The change is disruptive.
>
>
>>Another viable option might be to allow the client to assign a name 
>>to the temp destination which is mapped on the server. This would 
>>allow us to continue to avoid specifying server behavior (stomp isn't 
>>necessarily always used with traditional MQ semantics, though that 
>>certainly is the typical case). This does, however, make creation and 
>>destruction of destination implicit and unspecified, which has both 
>>benefits and drawbacks. The biggest drawback that comes to mind is in 
>>the case of an distributed server implementation which wants to 
>>support ~transparent client reconnects -- the mapping of the temp 
>>destination name associated with  given connection would need to be 
>>communicated to the other nodes. Most JMS implementations, at least, 
>>don't support this anyway as the temp destination will be destroyed 
>>between reconnects, but it is a valid concern.
>
> may be we need to introduce the notion of core Stomp protocol which is
> required, and some others that are optional. This way each problem space,
> will implement the required ones and optionally implements the rest.
> For Message Queue domain JMS and other traditional ones support the
> temp destination. So, make it optional.
>
>
>>Another alternative is to do implicit destination creation and encode 
>>destination type in the destination name. That is how ActiveMQ's 
>>implementation works right now, and could be fairly straightforwardly 
>>extended to encode tempqueue and temptopic destination types into its 
>>destination naming rules.
>
> I like that...This could be encoded into destination fileld as follows:
>
> destination: /tempqueue/a
>                  /temptopic/b
>
> This is better alternative and keeps the protocol simple.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
View this message in context: http://www.nabble.com/Proposal-1%3A-For-STOMP-protocol-spec-update-tf2508792.html#a7004411
Sent from the stomp - dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

James Strachan-2
BTW transaction IDs are purely local to the client - so you could use
a simple integer counter if you wish?

On 10/26/06, Alan Willis <[hidden email]> wrote:

>
>
>
> As for the usefulness of the CONNECTED frame, I've been using the session
> identifier it returns and an iterator to uniquely identify transactions.
>
>  -alan
>
>
>
>  -----Original Message-----
>  From: sileshi <[hidden email]>
>  To: [hidden email] <[hidden email]>
>  Sent: Wed Oct 25 20:00:13 2006
>  Subject: Re: [stomp-dev] Proposal 1: For STOMP protocol spec update
>
>
>
>
>  Brian McCallister wrote:
>  >
>  > On Oct 25, 2006, at 9:48 AM, sileshi wrote:
>  >
>  >> Here is my proposal;
>  >> 1. A new command Frame to server
>  >>
>  >> CREATE
>  >> destination:temp-queue, temp-topic, queue, or topic
>  >>
>  >> ^@
>  >>
>  >> 2. A server reply frame
>  >>
>  >> CREATED
>  >> destination:<destination name>
>  >>
>  >>  ^@
>  >
>  >>Some initial comments:
>  >>
>  >>destination should be an opaque identifier for the destination.
>  >>Individual implementations are free to encode/decode information from
>  >>the destination name, but from a Stomp perspective, destinations are
>  >>just labels:
>  >
>  > I agree destination name should be opaqueue.
>  >
>  >
>  >>CREATE
>  >>destination: Wombats are funny animals
>  >>
>  >>^@
>  >>
>  >>is as valid as
>  >>
>  >>CREATE
>  >>destination: temp-queue://replytomemore
>  >>
>  >>^@
>  >>
>  >>as
>  >>
>  >>CREATE
>  >>destination: /topic/NUGGET.WOMBAT.KANGAROO
>  >>
>  >>^@
>  >>
>  >>If we expose CREATE should we expose DESTROY?
>  >>
>  >
>  > So, I like the implicit creation of non-temp destinations.
>  > Butl,  my intention for CREATE is to just create temporary destination.
>  > The header for CREATE should only identify the type of destination.
>  > Therefore, I will amend it as follows:
>  >
>  > CREATE
>  > destination-type:<type>
>  >
>  > ^@
>  >
>  > where <type> is type of temp destination with valid value of either
>  > "queue" or "topic".
>  > The Stomp server creates the temp destination and returns the
>  > identifier/name.
>  >
>  > Regarding adding DESTROY at protocol level may not be a bad idea. It
>  > becomes a NOP operation
>  > in most implementation. In this case, temp destinations suppose to be
>  > destroyed at the ned of
>  > the session.
>  >
>  >>In general we have hadn't request/response style communication except
>  >>on CONNECT (and I have mixed feelings about the usefulness of
>  >>CONNECTED). The CREATED frame seems to exist for the purpose of
>  >>communicating a destination name back to the client in the case of a
>  >>temporary destination.
>  >
>  > I think the CONNECTED frame does at least two purposes:
>  > 1. It confirms the connection is successful
>  > 2. the session-id it returns can be used as identifier for follow up
>  > operations
>  >    that includes transaction and durable subcscriber creation.
>  >
>  > Another alternative is the idea  have a generic RESPONSE frame that is
>  > command context dependent. The change is disruptive.
>  >
>  >
>  >>Another viable option might be to allow the client to assign a name
>  >>to the temp destination which is mapped on the server. This would
>  >>allow us to continue to avoid specifying server behavior (stomp isn't
>  >>necessarily always used with traditional MQ semantics, though that
>  >>certainly is the typical case). This does, however, make creation and
>  >>destruction of destination implicit and unspecified, which has both
>  >>benefits and drawbacks. The biggest drawback that comes to mind is in
>  >>the case of an distributed server implementation which wants to
>  >>support ~transparent client reconnects -- the mapping of the temp
>  >>destination name associated with  given connection would need to be
>  >>communicated to the other nodes. Most JMS implementations, at least,
>  >>don't support this anyway as the temp destination will be destroyed
>  >>between reconnects, but it is a valid concern.
>  >
>  > may be we need to introduce the notion of core Stomp protocol which is
>  > required, and some others that are optional. This way each problem space,
>  > will implement the required ones and optionally implements the rest.
>  > For Message Queue domain JMS and other traditional ones support the
>  > temp destination. So, make it optional.
>  >
>  >
>  >>Another alternative is to do implicit destination creation and encode
>  >>destination type in the destination name. That is how ActiveMQ's
>  >>implementation works right now, and could be fairly straightforwardly
>  >>extended to encode tempqueue and temptopic destination types into its
>  >>destination naming rules.
>  >
>  > I like that...This could be encoded into destination fileld as follows:
>  >
>  > destination: /tempqueue/a
>  >                  /temptopic/b
>  >
>  > This is better alternative and keeps the protocol simple.
>  >
>  >
>  >
>  >
>  >
>  >
>  >
> ---------------------------------------------------------------------
>  > To unsubscribe from this list please visit:
>  >
>  >     http://xircles.codehaus.org/manage_email
>  >
>  >
>  >
>
>  --
>  View this message in context:
> http://www.nabble.com/Proposal-1%3A-For-STOMP-protocol-spec-update-tf2508792.html#a7004411
>  Sent from the stomp - dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
>  To unsubscribe from this list please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

Alan Willis
In reply to this post by sileshi
Re: [stomp-dev] Proposal 1: For STOMP protocol spec update

Didn't know that.  It is still useful to the client to have a unique transaction identifier that corresponds with the session that it occurred in, in logging and tracking down problems that occur between client and server.

-alan

-----Original Message-----
From: James Strachan <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Thu Oct 26 05:21:36 2006
Subject: Re: [stomp-dev] Proposal 1: For STOMP protocol spec update

BTW transaction IDs are purely local to the client - so you could use
a simple integer counter if you wish?

On 10/26/06, Alan Willis <[hidden email]> wrote:
>
>
>
> As for the usefulness of the CONNECTED frame, I've been using the session
> identifier it returns and an iterator to uniquely identify transactions.
>
>  -alan
>
>
>
>  -----Original Message-----
>  From: sileshi <[hidden email]>
>  To: [hidden email] <[hidden email]>
>  Sent: Wed Oct 25 20:00:13 2006
>  Subject: Re: [stomp-dev] Proposal 1: For STOMP protocol spec update
>
>
>
>
>  Brian McCallister wrote:
>  >
>  > On Oct 25, 2006, at 9:48 AM, sileshi wrote:
>  >
>  >> Here is my proposal;
>  >> 1. A new command Frame to server
>  >>
>  >> CREATE
>  >> destination:temp-queue, temp-topic, queue, or topic
>  >>
>  >> ^@
>  >>
>  >> 2. A server reply frame
>  >>
>  >> CREATED
>  >> destination:<destination name>
>  >>
>  >>  ^@
>  >
>  >>Some initial comments:
>  >>
>  >>destination should be an opaque identifier for the destination.
>  >>Individual implementations are free to encode/decode information from
>  >>the destination name, but from a Stomp perspective, destinations are
>  >>just labels:
>  >
>  > I agree destination name should be opaqueue.
>  >
>  >
>  >>CREATE
>  >>destination: Wombats are funny animals
>  >>
>  >>^@
>  >>
>  >>is as valid as
>  >>
>  >>CREATE
>  >>destination: temp-queue://replytomemore
>  >>
>  >>^@
>  >>
>  >>as
>  >>
>  >>CREATE
>  >>destination: /topic/NUGGET.WOMBAT.KANGAROO
>  >>
>  >>^@
>  >>
>  >>If we expose CREATE should we expose DESTROY?
>  >>
>  >
>  > So, I like the implicit creation of non-temp destinations.
>  > Butl,  my intention for CREATE is to just create temporary destination.
>  > The header for CREATE should only identify the type of destination.
>  > Therefore, I will amend it as follows:
>  >
>  > CREATE
>  > destination-type:<type>
>  >
>  > ^@
>  >
>  > where <type> is type of temp destination with valid value of either
>  > "queue" or "topic".
>  > The Stomp server creates the temp destination and returns the
>  > identifier/name.
>  >
>  > Regarding adding DESTROY at protocol level may not be a bad idea. It
>  > becomes a NOP operation
>  > in most implementation. In this case, temp destinations suppose to be
>  > destroyed at the ned of
>  > the session.
>  >
>  >>In general we have hadn't request/response style communication except
>  >>on CONNECT (and I have mixed feelings about the usefulness of
>  >>CONNECTED). The CREATED frame seems to exist for the purpose of
>  >>communicating a destination name back to the client in the case of a
>  >>temporary destination.
>  >
>  > I think the CONNECTED frame does at least two purposes:
>  > 1. It confirms the connection is successful
>  > 2. the session-id it returns can be used as identifier for follow up
>  > operations
>  >    that includes transaction and durable subcscriber creation.
>  >
>  > Another alternative is the idea  have a generic RESPONSE frame that is
>  > command context dependent. The change is disruptive.
>  >
>  >
>  >>Another viable option might be to allow the client to assign a name
>  >>to the temp destination which is mapped on the server. This would
>  >>allow us to continue to avoid specifying server behavior (stomp isn't
>  >>necessarily always used with traditional MQ semantics, though that
>  >>certainly is the typical case). This does, however, make creation and
>  >>destruction of destination implicit and unspecified, which has both
>  >>benefits and drawbacks. The biggest drawback that comes to mind is in
>  >>the case of an distributed server implementation which wants to
>  >>support ~transparent client reconnects -- the mapping of the temp
>  >>destination name associated with  given connection would need to be
>  >>communicated to the other nodes. Most JMS implementations, at least,
>  >>don't support this anyway as the temp destination will be destroyed
>  >>between reconnects, but it is a valid concern.
>  >
>  > may be we need to introduce the notion of core Stomp protocol which is
>  > required, and some others that are optional. This way each problem space,
>  > will implement the required ones and optionally implements the rest.
>  > For Message Queue domain JMS and other traditional ones support the
>  > temp destination. So, make it optional.
>  >
>  >
>  >>Another alternative is to do implicit destination creation and encode
>  >>destination type in the destination name. That is how ActiveMQ's
>  >>implementation works right now, and could be fairly straightforwardly
>  >>extended to encode tempqueue and temptopic destination types into its
>  >>destination naming rules.
>  >
>  > I like that...This could be encoded into destination fileld as follows:
>  >
>  > destination: /tempqueue/a
>  >                  /temptopic/b
>  >
>  > This is better alternative and keeps the protocol simple.
>  >
>  >
>  >
>  >
>  >
>  >
>  >
> ---------------------------------------------------------------------
>  > To unsubscribe from this list please visit:
>  >
>  >     http://xircles.codehaus.org/manage_email
>  >
>  >
>  >
>
>  --
>  View this message in context:
> http://www.nabble.com/Proposal-1%3A-For-STOMP-protocol-spec-update-tf2508792.html#a7004411
>  Sent from the stomp - dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
>  To unsubscribe from this list please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

RE: Proposal 1: For STOMP protocol spec update

David Jones
In reply to this post by Alan Willis
 Re: [stomp-dev] Proposal 1: For STOMP protocol spec update
It is my understanding that, while the current STOMP spec doesn't currently allow it, there may be more than one session per connection.*
The CONNECT frame is a bit confusing really, as it suggests a "connection" but is really a "session". Once you DISCONNECT, your socket is also closed.
 
I tried connecting to an ActiveMQ 4.0.2 server and giving it multiple CONNECT frames. The communication went as follows:
 
CONNECT

^@
CONNECTED
session:ID:scratch3.ingenta.com-42161-1161861748179-3:7


CONNECT

^@

ERROR
message:Allready connected.
 
As for the temporary queue/topic, the JMS[1] spec states that temporary queues/topics may be used by any session using that connection. This seems sensible and should probably be a mechanism embraced by STOMP. If connecting to an ActiveMQ server, then the destinations /temporary/queue/foo, or /queue/temp/foo would be nice. The queue/topic could easily be based on the connection id -- once the connection dies, the associated queue/topic is deleted. But I guess that's for the ActiveMQ people to decide.
 
CONNECT is okay as it is as it creates a default session. CREATE could be used to initiate a new session on the connection for consumption/publishing, rather than specifically making a new destination. If connecting to an ActiveMQ server, you automatically create queues/topics based on name anyhow.
Maybe the frame naming should be different somehow. Could be something like:
 
Connections:
CONNECT
CONNECTED
DISCONNECT
 
Sessions:
SESSION-START/-END
SESSION-STARTED/-ENDED
required header:
session
 
Transactions:
BEGIN/COMMIT/ABORT
required headers:
transaction
 
Subscriptions:
SUBSCRIBE
UNSUBSCRIBE
required headers:
destination
 
Messages:
MESSAGE
RECEIPT
ERROR
ACK
 
Messages obviously need different headers depending on their use. I.e. A header belonging to a transaction would need a transaction header, an ACK needs a message-id, etc
 
 
 
-----Original Message-----
From: Alan Willis [mailto:[hidden email]]
Sent: 26 October 2006 4:32 am
To: [hidden email]
Subject: Re: [stomp-dev] Proposal 1: For STOMP protocol spec update

As for the usefulness of the CONNECTED frame, I've been using the session identifier it returns and an iterator to uniquely identify transactions.

-alan


-----Original Message-----
From: sileshi <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Wed Oct 25 20:00:13 2006
Subject: Re: [stomp-dev] Proposal 1: For STOMP protocol spec update




Brian McCallister wrote:


>
> On Oct 25, 2006, at 9:48 AM, sileshi wrote:
>
>> Here is my proposal;
>> 1. A new command Frame to server
>>
>> CREATE
>> destination:temp-queue, temp-topic, queue, or topic
>>
>> ^@
>>
>> 2. A server reply frame
>>
>> CREATED
>> destination:<destination name>
>>
>>  ^@
>
>>Some initial comments:
>>
>>destination should be an opaque identifier for the destination. 
>>Individual implementations are free to encode/decode information from 
>>the destination name, but from a Stomp perspective, destinations are 
>>just labels:
>
> I agree destination name should be opaqueue.
>
>
>>CREATE
>>destination: Wombats are funny animals
>>
>>^@
>>
>>is as valid as
>>
>>CREATE
>>destination: temp-queue://replytomemore
>>
>>^@
>>
>>as
>>
>>CREATE
>>destination: /topic/NUGGET.WOMBAT.KANGAROO
>>
>>^@
>>
>>If we expose CREATE should we expose DESTROY?
>>
>
> So, I like the implicit creation of non-temp destinations.
> Butl,  my intention for CREATE is to just create temporary destination.
> The header for CREATE should only identify the type of destination.
> Therefore, I will amend it as follows:
>
> CREATE
> destination-type:<type>
>
> ^@
>
> where <type> is type of temp destination with valid value of either
> "queue" or "topic".
> The Stomp server creates the temp destination and returns the
> identifier/name.
>
> Regarding adding DESTROY at protocol level may not be a bad idea. It
> becomes a NOP operation
> in most implementation. In this case, temp destinations suppose to be
> destroyed at the ned of
> the session.
>
>>In general we have hadn't request/response style communication except 
>>on CONNECT (and I have mixed feelings about the usefulness of 
>>CONNECTED). The CREATED frame seems to exist for the purpose of 
>>communicating a destination name back to the client in the case of a 
>>temporary destination.
>
> I think the CONNECTED frame does at least two purposes:
> 1. It confirms the connection is successful
> 2. the session-id it returns can be used as identifier for follow up
> operations
>    that includes transaction and durable subcscriber creation.
>
> Another alternative is the idea  have a generic RESPONSE frame that is
> command context dependent. The change is disruptive.
>
>
>>Another viable option might be to allow the client to assign a name 
>>to the temp destination which is mapped on the server. This would 
>>allow us to continue to avoid specifying server behavior (stomp isn't 
>>necessarily always used with traditional MQ semantics, though that 
>>certainly is the typical case). This does, however, make creation and 
>>destruction of destination implicit and unspecified, which has both 
>>benefits and drawbacks. The biggest drawback that comes to mind is in 
>>the case of an distributed server implementation which wants to 
>>support ~transparent client reconnects -- the mapping of the temp 
>>destination name associated with  given connection would need to be 
>>communicated to the other nodes. Most JMS implementations, at least, 
>>don't support this anyway as the temp destination will be destroyed 
>>between reconnects, but it is a valid concern.
>
> may be we need to introduce the notion of core Stomp protocol which is
> required, and some others that are optional. This way each problem space,
> will implement the required ones and optionally implements the rest.
> For Message Queue domain JMS and other traditional ones support the
> temp destination. So, make it optional.
>
>
>>Another alternative is to do implicit destination creation and encode 
>>destination type in the destination name. That is how ActiveMQ's 
>>implementation works right now, and could be fairly straightforwardly 
>>extended to encode tempqueue and temptopic destination types into its 
>>destination naming rules.
>
> I like that...This could be encoded into destination fileld as follows:
>
> destination: /tempqueue/a
>                  /temptopic/b
>
> This is better alternative and keeps the protocol simple.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

--
View this message in context: http://www.nabble.com/Proposal-1%3A-For-STOMP-protocol-spec-update-tf2508792.html#a7004411
Sent from the stomp - dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

James Strachan-2
On 10/26/06, David Jones <[hidden email]> wrote:
> It is my understanding that, while the current STOMP spec doesn't currently
> allow it, there may be more than one session per connection.*
> The CONNECT frame is a bit confusing really, as it suggests a "connection"
> but is really a "session". Once you DISCONNECT, your socket is also closed.

Yeah - CONNECT really is a connection. There's no real need to create
sessions in stomp - you just use a session id (transaction id) when
using transactions.


> As for the temporary queue/topic, the JMS[1] spec states that temporary
> queues/topics may be used by any session using that connection. This seems
> sensible and should probably be a mechanism embraced by STOMP. If connecting
> to an ActiveMQ server, then the destinations /temporary/queue/foo, or
> /queue/temp/foo would be nice.

Yeah. I guess the decision needs to be, does the client make up some
name and have the broker auto-create it, or should there be an
explicit CREATE/DESTROY type verbs on the STOMP protocol.


> The queue/topic could easily be based on the
> connection id -- once the connection dies, the associated queue/topic is
> deleted. But I guess that's for the ActiveMQ people to decide.

Yeah; its easy to map the stomp client side names such as
/temporary/queue/foo to some broker side temporary queue (which is
globally unique and so forth).

I guess the simplest thing that could possibly work is just to use a
naming convention; that /temporary/queue/* (or /tempqueue/*) indicates
temporary queues. Though the complication then arises that a client
may wish to specify the reply-to destination (more here
http://incubator.apache.org/activemq/stomp.html) - which if there was
a client side alias (/tempqueue/foo) that would need to get switched
to the globally unique queue name.

e.g. a service receiving a message needs to send replies back to the
'reply-to' address, and /tempqueue/foo would be a local temp queue
called foo - not a globally unique queue name.

So to avoid these alias complications, I'd be tempted to add a CREATE
TOPIC/QUEUE / DESTROY TOPIC/QUEUE operation to Stomp. It makes the
client's job a tiny bit harder, but it'd make things a little cleaner.

Then a client can create a temporary queue/topic, get the globally
unique name back and then add it to any messages it wishes - then
destroy the temporary queue/topic when its done with it. Then
clients/brokers don't need to worry about whether a destination is
really a client-side-alias or a real broker side name etc


> CONNECT is okay as it is as it creates a default session. CREATE could be
> used to initiate a new session on the connection for consumption/publishing,
> rather than specifically making a new destination. If connecting to an
> ActiveMQ server, you automatically create queues/topics based on name
> anyhow.
> Maybe the frame naming should be different somehow. Could be something like:
>
> Connections:
> CONNECT
> CONNECTED
> DISCONNECT
>
>
> Sessions:
> SESSION-START/-END
> SESSION-STARTED/-ENDED

I'm not sure how useful the SESSION is; as folks can use a transaction
for a session?
--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Proposal 1: For STOMP protocol spec update

sileshi
James.Strachan wrote
> As for the temporary queue/topic, the JMS[1] spec states that temporary
> queues/topics may be used by any session using that connection. This seems
>> sensible and should probably be a mechanism embraced by STOMP. If connecting
>> to an ActiveMQ server, then the destinations /temporary/queue/foo, or
>> /queue/temp/foo would be nice.

>Yeah. I guess the decision needs to be, does the client make up some
>name and have the broker auto-create it, or should there be an
>explicit CREATE/DESTROY type verbs on the STOMP protocol.


An explicit client request to CREATE temporary queue/topic where the server
creates and return via CREATED frame would have been be ideal. One possible
server side implementation could associate the temp queue/topic to the session,
and automatically deletes it when session ends which is consistent JMS side behavior.
I suggested this a while back but the consensus was not to change the stomp protocol, rather
extend it for ActiveMQ.
Thus, I have proposed a simple temp queue/topic naming convention
which doesn't require the Stomp protocol change or extension:
destination: /tempqueue/Foo

or

destination: /temptopic/Bar

This temp destination must be globally unique name as in the case of JMS side.
And the server somehow associates the temp queue/topic to the session, and
deletes it without a client request when the session ends.
Mostly a temp queue is created so that it can be used for replyTo.

>I guess the simplest thing that could possibly work is just to use a
>naming convention; that /temporary/queue/* (or /tempqueue/*) indicates
>temporary queues. Though the complication then arises that a client
>may wish to specify the reply-to destination (more here
>http://incubator.apache.org/activemq/stomp.html) - which if there was
>a client side alias (/tempqueue/foo) that would need to get switched
>to the globally unique queue name.

I prefer /tempqueue/Foo, /temptopic/Bar type convention which quite
similar to regular queue/topic: /queue/Foo, /topic/Bar


>I'm not sure how useful the SESSION is; as folks can use a transaction
>for a session?

A stomp connection can be viewed as an implicit session.
Having multiple session within a stomp connection may
introduce complexity
--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email