Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
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
[deleted comment]
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
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
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
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
Original issue reported on code.google.com by
carsten.kraus
on 11 Oct 2010 at 6:07