Re: Outrigger memory leak?

Hmmm, seems odd - not sure why your test client would result in OoMEs. I
assume your entry is just a Uuid and a byte[]?

Given your access patters I think it makes sense that change the
reapingInternal or Priority didn't have any effect. The takes your are
doing should have the save the same effect as the reaping thread.

Random thought - Java will throw OoME for other conditions besides
running out of memory, it could have memory but no block is big enough
to satisfy the requested allocation, it could be out of threads (seems
unlikely that would be the case here though). Don't suppose there is any
sort of useful stack trace from the OoME?

What was the smallest payload size you tried? 250KB seems a bit large (I
may just be showing my age - when I was your age all we had was 128
bytes, and WE LIKED IT...) I could imagine the GC is getting into some
odd state, when you let it sit idle for a short time how long would you
wait? Was the waiting between testSpace calls or the between the write
and take?

Greg Trasuk wrote:
> Hi all:
>
>         I'm running up against out-of-memory errors using transient outrigger.
> I got the errors in a production system that runs a fair bit of data
> through the space, then wrote a test script to try and isolate the
> problem (code attached below).  When running with max heap size at the
> default (512M, I believe), the Outrigger instance runs out of heap after
> about 2100 iterations with a payload size of 250e3 bytes.  With smaller
> payloads, I get more iterations (although curiously not in any kind of
> linear relationship.  hmmm...), but I still get the failure eventually.
>
>         Note that the test case verifies that the entry is gone after I 'take'
> it.  I've also confirmed in other tests that it disappears on its own
> when the lease time expires, so everything seems to be behaving as
> expected.  Letting the space sit idle for a short time between accesses
> also has no effect (I wondered if perhaps the reaping thread didn't get
> a chance to run).  I've tried setting 'reapingInterval=5000;
> reapingPriority=Thread.MAX_PRIORITY', which had no effect.
>
>         Am I missing something in the configuration?  The problem is
> independent of whether Outrigger is run under Harvester or from the
> Launch-All script in the starter kit.  I haven't found any other bug
> reports, and I find it hard to believe I've found a bug in a mature
> product.  Any suggestions?
>
> Thanks in advance,
>
> Greg.
>
> Environment details:
> --------------------
> JSK 2.1
> JDK 1.5.0_09 Server VM on Solaris 10 (same issue on Windows XP running
> JDK6)
> Opteron 165 Processor (dual-core), 2GB physical memory
>
> Test Case (run in a different VM from Outrigger):
> -------------------------------------------------
> public class TestSpace extends TestCase {
>
>     private static final int PAYLOAD_SIZE=250000;
>
>     /** Creates a new instance of TestSpace */
>     public TestSpace(String s) {
>         super(s);
>     }
>
>     private ApplicationContext applicationContext=null;
>     private JavaSpace space=null;
>
>     public void setUp() {
>         setApplicationContext(StaticApplicationContext.getContext());
>     }
>
>     /** We should be able to create an entry, drop it in and retrieve
> it. */
>     public void testSpace() throws Exception {
>         DynamicResolver resolver=new DynamicResolver(this);
>         try {
>
>             resolver.resolve();
>             assertTrue("No JavaSpace was found", getSpace()!= null);
>
>             SampleEntry entry = new SampleEntry();
>             entry.uuid=UuidFactory.generate();
>             byte[] payload=new byte[PAYLOAD_SIZE];
>             entry.payload=payload;
>
>             getSpace().write(entry, null, 5000);
>             entry.payload=null;
>
>             SampleEntry retrievedEntry=(SampleEntry)
> getSpace().takeIfExists(entry, null, JavaSpace.NO_WAIT);
>             assertTrue("Didn't get my entry back",
> retrievedEntry!=null);
>             assertTrue("Didn't get the payload back",
> retrievedEntry.payload!=null);
>             byte[] retrievedPayload=(byte[]) retrievedEntry.payload;
>             assertTrue("Payload size wasn't right.",
> retrievedPayload.length==payload.length);
>             /* Once we have retrieved it, it should not be retrievable
> again. */
>             retrievedEntry=(SampleEntry) getSpace().takeIfExists(entry,
> null, JavaSpace.NO_WAIT);
>             assertTrue("Entry was still there after I took it",
> retrievedEntry==null);
>         } catch(RuntimeException ex) {
>             resolver.fail();
>             throw ex;
>         } catch(Exception t) {
>             resolver.fail();
>             throw t;
>         } finally {
>             resolver.clear();
>         }
>     }
>
>     public void testSpaceALot() throws Exception {
>         int i=0;
>         try {
>             for(i=0; i <5000; i++) {
>                 testSpace();
>             }
>         } catch(Exception ex) {
>             fail("Exception " + ex.getMessage() + " at " + i + "
> iterations and payload size=" + PAYLOAD_SIZE+ ".");
>         }
>     }
>
>     public ApplicationContext getApplicationContext() {
>         return applicationContext;
>     }
>
>     public void setApplicationContext(ApplicationContext
> applicationContext) {
>         this.applicationContext = applicationContext;
>     }
>
>     public JavaSpace getSpace() {
>         return space;
>     }
>
>     public void setSpace(JavaSpace space) {
>         this.space = space;
>     }
> }
> --
> Greg Trasuk, President
> StratusCom Manufacturing Systems Inc. - We use information technology to
> solve business problems on your plant floor.
> http://stratuscom.com


--
BTW, if you want to reply to this message, please direct your reply
to the list, thanks

John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

         - David Brooks

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html