users@jersey.java.net

Re: [Jersey] Jersey leaving streams open

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 26 May 2008 10:43:25 +0200

On May 26, 2008, at 10:33 AM, Paul Sandoz wrote:

> Hi Jordi,
>
> This is the code from the trunk (and for 0.7 [1]) that writes out
> the data from the InputStream:
>
> public void writeTo(
> InputStream t,
> Class<?> type,
> Type genericType,
> Annotation annotations[],
> MediaType mediaType,
> MultivaluedMap<String, Object> httpHeaders,
> OutputStream entityStream) throws IOException {
> try {
> writeTo(t, entityStream);
> } finally {
> t.close();
> }
> }
>
> As you can see the finally block will close the stream.
>
> I have done performance tests, using Glassfish, that repeatedly
> send/receive both small and large ByteArray*Stream data sets and
> have encountered out of memory issues.
                                      ^
                                      |
                                *not*

Paul.


> I have not tested the LW HTTP server for such as case, but i do
> make sure i flush and close everything (for 0.7 and trunk).
>
> Is it possible to run a memory profiler on your server code? If
> using NB 6.x this is rather easy to do (see the top-level Profile
> menu).
>
> Paul.
>
> [1] https://jersey.dev.java.net/source/browse/*checkout*/jersey/
> tags/jersey-0.7/jersey/src/impl/com/sun/ws/rest/impl/provider/
> entity/InputStreamProvider.java
> On May 26, 2008, at 9:51 AM, Jordi Cucurull Juan wrote:
>
>> Hi,
>>
>> I am recently using Jersey to create a server of code. The idea is
>> downloading and uploading code using a REST interface. The problem I
>> have is that doing performance tests, after serving approximately
>> 3000
>> codes of 70KB each one, the application gets out of memory. I
>> thought it
>> could happen by a mistake closing the files where the code
>> resides, but
>> this is an operation which is automatically done by the Jersey,
>> since I
>> serve this code through an InputStream:
>>
>> resp = Response.ok(is).type
>> (MediaType.APPLICATION_OCTET_STREAM).build();
>>
>> where "is" is the InputStream to the file. Then, I read some
>> messages in
>> the Jersey users newslist and I saw that some time ago there were a
>> problem closing these streams. Is it possible that this problem has
>> reappeared now? I am using Jersey 0.7ea. I include the error
>> thrown in
>> the following lines:
>>
>> Exception in thread "Thread-2" java.lang.OutOfMemoryError: Java
>> heap space
>> at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:39)
>> at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
>> at sun.net.httpserver.Request$WriteStream.write
>> (Request.java:383)
>> at
>> sun.net.httpserver.ChunkedOutputStream.writeChunk(ChunkedOutputStream
>> .java:104)
>> at
>> sun.net.httpserver.ChunkedOutputStream.write(ChunkedOutputStream.java
>> :68)
>> at
>> sun.net.httpserver.PlaceholderOutputStream.write(ExchangeImpl.java:37
>> 5)
>> at
>> com.sun.ws.rest.impl.provider.entity.AbstractMessageReaderWriterProvi
>> der.writeTo(AbstractMessageReaderWriterProvider.java:65)
>> at
>> com.sun.ws.rest.impl.provider.entity.InputStreamProvider.writeTo(Inpu
>> tStreamProvider.java:66)
>> at
>> com.sun.ws.rest.impl.provider.entity.InputStreamProvider.writeTo(Inpu
>> tStreamProvider.java:37)
>> at
>> com.sun.ws.rest.spi.container.AbstractContainerResponse.writeEntity(A
>> bstractContainerResponse.java:270)
>> at
>> com.sun.ws.rest.impl.container.httpserver.HttpServerResponseAdaptor.c
>> ommitAll(HttpServerResponseAdaptor.java:83)
>> at
>> com.sun.ws.rest.impl.container.httpserver.HttpHandlerContainer.handle
>> (HttpHandlerContainer.java:72)
>> at com.sun.net.httpserver.Filter$Chain.doFilter
>> (Filter.java:65)
>> at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:65)
>> at com.sun.net.httpserver.Filter$Chain.doFilter
>> (Filter.java:68)
>> at
>> sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.
>> java:552)
>> at com.sun.net.httpserver.Filter$Chain.doFilter
>> (Filter.java:65)
>> at sun.net.httpserver.ServerImpl$Exchange.run
>> (ServerImpl.java:524)
>> at
>> sun.net.httpserver.ServerImpl$DefaultExecutor.execute(ServerImpl.java
>> :119)
>> at
>> sun.net.httpserver.ServerImpl$Dispatcher.handle(ServerImpl.java:349)
>> at sun.net.httpserver.ServerImpl$Dispatcher.run
>> (ServerImpl.java:321)
>> at java.lang.Thread.run(Thread.java:619)
>>
>> Thank you for you help,
>> Jordi.
>>
>> --
>>
>>
>> .............................................................
>> :: Jordi Cucurull Juan :: Phone: +34 93 581 3577
>> :: (jcucurull_at_deic.uab.cat)
>> Departament d'Enginyeria de la Informacio i les Comunicacions
>> Universitat Autonoma de Barcelona - 08193 Bellaterra, Spain
>> .............................................................
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>