Thank you for your prompt reply. I will try to do some memory profiling.
If the problem didn't was my fault (as probably it is) I would inform
about that in this mailing list.
Jordi.
En/na Paul Sandoz ha escrit:
> 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. 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
--
.............................................................
:: 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
.............................................................