activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From huntc <>
Subject Greater Openwire MapMessage efficiency
Date Tue, 17 Jul 2007 03:20:08 GMT

Hi there,

I've started encoding XML messages with MapMessage objects. To do this I use
the name of the map to provide an Xpath expression into the document that
the value represents e.g. a name might be:


The benefit of this approach is that:
(i) the client/server code is readable; and
(ii) an XML document can be reconstructed by the client.

In the interests of efficiency I'm thinking of representing the Xpath
expression numerically to reduce it to a 32 bit number - possibly using
Java's String hashCode method to generate it. Thus a hex string name could
be something like "0F1C3D4A" i.e. 8 UTF-8 characters. Naturally one has to
consider possible duplicate hash keys for different string values... that
shouldn't be a big issue though.

This got me thinking - I started to wonder whether there had ever been any
consideration for efficiently passing map messages with Openwire (more so
than it presently does of course). What I'm thinking is that Openwire could
provide a map key name -> number translation of known keys upon a client
first requesting/subscribing to a queue/topic respectively. For new keys
that are published the protocol could update its translation table and also
send out the new translation information to the client.

As I recall from my Tuxedo days, key name elements were passed as numbers
and each client had to #include that mapping. Naturally if that number
scheme was updated then it could break each client. Thus my thinking on
hashing the key name so that their values are more resilient to keys being
added or removed.

Is the incorporation of hashing map message key values something that has
been thought out before?

Indeed, is this something that should be exposed at the JMS level - perhaps
a HashKeyMapMessage class...

View this message in context:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message