[jira] [Resolved] (ARIES-1034) Excessive IO when install subsystems and when initializing the root subsystem

["John Ross (JIRA)" <ji...@apache.org>]

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

John Ross resolved ARIES-1034.
------------------------------

    Resolution: Fixed
      Assignee: John Ross

Patch released with http://svn.apache.org/viewvc?view=revision&revision=1464713.

The patch contained a modification to subsystem-core/pom.xml that pointed to the 1.0.0-SNAPSHOT version of subsystem-api. This was only necessary in order to run a build before subsystem-api 1.0.0 was released and was not included in the commit.

I also changed the visibility of the SaveManifestParticipant static inner class to private and added a protected no-arg constructor to get rid of the synthetic accessor method warning.
                
> Excessive IO when install subsystems and when initializing the root subsystem
> -----------------------------------------------------------------------------
>
>                 Key: ARIES-1034
>                 URL: https://issues.apache.org/jira/browse/ARIES-1034
>             Project: Aries
>          Issue Type: Improvement
>          Components: Subsystem
>            Reporter: Thomas Watson
>            Assignee: John Ross
>         Attachments: org.apache.aries.subsystem.core.patch
>
>
> I noticed this when activating the subsystem.core bundle.  It was taking a long time to start subsystem.core.  A lot of IO is being done to establish the constituents of the root subsystem.  In my particular environment there are about 120 bundles.  All of these bundles end up being constituents of the root subsystem.
> In the call to org.apache.aries.subsystem.core.internal.Subsystems.getRootSubsystem() the deployment manifest for the root subsystem is being rewritten once for each constituent detected and the file content gets progressively larger with each constituent added.  That ends up being 121 times the whole file gets written and the final content of the file ends up being around 14 KB.
> I have two observations:
> 1) a BufferedOutputStream is not used to write the deployment manifest.  Since the file can grow to several KB in size it would be optimal to use a buffered output stream.
> 2) can we avoid writing the persistent deployment manifest until a successful installation is done and then at the end we only write the complete deployment manifest once?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira