You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2009/01/15 17:51:02 UTC

[jira] Commented: (QPID-396) Broker OutOfMemory Error handling

    [ https://issues.apache.org/jira/browse/QPID-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664167#action_12664167 ] 

Marnie McCormack commented on QPID-396:
---------------------------------------

We should not be attempting to perform any elegant client interaction on broker OOM. But we should go bang immediately on the broker side. Inherent in OOM scenarios is that you cannot (should never) assume there's enough memory to do anything else. We need to look at what (if anything) we need to do to encourage a clean store shutdown though.

> Broker OutOfMemory Error handling
> ---------------------------------
>
>                 Key: QPID-396
>                 URL: https://issues.apache.org/jira/browse/QPID-396
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: M1, M2
>            Reporter: Martin Ritchie
>            Assignee: Martin Ritchie
>
> When the broker runs out of memory the response to the client can be unpredicatable. 
> If this is something that you believe may occur currently the best thing to do is to ensure that you are not hammering the broker with data. A slight pause between message sending should allow the broker time to throw the OutOfMemory Error during the handling of one of the methods rather than at the mina level when receiving the data. 
> This should allow the broker to write a ConnectionClose frame back to the client. We could signal here that we are out of memory and stop listening for new connectons that will cause further OoM Errors.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.