Jeanfrancois Arcand-2 wrote:
>
> Salut,
>
> Mark Hig wrote:
>> Hi,
>> I have had a quick try of your suggestion. I am not sure that this is the
>> answer. The JVM runs out of memory quite quickly at quite low loads.
>>
>> I am running an asynchronous Grizzly server, as mentioned above. I have
>> tried a simple ping style test through Grizzly that just provides a
>> simple
>> response. I have tested this set up with JMeter and it performs well on
>> my
>> laptop, running in Eclipse upto about 150 users.
>>
>> However, replacing the response with your suggested disconnect technique
>> in
>> the AsyncAdapter:
>>
>> Just call the following method and the connection will be resumed/closed:
>>
>> // Finish the response
>> processorTask.postResponse();
>>
>> // Clean up the objects
>> processorTask.postProcess();
>>
>> Internally, Grizzly will make sure the connection is closed and the
>> associated recycled (for re-use).
>>
>> (Obviously after doing the above, I can not do the Async callback to
>> clean
>> up because the processorTask no longer exists.)
>>
>> Grizzly runs out of memory within 2 minutes at only a 50 user load:
>
> Hum that's strange. Can you share your code so I can take a look? I
> suspect ProcessorTask aren't recycled properly. As an example, just take
> a look at how I do that for Grizzly Comet:
>
> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/comet/CometAsyncFilter.html
> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/comet/CometEngine.html
>
> When resuming the connection, I've just manipulate the
> AsynchProcessorTask(apt) by first making sure the request/response
> object are properly recycled:
>
> 532 apt.setStage(AsyncTask.POST_EXECUTE);
> 533 try{
> 534 apt.doTask();
> 535 } catch (IllegalStateException ex){
> 536 if (logger.isLoggable(Level.FINEST)){
> 537 logger.log(Level.FINEST,"flushResponse failed",ex);
> 538 }
> 539 } catch (IOException ex) {
> 540 logger.log(Level.SEVERE,"flushResponse failed",ex);
> 541 }
>
> then resume
>
> AsyncHandler.removeFromInterruptedQueue(apt);
>
> The exception below really means ProcessorTask aren't recycled and you
> end up with too many of them.
>
>>
>> SEVERE: Java heap space
>> java.lang.OutOfMemoryError: Java heap space
>> at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:39)
>> at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
>> at
>> com.sun.grizzly.http.SocketChannelOutputBuffer.<init>(SocketChannelOutputBuffer.java:105)
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.initialize(DefaultProcessorTask.java:425)
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.preProcess(DefaultProcessorTask.java:477)
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.preProcess(DefaultProcessorTask.java:463)
>> at
>> com.sun.grizzly.arp.DefaultAsyncExecutor.preExecute(DefaultAsyncExecutor.java:138)
>> at
>> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:90)
>> at com.sun.grizzly.http.TaskBase.call(TaskBase.java:359)
>> at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>> 03-Jul-2008 15:55:17 com.sun.grizzly.http.DefaultProcessorTask
>> postResponse
>> SEVERE: processorTask.errorFinishingResponse
>> java.lang.NullPointerException
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.postResponse(DefaultProcessorTask.java:585)
>> at
>> com.sun.grizzly.arp.DefaultAsyncExecutor.postExecute(DefaultAsyncExecutor.java:191)
>> at
>> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:101)
>> at com.sun.grizzly.http.TaskBase.call(TaskBase.java:359)
>> at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>> 03-Jul-2008 15:55:17 com.sun.grizzly.arp.AsyncProcessorTask doTask
>> SEVERE: null
>> java.lang.NullPointerException
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.postResponse(DefaultProcessorTask.java:608)
>> at
>> com.sun.grizzly.arp.DefaultAsyncExecutor.postExecute(DefaultAsyncExecutor.java:191)
>> at
>> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:101)
>> at com.sun.grizzly.http.TaskBase.call(TaskBase.java:359)
>> at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>> 03-Jul-2008 15:55:17 com.sun.grizzly.util.WorkerThreadImpl run
>> SEVERE: WorkerThreadImpl unexpected exception:
>> java.lang.RuntimeException: java.lang.NullPointerException
>> at
>> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:112)
>> at com.sun.grizzly.http.TaskBase.call(TaskBase.java:359)
>> at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>> Caused by: java.lang.NullPointerException
>> at
>> com.sun.grizzly.http.DefaultProcessorTask.postResponse(DefaultProcessorTask.java:608)
>> at
>> com.sun.grizzly.arp.DefaultAsyncExecutor.postExecute(DefaultAsyncExecutor.java:191)
>> at
>> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:101)
>> ... 2 more
>>
>> This suggests that Grizzly is not clearing its resources when I am trying
>> to
>> close the connection.
>
> Exactly.
>
>
>>
>>
>> Trying Oleksiy's suggestion of just cancelling the key:
>>
>> Grizzly, by default, doesn't have any resource associated with the
>> connection - so it should be safe enough to close connection using
>> method:
>> SelectionKeyHandler.cancel(SelectionKey)
>>
>>
>> Grizzly throws the following errors for each cancelled connection:
>>
>>
> 04-Jul-2008 08:50:17 com.sun.grizzly.arp.AsyncProcessorTask doTask
> SEVERE: null
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
> at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:69)
> at java.nio.channels.SelectionKey.isWritable(SelectionKey.java:294)
> at test.osr.OSRAsyncFilter.doFilter(OSRAsyncFilter.java:67)
> at
> com.sun.grizzly.arp.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:177)
> at
> com.sun.grizzly.arp.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:155)
> at
> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:94)
> at com.sun.grizzly.http.TaskBase.call(TaskBase.java:359)
> at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
> 04-Jul-2008 08:50:17 com.sun.grizzly.util.WorkerThreadImpl run
> SEVERE: WorkerThreadImpl unexpected exception:
> java.lang.RuntimeException: java.nio.channels.CancelledKeyException
> at
> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:112)
> at com.sun.grizzly.http.TaskBase.call(TaskBase.java:359)
> at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
> Caused by: java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
> at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:69)
> at java.nio.channels.SelectionKey.isWritable(SelectionKey.java:294)
> at test.osr.OSRAsyncFilter.doFilter(OSRAsyncFilter.java:67)
> at
> com.sun.grizzly.arp.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:177)
> at
> com.sun.grizzly.arp.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:155)
> at
> com.sun.grizzly.arp.AsyncProcessorTask.doTask(AsyncProcessorTask.java:94)
> ... 2 more
>
> Can you add the exception?
>
>> This is what I would expect. However, Grizzly seems to be far more stable
>> taking this approach. There were no memory errors running on a 50 user
>> load
>> as above.
>
> Yes, internally Grizzly is recovering (this is what I suspect). Can you
> share your code? If not, send it to me privately and I will take a look.
>
>>
>>
>> Do you have any mnore suggestions as to what is the correct approach for
>> cancelling a connection?
>
> I need more info but Alexey's recommendation might be a good solution
> for this situation, but I do think using the Grizzly APR is a more clean
> solution.
>
> Thanks
>
> -- Jeanfrancois
>
>
>>
>> Thanks
>>
>> --- Mark
>>
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> Oleksiy Stashok wrote:
>>>> Ok.
>>>> Grizzly, by default, doesn't have any resource associated with the
>>>> connection - so it should be safe enough to close connection using
>>>> method:
>>>> SelectionKeyHandler.cancel(SelectionKey)
>>> I would not touch that as the HTTP object will not be recycled and http
>>> response/connection will be in limbo.
>>>
>>>> For sure if you're inside some HTTP processor, there could be some HTTP
>>>> specific way of closing the connection. Jean-Francois can advice better
>>>> here.
>>> Done :-)
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> On Jun 20, 2008, at 15:54 , Mark Hig wrote:
>>>>
>>>>> Yes we are. We are using Grizzly 1.8 http and framework.
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Closing-connections-tp18026485p18030095.html
>>>>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/Closing-connections-tp18026485p18274638.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.