Well after many years of thinking about it, it didn't take long to
implement, below is a configuration file entry for deflate
compression. Performance impact is no noticeable I'm not getting any
hotspot's for compression / decompression. It would probably make
sense for a registrar, but not so much for a service that doesn't return
a large number of results or is unlikely to receive large parameters.
Cheers,
Peter.
/* the exporter for test listeners */
integrityExporter = new BasicJeriExporter(
SslServerEndpoint.getInstance(0),
new AtomicILFactory(
new StringMethodConstraints(
new InvocationConstraints(
new InvocationConstraint[]{
Integrity.YES,
AtomicInputValidation.YES},
null
)
),
AccessPermission.class,
org.apache.river.test.share.BaseQATest.class,
Compression.DEFLATE
)
);
On 6/8/2020 2:58 PM, Peter Firmstone wrote:
Hello River folk,
A couple of years or so ago I was working on using Pack200 for
compression of proxy codebases, then it was deprecated and more
recently removed from Java 14.
Initially I took pack 200 from Harmony and started working on that, at
the time I thought the JDK version was written in C. But then it
turned out there was a java version of Pack200 in the openJDK.
I haven't focused on this recently, however I registered the
pack200.net domain, so that I could release on Maven Central. The
OpenJDK version supports Java 8, while the Harmony version is Java
5. It also seem that not a lot of work is required to get this up to
date for the latest bytecode.
https://github.com/pfirmstone/pack200
https://github.com/pfirmstone/Pack200-ex-openjdk
The other thing I've long considered using is deflate, gzip or zip
compression of marshalled streams. This is actually very easy to
code up into a JERI InvocationLayerFactory implementation, however
I've had other priorities and never gotten around to.
I wanted to determine whether there is interest in improving
performance using compression?
Regards,
Peter.
