river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fred Oliver (JIRA)" <j...@apache.org>
Subject [jira] Commented: (RIVER-81) Outrigger could limit the amount of memory used for entry storage
Date Thu, 26 Jul 2007 21:14:03 GMT

    [ https://issues.apache.org/jira/browse/RIVER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515870
] 

Fred Oliver commented on RIVER-81:
----------------------------------

Requires either that we add methods to MarsahlledInstance so we can
find out how big the byte arrays inside are, or that we break wire and
store compatibility so we can switch to a clone of MarsahlledInstance
where we have added those methods (which might be a reasonable long
term investment....)

> Outrigger could limit the amount of memory used for entry storage
> -----------------------------------------------------------------
>
>                 Key: RIVER-81
>                 URL: https://issues.apache.org/jira/browse/RIVER-81
>             Project: River
>          Issue Type: Improvement
>          Components: com_sun_jini_outrigger
>    Affects Versions: jtsk_1.1
>            Reporter: Fred Oliver
>            Priority: Minor
>
> Bugtraq ID [5022708|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5022708]
> Outrigger does not protect itself against client attempts to put too
> many entries in the space. There may be a fairly straight forward fix
> we could put in that would address most of this issue. Most of
> Outrigger's memory usage is tied up in the byte arrays that encode the
> fields of the Entries in the space. A reasonable estimate of
> Outrigger's memory usage would be the sum of the lengths of these
> arrays. We could keep a running total of these lengths (adding when
> entries are written and subtracting when entries are taken or expired)
> and reject writes when the total reaches some configurable limit, and
> then start allowing writes again when the total drops bellow some
> other (configurable) value. This would not solve the complete problem
> but may very well make it manageable. For example, Outrigger would
> still be vulnerable to various semi-pathological cases of very large
> entries / templates being sent to the space (which could cause a
> OutOfMemoryError during unmarshalling before we could update and check
> the running total). The running total would only be related to total
> memory use, not a direct stand-in so experimentation would still be
> necessary to get the limit right relative to the heap size.

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


Mime
View raw message