You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by jhakim <ja...@codestreet.com> on 2006/08/09 23:20:47 UTC

Compression from provider to consumer

Is compression of payload done only from publisher to JMS provider or all the
way from publisher to JMS provider to consumer?

If the answer is (as I would prefer it to be) that compression of message
body is done all the way from publisher to client, then the follow up
question is whether or not compression is available (using NMS) if the
publisher is a Java process and the consumer is a C# process.
-- 
View this message in context: http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5734124
Sent from the ActiveMQ - User forum at Nabble.com.


Re: Compression from provider to consumer

Posted by James Strachan <ja...@gmail.com>.
On 8/10/06, jhakim <ja...@codestreet.com> wrote:
>
> There is a great port of the JAVA compression package to .NET. Check out
> http://www.icsharpcode.net/OpenSource/SharpZipLib/.
>
> Using the .NET port the uncompression is comething like:
>
>                 private static byte[] Inflate(byte[] bytes)
>                 {
>                         MemoryStream mis = new MemoryStream();
>                         mis.Write(bytes, 0, bytes.Length);
>                         mis.Flush();
>                         mis.Position = 0;
>                         Stream ins = new GZipInputStream(mis);
>
>                         MemoryStream mos = new MemoryStream();
>                         byte[] buf = new byte[102400];
>                         while (true)
>                         {
>                                 int count = ins.Read(buf, 0, buf.Length);
>                                 if (count == 0)
>                                         break;
>                                 mos.Write(buf, 0, count);
>                         }
>                         ins.Close();
>                         mos.Position = 0;
>                         byte[] uncompressedBytes = new byte[mos.Length];
>                         mos.Read(uncompressedBytes, 0, uncompressedBytes.Length);
>                         mos.Close();
>
>                         return uncompressedBytes;
>                 }
>
>
> In the case of the bond trading sysetm that I am working on compression is
> required only from the server (java) to client (.NET). I am sure that
> compression code in .NET is pretty straightforward as well.

Great, thanks!

Unfortunately that library is GPL so I'm afraid we can't use it though.
http://people.apache.org/~cliffs/3party.html

I wonder if they'd dual licence it?

-- 

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

Re: Compression from provider to consumer

Posted by jhakim <ja...@codestreet.com>.
There is a great port of the JAVA compression package to .NET. Check out
http://www.icsharpcode.net/OpenSource/SharpZipLib/. 

Using the .NET port the uncompression is comething like:

		private static byte[] Inflate(byte[] bytes)
		{
			MemoryStream mis = new MemoryStream();
			mis.Write(bytes, 0, bytes.Length);
			mis.Flush();
			mis.Position = 0;
			Stream ins = new GZipInputStream(mis);

			MemoryStream mos = new MemoryStream();
			byte[] buf = new byte[102400];
			while (true)
			{
				int count = ins.Read(buf, 0, buf.Length);
				if (count == 0)
					break;
				mos.Write(buf, 0, count);
			}
			ins.Close();
			mos.Position = 0;
			byte[] uncompressedBytes = new byte[mos.Length];
			mos.Read(uncompressedBytes, 0, uncompressedBytes.Length);
			mos.Close();

			return uncompressedBytes;
		}


In the case of the bond trading sysetm that I am working on compression is
required only from the server (java) to client (.NET). I am sure that
compression code in .NET is pretty straightforward as well. 


