You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Fred Oliver (JIRA)" <ji...@apache.org> on 2007/07/26 23:12:03 UTC
[jira] Created: (RIVER-81) Outrigger could limit the amount of
memory used for entry storage
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.
[jira] Commented: (RIVER-81) Outrigger could limit the amount of
memory used for entry storage
Posted by "Fred Oliver (JIRA)" <ji...@apache.org>.
[ 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.