Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#1571 closed defect (not a bug)

Http compression has zero or negative benefit for non html files

Reported by: DjJeshk Owned by:
Priority: minor Milestone: undecided
Component: apps/i2ptunnel Version: 0.9.19
Keywords: Cc:
Parent Tickets: Sensitive: no


I2P version: 0.9.19-18
Java version: Oracle Corporation 1.8.0_45 (Java™ SE Runtime Environment 1.8.0_45-b15)
Wrapper version: 3.5.25
Server version: 8.1.17.v20150415
Servlet version: Jasper JSP 2.1 Engine
Platform: Windows 7 x86 6.1
Processor: Core 2 (45nm) (core2)
Jbigi: Locally optimized library jbigi-windows-core2.dll loaded from file
Encoding: Cp1257
Charset: windows-1257

Did a thread dump for most CPU hungry threads affected by #1506 and noticed that compression is used for every http transfer.

"I2PTunnel Client Runner 5" #283 daemon prio=5 os_prio=0 tid=0x28cfd400 nid=0x124c in Object.wait() [0x2c60f000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at Source)
	- locked <0x125c1700> (a
	at net.i2p.util.ResettableGZIPInputStream$
	at Source)
	at Source)
	at net.i2p.i2ptunnel.HTTPResponseOutputStream$
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$ Source)
	at Source)

"I2PTunnel Client Runner 4" #282 daemon prio=5 os_prio=0 tid=0x28cfcc00 nid=0x1030 in Object.wait() [0x2c5bf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Object.wait(Native Method)
	at net.i2p.client.streaming.impl.Connection.packetSendChoke(
	- locked <0x125c1b90> (a java.util.TreeMap)
	at net.i2p.client.streaming.impl.PacketLocal.waitForAccept(
	at net.i2p.client.streaming.impl.MessageOutputStream.write(
	at Source)
	at Source)
	at Source)
	- locked <0x125c1f18> (a net.i2p.i2ptunnel.I2PTunnelHTTPServer$InternalGZIPOutputStream)
	at net.i2p.i2ptunnel.HTTPResponseOutputStream.write(
	at net.i2p.i2ptunnel.I2PTunnelHTTPServer$
	at net.i2p.i2ptunnel.I2PTunnelHTTPServer$
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$ Source)
	at Source)

Most traffic are generated by images and other already compressed data. Use of another layer of compression is completely unneeded. This looks like you created compressed archive and try to compress again (stupid waste of power).
Even Jetty is configurable to generate compressed traffic so there is no need for additional compression layer. I do not know what about developers were thinking when this "feature" was implemented.


Change History (2)

comment:1 Changed 6 years ago by zzz

Resolution: not a bug
Status: newclosed

No, we don't do compression for "every http transfer". Don't believe everything you read.

While I appreciate your enthusiasm for testing and reporting bugs, your comments about 'stupid" and "what were we thinking" are very much not appreciated. Please do not make any assumptions or speculation on our lack of intelligence or thought process again, it is unproductive and it doesn't make it any more likely that we're going to take your bug reports seriously.

comment:2 Changed 6 years ago by DjJeshk

Sorry about my harassment, my mates who I see almost every day sometimes are so lazy that such attack needs to be done to get things working (maybe too much). You are not taking make thoughts seriously before this "gift", so I should worry even less. Do not try to give up, anonymity opponents will only become happier.

Take me seriously or not, but big incompressible file has gone through GZIP streams twice at the same time.

Could you provide details about implemented GZIP stream on http (compression level, chunk size)?

Note: See TracTickets for help on using tickets.