Serve command in RAW mode: java.io.IOException on Ubuntu

[GoogleCodeExporter]

I recently started to see the following exceptions when using raw mode.
That only happens on my Ubuntu box - same code & config run just fine on MacOs 
and Windows.

Some idea, how I could fix this? Maybe use a different JDK or so?

Oct 11, 2010 7:42:32 PM org.plovr.AbstractGetHandler handle
SEVERE: Error during GET request to 
/input?id=content-browser-app&name=%2Fcore%2Ftt%2Futils%2Ftracking_helper.js
java.io.IOException: too many bytes to write to stream
    at sun.net.httpserver.FixedLengthOutputStream.write(FixedLengthOutputStream.java:76)
    at sun.net.httpserver.PlaceholderOutputStream.write(ExchangeImpl.java:411)
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220)
    at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:315)
    at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:148)
    at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
    at org.plovr.InputFileHandler.doGet(InputFileHandler.java:153)
    at org.plovr.AbstractGetHandler.handle(AbstractGetHandler.java:50)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83)
    at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:86)
    at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:589)
    at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83)
    at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:561)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:636)

Original issue reported on code.google.com by carsten.kraus on 11 Oct 2010 at 6:07

[GoogleCodeExporter]

Are you running Sun/Oracle Java? On my Ubuntu box, I had to make sure to 
apt-get install sun-java6-jdk (as opposed to openjdk or icedtea or whatever).

Though even if you have the right Java installed, /usr/bin/java might not point 
to it. In that case, you have to run update-java-alternatives to fix this:

https://help.ubuntu.com/community/Java

I have been burned by the "wrong Java" a number of times on Ubuntu, so it's 
always good to make sure that you are running the Sun/Oracle one.

Please let me know whether this fixes the bug,
Michael

Original comment by bolinf...@gmail.com on 14 Oct 2010 at 2:17

[GoogleCodeExporter]

Thanks for the hints!

Hm, I actually tried several things and from what I can tell I already use the 
sun version.
Following your hints I get:
$ sudo update-java-alternatives -s java-6-sun
update-alternatives: error: no alternatives for xulrunner-1.9-javaplugin.so.
update-alternatives: error: alternative 
/usr/lib/jvm/java-6-sun/jre/lib/amd64/libnpjp2.so for mozilla-javaplugin.so not 
registered, not setting.
update-alternatives: error: no alternatives for xulrunner-1.9-javaplugin.so.

Anyway, when I directly point to the sun version all should be fine, no? But 
using:
/usr/lib64/jvm/java-6-sun/bin/java -jar plovr.jar serve plovr-config.json

..still produces:
java.io.IOException: too many bytes to write to stream
    at sun.net.httpserver.FixedLengthOutputStream.write(FixedLengthOutputStream.java:58) ...

(same behaviour with /usr/lib/jvm/... btw)

Is it a problem that jre/bin/java is being linked?
$ ll /usr/lib64/jvm/java-6-sun/bin/java
lrwxrwxrwx 1 root root 15 2010-10-14 16:28 /usr/lib64/jvm/java-6-sun/bin/java 
-> ../jre/bin/java

Thanks again,
Carsten

Original comment by carsten.kraus on 14 Oct 2010 at 4:36

[GoogleCodeExporter]

Fyi I tried again on a freshly installed Ubuntu(32-bit this time, with no 
default, icedtea, whatever sdk installed).

$ update-java-alternatives -l
java-6-sun 63 /usr/lib/jvm/java-6-sun
$

Still the same problem with RAW mode. 

Googling for the error I found 
http://forums.sun.com/thread.jspa?threadID=5422445
There's an assumption that the Content-length might be a problem. Mayve thats 
related?

Cheers, Carsten

Original comment by carsten.kraus on 15 Oct 2010 at 5:01

[GoogleCodeExporter]

Hmm, that's certainly possible as I am probably sloppy with respect to getting 
the byte count right if non-latin1 characters are used -- are you using 
non-latin characters in your code?

Original comment by bolinf...@gmail.com on 18 Oct 2010 at 2:11

[GoogleCodeExporter]

Hi Michael,

you were right - special chars like the German Umlauts(ä, ü, ö, € etc.) 
were causing the problem. 
Replacing them with their entity equivalents (ä € etc.) allowed to use raw 
mode, again.

