[
https://jira.duraspace.org/browse/DS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=23100#comment-23100
]
Andrea Schweer commented on DS-1070:
------------------------------------
This issue was discussed in the developer meeting on 16 Nov 2011:
[20:49] <aschweer> https://jira.duraspace.org/browse/DS-1070 would be good to
get some eyes on
[20:49] <kompewter> [ https://jira.duraspace.org/browse/DS-1070 ] - [#DS-1070]
DSpaceObjectManager unnecessarily keeps references to DSpace objects -
DuraSpace JIRA
[20:49] <kompewter> [ [#DS-1070] DSpaceObjectManager unnecessarily keeps
references to DSpace objects - DuraSpace JIRA ] -
https://jira.duraspace.org/browse/DS-1070
[20:50] <tdonohue> I had no other topics, so discussion of Ds-1070 sounds good
to me
[20:50] <aschweer> it seems to have fixed the problem for us, but we've been
having some other issues (most likely unrelated), so it'd be great to have
others look at it
[20:50] <aschweer> essentially, Ds-1070 made 1.7.2 pretty much unuseable for
us. the problem is still in trunk, so it's in 1.8 as well
[20:51] <tdonohue> aschweer -- I admit I haven't looked at this in much detail,
but it looks reasonable to me at a glance (as long as it doesn't cause major
performance areas elsewhere?). Though I personally don't understand why that
ArrayList was there in the first place
[20:51] <KevinVdV> *Adds Ds-1070 to his long TODO list*
[20:52] <aschweer> tdonohue: I don't understand it either, which is why I think
it's fine to just kick it out
[20:52] <tdonohue> I meant to say "major performance issues elsewhere"
[20:52] <PeterDietz> is there any reason why these objects get added to an
arrayList?
[20:52] <aschweer> I think it's probably left over from refactoring
[20:52] <aschweer> or something
[20:52] <kshepherd> +1 to this patch, it's beautiful
[20:52] <aschweer> it's been in the code ever since xmlui was released as a
standard dspace module
[20:52] <kshepherd> we have only tested for a few days so far
[20:53] <kshepherd> but results are looking *very* good, in terms of memory
footprint
[20:53] <tdonohue> no idea, PeterDietz. Anyone know why this is? Maybe someone
who helped build XMLUI in the first place (ahem, scottatm) would know or have
an idea?
[20:53] <aschweer> I have some scary before/after heap usage graphs if anyone
is interested...
[20:53] <scottatm> What's the question?
[20:53] <mhwood> So what does DSpaceObjectManager *do*, after the patch?
[20:53] <aschweer> thanks kshepherd
[20:53] <tdonohue> scottatm: DS-1070 -- any idea why all these objects are
cached in an ArrayList?
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-1070 ] - [#DS-1070]
DSpaceObjectManager unnecessarily keeps references to DSpace objects -
DuraSpace JIRA
[20:55] <tdonohue> scottam -- as noted in ticket & discussion above, this seems
to cause XMLUI to have a large memory footprint, and aschweer & others wonder
if we can just remove that caching altogether
[20:55] <scottatm> I believe that array is left over from previous version of
DRI where objects were included inline with the document.
[20:56] <KevinVdV> +1 to the patch after looking into it
[20:56] <tdonohue> aha. thanks scottatm! So, it likely is an artifact of some
refactoring/reworking
[20:56] <aschweer> scottatm: I suspected something like that. So you think my
patch is fine?
[20:56] <scottatm> Yes, it's definitaly left over after refactoring.
[20:56] <scottatm> yes.
[20:56] <tdonohue> I'd say assuming this is been well tested, then +1 to the
patch (and it may be a good reason to release a 1.8.1 in near future)
[20:56] <mhwood> Eww, in the copy I am looking at I see a bug: "handel.prefix"
[20:56] <scottatm> It quite litteraly dosn't do anything with the array.
[20:57] <PeterDietz> you can also remove the throws WingException
[20:57] <aschweer> tdonohue: yes, I'd wondered about a 1.8.1 for this
[20:57] <tdonohue> yea, I think this would be a good reason for a 1.8.1
[20:57] <aschweer> ok so I'll apply the patch to trunk and the 1.8 branch, and
also look at the things mhwood and PeterDietz mentioned just now while I'm at
it?
[20:57] <tdonohue> +1
[20:58] <mhwood> getRepositoryURL calls ConfigurationManager to get the prefix,
while getAllManagedRepositories callse HandleManager.getPrefix() which is
probably better.
[20:59] <aschweer> great, thanks everyone who had a look, and especially
scottatm for your comments
[20:59] <tdonohue> I'll add a "1.8.1" version to JIRA shortly and schedule this
for 1.8.1. I personally wouldn't want to wait for a year to get this big fix out
> DSpaceObjectManager unnecessarily keeps references to DSpace objects
> --------------------------------------------------------------------
>
> Key: DS-1070
> URL: https://jira.duraspace.org/browse/DS-1070
> Project: DSpace
> Issue Type: Bug
> Components: XMLUI
> Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1,
> 1.7.2, 1.8.0
> Reporter: Andrea Schweer
> Assignee: Andrea Schweer
> Priority: Major
> Fix For: 1.8.1
>
> Attachments: objectmanager.patch
>
>
> DSpaceObjectManager keeps an ArrayList with a reference to every DSpaceObject
> instance it encounters. The DSpaceObject instances aren't used for anything
> but take up heap memory. The effect is particularly noticeable with Discovery
> enabled because several Discovery components each have their own copy of
> DSpaceObjectManager.
> The attached patch removes the ArrayList (and tidies up the code slightly).
> On a test instance, applying this patch brought down heap usage from 600 MB
> down to 70 MB (heap size measured a few minutes after starting up DSpace,
> with comparable activity).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel