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:
"/j:FeatureCollection/featureMembers/j:Flight/track/j:JourneyStatus/validtime/TimeInstant/timePosition" 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... Cheers, -C -- View this message in context: http://www.nabble.com/Greater-Openwire-MapMessage-efficiency-tf4094367s2354.html#a11642343 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
