Problems at runtime

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems at runtime

romje

Hi all,

we are using some Aries modules inside our application (deployed as 150 bundles at runtime) :

- Aries JTA/JPA

- Aries Async

- Aries Subsystems


At runtime we encounter OutOfMemoryException and the dumps show a strange context:

  • 88000 instances of Classloaders
  • 88000 instances of PermissionDomain (ok for the 1 -1 cardinality)
  • 896 instances of java.lang.Package[] (I expected 88000 approximately)
  • a huge number of Async instances

I would like to know if this context could be explained by some kind of bug inside Aries .

I just can imagine one scenario like this:

  • trying to load a bundle
  • error
  • retry (several times)

Logging on our application is horrible so I just get useless traces..


We have seen sometimes erratic behaviour  with bundle resolution very long (40 minutes before succeeding). I suspect some problems with bundle wiring but don't  have many clues.


Did you ever seen such things happen ? Is it a known issue with previous Aries versions (our bundles are not so old , may be 2 or 3  months old).

Kind regards

jerome

PS:

excuse me I can't be really accurate because of the logging and because of legal aspects...

Reply | Threaded
Open this post in threaded view
|

Re: Problems at runtime

John Ross
Make sure you're using the latest released version of Subsystems (2.0.8). Also, be sure you are using the latest release of the Apache Felix Resolver (1.8.0 according to http://felix.apache.org/downloads.cgi).

On Sat, Jun 11, 2016 at 5:26 AM, romje <[hidden email]> wrote:

Hi all,

we are using some Aries modules inside our application (deployed as 150 bundles at runtime) :

- Aries JTA/JPA

- Aries Async

- Aries Subsystems


At runtime we encounter OutOfMemoryException and the dumps show a strange context:

  • 88000 instances of Classloaders
  • 88000 instances of PermissionDomain (ok for the 1 -1 cardinality)
  • 896 instances of java.lang.Package[] (I expected 88000 approximately)
  • a huge number of Async instances

I would like to know if this context could be explained by some kind of bug inside Aries .

I just can imagine one scenario like this:

  • trying to load a bundle
  • error
  • retry (several times)

Logging on our application is horrible so I just get useless traces..


We have seen sometimes erratic behaviour  with bundle resolution very long (40 minutes before succeeding). I suspect some problems with bundle wiring but don't  have many clues.


Did you ever seen such things happen ? Is it a known issue with previous Aries versions (our bundles are not so old , may be 2 or 3  months old).

Kind regards

jerome

PS:

excuse me I can't be really accurate because of the logging and because of legal aspects...


Reply | Threaded
Open this post in threaded view
|

Re: Problems at runtime

romje

Thanks for your help John.

We are using the latest Subsystems version (I am sure) but I am not sure for the felix resolver.

Thanks again

regards

PS:

did you ever see such strange behaviour?


Le 13/06/2016 à 19:46, John Ross a écrit :
Make sure you're using the latest released version of Subsystems (2.0.8). Also, be sure you are using the latest release of the Apache Felix Resolver (1.8.0 according to http://felix.apache.org/downloads.cgi).

On Sat, Jun 11, 2016 at 5:26 AM, romje <[hidden email]> wrote:

Hi all,

we are using some Aries modules inside our application (deployed as 150 bundles at runtime) :

- Aries JTA/JPA

- Aries Async

- Aries Subsystems


At runtime we encounter OutOfMemoryException and the dumps show a strange context:

  • 88000 instances of Classloaders
  • 88000 instances of PermissionDomain (ok for the 1 -1 cardinality)
  • 896 instances of java.lang.Package[] (I expected 88000 approximately)
  • a huge number of Async instances

I would like to know if this context could be explained by some kind of bug inside Aries .

I just can imagine one scenario like this:

  • trying to load a bundle
  • error
  • retry (several times)

Logging on our application is horrible so I just get useless traces..


We have seen sometimes erratic behaviour  with bundle resolution very long (40 minutes before succeeding). I suspect some problems with bundle wiring but don't  have many clues.


Did you ever seen such things happen ? Is it a known issue with previous Aries versions (our bundles are not so old , may be 2 or 3  months old).

Kind regards

jerome

PS:

excuse me I can't be really accurate because of the logging and because of legal aspects...



Reply | Threaded
Open this post in threaded view
|

Re: Problems at runtime

John Ross
OutOfMemory errors are known to occur on older versions of the resolver if you have large applications. Note that using a newer resolver version may equate to using a newer version of the framework. I don't know whether or not Felix packages the resolver as part of the framework, but Equinox does. If you're using the latter you want to be using Mars at least, and ideally Neon when it is shortly released.

On Wed, Jun 15, 2016 at 7:54 AM, deadbrain <[hidden email]> wrote:

Thanks for your help John.

We are using the latest Subsystems version (I am sure) but I am not sure for the felix resolver.

Thanks again

regards

PS:

did you ever see such strange behaviour?


Le 13/06/2016 à 19:46, John Ross a écrit :
Make sure you're using the latest released version of Subsystems (2.0.8). Also, be sure you are using the latest release of the Apache Felix Resolver (1.8.0 according to http://felix.apache.org/downloads.cgi).

On Sat, Jun 11, 2016 at 5:26 AM, romje <[hidden email]> wrote:

Hi all,

we are using some Aries modules inside our application (deployed as 150 bundles at runtime) :

- Aries JTA/JPA

- Aries Async

- Aries Subsystems


At runtime we encounter OutOfMemoryException and the dumps show a strange context:

  • 88000 instances of Classloaders
  • 88000 instances of PermissionDomain (ok for the 1 -1 cardinality)
  • 896 instances of java.lang.Package[] (I expected 88000 approximately)
  • a huge number of Async instances

I would like to know if this context could be explained by some kind of bug inside Aries .

I just can imagine one scenario like this:

  • trying to load a bundle
  • error
  • retry (several times)

Logging on our application is horrible so I just get useless traces..


We have seen sometimes erratic behaviour  with bundle resolution very long (40 minutes before succeeding). I suspect some problems with bundle wiring but don't  have many clues.


Did you ever seen such things happen ? Is it a known issue with previous Aries versions (our bundles are not so old , may be 2 or 3  months old).

Kind regards

jerome

PS:

excuse me I can't be really accurate because of the logging and because of legal aspects...