Book a Demo

Author Topic: Memory issue with Java API and models over 200 MB?  (Read 6176 times)

kosh.iii

  • EA Novice
  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Memory issue with Java API and models over 200 MB?
« on: February 08, 2012, 04:20:18 am »
I am generating a quite big model using the Java API (eaapi.jar + SSJavaCOM.dll) and it seems I reached some kind of limit recently. During the creation process there comes a point where I add some element, diagram or put something into a collection (e.g. addind something to a package or diagram) and then the returned object is null for no obvious reason.

There is no specific place in the code where this happens. When I limit the number of elements used in the model the problem appears a bit later in the process. Limiting the elements further results in the model being created without problems.

As I see it, my model has crossed some "point of no return", where EA cannot handle adding more elements due to some memory problem.

Has anyone else experienced something like that? I'm glad for any kind of idea on how to further analyze or - even better - circumvent this problem.

Thanks a lot!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: Memory issue with Java API and models over 200
« Reply #1 on: February 08, 2012, 08:40:45 am »
From the readme for the java API.

2. Due to the nature of Java interacting with native methods and COM, garbage collection is not optimal. Native COM classes and memory allocated for these is not seen by the Java garbage collector, so you should explicitly invoke a garbage collection from time to time when working with many objects using the Java API. This will ensure native memory is freed in a timely fashion.

kosh.iii

  • EA Novice
  • *
  • Posts: 15
  • Karma: +0/-0
    • View Profile
Re: Memory issue with Java API and models over 200
« Reply #2 on: February 08, 2012, 09:09:34 am »
Yeah, yeah, I know that part. I am pretty sure it is not my JVM that runs into memory problems, because it has 1 GB of RAM explicitly assigned and doesn't neraly use all of it. Furthermore Java processes runnig low on memory tend to die with an OutOfMemoryError instead of just behaving strangely.

The behavior I get from the program is, that a newly created UML element is not returned via the Java API as happend successfully 1000 times before during the program. Instead null is returned. The UML element creation in the Java API happens via a rather dull COM-Wrapper call to the underlying DLL, and I strongly suppose that the DLL already doesn't return anything, because the EA process running invisibly has memory problems.

I hope I made my problem clear enough for you to look into it? If not, please let me know. I'm really running out of options here, because I already wrapped the whole Java API into an own API which caches as much as possible in order to avoid unnecessary COM-Wrapper calls... :(

RoyC

  • EA Administrator
  • EA Practitioner
  • *****
  • Posts: 1297
  • Karma: +21/-4
  • Read The Help!
    • View Profile
Re: Memory issue with Java API and models over 200
« Reply #3 on: February 08, 2012, 09:58:34 am »
Some of us provide ad hoc comments on this user forum that (we hope) help people with difficulties they might have. But this isn't the channel for support requests. If you want a Sparx employee to look into a problem, please submit a bug report to Sparx Support, using the link in the Support column at the foot of the screen. Thanks!
« Last Edit: February 08, 2012, 09:59:03 am by RoyC »
Best Regards, Roy

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: Memory issue with Java API and models over 200
« Reply #4 on: February 09, 2012, 08:19:13 am »
No. It's not directly the JVM, Java is holds references to native objects and knows nothing about the memory allocated for those. So even when it's running out of memory it thinks it doesn't need to do garbage collection.

Having said that, I have no idea what your wrapper is doing, and I wouldn't be able to debug it for you.