You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Mittler, Nathan" <na...@sensis.com> on 2006/06/12 21:59:36 UTC
STOMP and JMSType
I'm working on fixing the way the STOMP transport determines Text and
Bytes messages for issue AMQ-739. Previously we keyed off of the
content-length header - if it was there, it's a bytes message, and
otherwise it's a text message.
Since all STOMP messages can have content-length, we need to use JMSType
to distinguish in these cases. To do this, we need to define standard
JMSType values for Text and Bytes messages. I have a build that uses
"text" and "bytes" as the standard values for the "type" header. On the
broker side, the logic in Send.java looks like this ...
****** BEGIN CODE ******
// Assume the message is a bytes message.
Boolean isBytesMessage = true;
// If the message does not contain a content length,
// we have to assume it's a text message - first zero
// we encounter denotes the end of the frame.
If( !headers.containsKey(Stomp.Headers.CONTENT_LENGTH) ){
isBytesMessage = false;
}
// There is a content length specified,
// now use JMSType to determine the message type (default to bytes if
none specified)
else if( headers.containsKey( Stomp.Headers.Send.TYPE ) ){
isBytesMessage =
(headers.getProperty(Stomp.Headers.Send.TYPE) ==
Stomp.Headers.TypeValues.BYTES);
}
if( isBytesMessage ){
// create a bytes message.
}else{
// create a text message.
}
****** END CODE *******
Any objections?
Regards,
Nate
Re: STOMP and JMSType
Posted by James Strachan <ja...@gmail.com>.
FWIW I'd like to have content-type header support. Couldn't we then
use content-type as the standard header that any Stomp-JMS bridge
would use to decide if something is a TextMessage or a BytesMessage?
On 6/13/06, Nathan Mittler <na...@gmail.com> wrote:
> I think that clears things up for me a bit - what you're proposing makes
> sense. I'll poke around today and see what I can come up with.
>
> Thanks,
> Nate
>
> On 6/12/06, Brian McCallister <br...@apache.org> wrote:
> >
> > On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote:
> >
> > > Agreed ... using the "type" header is not an option.
> >
> > --- From the bug report ---
> > It isn't possible to reuse the "type" header (JMSType) for the
> > purpose of sending through the information as to what type of message
> > it is (text or bytes). So this means that we need to add another
> > activemq extension header. I propose "amq-msg-type".
> > --- / From the bug report --
> >
> > I like this a lot better, and think it would be a reasonable default
> > rule for mapping in 4.X.
> >
> > >> I am not convinced we need this, but I much prefer it to a hardcoded
> > >> transform, as this would allow for much more useful transforms (ie,
> > >> aplication-aware).
> > >
> > >
> > > Although I agree conceptually, I'm thinking this might be a bit of an
> > > overkill for the task at hand.
> >
> > Agreed. I just hate to layer on another backwards compatibility issue
> > beyond what we already have. By designing it to be forward compatible
> > with an arbitrary mapping we can grow into a future solution more
> > easily. Once we add this header we will need to support it ~forever.
> >
> > > Right now the STOMP transport only works
> > > with bytes and text messages, and creating this transform model
> > > won't change
> > > that. I think if we one day decide to refactor the transport to
> > > accept
> > > other message types - that would be the time to make this sort of
> > > change.
> >
> > What if I want to switch on "Content-type" to decide between text or
> > bytes? It is a common header to use, but is not part of the spec (as
> > stomp doesn;t care, but is happy to pass it along). This makes more
> > sense to me in terms of mapping between Stomp and JMS, but it is not
> > compatible with switching on a specific content header.
> >
> > The mapping between Stomp and JMS is actually rather important to get
> > right as it is the low level interop mapping between various
> > platforms and Java. As such, I want to make sure we are building
> > towards a correct solution.
> >
> > Aside from all this, controlling the protocol <--> (semi-)protocol
> > mapping should be a configuration thing, not a flag the client must
> > put on every message it sends.
> >
> > The end goal for me is to have all messages coming in from the Stomp
> > adaptor be bytes messages, unless someone has an overriding need for
> > something else (quote possible). The current behavior is pretty bad
> > as a default, but we just released 4.0 with it, so we are stuck until
> > we make another backwards incompatible release (5.0).
> >
> > In 4.1 we can add the amq-msg-type header to allow people to force
> > things to bytes (or text) but for the 5.0 end game we will need to
> > make the mapping pluggable in order to make the upgrade path as easy
> > as possible. if we are going to need pluggable eventually, why not do
> > it now in order to allow people to fix the bytes/text mistake (I can
> > say it is a mistake, I wrote it =) at the server level instead of
> > having to add a header to every message.
> >
> > We have, then, three configurations which people are likely to want:
> >
> > 1) Current (3.2 and 4.0 compatible) one which is made more palatable
> > by letting the client specify via the amq-msg-type.
> >
> > 2) Map everything to bytes, which I would like to make the default in
> > 5.0.
> >
> > 3) Map everything to Text (which is what I would actually use if we
> > had it as I convert all the bytes ones I send now into strings anyway).
> >
> > If we are going to have it be sufficiently pluggable to support these
> > three, we should consider letting users provide their own.
> >
> > -Brian
> >
> >
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: STOMP and JMSType
Posted by Nathan Mittler <na...@gmail.com>.
I think that clears things up for me a bit - what you're proposing makes
sense. I'll poke around today and see what I can come up with.
Thanks,
Nate
On 6/12/06, Brian McCallister <br...@apache.org> wrote:
>
> On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote:
>
> > Agreed ... using the "type" header is not an option.
>
> --- From the bug report ---
> It isn't possible to reuse the "type" header (JMSType) for the
> purpose of sending through the information as to what type of message
> it is (text or bytes). So this means that we need to add another
> activemq extension header. I propose "amq-msg-type".
> --- / From the bug report --
>
> I like this a lot better, and think it would be a reasonable default
> rule for mapping in 4.X.
>
> >> I am not convinced we need this, but I much prefer it to a hardcoded
> >> transform, as this would allow for much more useful transforms (ie,
> >> aplication-aware).
> >
> >
> > Although I agree conceptually, I'm thinking this might be a bit of an
> > overkill for the task at hand.
>
> Agreed. I just hate to layer on another backwards compatibility issue
> beyond what we already have. By designing it to be forward compatible
> with an arbitrary mapping we can grow into a future solution more
> easily. Once we add this header we will need to support it ~forever.
>
> > Right now the STOMP transport only works
> > with bytes and text messages, and creating this transform model
> > won't change
> > that. I think if we one day decide to refactor the transport to
> > accept
> > other message types - that would be the time to make this sort of
> > change.
>
> What if I want to switch on "Content-type" to decide between text or
> bytes? It is a common header to use, but is not part of the spec (as
> stomp doesn;t care, but is happy to pass it along). This makes more
> sense to me in terms of mapping between Stomp and JMS, but it is not
> compatible with switching on a specific content header.
>
> The mapping between Stomp and JMS is actually rather important to get
> right as it is the low level interop mapping between various
> platforms and Java. As such, I want to make sure we are building
> towards a correct solution.
>
> Aside from all this, controlling the protocol <--> (semi-)protocol
> mapping should be a configuration thing, not a flag the client must
> put on every message it sends.
>
> The end goal for me is to have all messages coming in from the Stomp
> adaptor be bytes messages, unless someone has an overriding need for
> something else (quote possible). The current behavior is pretty bad
> as a default, but we just released 4.0 with it, so we are stuck until
> we make another backwards incompatible release (5.0).
>
> In 4.1 we can add the amq-msg-type header to allow people to force
> things to bytes (or text) but for the 5.0 end game we will need to
> make the mapping pluggable in order to make the upgrade path as easy
> as possible. if we are going to need pluggable eventually, why not do
> it now in order to allow people to fix the bytes/text mistake (I can
> say it is a mistake, I wrote it =) at the server level instead of
> having to add a header to every message.
>
> We have, then, three configurations which people are likely to want:
>
> 1) Current (3.2 and 4.0 compatible) one which is made more palatable
> by letting the client specify via the amq-msg-type.
>
> 2) Map everything to bytes, which I would like to make the default in
> 5.0.
>
> 3) Map everything to Text (which is what I would actually use if we
> had it as I convert all the bytes ones I send now into strings anyway).
>
> If we are going to have it be sufficiently pluggable to support these
> three, we should consider letting users provide their own.
>
> -Brian
>
>
>
Re: STOMP and JMSType
Posted by Brian McCallister <br...@apache.org>.
On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote:
> Agreed ... using the "type" header is not an option.
--- From the bug report ---
It isn't possible to reuse the "type" header (JMSType) for the
purpose of sending through the information as to what type of message
it is (text or bytes). So this means that we need to add another
activemq extension header. I propose "amq-msg-type".
--- / From the bug report --
I like this a lot better, and think it would be a reasonable default
rule for mapping in 4.X.
>> I am not convinced we need this, but I much prefer it to a hardcoded
>> transform, as this would allow for much more useful transforms (ie,
>> aplication-aware).
>
>
> Although I agree conceptually, I'm thinking this might be a bit of an
> overkill for the task at hand.
Agreed. I just hate to layer on another backwards compatibility issue
beyond what we already have. By designing it to be forward compatible
with an arbitrary mapping we can grow into a future solution more
easily. Once we add this header we will need to support it ~forever.
> Right now the STOMP transport only works
> with bytes and text messages, and creating this transform model
> won't change
> that. I think if we one day decide to refactor the transport to
> accept
> other message types - that would be the time to make this sort of
> change.
What if I want to switch on "Content-type" to decide between text or
bytes? It is a common header to use, but is not part of the spec (as
stomp doesn;t care, but is happy to pass it along). This makes more
sense to me in terms of mapping between Stomp and JMS, but it is not
compatible with switching on a specific content header.
The mapping between Stomp and JMS is actually rather important to get
right as it is the low level interop mapping between various
platforms and Java. As such, I want to make sure we are building
towards a correct solution.
Aside from all this, controlling the protocol <--> (semi-)protocol
mapping should be a configuration thing, not a flag the client must
put on every message it sends.
The end goal for me is to have all messages coming in from the Stomp
adaptor be bytes messages, unless someone has an overriding need for
something else (quote possible). The current behavior is pretty bad
as a default, but we just released 4.0 with it, so we are stuck until
we make another backwards incompatible release (5.0).
In 4.1 we can add the amq-msg-type header to allow people to force
things to bytes (or text) but for the 5.0 end game we will need to
make the mapping pluggable in order to make the upgrade path as easy
as possible. if we are going to need pluggable eventually, why not do
it now in order to allow people to fix the bytes/text mistake (I can
say it is a mistake, I wrote it =) at the server level instead of
having to add a header to every message.
We have, then, three configurations which people are likely to want:
1) Current (3.2 and 4.0 compatible) one which is made more palatable
by letting the client specify via the amq-msg-type.
2) Map everything to bytes, which I would like to make the default in
5.0.
3) Map everything to Text (which is what I would actually use if we
had it as I convert all the bytes ones I send now into strings anyway).
If we are going to have it be sufficiently pluggable to support these
three, we should consider letting users provide their own.
-Brian
Re: STOMP and JMSType
Posted by Nathan Mittler <na...@gmail.com>.
Hi Brian,
Thanks for the response. Comments inline ....
On 6/12/06, Brian McCallister <br...@apache.org> wrote:
>
> JMSType is a reserved header in JMS, for use at the application
> level. I think what you are proposing is more accurately an ActiveMQ
> specific transform header. I think this type of transform should
> either be a real, arbitrary, pluggable, transform mechanism, or
> should not be done.
Agreed ... using the "type" header is not an option.
I would much prefer to *always* use a bytes message, but this is
> backwards incompatible so cannot be done in 4.X.
>
> I would propose that instead of overloading JMSType, if we think we
> need to have a transform/mapping mechanism we base it on an active-mq
> specific header, and make it something like:
>
> STOMPMessageTransformer {
> public ActiveMQMessage transform
> (SomeRepresentationOfTheSendFrameIncludingHeaders frame) {
> ...
> }
> }
>
> I am not convinced we need this, but I much prefer it to a hardcoded
> transform, as this would allow for much more useful transforms (ie,
> aplication-aware).
Although I agree conceptually, I'm thinking this might be a bit of an
overkill for the task at hand. Right now the STOMP transport only works
with bytes and text messages, and creating this transform model won't change
that. I think if we one day decide to refactor the transport to accept
other message types - that would be the time to make this sort of change.
I think that, properly, this should be done by a service on the
> messaging bus though, NOT in a protocol handler.
The logic to choose which message to create already lies in the transport,
I'm just changing the logic. If we want to refactor this, then I think that
is another JIRA issue for another day (and discussion :) ).
-Brian
>
Thanks,
Nate
Re: STOMP and JMSType
Posted by Brian McCallister <br...@apache.org>.
JMSType is a reserved header in JMS, for use at the application
level. I think what you are proposing is more accurately an ActiveMQ
specific transform header. I think this type of transform should
either be a real, arbitrary, pluggable, transform mechanism, or
should not be done.
I would much prefer to *always* use a bytes message, but this is
backwards incompatible so cannot be done in 4.X.
I would propose that instead of overloading JMSType, if we think we
need to have a transform/mapping mechanism we base it on an active-mq
specific header, and make it something like:
STOMPMessageTransformer {
public ActiveMQMessage transform
(SomeRepresentationOfTheSendFrameIncludingHeaders frame) {
...
}
}
I am not convinced we need this, but I much prefer it to a hardcoded
transform, as this would allow for much more useful transforms (ie,
aplication-aware).
I think that, properly, this should be done by a service on the
messaging bus though, NOT in a protocol handler.
-Brian
On Jun 12, 2006, at 12:59 PM, Mittler, Nathan wrote:
> I'm working on fixing the way the STOMP transport determines Text and
> Bytes messages for issue AMQ-739. Previously we keyed off of the
> content-length header - if it was there, it's a bytes message, and
> otherwise it's a text message.
>
>
>
> Since all STOMP messages can have content-length, we need to use
> JMSType
> to distinguish in these cases. To do this, we need to define standard
> JMSType values for Text and Bytes messages. I have a build that uses
> "text" and "bytes" as the standard values for the "type" header.
> On the
> broker side, the logic in Send.java looks like this ...
>
>
>
> ****** BEGIN CODE ******
>
>
>
> // Assume the message is a bytes message.
>
> Boolean isBytesMessage = true;
>
>
>
> // If the message does not contain a content length,
>
> // we have to assume it's a text message - first zero
>
> // we encounter denotes the end of the frame.
>
> If( !headers.containsKey(Stomp.Headers.CONTENT_LENGTH) ){
>
> isBytesMessage = false;
>
> }
>
> // There is a content length specified,
>
> // now use JMSType to determine the message type (default to bytes if
> none specified)
>
> else if( headers.containsKey( Stomp.Headers.Send.TYPE ) ){
>
> isBytesMessage =
> (headers.getProperty(Stomp.Headers.Send.TYPE) ==
> Stomp.Headers.TypeValues.BYTES);
>
> }
>
>
>
> if( isBytesMessage ){
>
> // create a bytes message.
>
> }else{
>
> // create a text message.
>
> }
>
>
>
> ****** END CODE *******
>
>
>
> Any objections?
>
>
>
> Regards,
>
> Nate
>
>
>
>
>