activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: Recent OpenWire changes
Date Thu, 02 Mar 2006 21:01:20 GMT
Mats,

That's correct.

Regards,
Hiram

On Mar 2, 2006, at 7:39 AM, Mats Forslöf wrote:

> Most informative, thanks Hiram. Is it correct that the C# client  
> only supports tight marshalling at the moment?
>
> Regards,
> Mats
>
> -----Original Message-----
> From: Hiram Chirino [mailto:hiram@hiramchirino.com]
> Sent: den 1 mars 2006 19:26
> To: activemq-dev@geronimo.apache.org
> Subject: Recent OpenWire changes
>
> Hi Everybody,
>
> Just a quick heads up,  openwire by default tries to encode commands
> as tight as possible on the wire to decrease bandwidth requirements.
> To do this, it currently uses a 2 pass algorithm where the first  
> pass collects all boolean writes into a bit array and pre  
> calculates the size of the command on the wire.  The second pass  
> writes the command to the stream.
>
> While this produces small on the wire size, it's  a bit CPU  
> intensive, so I made a change so that a loose encoding is also  
> possible which marshals the messages in a single pass and avoids  
> doing all the fancy things that the tight encoding was using.   
> Using loose encoding should make sense if your broker is CPU bound  
> and network bandwidth is not an issue.  So if you look at the open  
> wire classes you will now see a bunch of tightMarshal/Unmarshal and  
> looseMarshal/Unmarshal methods.
>
> Another option that has been added is the ability to omit the  
> command size prefix on the serialized commands.  The command size  
> prefix is actually only useful for non blocking implementations  
> where we only want to unmarshal the command once it has been fully  
> received.  In normal blocking IO, knowing the size of the command  
> in not necessary.  By omitting the command size, we should be able  
> to do more efficient marshaling of the command since we don't have  
> to calculate the command size beforehand.
>
> These default options are still at what they were before (tight  
> encoding and command size prefixing), but they can be negotiated  
> between the client and server with the WireFormatInfo packet.
>
> Regards,
> Hiram


Mime
View raw message