[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1664) Unloaded entities returned in low memory conditions

2005-04-08 Thread Arto Huusko (JIRA)
 [ 
http://jira.jboss.com/jira/browse/JBAS-1664?page=comments#action_12316784 ]
 
Arto Huusko commented on JBAS-1664:
---

Yes, sorry, I do mean OutOfMemoryError.

However, if it is true that JVM is unusable after OutOfMemoryError, JBoss 
should be changed to terminate immediately the first time it sees that error. 
And, I'm curious as to why the JVM itself bothers to throw an error, if it 
really is so that application can never do anything to recover.

The fact is that in the face of OutOfMemoryError, the JVM really was 
surprisingly usable and in working state. Our code was able to do some real 
work off and on for hours while also seeing OOMEs -- but also some damage, when 
those BMP beans started misbehaving.

And we had a heavily tweaked configuration: BMP beans with commit option A, 
maximum cache size of 1 instances and maximum memory of 1GB (which, though, 
is a slightly moot point because at the time we were bitten by issue JBAS-1662).

Anyway, I feel very strongly that something should be done about this, even if 
it is that immediate termination of JVM, because otherwise some really bad 
things can happen if there is some other problem (be it in JBoss or 
application) that causes the JVM to run out of memory.

 Unloaded entities returned in low memory conditions
 ---

  Key: JBAS-1664
  URL: http://jira.jboss.com/jira/browse/JBAS-1664
  Project: JBoss Application Server
 Type: Bug
   Components: EJBs
 Versions: JBossAS-3.2.6 Final
 Reporter: Arto Huusko



 In low memory conditions (that is, when OutOfMemoryExceptions are seen 
 frequently all over the place), JBoss can behave wrong in a way that is 
 critically wrong.
 I have seen on several occasions that a finder returns an entity with the 
 correct identity, but where ejbLoad() has either not been called at all, or 
 where ejbLoad() has failed at some point (I have no way of knowing which is 
 the case).
 I have observed this behaviour only with BMP beans (and so there is a 
 possibility that I am doing something wrong in the BMP code, but I doubt 
 this). However, the fact that I haven't seen this with CMP beans may be just 
 because CMP beans work differently, or just plain luck. When this occurs, the 
 wrong behaviour can be seen because the instance variables of the entity bean 
 contain what ever they had when the entity instance was previously attached 
 to some other identity.
 For example, I may store the primary key of the entity in some instance 
 variable. Let's say I can access the primary key via method Long 
 getMyPrimaryKey(). If the finder returns an entity with the correct identity 
 (what I asked for in the finder call), but where ejbLoad() is not called or 
 it fails, then
entity.getMyPrimaryKey().equals(entity.getPrimaryKey())
 is false. And this is exactly what I have seen.
 I have no idea where the problem is, and, as I said above, it may be a 
 problem with my code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1662) Memory leak with SpecCompliant=true in transaction-service.xml

2005-04-05 Thread Arto Huusko (JIRA)
Memory leak with SpecCompliant=true in transaction-service.xml
--

 Key: JBAS-1662
 URL: http://jira.jboss.com/jira/browse/JBAS-1662
 Project: JBoss Application Server
Type: Bug
  Components: Transaction Manager service  
Versions: JBossAS-3.2.6 Final
 Environment: jboss 3.2.6, linux 2.[46], DB2 7.[12]
Reporter: Arto Huusko


If SpecCompliant is set to true in transaction-service.xml, jboss begins to leak
memory on a massive scale: all entity beans (both CMP and BMP) that become 
unused
(that is: they are flushed from cache, and instance pool is full, so they are
discarded) are never garbage collected.

I don't pretend to understand the problem fully (I was in quite a rush to solve
the memory leaks and it still took me over a week). I investigated the matter
with a home-grown memory profiler, and found out that the leak ultimately occurs
in org.jboss.resource.connectionmanager.CachedConnectionManager, which never
releases the KeyConnectionAssociation objects (that are stored in a ThreadLocal
LinkedList).

And since KeyConnectionAssociation also holds a reference to the entity object,
the entity objects leak once they are thrown out of the pool.

And those KeyConnectionAssociation objects are of course created as a result
of the entity beans opening connection to the database.

I never found out why the KeyConnectionAssociation objects were never removed
from the list (which would have resulted in garbage collection of the entity
and all). I just saw somewhere in the code promising references to
SpecCompliant, and thankfully it solved the problem for me.

Note that leakage also occurs (immediately) if JBoss gets an entity from 
instance
pool to run a finder, and the finder throws an exception. In that case, the
entity used to run the finder is leaked immediately (the leakage happens in the
same way as outlined above).


I marked this problem for 3.2.6, but as far as I can see, the problem is the
same in 3.2.7 and 4, too. Maybe priority should really be minor, since I'm
not sure that many people use SpecCompliant.

Oh, and I also have Debug=true in transaction-service, if that makes any
difference.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1663) unsetEntityContext never called

2005-04-05 Thread Arto Huusko (JIRA)
unsetEntityContext never called
---

 Key: JBAS-1663
 URL: http://jira.jboss.com/jira/browse/JBAS-1663
 Project: JBoss Application Server
Type: Bug
  Components: EJBs  
Versions: JBossAS-3.2.6 Final
Reporter: Arto Huusko


When entity instances are discarded, according to EJB 2.1 unsetEntityContext()
should be called (although, for some reason, this is not mentioned in Container
Provider Responsibilities, section 10.5.2 makes it quite clear that bean
providers may rely on unsetEntityContext() being called). As far as I can see
(and have tested slightly), unsetEntityContext() is never called in JBoss.

The problem can be seen in org.jboss.ejb.plugins.AbstractInstancePool.free():
if the pool is full, nothing spectacular is done; the entity instance is simply
left alone, which causes it to be GC at some time.

I believe, this code should be in the method:

// this already is there
if (pool.size()  maxSize)
{
   pool.addFirst(ctx);
}
// add something like this
else
{
   ctx.discard();
}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1664) Unloaded entities returned in low memory conditions

2005-04-05 Thread Arto Huusko (JIRA)
Unloaded entities returned in low memory conditions
---

 Key: JBAS-1664
 URL: http://jira.jboss.com/jira/browse/JBAS-1664
 Project: JBoss Application Server
Type: Bug
  Components: EJBs  
Versions: JBossAS-3.2.6 Final
Reporter: Arto Huusko


In low memory conditions (that is, when OutOfMemoryExceptions are seen 
frequently all over the place), JBoss can behave wrong in a way that is 
critically wrong.

I have seen on several occasions that a finder returns an entity with the 
correct identity, but where ejbLoad() has either not been called at all, or 
where ejbLoad() has failed at some point (I have no way of knowing which is the 
case).

I have observed this behaviour only with BMP beans (and so there is a 
possibility that I am doing something wrong in the BMP code, but I doubt this). 
However, the fact that I haven't seen this with CMP beans may be just because 
CMP beans work differently, or just plain luck. When this occurs, the wrong 
behaviour can be seen because the instance variables of the entity bean contain 
what ever they had when the entity instance was previously attached to some 
other identity.

For example, I may store the primary key of the entity in some instance 
variable. Let's say I can access the primary key via method Long 
getMyPrimaryKey(). If the finder returns an entity with the correct identity 
(what I asked for in the finder call), but where ejbLoad() is not called or it 
fails, then

   entity.getMyPrimaryKey().equals(entity.getPrimaryKey())

is false. And this is exactly what I have seen.

I have no idea where the problem is, and, as I said above, it may be a problem 
with my code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development