• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Memory leak
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory leak


  • Subject: Re: Memory leak
  • From: Ramsey Gurley <email@hidden>
  • Date: Wed, 23 Jan 2013 11:25:48 -0700

You're probably not going to find this answer on list. You need to debug the leak with jvisualvm.

http://visualvm.java.net/oqlhelp.html

I can tell you that the undo manager is probably not your problem, and setting it to null can cause problems.  Revert a delete and you'll get an IllegalStateException to the tune of:

"Editing context needs an undo manager to recover from delete propagation problems. Do not set the undo manager of this editing context to null"

I finally killed a leak after months of guessing last year in one of our threaded processes here at work. I would have never ever found it without jvisualvm. The thread itself referenced the EC so it was never GC'ed. The reference was not visible anywhere in our code. If I recall correctly, I needed to run the thread in a thread to break the reference by allowing the thread to be GC'ed. That may be your problem too.

Ramsey

On Jan 23, 2013, at 10:29 AM, Sisi Li wrote:

> Dear all,
>
> We have a wonder accounting application that is misbehaving. As part of the application the user processes a large amount of transactions, generating invoices and so on in a single LongResponse Thread.
>
> Here is the code inside the run method of that thread:
>
> public void _run() {
>
> editingContext.setUndoManager(null);
>
> editingContext.lock();
>
> try
>
> {
>
> setup();
>
> createPaymentReceivedAndMadeTransactions();
>
> editingContext.saveChanges();
>
> NSNotificationCenter.defaultCenter().postNotification(Repayment.REPAYMENT_TRANSACTIONS_PAID, accountGID);
>
> }
>
> catch (Exception e)
>
> {
>
> editingContext.revert();
>
> e.printStackTrace();
>
> }
>
> finally
>
> {
>
> editingContext.unlock();
>
> editingContext.dispose();
>
> System.gc();
>
> }
>
> }
>
>
>
>
>
> You will notice the GarbageCollector call in the finally catch. I have checked the advice on this link: https://en.wikibooks.org/wiki/WebObjects/EOF/Using_EOF/Memory_Management#Calling_System.gc.28.29 . I tried multiple solutions to reduce the load but to no avail.
>
> I have profiled the application and there is a tiny memory leak but mostly with repeated processing of payments (one after the other) the GC does not seem to clear the memory fast enough and the application runs into problems.
>
> http://imageshack.us/photo/my-images/841/withgcclear.png/
>
> http://imageshack.us/photo/my-images/145/withoutgcclear.png/
>
>
>
> I would very much like to get your opinions before going to garbage collector for a solution.
>
> Regards,
>
>
>
> Mouradk
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Memory leak (From: Sisi Li <email@hidden>)

  • Prev by Date: Re: jasperreport help please
  • Next by Date: Re: Bug with frameworks as jar and bundless build
  • Previous by thread: Memory leak
  • Next by thread: Re: Memory leak
  • Index(es):
    • Date
    • Thread