You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by ahgittin <gi...@git.apache.org> on 2017/04/25 13:12:16 UTC

[GitHub] brooklyn-server pull request #649: Reuse embedded OSGi container in tests

GitHub user ahgittin opened a pull request:

    https://github.com/apache/brooklyn-server/pull/649

    Reuse embedded OSGi container in tests

    This speeds up build time from 17m to 11m on my machine by reusing OSGi framework containers where possible.  That also fixes an OSGi container which is causing lots of build failures on Jenkins.
    
    See the last commit which is the only thing new, and the `OsgiManager` class is the main significant difference in that.  Other things are just wiring to control bundle reuse or not.
    
    This includes #645 and #647 so if this build passes we can assume the failures in those PR's are ignorable (they seem to be due to memory leaks).  But merge those before merging this (and I can rebase this if needed once they are merged.)
    
    /cc @neykov @aledsage @geomacy 

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/ahgittin/brooklyn-server persist-plus

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/649.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #649
    
----
commit fbe99f1f814c3442f7ffec644d1d1eea023ceef6
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-19T18:11:56Z

    bulk of structural additions to support persisting osgi bundles
    
    not yet actually writing or reading bundle zip data, nor installing them, but saving metadata, and clear now where to add the binary zip data

commit e8b5fd053cd4434c66b63c9124d7aa0ef9cb1237
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-20T16:01:01Z

    osgi bundle persistence code written ... but not yet tested.
    need to write unit test for persistence, and do manual test against S3 or similar.
    
    then the fun stuff, CLI push and upgrade workflow, bundles used in search path instead of catalog item id, bundles managed in REST/UI

commit abd0cb8bf79457396036d870d9f3ba3c41e6aa80
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-21T10:52:02Z

    done the basics, bundle persistence working and with a test
    
    note `PersistenceObjectStore` for accessing blob store impls have been changed to handle byte streams better.
    also comments on managementPlaneId updated and more logging around it, as i was getting confused debugging this.

commit 340e036d78ed3c55317c5d38bf3d2cc9791d6b0b
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-21T23:05:32Z

    Merge branch 'master' into persist-osgi-bundles

commit cee8e1eed5b069dee62462e5be0d4785502328ba
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-21T23:05:41Z

    minor comments, tidy, and logging

commit c9fd07703b7d072da2508e740be229ed7eb1e41f
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-24T14:17:46Z

    don't use the deprecated method when given json input

commit 99dfb6f98837dd04c7a18a5767c8537af9e3b949
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-24T14:19:53Z

    use bundle metadata from BOM file

commit 3097bb985e7a5a158acd6a4d0215e56008273498
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-24T15:46:23Z

    call it `bundles/` in the persisted space, not `bundle/`

commit 950d8f962c5f635d8a5604e52a910e4e3b6c5f43
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-24T14:21:16Z

    better logging of REST exceptions
    
    include the trace on the first encounter of a new type or simply a new place where a type is thrown from;
    subsequent instances won't get the trace but handy when debugging if the first one does

commit aba02c4a31f74e5603e2f77638f20717cc2a9d1b
Author: Alex Heneveld <al...@cloudsoftcorp.com>
Date:   2017-04-25T12:24:02Z

    allow reuse of embedded osgi framework (speed up tests and reduce memory)
    
    primary change is in OsgiManager, to leave frameworks running
    
    build times including test reduced from 17m to 11m on my box,
    saving 6m in CAMP (from 7m to 1m)!
    
    have done some assertions that starting a framework takes 200ms each time,
    plus it leaks a couple MB, so it's a bad idea to bake this in to our unit tests.
    (see comments in new OsgiTestingLeaksAndSpeedTest for full details.)
    
    have also "confirmed" that reusing a running framework has no adverse impact,
    after we remove bundles that a test installs (all tests pass in reusable mode
    except a few which asserted the cache dir is deleted (as it no longer is)
    and these still pass in non-reusable mode)

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server pull request #649: Reuse embedded OSGi container in tests

Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:

    https://github.com/apache/brooklyn-server/pull/649


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] brooklyn-server issue #649: Reuse embedded OSGi container in tests

Posted by geomacy <gi...@git.apache.org>.
Github user geomacy commented on the issue:

    https://github.com/apache/brooklyn-server/pull/649
  
    This all looks good to me; tests all pass, with speedup (just for brooklyn-server build) on my machine from 12:20 min to 09:05 min.
    
    Will merge.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---