Hi Felix,
Ive looked again at this issue and dont see why it occurs. The close()
method should be invoked by the HTTP server connector already, sometimes
after the write().
Otherwise, in the ByteUtils class we only close the inputstream when copying
it to an outputstream, but not the outputstream itself (at least in SVN
trunk).
Therefore, I suspect a JVM issue and just entered a report:
http://restlet.tigris.org/issues/show_bug.cgi?id=1066
Could you try setting a breakpoint on the DeflaterOutputStream#close()
method and see if it is indeed called by the HTTP server connector? BTW,
which connector are you using?
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Technical Lead ~ <http://www.restlet.org/>
http://www.restlet.org
Noelios Technologies ~ <http://www.noelios.com/> http://www.noelios.com
De : Thierry Boileau [mailto:[email protected]]
Envoyé : vendredi 19 février 2010 18:09
À : [email protected]
Objet : Re: Memory problem using EncodeRepresentation with Gzip
Hello Felix,
do you mind to create an issue about this problem?
We don't see clearly why it could be appropriate to close the stream in the
"write" method.
Another point is that this may be related to concurrency and threads, but in
this case, the fix should be handled in another way.
This could also be related to the implementation of the JVM.
Best regards,
Thierry Boileau
Hi,
we are using Restlet 1.1.8 with spring on a tomcat server. We switched
to the EncodeRepresentation with Gzip to reduce the traffic on client
side. This works fine for most systems, but on one system the jvm
crashes after a few minutes with client requests (ubuntu on an xen host).
The java process grows up to more than 3GB and crashes with a fatal error.
The EncodeRepresentation only calls finish() and not close() on the
GzipOutputStream. The GzipOutputStream calls the end() method on the
native gzip deflater at the close() method not at the finish().
A lot of other Represenations uses the ByteUtils to write the stream and
there is close() on the steam. I put encoderOutputStream.close(); next
to the finish at the write method of the EncodeRepresentation and the
server runs.
Is it safe to close the stream?
I do not know why the problem only exists on the xen system. The heap
size is the same, so the gc should work (and close the streams) similar
to all other tomcats.
Thanks,
Felix
@Override
public void write(final OutputStream outputStream) throws IOException {
if (canEncode()) {
DeflaterOutputStream encoderOutputStream = null;
if (encoding.equals(Encoding.GZIP)) {
encoderOutputStream = new GZIPOutputStream(outputStream);
} else if (encoding.equals(Encoding.DEFLATE)) {
encoderOutputStream = new
DeflaterOutputStream(outputStream);
} else if (encoding.equals(Encoding.ZIP)) {
final ZipOutputStream stream = new
ZipOutputStream(outputStream);
if (getWrappedRepresentation().getDownloadName() != null) {
stream.putNextEntry(new
ZipEntry(getWrappedRepresentation().getDownloadName()));
} else {
stream.putNextEntry(new ZipEntry("entry"));
}
encoderOutputStream = stream;
} else if (encoding.equals(Encoding.IDENTITY)) {
// Encoder unecessary for identity encoding
}
if (encoderOutputStream != null) {
getWrappedRepresentation().write(encoderOutputStream);
encoderOutputStream.finish();
encoderOutputStream.close();
} else {
getWrappedRepresentation().write(outputStream);
}
} else {
getWrappedRepresentation().write(outputStream);
}
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2464783
