Azfar: To be frank I do not know. But its possible. I used to get OOM on a variety of geronimo build failures including the ones where the test cases were failing. I do not remember whether they were on these test cases. I did have only 256MB RAM on my new box (where I am testing out the build) and I upgraded it to 1.2GB. For the latest build failures I do not remember seeing OOM, but I have not looked closely enough. One thing is for sure. When I monitor my memory, during the build the memory usage grows from about 230Mb and fills up everything (1.2Gb) and starts using swap. Next time I do a build, I will see whether it does show OOM.
rgds -Hari On Wed, 2004-12-08 at 15:02, Azfar Kazmi wrote: > Hari: do you get OutOfMemory error after those FATALs too? > > I have been getting OOM error after exactly the same FATALs for few > days now - despite multiple fresh-checkouts. > > -Azfar > > > On Wed, 8 Dec 2004 11:41:20 -0800, David Jencks <[EMAIL PROTECTED]> wrote: > > > > On Dec 8, 2004, at 11:27 AM, Hari Kodungallur wrote: > > > > > I did a maven m:co a couple of days back and I do a maven m:update > > > before I build. I did not specifically check whether the two modules > > > (tanql and openejb) are in sync. I assume, m:update gets the latest > > > source for both the modules and that they are in sync. Is that a safe > > > assumption? > > > > yes > > > > > > > > > > There are three tests that fails with FATAL. All of them have the same > > > exception shown below. The tests are in BmpTestSuite, CmpTestSuite and > > > Cmp2TestSuite. > > > > > > 20:56:45,758 FATAL [EjbRequestHandler] Invocation result object is not > > > serializable: org.apache.derby.impl.jdbc.EmbedSQLException > > > java.io.NotSerializableException: > > > org.apache.derby.impl.sql.compile.TableName > > > at > > > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) > > > at > > > java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224) > > > at > > > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050) > > > at > > > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java: > > > 1332) > > > ... > > > ... > > > > very odd -- these usually aren't a problem, they are usually the result > > of trying to delete a non-existent table, and are ignored. The not > > serializable exception is masking the contents of the actual sql > > exception that hopefully explains what is going wrong. Derby has fixed > > this problem, I guess we haven't updated our derby version yet. > > > > I'm not sure what to try next since I don't see the same problem. I'd > > guess the best next step would be to get a more recent derby snapshot > > into the openejb repo and used by the build. This might take a little > > while. > > > > anyone else have an idea? > > > > thanks > > david jencks > > > > > > > > > > > > > > > Thanks > > > -Hari > > > > > > > > > > > > > > > > > > On Wed, 2004-12-08 at 11:04, David Jencks wrote: > > >> A full build worked for me this morning. Are you sure that tranql and > > >> openejb are up to date? > > >> > > >> Which test is failing? > > >> The ejb timer tests are slightly indeterminate and sometimes fail for > > >> me if I'm running a lot of other stuff at the same time as the tests. > > >> > > >> I don't know of any way to disable tests in individual modules. > > >> > > >> thanks > > >> david jencks > > >> On Dec 8, 2004, at 10:57 AM, Hari Kodungallur wrote: > > >> > > >>> Hi All, > > >>> > > >>> Everytime I update and do a complete build it fails on the Junit test > > >>> of > > >>> OpenEJB. The Geronimo build is okay when I specify > > >>> -Dmaven.test.skip=true. Is it a known issue? Or is there something I > > >>> can > > >>> do to fix it or configure it such that it tests every module except > > >>> OpenEJB? > > >>> > > >>> Thanks much! > > >>> -Hari > > >>> > > >> > > > > > > >
