Jeff,
Although you are hitting an OOME, it doesn't sound like you are hitting the
same problem as originally reported by OPENJPA-258. It sounds like
different scenarios that end up with the same OOME result.
Anyway, I'm curious about the use of the Sun JDK. So, while attempting to
enhance your classes using the PCEnhancer, you are hitting the OOME? If
the problem exists with the Sun JDK, we might get more involvement from
other participants in this forum. (The IBM JDK is not as widely used. I've
been about the only person that drives IBM JDK related problems.)
If the problem exists with running the PCEnhancer on your set of entities,
then you could turn on tracing for that aspect of your build. We could see
what entities are being processed when it fails and maybe narrow in on the
culprit. The property for tracing is like this:
<property name="openjpa.Log" value="DefaultLevel=TRACE" />
This will produce a lot of output, but since it would be limited to the
PCEnhancement step, it should be containable.
Thanks,
Kevin
On Tue, Mar 4, 2008 at 1:35 PM, Jeff Melching <[EMAIL PROTECTED]> wrote:
>
> I guess when I same same problem I mean it displays the same symptoms as
> what were exhibited under 1.0.1 with sun jdk and the test case attached to
> original jira item. I tried the original jira item using 1.0.2 on both
> sun and ibm's jdks and that specific test case works. My application
> produces an eventual OutOfMemory Exception listed below from a javacore, and
> as mentioned in the bug the loop runs forever. Not sure how I can reproduce
> the exact situation to cause this to occur in a sample use case.
>
> 3XMTHREADINFO "http-8080-Processor23" (TID:0x93E39600,
> sys_thread_t:0x93E36650, state:R, native ID:0x000054FE) prio=5
> 4XESTACKTRACE at java/util/ArrayList.ensureCapacity(
> ArrayList.java:195(Compiled Code))
> 4XESTACKTRACE at java/util/ArrayList.add(ArrayList.java:377(Compiled
> Code))
> 4XESTACKTRACE at
> org/apache/openjpa/meta/MetaDataRepository.processBuffer(
> MetaDataRepository.java:676(Compiled Code))
> 4XESTACKTRACE at
> org/apache/openjpa/meta/MetaDataRepository.resolveMeta(
> MetaDataRepository.java:575(Compiled Code))
> 4XESTACKTRACE at
> org/apache/openjpa/meta/MetaDataRepository.resolve(MetaDataRepository.java:500(Compiled
> Code))
> 4XESTACKTRACE at
> org/apache/openjpa/meta/MetaDataRepository.getMetaData(
> MetaDataRepository.java:302(Compiled Code))
> 4XESTACKTRACE at org/apache/openjpa/kernel/BrokerImpl.persist(
> BrokerImpl.java:2372)
> 4XESTACKTRACE at org/apache/openjpa/kernel/BrokerImpl.persist(
> BrokerImpl.java:2225)
> 4XESTACKTRACE at
> org/apache/openjpa/kernel/DelegatingBroker.persist(DelegatingBroker.java
> :1005)
> 4XESTACKTRACE at
> org/apache/openjpa/persistence/EntityManagerImpl.persist(
> EntityManagerImpl.java:541)
> ...
>
> Now as far as differences in jvm's I tried with both sun and ibm.
>
> Sun: Couldn't even run the enhancer ant script I had setup as it ran out
> of memory in the same spot.
> IBM: able to enhance the entities, but OOME at runtime as above.
>
> Any suggestions on what you need to help diagnose as far as object
> relationships,etc. and I will try to provide. But as my application contains
> a very large number of entities it is hard to tell which relationship is
> causing the issue. So
>
>
>
> *Re: Bug 258 revisited*
> *Kevin Sutter * to: users 03/04/2008 12:15 PM
>
> *Please respond to users*
>
>
>
> ------------------------------
>
>
>
> Jeff,
> What aspect of OPENJPA-258 are you experiencing? The OOME? Does your
> scenario mimic the scenario in 258, or something similar? Or, is there
> some
> other aspect of 258 that you are referring to?
>
> It's interesting that the scenario described in 258 was not resolved until
> 1.0.2. And, since you just moved to 1.0.2 and are now experiencing the
> "same problem" that was supposedly fixed in 1.0.2, then I wonder whether
> we
> are talking about the same problem.
>
> You mention the IBM JDK. Are you indicating that the problem does not
> surface with the Sun JDK? That should be a relatively simple
> verification.
> I switch back and forth between the IBM and Sun JDK's all the time.
>
> If you can provide more details on the specific problem and environment
> for
> your scenario, then we can hopefully help narrow down the problem and get
> it
> resolved. Thanks.
>
> Kevin
>
> On Tue, Mar 4, 2008 at 11:42 AM, Jeff Melching <[EMAIL PROTECTED]> wrote:
>
> > I tried to upgrade my application to the 1.0.2 release from 1.0.1 and I
> am
> > now seeing the exact behavior listed in
> > https://issues.apache.org/jira/browse/OPENJPA-258.
> >
> > I am however using an ibm jvm not sun. I ran the main method from the
> > sample attached to the jira item using 1.0.2 and my ibm jvm and received
> > matching behavior to my application. Could we get this fixed for ibm's
> > jvm as well?
> >
> > I tried 2 different ibm jvm's.
> >
> > java version "1.5.0"
> >
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> > pxi32devifx-20070806 (SR5a))
> >
> > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32
> > j9vmxi3223-20070426 (JIT enabled)
> >
> > J9VM - 20070420_12448_lHdSMR
> >
> > JIT - 20070419_1806_r8
> >
> > GC - 200704_19)
> >
> > JCL - 20070725
> >
> > java version "1.5.0"
> >
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> > pxi32devifx-20071025a (SR6b))
> >
> > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32
> > j9vmxi3223-20071005 (JIT enabled)
> >
> > J9VM - 20071004_14218_lHdSMR
> >
> > JIT - 20070820_1846ifx1_r8
> >
> > GC - 200708_10)
> >
> > JCL - 20071025
> >
> >
> >
> >
>
>