James.Strachan wrote:
> 
> On 8/10/06, jhakim <ja...@codestreet.com> wrote:
>>
>> I can answer that - yes. .NET has extensive built-in support for
>> compression.
> 
> Great - thanks. Do you fancy submitting some C# code to deal with
> compression? :)
> 
> James
> 
>>
>>
>> Hiram Chirino wrote:
>> >
>> > On 8/9/06, jhakim <ja...@codestreet.com> wrote:
>> >>
>> >> Is compression of payload done only from publisher to JMS provider or
>> all
>> >> the
>> >> way from publisher to JMS provider to consumer?
>> >>
>> >
>> > publisher compresses and the consumer decompresses.  Broker just moves
>> > around a byte[] payload (he does not care if it's compressed or not).
>> >
>> >> If the answer is (as I would prefer it to be) that compression of
>> message
>> >> body is done all the way from publisher to client, then the follow up
>> >
>> > Yep.
>> >
>> >> question is whether or not compression is available (using NMS) if the
>> >> publisher is a Java process and the consumer is a C# process.
>> >
>> > I don't think the C# client supports payload compression and
>> > decompression yet.  This is one of the reasons that compression is off
>> > by default.  Anybody know of .NET has gzip compression algorithms
>> > included in the platform APIs?
>> >
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5734124
>> >> Sent from the ActiveMQ - User forum at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Regards,
>> > Hiram
>> >
>> > Blog: http://hiramchirino.com
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5745175
>> Sent from the ActiveMQ - User forum at Nabble.com.
>>
>>
> 
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 

-- 
View this message in context: http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5750569
Sent from the ActiveMQ - User forum at Nabble.com.


Re: Compression from provider to consumer

Posted by James Strachan <ja...@gmail.com>.
On 8/10/06, jhakim <ja...@codestreet.com> wrote:
>
> I can answer that - yes. .NET has extensive built-in support for compression.

Great - thanks. Do you fancy submitting some C# code to deal with
compression? :)

James

>
>
> Hiram Chirino wrote:
> >
> > On 8/9/06, jhakim <ja...@codestreet.com> wrote:
> >>
> >> Is compression of payload done only from publisher to JMS provider or all
> >> the
> >> way from publisher to JMS provider to consumer?
> >>
> >
> > publisher compresses and the consumer decompresses.  Broker just moves
> > around a byte[] payload (he does not care if it's compressed or not).
> >
> >> If the answer is (as I would prefer it to be) that compression of message
> >> body is done all the way from publisher to client, then the follow up
> >
> > Yep.
> >
> >> question is whether or not compression is available (using NMS) if the
> >> publisher is a Java process and the consumer is a C# process.
> >
> > I don't think the C# client supports payload compression and
> > decompression yet.  This is one of the reasons that compression is off
> > by default.  Anybody know of .NET has gzip compression algorithms
> > included in the platform APIs?
> >
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5734124
> >> Sent from the ActiveMQ - User forum at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5745175
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>


-- 

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

Re: Compression from provider to consumer

Posted by jhakim <ja...@codestreet.com>.
I can answer that - yes. .NET has extensive built-in support for compression.


Hiram Chirino wrote:
> 
> On 8/9/06, jhakim <ja...@codestreet.com> wrote:
>>
>> Is compression of payload done only from publisher to JMS provider or all
>> the
>> way from publisher to JMS provider to consumer?
>>
> 
> publisher compresses and the consumer decompresses.  Broker just moves
> around a byte[] payload (he does not care if it's compressed or not).
> 
>> If the answer is (as I would prefer it to be) that compression of message
>> body is done all the way from publisher to client, then the follow up
> 
> Yep.
> 
>> question is whether or not compression is available (using NMS) if the
>> publisher is a Java process and the consumer is a C# process.
> 
> I don't think the C# client supports payload compression and
> decompression yet.  This is one of the reasons that compression is off
> by default.  Anybody know of .NET has gzip compression algorithms
> included in the platform APIs?
> 
>> --
>> View this message in context:
>> http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5734124
>> Sent from the ActiveMQ - User forum at Nabble.com.
>>
>>
> 
> 
> -- 
> Regards,
> Hiram
> 
> Blog: http://hiramchirino.com
> 
> 

-- 
View this message in context: http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5745175
Sent from the ActiveMQ - User forum at Nabble.com.


Re: Compression from provider to consumer

Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 8/9/06, jhakim <ja...@codestreet.com> wrote:
>
> Is compression of payload done only from publisher to JMS provider or all the
> way from publisher to JMS provider to consumer?
>

publisher compresses and the consumer decompresses.  Broker just moves
around a byte[] payload (he does not care if it's compressed or not).

> If the answer is (as I would prefer it to be) that compression of message
> body is done all the way from publisher to client, then the follow up

Yep.

> question is whether or not compression is available (using NMS) if the
> publisher is a Java process and the consumer is a C# process.

I don't think the C# client supports payload compression and
decompression yet.  This is one of the reasons that compression is off
by default.  Anybody know of .NET has gzip compression algorithms
included in the platform APIs?

> --
> View this message in context: http://www.nabble.com/Compression-from-provider-to-consumer-tf2081319.html#a5734124
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com