On Mon, Jun 25, 2012 at 7:00 PM, Rupert Westenthaler <
[email protected]> wrote:

> Hi
>
> I think this change causes current Jenkins build to fail during
> integration tests with
>
> ERROR: Bundle org.apache.felix.scr [181]: EventDispatcher: Error
> during dispatch. (java.lang.OutOfMemoryError: PermGen space)
> java.lang.OutOfMemoryError: PermGen space
>
> Adding
>
> >> > -XX:MaxPermSize=256m vm option.
>
> to the jvm options of the integration tests solves that to me.
> I will commit this change and see if it does make Jenkins happy again.
>
> To further qualify the increase of the memory requirements regarding
> this feature I ran the integration-test several times with and without
> this features.
>
> Results:
>
> With the "zz> shell" bundle list included the average PermGen was about
> 220MByte
> Without this feature PermGen was about 85MByte
>
> Tested by using java VisualVM on Mac JVM 1.6.something.
>
> Can someone else confirm those findings.
>
> If other can confirm this results I suggest to keep this as an optional
> feature that is not enabled by default.
>

Similar here, but given that stanbol needs normally to be started (as per
the recomenation on the website) with 1g of heap space, what's the problem
with increasing PermGenSpace to 256Mb?

Did you happen to see which bundle uses such a lot of PermGenSpace?


Cheers,
Reto


>
> WDYT
> Rupert
>
> On Mon, Jun 25, 2012 at 9:07 AM, Reto Bachmann-Gmür <[email protected]>
> wrote:
> > On Jun 24, 2012 11:13 PM, "Fabian Christ" <[email protected]>
> > wrote:
> >>
> >> Hi,
> >>
> >> cool. So this is something that can be used, e.g. for live debugging
> >> in the console
> >
> > You can interactively play around with the exposed java api and the
> > available services. This can well be used in combination with a debugger
> > allowing to be more quickly at a breakpoint (by calling the service
> method
> > right away, skipping the web request).
> >
> >> and making changes that are directly applied?
> >
> > No, it is by itself not a tool to modify existing code. You could write
> > classes, instantiate them and register them as services all on the
> console.
> > But as these classes are not persitence this is mainly of use for testing
> > purposes.
> >
> >>
> >> Best,
> >>  - Fabian
> >>
> >> 2012/6/22 Reto Bachmann-Gmür <[email protected]>:
> >> > Hi
> >> >
> >> > I've resolved STANBOL-312 and added the ssh accessible and scala based
> >> > clerezza shell to stanbol.
> >> >
> >> > The bad news first: on my machine the additional bundles caused the
> jvm
> > to
> >> > require more permsize than its default, so I hat to launch with the
> >> > -XX:MaxPermSize=256m vm option.
> >> >
> >> > The ssh daemon is listening on port 8022 (this can of course be
> changed
> > via
> >> > service property), to connect to it use:
> >> >
> >> > ssh -p 8022 admin@localhost
> >> >
> >> > the default pwd for the admin user is "admin"
> >> >
> >> > Once connected you have a full scala console with access to the OSGi
> >> > service registry. To get an instance of a service you can use the
> >> > $[<className>] shortcut, for example:
> >> >
> >> > zz>import org.apache.stanbol.enhancer.servicesapi._
> >> > zz>val jm = $[EnhancementJobManager]
> >> >
> >> > jm now point to an EnhancementJobManager instance, you can use the tab
> > key
> >> > to find the methods than can be invoked on an object:
> >> >
> >> > zz>jm.
> >> > asInstanceOf    enhanceContent    getActiveEngines    isInstanceOf
> >> > toString
> >> >
> >> > I hope this is of use.
> >> >
> >> > Reto
> >>
> >>
> >>
> >> --
> >> Fabian
> >> http://twitter.com/fctwitt
>
>
>
> --
> | Rupert Westenthaler             [email protected]
> | Bodenlehenstraße 11                             ++43-699-11108907
> | A-5500 Bischofshofen
>

Reply via email to