Hm, I wonder, if I will be consistent enough to not get bitten by that, again : 
)
Do you have an idea, if wether you can have plovr be more tolerant to these 
encoding issues or if there's an easy way to check multiple files for such 
problematic content?

I think, in one or two cases the problem was not only caused by the Umlauts but 
by strange whitespace chars, too. 
Umlauts would be easily grep-able, I guess, but the strange whitespace maybe 
would not.

Thanks, Carsten

Original comment by carsten.kraus on 9 Nov 2010 at 3:16

[GoogleCodeExporter]

This problem also occurs when plovr tries to serve 
"/input/task/closure/goog/i18n/datetimesymbols.js", which contains a bunch of 
non-ascii characters.

The problem occurs both with java-6-openjdk and java-6-sun-1.6.0.22 on Ubuntu 
10.04.

How to serve at all datetimesymbol.js in RAW mode with this problem? Since RAW 
mode is essential for development and debugging, I think this should be 
considered a serious bug.

Original comment by david.al...@gmail.com on 18 Nov 2010 at 3:16

[GoogleCodeExporter]

Fyi I can reproduce Davids scenario: making use of eg goog.i18n.DateTimeFormat 
will stop me from being able to use raw mode.

Original comment by carsten.kraus on 29 Nov 2010 at 12:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I can confirm that this problem is triggered on Sun/Oracle's java on Archlinux 
current.

I use an LP tool that embeds text in three Western languages inside Javascript 
comments making use of non-Latin1 symbols. Since I cannot go and simply 
re-encode my source files, in my scenario it would be extremely convenient to 
correctly parse symbols while keeping the ability of using RAW mode for 
debugging purposes.

Original comment by ale...@ymail.com on 30 Nov 2010 at 1:40

[GoogleCodeExporter]

I finally had a chance to look into this tonight and fixed it in 
http://code.google.com/p/plovr/source/detail?r=4ee251d99814e4aa0669b7d240148f724
3501256

As explained in the changeset description, I need to audit the plovr codebase 
in general to make sure that a Charset is always specified and that the correct 
value for Content-Length is specified. I will do a release once I have done 
such an audit, but those of you who are blocked on this change are encouraged 
to build plovr from source.

Original comment by bolinf...@gmail.com on 1 Dec 2010 at 2:32

• Changed state: Fixed

[GoogleCodeExporter]

If you follow the change history, you can see I made a number of other utf-8 
related changes tonight. I'm going to run some more tests and hopefully I will 
do a new release in the next day or two.

I was hoping to wait until 
http://code.google.com/p/closure-compiler/issues/detail?id=289 got fixed before 
the next plovr release (since I need it for my project!), but I certainly won't 
hold up the plovr release for the Compiler bug since it's pretty clear quite a 
few of you need this utf-8 stuff resolved ASAP.

Original comment by bolinf...@gmail.com on 1 Dec 2010 at 4:51

[GoogleCodeExporter]

I wonder if this is the same issue but I got a similar one.
I only got this log when a soyweb serves multi-byte string from soy. What 
should I do?

May 12, 2014 1:57:12 PM org.plovr.soy.server.SoyRequestHandler handle
SEVERE: IO Error: response may not have been written
java.io.IOException: too many bytes to write to stream
        at sun.net.httpserver.FixedLengthOutputStream.write(FixedLengthOutputStream.java:76)
        at sun.net.httpserver.PlaceholderOutputStream.write(ExchangeImpl.java:444)
        at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
        at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316)
        at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
        at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
        at org.plovr.soy.server.SoyRequestHandler.doHandle(SoyRequestHandler.java:141)
        at org.plovr.soy.server.SoyRequestHandler.handle(SoyRequestHandler.java:70)
        at org.plovr.soy.server.RequestHandlerSelector.handle(RequestHandlerSelector.java:104)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
        at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:80)
        at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:677)
        at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77)
        at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:649)
        at sun.net.httpserver.ServerImpl$DefaultExecutor.execute(ServerImpl.java:158)
        at sun.net.httpserver.ServerImpl$Dispatcher.handle(ServerImpl.java:433)
        at sun.net.httpserver.ServerImpl$Dispatcher.run(ServerImpl.java:398)
        at java.lang.Thread.run(Thread.java:744)

Original comment by ThePigLo...@gmail.com on 12 May 2014 at 2:04