[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] [Updated] (AMQ-4495) Improve cursor memory management
From:       "Torsten Mielke (JIRA)" <jira () apache ! org>
Date:       2015-01-29 16:35:36
Message-ID: JIRA.12645235.1367243061000.205927.1422549336120 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/AMQ-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Torsten Mielke updated AMQ-4495:
--------------------------------
    Summary: Improve cursor memory management  (was: Imporve cursor memory \
management)

> Improve cursor memory management
> --------------------------------
> 
> Key: AMQ-4495
> URL: https://issues.apache.org/jira/browse/AMQ-4495
> Project: ActiveMQ
> Issue Type: Bug
> Reporter: Dejan Bosanac
> Assignee: Dejan Bosanac
> Fix For: 5.9.0
> 
> Attachments: FasterDispatchTest.java
> 
> 
> As currently stands, the store queue cursor will cache producer messages until it \
> gets to the 70% (high watermark) of its usage. After that caching stops and \
> messages goes only in store. When consumers comes, messages get dispatched to it, \
> but memory isn't released until they are acked. The problem is with the use case \
> where producer flow control is off and we have a prefetch large enough to get all \
> our messages from the cache. Then, basically the cursor gets empty and as message \
> acks release memory one by one, we go to the store and try to batch one message at \
> the time. You can guess that things start to be really slow at that point.  The \
> solution for this scenario is to wait with batching until we have more space so \
> that store access is optimized. We can do this by adding a new limit (smaller then \
> the high watermark) which will be used as the limit after which we start filling \
> cursor from the store again. All this led us to the following questions:
> 1. Why do we use 70% as the limit (instead of 100%) when we stop caching producer \
> messages? 2. Would a solution that stop caching producer messages at 100% of usage \
> and then start batching messages from the store when usage drops below high \
> watermark value be enough. Of course, high watermark would be configurable, but \
> 100% by default so we don't alter any behavior for regular use cases.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[prev in list] [next in list] [prev in thread] [next in thread]